---

This multipart blog series is focused on the real-world lessons learned while securing Microsoft Entra ID. Based on hands-on experience across various environments and organizations, we’ll explore the practical, high-impact strategies that work and more importantly, the common misconfigurations, overlooked settings, and pitfalls that can expose your identity perimeter.

Throughout the series, we’ll cover both foundational and advanced topics: from hardening your hybrid identity configuration, to addressing Conditional Access misconfigurations, securing Privileged Access assignments, and much more.

To start, we’ll align on what “securing Entra ID” really means. This includes understanding the threat model behind identity-based attacks, what Microsoft provides out-of-the-box, and where gaps or misconfigurations often exist, even in mature environments.

What is Entra ID and why do adversaries target it?

Microsoft Entra ID is a product family name for Microsoft’s identity and access management solutions. It is not a replacement for Active Directory but rather a cloud-based identity and access management service that enables employees to securely access resources. These resources include Microsoft 365, the Azure Portal, SaaS applications, and even on-premises applications.

Attackers target identity as the first layer of defense, using methods like phishing, token theft, or exploiting misconfigured Conditional Access. Once they compromise identity, they can access the environment and employ techniques like lateral movement and privilege escalation to expand their foothold.

In the screenshot below we will see an overview of an attack process:

In a typical attack process, it often begins with a phishing email, where the attacker creates a message aimed at tricking the recipient into clicking on a malicious link. Once the victim clicks on that link, credential theft occurs, allowing the attacker to harvest usernames and passwords, granting them initial access to the network. Moving forward, the attacker engages in lateral movement, navigating through the network to access multiple devices or accounts, expanding their foothold. As the attack progresses, the attacker seeks privilege escalation, upgrading their access rights to obtain higher-level privileges, such as administrative rights, enabling them to gain control over more critical resources within the network.

In cloud environments, lateral movement frequently occurs in the identity and access management (IAM) layer rather than across networks. Adversaries may capture session or refresh tokens (for example via Adversary-in-the-Middle phishing), impersonate users, bypass multi-factor authentication and Conditional Access, abuse service principals or misconfigured roles, or even register “ghost” devices. In this model, attackers pivot through cloud resources and IAM relationships, making identity the primary attack surface.

According to IBM’s Threat Intelligence Index [1], there has been a significant rise in the delivery of infostealers via phishing emails, with an increase of 84% per week. Moreover, identity-based attacks now constitute 30% of total intrusions, highlighting the critical need for enhanced security measures to protect against unauthorized access and data breaches.

Let’s start diving into the main concepts of securing our Entra ID environment, especially when we have a modern hybrid working environment.

Hybrid Identity in the Modern Workplace

A hybrid identity is one that spans on both on-premises infrastructure and cloud-based services, enabling users to access resources across environments with a single identity. For many organizations, this model is still the one that is most commonly used.

To bridge these two worlds, Microsoft provides Entra Connect, which comes in two options: Connect Sync and Cloud Sync. Both of these are very useful and powerful, but they also introduce complexity and with complexity, risk comes. In real-world environments, we’ve frequently seen hybrid identity setups misconfigured, with issues like unnecessary Seamless SSO, stale or unrotated Kerberos decryption keys, and silent directory sync errors that can go unnoticed for extended periods.

This section unpacks those common pitfalls, explains what to watch out for, and helps you align your hybrid identity strategy with secure, modern best practices.

New application based authentication in Entra ID for stronger security

Microsoft has streamlined the upgrade process. Now, you can download the latest version of Entra Connect and benefit from the application-based authentication, moving away from the traditional username/password previously used for syncing identities to the cloud.

However, while certificate-based authentication is indeed more secure and helps reduce the overall attack surface, it introduces a new layer of risk. The service principal that authenticates using the certificate becomes a critical identity and any strange behavior should be monitored carefully, as it operates silently in the background and may be overlooked in traditional security audits.

There are three options to choose for certificate and application management:

1. Managed by Microsoft Entra Connect
2. Bringing your own application
3. Bringing your own certificate

