Every Microsoft 365 tenant we audit has at least one Conditional Access policy that is either doing nothing, actively blocking the wrong users, or creating a false sense of security by protecting the wrong things. In some cases, all three.
Conditional Access is the most powerful security control in Microsoft 365. It is also the most consistently misconfigured. When it works properly, it removes the most common attack paths against a tenant. When it doesn’t, the rest of your security spend is largely decoration.
This post explains what Conditional Access actually does, where the failures consistently happen, and what a serious policy set looks like in 2026. For the wider tenant picture, see our guide to hardening Microsoft 365 in 2026.
What Conditional Access actually does
Conditional Access is the policy engine that sits between a user trying to access something and Microsoft 365 letting them do it. Every sign-in, every application access, every application programming interface call passes through it.
The logic is straightforward: if a user matches certain conditions, apply certain controls. The conditions can include who the user is, which application they’re accessing, where they’re signing in from, what device they’re using, what risk signals are present, and whether they’ve recently authenticated. The controls can be block access, require multi-factor authentication, require a managed and compliant device, restrict what the user can do after sign-in, or force re-authentication on a schedule.
Unlike firewall rules, Conditional Access policies have no order or priority. All matching policies are evaluated simultaneously, and the most restrictive result wins. If you've designed your policies assuming they fire in sequence, like firewall rules, your policy set is probably not doing what you think it is.
Why multi-factor authentication alone is no longer enough
For years the standard advice was: enable multi-factor authentication, job done. That advice is now incomplete.
Attackers adapted. They don’t try to bypass multi-factor authentication by stealing the second factor. They steal the authentication token after the user has already completed multi-factor authentication successfully. An adversary-in-the-middle proxy sits between the user and Microsoft, captures the session token once authentication is complete, and replays it from a different location. The user sees a normal login. Multi-factor authentication fires and passes. The attacker walks in through the valid session.
This is not a theoretical attack. It is the mechanism behind a significant proportion of Microsoft 365 compromises in 2024 and 2025, including the Midnight Blizzard attack against Microsoft’s own tenant in early 2024.
Conditional Access addresses this because it doesn’t just check whether authentication succeeded. It evaluates the context of the session continuously: is this device managed and compliant? Is this sign-in from a trusted location? Is this sign-in risk score elevated? Is the session token being used from a different IP than where it was issued?
Multi-factor authentication verifies identity at the point of sign-in. Conditional Access verifies the context of every access attempt, including whether the session itself is still trustworthy after authentication has completed.
What the default configuration gives you
A new Microsoft 365 tenant comes with security defaults enabled: basic multi-factor authentication enforcement for all users and blocking of legacy authentication protocols. Better than nothing. But it cannot be tuned, it doesn’t account for context, and it fails the moment you need to do anything more sophisticated than “everyone must use multi-factor authentication.”
The moment you disable security defaults and enable Conditional Access properly, you are responsible for designing the full policy set. Most organisations at this point create a single policy requiring multi-factor authentication for all users, decide the job is done, and move on.
It isn’t.
The seven questions a serious policy set must answer
A properly designed Conditional Access configuration answers all of the following. If any are unanswered, you have a gap.
Who is allowed to sign in from where?
Named locations let you define trusted networks and restrict sign-ins to those locations, or block sign-ins from countries you don't operate in. This is not a complete control on its own because attackers use virtual private networks, but combined with sign-in risk detection it significantly raises the cost of an attack.
If your business operates entirely in the United Kingdom, there is no legitimate reason for a sign-in to succeed from a sanctioned country at three in the morning.
Action: define named locations, create location-based access policies, and combine with sign-in risk detection rather than relying on location alone.Which devices are trusted?
Conditional Access can require that users sign in from devices that are managed by Microsoft Intune and meet your compliance policy. A managed compliant device gets full access. An unmanaged personal device gets browser-only access with no downloads. A non-compliant device gets blocked entirely.
Without device compliance requirements, a stolen laptop with valid credentials and a passed multi-factor authentication prompt is indistinguishable from a legitimate sign-in. The device itself tells you nothing.
Action: require device compliance for access to sensitive applications and data. For personal devices, use app protection policies rather than blocking access entirely.How are legacy authentication protocols handled?
Legacy protocols such as older versions of IMAP, POP3, and SMTP do not support multi-factor authentication. They authenticate with username and password only. An attacker with stolen credentials can use these protocols to access email or other services and bypass every Conditional Access policy that requires multi-factor authentication, because the protocol itself doesn't support the challenge.
This should be one of the first policies you create. The objection is always the same: printers, scanners, and older line-of-business applications that still use legacy authentication. Identify them, migrate them to modern authentication, then block legacy authentication universally.
Action: block legacy authentication for all users as an early priority. Audit what currently uses legacy protocols before blocking and migrate those systems first.Are admins treated differently from regular users?
Privileged accounts are the highest-value target in any tenant. They should have stricter controls than standard users, not the same ones. A global administrator should be required to use phishing-resistant authentication (hardware security keys or Windows Hello for Business), access administrative portals only from compliant devices, re-authenticate frequently, and ideally only from trusted locations.
Most organisations have one policy for all users. Administrators get caught in it and sometimes exempted from it, which is worse. Privileged accounts need their own policy set with tighter requirements on every dimension.
Action: create a dedicated policy set for administrator and privileged roles. Require phishing-resistant authentication, compliant devices, and short session lifetimes.What happens when a sign-in looks suspicious?
Microsoft Entra Identity Protection calculates a risk score for every sign-in. Signals include impossible travel (signing in from London and Tokyo within an hour), anonymous IP addresses, password spray patterns, and credentials that have appeared in known data breaches. Risk-based Conditional Access policies can require a password change or block access entirely when sign-in risk is elevated.
This requires Microsoft Entra ID P2 licensing, which comes with Microsoft 365 E5 or Business Premium. If you don't have the licensing, the fallback is tighter location and session controls, but risk-based policies are meaningfully more effective. If you have the licensing and aren't using risk-based policies, you're leaving your most powerful detection tool switched off.
Action: if you have Microsoft Entra ID P2 licensing, implement sign-in risk and user risk policies immediately. They are the highest-value Conditional Access feature available.Are service accounts and automation covered correctly?
User-facing policies should not apply to service accounts, synchronisation accounts, and automated workflows. When they do, you get silent failures: directory synchronisation stops, automated provisioning breaks, reporting pipelines fail. The user-facing policy blocked the service account and nobody noticed for a week.
Service accounts need their own policies, typically restricted by network location rather than multi-factor authentication (since they can't interactively complete a challenge). Every service account should be explicitly included in a policy, not left to fall into a user-facing one by default.
Action: enumerate all service accounts and automated workflows. Create dedicated policies restricting them to trusted IP ranges and excluding them explicitly from user-facing policies.What is the break-glass plan?
A misconfigured Conditional Access policy can lock every administrator out of the tenant. This happens. Microsoft Support recovery from a full tenant lockout is not fast. The standard protection is at least two emergency access accounts that are excluded from all Conditional Access policies, have long randomly-generated passwords, and are stored in a secure physical location, not in a password manager that requires the tenant to be accessible.
These accounts should be monitored. Any sign-in from a break-glass account should trigger an immediate alert, because the only time they should ever be used is in an emergency.
Action: create two break-glass accounts, exclude them from all Conditional Access policies, store credentials offline, and set up alerts on any sign-in activity from those accounts.The trap that catches everyone: exclusions
Most Conditional Access failures we see in Microsoft 365 security audits are not bad policies. They’re good policies with quiet exclusions that have accumulated over time.
A single excluded user account left in from a proof-of-concept test six months ago. An application exempted because the vendor said it would break otherwise (and nobody went back to check). A “temporary” location exception that became permanent. Each one is an attacker’s preferred entry point.
Every exclusion in every Conditional Access policy should have an owner, a documented reason, and a review date. If you can't state those three things for each one, the exclusion should be removed. Audit your exclude lists quarterly at minimum.
A note on Microsoft 365 Copilot
If your organisation has deployed or is considering Microsoft 365 Copilot, Conditional Access design matters more than it used to. Copilot indexes data across your tenant and can surface files, emails, and records that individual users wouldn’t normally find themselves. A compromised account with a valid session token now has access not just to that user’s data but to anything Copilot can reach on their behalf.
Multi-factor authentication prompts are often the last human control in the chain, and attackers have adapted to aim for tokens and session proxies rather than credentials. In a Copilot-enabled tenant, a stolen token represents significantly more exposure than it did before.
Where to start
If your Conditional Access configuration hasn’t been reviewed seriously, the priority order:
- Create break-glass accounts and exclude them from all policies before making any other changes
- Block legacy authentication for all users
- Require multi-factor authentication for all users, with only break-glass exceptions
- Create a stricter separate policy set for all administrator and privileged roles
- Audit every existing exclude list and remove anything that cannot be justified in writing
- Add device compliance requirements for sensitive applications
- Enable risk-based sign-in policies if you have Microsoft Entra ID P2 licensing
- Block multi-factor authentication registration from untrusted locations to prevent attackers registering their own authentication method with a stolen password
Test every policy in report-only mode before switching it on. Review the sign-in logs daily during rollout. The question isn’t whether a policy is theoretically correct. It’s whether it behaves correctly against your actual users, devices, and service accounts in production.
Conditional Access design is a significant part of our Microsoft 365 Security service. If you’d like a review of your current policy set, get in touch.