The Art (and Chaos) of Conditional Access
Build a policy structure that meets your needs without unnecessary complexity.
In 2020, I had the opportunity to help launch a business from the ground up with a trusting founder and a clear mission. Armed with basic PowerShell and dusty programming skills, I set out to create a repeatable Microsoft 365 scan that could identify configuration gaps and hardening opportunities.
Later that year, I began running my duct-tape-and-string code in real customer environments. That experience changed everything.
During my time at that company, through its eventual acquisition, I saw a wide range of environments and learned from each of them. Our clients spanned industries and continents, each with unique operational demands. Those experiences taught me a great deal about how organizations approach security and, more specifically, how they manage Conditional Access (CA) policies.
Anti-Patterns
Few organizations fully understand their Conditional Access policies. Even fewer feel confident managing them.
This usually happens because Conditional Access arrived as a solution to a new type of problem that most teams had never faced before. It also came bundled with a flood of other cloud-related changes, which meant learning proper design patterns often took a back seat.
As a result, several anti-patterns have become common across environments.
Pattern One: Treating Conditional Access Like a Firewall
Many organizations try to mirror firewall logic when designing Conditional Access. They create long lists of rules tailored to every possible scenario.
If your developers run Temple OS, use YubiKeys, and connect from restricted regions, there is a policy for that. If your support team needs an exception for multi-factor authentication (MFA), there is another policy for that too.
On the surface, this seems flexible, but it quickly leads to problems. When every group has its own policy, universal controls become impossible to enforce without updating several configurations at once. Combine that with limited visibility across your CA stack, and you can easily introduce gaps that allow users to bypass MFA.
It might look like precision, but it often results in confusion.
Pattern Two: Using Conditions as Controls
Another common mistake is treating conditions as controls.
For example, you might create a policy that blocks access when a device reports its operating system as Linux. While that seems logical, much of that device data is self-reported and can be tampered with. I have tested and reported this behavior before.
The takeaway is simple: conditions describe context, while controls enforce requirements. Confusing the two leads to fragile policies that can be exploited.
Pattern Three: Inclusive Policies
Some administrators rely on inclusive policy architecture, where users are added to groups or policies individually rather than using the global “All Users” option.
I have seen setups using dynamic groups, birthright group management, and other forms of automation designed to ensure everyone has MFA enabled. While creative, these methods depend on perfect group membership management, which rarely happens.
The result is predictable: policies that appear solid but quietly miss accounts that fall through the cracks.
Quick Detour: Understanding Deconfliction
Microsoft resolves Conditional Access policy conflicts based on specificity and restriction.
The order of evaluation matters, and understanding it is key to building policies that behave as intended.
Example One: Group-Based Inclusion
Policy A: MFA required for members of a group (George, Sally, others)
Policy B: MFA excluded for user George
Result: George is not required to authenticate with MFA because the exclusion is more specific.
Example Two: Group-Based Exclusion
Policy A: MFA not required for members of a group (George, Sally, others)
Policy B: MFA required for user George
Result: George must authenticate with MFA because the inclusion is more specific.
Example Three: Same-Specificity Clash
Policy A: MFA not required for George
Policy B: MFA required for George
Result: George must authenticate with MFA because when specificity is equal, the more restrictive policy takes precedence.
With these examples in mind, we can now look at how to structure Conditional Access policies effectively.
Another Detour: Additive Behavior
Unlike firewalls, Conditional Access policies are additive. Microsoft evaluates every applicable policy at sign-in to ensure all conditions are met.
This allows you to stack policies so each one adds requirements without creating a tangled web of overlapping configurations.
Understanding this additive model is the key to scalable, maintainable Conditional Access architecture.
Re-Architecting Conditional Access Policies
Conditional Access policies can be thought of as a set of four levers you can adjust:
Scope – Apps, Users, Roles, and Groups
Conditions – Devices, Management, Location, and similar factors
Grant Requirements – MFA, Trusted Device, or other access checks
Session Management – Sign-in frequency and session persistence
Let’s see how these levers work in practice.
Policy One: Multi-Factor Authentication
Scope: All users, all apps
Conditions: None
Grant Requirements: MFA
Session Management: Default
This policy enforces MFA across your entire tenant by default. There is no guesswork about who has MFA enabled.
But what about legacy service accounts? That is easy to handle:
Scope: All users, all apps, excluding users in the “Service Accounts” group
This single change clarifies which accounts are excluded, making exception management straightforward.
Policy Two: Trusted Devices
Scope: All users, all apps
Conditions: None
Grant Requirements: Trusted Device
Session Management: Default
This policy ensures that only compliant or trusted devices can access company resources. It is an effective way to prevent data exposure from unmanaged endpoints.
Having a single policy for this requirement makes exceptions visible and easier to track.
Policy Three: Forced Re-Authentication
Scope: All users, selected apps
Conditions: None
Grant Requirements: MFA
Session Management: Sign in every time
This policy adds friction for critical portals such as financial systems, security dashboards, or administrative consoles.
Be mindful that “every time” can frustrate users. If it causes too much disruption, reduce the frequency to once every 24 hours.
Looking Back
With just three policies, you can cover most organizational needs: baseline MFA, trusted device enforcement, and targeted re-authentication.
This structure minimizes overlap, simplifies audits, and reduces the likelihood of misconfiguration.
By separating your controls, you can adapt them to new scenarios without rewriting or duplicating policies.
There will always be exceptions that require additional consideration, but avoiding the anti-patterns discussed earlier and using the additive nature of Conditional Access allows you to build a policy structure that meets your needs without unnecessary complexity.