If you don’t already manage your own certificates, use the recommended Microsoft-managed option which offers both security and little administrative overhead.

The certificate is stored in the CURRENT_USER certificate store. For optimal protection of the certificate’s private key, it is recommended to use a Trusted Platform Module (TPM), because:

• On a host without a TPM, the authentication certificate and private key used by the service principal can be extracted from disk or memory which is a classic case of key theft.
• When a TPM is present, the private key is non-exportable, meaning it cannot be copied or stolen directly. Instead, the TPM securely performs signing operations to authenticate and obtain tokens. In this scenario, an attacker doesn’t need to steal the key itself; they must exploit the TPM to misuse it.

Seamless SSO – Do we really need it?

The short answer is No. Not in most modern environments.

Let’s break it down.

Seamless SSO feature is designed to provide passwordless access for domain-joined end-user devices that do not support Primary Refresh Tokens.

But here is the catch: Seamless SSO is now considered legacy. It relies on Kerberos tickets being sent from the client to Entra ID, where they’re decrypted to issue access tokens. In contrast, modern authentication paths, especially those using Entra ID Joined or Hybrid Joined devices, leverage PRTs (Primary Refresh Tokens) to achieve SSO without relying on Kerberos, even on mobile platforms, like iOS and Android.

There are two main concerns we’ve encountered in the field as shown in the screenshots below:

The first as mentioned is that we have seamless SSO configured for the on-premises system but also since as we said this relies on Kerberos authentication, the Kerberos decryption key has not been rotated for at least 3 months now. And where is the risk, you may ask: If an attacker compromises your on-premises DC and extracts the Kerberos decryption key, they could issue valid Kerberos tickets which Entra ID would happily accept effectively gaining persistent cloud access even after the initial breach is remediated.

So, what can you do now?

• Audit if Seamless SSO is really required [2]
  If your environment uses Entra ID Joined or Hybrid Joined devices with modern OS versions (e.g. Windows 10/11, macOS 13+), you likely don’t need it.
  
• Rotate Kerberos decryption keys regularly
  Regularly rotate Kerberos decryption keys, ensuring the process is well documented and monitored. Be aware of potential risks, such as applications failing to authenticate, and take steps to mitigate these issues during key rotation.

Now that we’ve explored the foundations of hybrid identity and some common pitfalls in syncing and authentication, the next crucial layer of defense is how and when users gain access to your cloud resources. This is where Microsoft Entra Conditional Access policies come, enabling you to enforce granular, context-aware access controls that strengthen your security posture and support Zero Trust principles.

What Conditional Access policies are and why they’re critical in Entra ID?

Conditional Access is a powerful security feature in Microsoft Entra that enforces access decisions based on specific conditions. These policies are scoped to:

1. Resources
2. User actions
3. Authentication contexts

This allows organizations to apply precise control over who can access what and under which circumstances. By evaluating factors such as user location, device compliance, or risk level, Conditional Access helps enforce strong security measures while enabling seamless user experiences.

Looking on the screenshot above, we can think of the 3 main pillars of CA policies:

• Signal could be the user, device or group assigned to a policy
• Decision is the most important aspect where we can focus on allow/block decisions based on various criteria, such as the requirement of a compliant device, or even the most used one the MFA requirement.
• Enforcement is interesting if you want to deep dive a bit further to enforce token protection [3], sign-in frequency, etc.

While Conditional Access policies provide powerful security controls, it’s important to recognize the potential risks of misconfiguration, such as accidentally locking yourself out.

Common Conditional Access Pitfalls and How to Avoid Them

Incomplete MFA Enforcement for Administrators

Let’s see what is the issue and the misconfigurations on the screenshots below.

Screenshot Colors Explanation: Green: Represents best practices being followed; Orange: Indicates areas that need attention; Red: Highlights where best practices are not being followed.

