Casting a Wide Net
During our external penetration tests, we regularly encounter Entra ID tenants drowning in so many conditional access policies that neither we nor the client can piece together how they interact. This complexity doesn’t just create confusion; it creates gaps in MFA enforcement. The first step in our journey is to cast a wide net: require MFA across as many resources as possible using as few conditional access policies as possible. Fewer policies mean less room for misconfiguration and better clarity on what resources are protected. Keep in mind this single policy won’t cover every edge case, but we’ll get to those in the next few sections.
Configuration
Browse to https://entra.microsoft.com and sign in using either a Global Administrator or Conditional Access Administrator account. Open the Conditional Access menu and then click the Create new policy button.
Give the policy a friendly name like “Require MFA for Users.” Under the Assignments section, make sure the policy applies to all users, excluding your service accounts and break-glass account, and applies to all resources. Under the Access controls section, make sure to select the control Require multifactor authentication.
Did he just say exclude service accounts? I did, but there’s a method to the madness. We’re going to cover service accounts and many other edge cases in later sections. Bear with me here while we create our first catch-all policy:
Restricting Service Account Logons
Service accounts are a common attack vector we exploit during external penetration tests. Organizations routinely exclude them from conditional access policies entirely, leaving a huge hole in their defenses. But why? Service accounts often run in automations that can’t handle interactive MFA prompts. Excluding them completely is the wrong move though. Instead, exclude service accounts from MFA requirements while enforcing location-based controls: configure trusted locations for your infrastructure, then block all sign-ins from anywhere else. This way, even if a service account’s credentials are compromised, a threat actor can’t use them from outside your network.
Configuration
Browse to https://portal.azure.comand sign-in using a Global Administrator account. Open the Microsoft Entra Named Locations menu then click the IP ranges location button. Give the location a friendly name like “Kansas Datacenter,” check the box for Mark as trusted location, and add the IP address or CIDR range where your service accounts will be authenticating from.
Now head back to the Entra Admin Center and create another conditional access policy. Give it a friendly name like “Restrict Service Account Logons.” Under the Assignments section, make sure the policy applies to your service accounts and to all resources. Under the Conditions section, include Any network or location and exclude the trusted location you just created. Under the Access controls section, make sure to select the control Block access.
Blocking Device Code Flow
If you haven’t heard of device code flow before, that’s probably because your Entra ID tenant doesn’t need it. Device code flow is a rarely used authentication method that allows users to authenticate with MFA from command-line tools by completing the login in a separate browser. The problem? Information gathering tools that both we and threat actors use, like GraphRunner, are command-line based, making device code flow a go-to authentication method.
We see this scenario often during external penetration tests: an Entra ID tenant requires MFA, but we compromise a user who hasn’t enrolled yet. We enroll them in MFA ourselves, then use device code flow to authenticate and run our reconnaissance tools. For most tenants, device code flow simply doesn’t need to be enabled. Block it, and threat actors lose an authentication method for many command-line tools. It won’t completely prevent them from using these tools against your tenant, but it’s one more landmine for them to step on and for you to detect.
Configuration
Create another conditional access policy and give it a friendly name like “Block Device Code Flow.” Under the Assignments section, make sure the policy applies to all accounts, excludes your break-glass account and service accounts, and applies to all resources. Under the Conditions section, include Device code flow. Under the Access controls section, make sure to select the control Block access.
Blocking Legacy Authentication Methods
Many legacy authentication protocols do not support MFA, which makes them a perfect target for threat actors looking to gain unauthorized access to your Entra ID tenant. While Microsoft has deprecated support for basic authentication and blocked protocols like POP3 and IMAP, others like SMTP AUTH remain available for the time being. Most organizations have no need to support these protocols anymore. Block them, and you eliminate an easy win for threat actors.
Configuration
Create another conditional access policy and give it a friendly name like “Block Legacy Authentication.” Under the Assignments section, make sure the policy applies to all accounts, excludes your break-glass account and service accounts, and applies to all resources. Under the Conditions section, include the client apps Exchange ActiveSync clients and Other clients. Under the Access controls section, make sure to select the control Block access.
Restricting MFA Self-Enrollment
Users should not be able to self-enroll in MFA using only a username and password. Remember the scenario from earlier? An Entra ID tenant requires MFA, but we compromise a user who hasn’t enrolled yet. We enroll them in MFA ourselves and gain access to the tenant.
You could use a conditional access policy to restrict when new users can enroll, such as only from corporate devices, trusted locations, or within a specific enrollment window. While this reduces the attack surface, it doesn’t address the underlying weakness of self-enrollment with just credentials.
The better solution? Pre-enroll new users in MFA using methods like a Temporary Access Pass (TAP), phone number, QR code, or a FIDO2 key. With this approach, a user must prove ownership of one of these authentication methods before enrolling additional MFA factors. A threat actor with stolen or guessed credentials alone can’t complete enrollment.
Configuration
Create another conditional access policy and give it a friendly name like “Restrict MFA Self-Enrollment.” Under the Assignments section, make sure the policy applies to all accounts and excludes your break-glass and service accounts. Under Target resources, select User actions, then check the box for Register security information. Under the Access controls section, make sure to select the control Require multifactor authentication.
Now open the Users menu in the Entra Admin Center and click on a user. Let’s say you have a new employee starting next Monday. Open the user’s Authentication methods menu and click on the Add authentication method button. Choose a Temporary Access Pass (TAP), set the Delayed start time to their start date, and set the Activation duration to eight hours.
You should now have a TAP and registration URL to send to your new employee. The employee can use the TAP to authenticate for the first time and enroll in a permanent MFA method. How you choose to distribute the TAP is up to you. It could be printed and mailed, emailed, or even texted. Just make sure it doesn’t end up somewhere that would be easily accessible by a threat actor with only a username and password. This entire process could be scripted using PowerShell and the Microsoft Graph API, although we will have to save that level of automation for another blog post.
With this policy in place, if the new employee tries to authenticate without using the TAP, they will receive the error shown below and be unable to enroll in a permanent MFA method. Crucially, this also prevents threat actors from doing the same with a compromised but unenrolled user. The TAP must be used to satisfy the policy requirements and allow enrollment in a permanent MFA method.
Restricting Device Registration
Along the same vein as MFA self-enrollment, users should also not be allowed to register or join devices to your Entra ID tenant using only a username and password. We see this scenario occasionally during our external penetration tests: an Entra ID tenant requires an Entra-joined device as a form of MFA but does not require MFA to join a device to the tenant. We then compromise a user, join a virtual machine to the tenant, and completely circumvent the policy. Require MFA when joining a device to your tenant and threat actors with stolen or guessed credentials alone can’t complete device registration.
Configuration
Create another conditional access policy and give it a friendly name like “Restrict Device Registration.” Under the Assignments section, make sure the policy applies to all accounts and excludes your break-glass and service accounts. Under Target resources, select User actions, then check the box for Register or join devices. Under the Access controls section, make sure to select the control Require multifactor authentication.
Blocking Risky Sign-Ins
Risky sign-ins are Microsoft’s way of telling you that a sign-in attempt looks suspicious. Entra ID Identity Protection analyzes sign-in patterns in real-time using signals like unfamiliar locations, anonymous IP addresses, atypical travel, leaked credentials and assigns a risk level. When the risk is high, you should block the sign-in attempt.
This is where defense in depth comes into play. Your other conditional access policies are your frontline defenses, but threat actors adapt. A risky sign-in policy catches what your other policies might miss. Block any sign-in with a risk level of high or above, and you have an additional layer of defense that stops suspicious activity even when a threat actor has technically met your other requirements.
Note: Sign-in risk requires an Entra ID P2 or E5 license. This condition can’t be used in policies without one of those licenses. The good news is that you only need to purchase and assign a single license to a user in your tenant. All other users in the tenant without the license will still benefit from the sign-in risk condition.
Configuration
Create another conditional access policy and give it a friendly name like “Block High-Risk Sign-Ins.” Under the Assignments section, make sure the policy applies to all accounts, excludes your break-glass account and service accounts, and applies to all resources. Under the Conditions section, include the High sign-in risk. Under the Access controls section, make sure to select the control Block access.
Blocking High-Risk Users
While sign-in risk represents the probability that a sign-in attempt is unauthorized, user risk represents the probability that an identity (the user) is compromised. You might be wondering what the difference is because both risk types sound the same, but there’s a subtle difference. Sign-in risk focuses on a single sign-in attempt, for example a user signing in from a new location. User risk, on the other hand, focuses on the accumulation of risk over time and many sign-in attempts. Just like with risky sign-ins, Entra ID Identity Protection analyzes sign-in patterns in real-time using various signals and will assign risk to a user over time. When the risk assigned to a user is high, you should block their sign-in attempts.
Consider a situation where a threat actor compromises a user and attempts to authenticate to your Entra ID tenant from an unfamiliar location. Our “Block High-Risk Sign-Ins” policy would block the sign-in attempt and, critically, the user’s risk would be increased, but what if the threat actor adapts and authenticates from a geographically similar location to the compromised user? Without a separate policy to block high-risk users, the threat actor’s second sign-in attempt could be successful.
Note: User risk requires an Entra ID P2 or E5 license. This condition can’t be used in policies without one of those licenses. The good news is that you only need to purchase and assign a single license to a user in your tenant. All other users in the tenant without the license will still benefit from the user risk condition.
Configuration
Create another conditional access policy and give it a friendly name like “Block High-Risk Users.” Under the Assignments section, make sure the policy applies to all accounts, excludes your break-glass account and service accounts, and applies to all resources. Under the Conditions section, include the High user risk. Under the Access controls section, make sure to select the control Block access.
Monitoring Your Sign-Ins
Building secure conditional access policies is only half the battle. You need to verify they’re actually working. Your Entra ID tenant’s sign-in logs are where you confirm your policies are doing what you think they’re doing. You can do this by heading to the Entra Admin Center again and opening the Conditional Access menu. On the overview page, you can glance at the Users tile to see how many users signed in during the last seven days without any policy coverage and quickly get a list of all unprotected sign-ins.
You can also open the Sign-in logs or Audit logs menus to see a list of all sign-ins. Click on any sign-in event to drill down, then click on the Conditional Access or Report-only tabs to view which policies were evaluated, which ones applied, and critically, which ones didn’t and why. Maybe a policy you thought would trigger didn’t because of an exclusion you forgot about. Maybe a user is signing in without MFA because they fall into a gap between policies. These logs surface the misconfigurations that look fine on paper but fail in practice.
Make it a habit to review your Entra ID tenant’s sign-in logs on a regular basis, filter for successful sign-ins without MFA, and investigate anything that looks suspicious. If a policy isn’t applying when it should be, you’ll find out here before a threat actor does.
Conclusion
Conditional access policies are the first line of defense against unauthorized access to your Entra ID tenant. Individually, each policy in this guide closes a specific gap that both we and threat actors regularly exploit. Together, they create overlapping layers of defense that make unauthorized access nearly impossible. If your current penetration testing provider is not uncovering gaps like the ones presented in this guide, it might be time to switch providers. We can only imagine what a threat actor would be thinking when coming up against these policies…