While Multi-Factor Authentication (MFA) is often configured for admin accounts, we frequently see exclusions for certain users, apps, or even entire directory roles. Additionally, some organizations rely only on basic MFA methods, which remain vulnerable to modern phishing attacks. Moreover, we’ve observed environments where only “Global Administrators” are protected by MFA policies, leaving out roles like “Privileged Role Administrator” or “Application Administrator”, both of which can grant access or elevate permissions.

What to do instead:

• Apply Conditional Access policies to all high-privilege roles, not just a subset.
• Remove unnecessary exclusions from CA policies.
• Create a compensating CA policy to counter every exclusion that you require.
• Enforce phishing-resistant MFA methods such as:
  • FIDO2 security keys
  • Windows Hello for Business

Device Code Flow Not Blocked – Exploiting Device Code Flow

The OAuth 2.0 Device Code Flow is designed for devices with limited input capabilities (like meeting room devices), but it can be abused by attackers in phishing or social engineering campaigns to steal bearer tokens.

If Device Code Flow is enabled, attackers can trick users into authenticating and silently capture tokens, often bypassing Conditional Access if not properly scoped.

Screenshot Colors Explanation: Green: Represents best practices being followed; Orange: Indicates areas that need attention; Red: Highlights where best practices are not being followed.

What we see in the screenshot above is that although a policy is configured to apply restrictions to the Device Code Flow, it’s not actually targeting “All cloud apps“ which means the policy doesn’t effectively block the flow. In practice, this leaves a critical gap where device code authentication is still permitted.

Additionally, network conditions have not been defined, which means there’s no restriction on where or how this flow can be used. If your environment requires Device Code Flow, it’s important to scope access based on trusted IP ranges for example or specific locations to minimize exposure.

But let’s take this a step further and walk through how this misconfiguration can be exploited in the real world. We’ll break down the full flow of a potential compromise and show you exactly how an attacker can take advantage of it.

The attack chain is presented in the screenshot below.

How in action that happens:

The threat actor initiates the legitimate device code flow process, luring the user on the device code authentication page, the user is tricked into entering the code that the threat actor included as the ID for the fake Teams meeting invitation as shown below. [4]

Once the victim uses the device code to authenticate, the threat actor receives the valid access token. The threat actor then uses this valid session to move laterally within the newly compromised network by sending additional phishing messages and so on.

During testing, we simulated this scenario by initiating a device code request and capturing the user code. If a user is tricked into entering that code on the legitimate Microsoft login page, access is granted immediately with no further validation required.

Practically speaking, once the attacker has that access token, it’s game over. The token acts as a temporary but valid credential. At that point:

• You’re no longer asked to prove who you are
• You can access services according to the user’s permissions
• You’ve bypassed MFA if Conditional Access doesn’t properly cover this flow. However, it’s important to note that subsequent login attempts will still be evaluated against CA policies.

What you should do instead:

• Explicitly block the device code flow in Conditional Access policies
  • If your environment doesn’t rely on it, block it entirely
• Scope the CA policy to All Cloud Apps
  • We often see organizations apply policies only to specific applications
• Monitor for anomalous sign-ins using the device code flow
  • Filter Entra ID sign-in logs by Client App: Other clients to identify users authenticating this way

Wrapping Up

In this first part, we explored the core identity foundations that directly influence security outcomes in Microsoft Entra ID, starting with hybrid identity configurations, which remain common in today’s modern workplace, and moving into common pitfalls and the strategic use of Conditional Access policies to enforce Zero Trust principles.

In the next post, we’ll turn our attention to securing privileged access and gaining deeper visibility through logging and monitoring. In a world where identity is the new perimeter, control and insight are your strongest defenses and that’s exactly where we’re going next.

If you’re unsure where your own setup stands, our team offers a tailored Entra ID Assessment to help uncover misconfigurations and strengthen your identity security posture. Feel free to reach out, I am always happy to connect.

References

[1] IBM X-Force 2025 Threat Intelligence Index
[2] Microsoft – Turn off Seamless SSO if there is no usage
[3] Microsoft Entra Conditional Access: Token protection (Preview)
[4] Storm-2372 conducts device code phishing campaign

About the Author

---