There is a moment most organizations hit when working with Conditional Access in Microsoft 365. At first, everything feels straightforward. You create a few policies, require MFA, block some risky locations, and it all seems under control. Then the environment grows. More apps, more users, more edge cases. Suddenly, policies begin to overlap, exceptions creep in, and what once felt clean becomes difficult to reason about.
The root cause is rarely the technology itself. It is almost always the approach taken to designing Conditional Access.
At a high level, most organizations fall into one of three patterns.
- Some treat Conditional Access like a set of firewall rules.
- Others organize it around user personas.
- The more mature environments evolve further, using risk and real-time signals to make decisions dynamically.
Each approach has value. Each also has limitations. The real goal is not to pick one but to understand how they fit together into a scalable model.
The Starting Point: Thinking in “Firewall Rules”
It is completely natural to begin by treating Conditional Access like a firewall. For years, that is how access control worked. You defined rules based on conditions, and the system enforced them consistently.
In this model, Conditional Access policies are built around straightforward logic. If a user connects from outside a trusted network, require MFA. If a sign-in comes from a high-risk country, block it. If an application is sensitive, add an extra layer of authentication.
There is a certain clarity to this. It is easy to explain, easy to implement, and aligns with how many administrators have been trained to think about security. In fact, Microsoft’s own baseline recommendations encourage this kind of thinking early on, especially when enforcing MFA and blocking legacy authentication.
The issue is not that this model is wrong. It is that it assumes the environment is static.
Users no longer behave in predictable, fixed patterns. They move constantly between locations, devices, and networks. A user signing in from a different country might be traveling or an attacker. A device might be inside the corporate network but completely unmanaged. A trusted IP range might include compromised endpoints.
What begins as a small set of rules often expands into a large and fragmented collection of policies. One policy for location, another for applications, another for device state, and more to handle exceptions. Over time, it becomes difficult to determine which policy is actually enforcing what behavior. Troubleshooting becomes reactive rather than intentional.
More importantly, this approach does not truly understand the user. It focuses on where the request comes from, not on who is making it or how risky it is.
To make that distinction clearer, it helps to contrast how this approach behaves compared to more modern designs:
| Aspect | Firewall-Style Conditional Access |
|---|---|
| Decision Driver | Static conditions (IP, location, app) |
| View of User | Generic, not role-aware |
| Flexibility | Low once deployed |
| Scalability | Degrades as policies grow |
| Troubleshooting | Often complex due to overlap |
That limitation is what drives the next stage of maturity.
Shifting the Perspective: Designing Around Personas
As environments grow, organizations begin to recognize that not all users should be treated the same. A global administrator logging into the tenant carries a very different level of risk than a standard employee checking email. A contractor who has access to a limited set of resources should not be governed by the same policies as a full-time employee.
This is where persona-based Conditional Access design comes into play.
Instead of building policies around conditions alone, policies are built around identity roles and responsibilities. Users are grouped into logical personas, and each persona is assigned a consistent set of controls.
For example, administrators might be required to use strong, phishing-resistant authentication methods and access systems only from compliant devices. Standard users might have a balanced set of controls that enforce MFA without introducing unnecessary friction. Guests might be restricted to browser-based access with tighter controls around data movement.
This shift changes how policies are structured. Rather than a scattered collection of rules, you begin to see a layered model emerge. There is a baseline that applies to everyone, and then additional policies that apply based on the user’s identity.
The benefit here is not just improved security. It is clarity.
Policies become easier to read, audit, and explain. When something breaks, you can trace it back to a persona rather than digging through dozens of overlapping conditions. Governance improves because the design is intentional rather than reactive.
However, persona-based design still has a limitation. It assumes that users behave consistently within their roles.
An administrator is always high-impact, but a standard user is not always low-risk. A compromised standard account can be just as dangerous when used to move laterally or access sensitive data. Likewise, a legitimate admin performing routine work should not always be subjected to maximum friction.
That is where the most advanced approach comes in.
Moving to Adaptive Security: Risk-Based Conditional Access
The most mature Conditional Access designs move beyond static definitions entirely. Instead of relying only on roles or predefined conditions, they incorporate real-time risk signals into every access decision.
Microsoft provides these signals through identity protection capabilities. Sign-in behavior is continuously analyzed for patterns such as impossible travel, unfamiliar locations, unusual application access, or indicators of compromised credentials. Each authentication attempt is assigned a risk level, and Conditional Access policies respond accordingly.
This allows access decisions to become dynamic.
A user signing in under normal conditions, from a familiar device and location, may experience little to no friction. The same user, attempting access from a suspicious location or exhibiting unusual behavior, may be required to perform additional authentication or be blocked entirely.
What makes this powerful is not just the increased security, but the balance it creates. Instead of applying strict controls universally, security is applied where and when it is needed.
To better understand how these three approaches differ in practice, the comparison below highlights how each one handles core decision-making:
| Capability | Firewall-Style | Persona-Based | Risk-Based |
|---|---|---|---|
| Primary Focus | Conditions (location, device) | Identity and role | Real-time signals |
| Policy Behavior | Static | Structured but still static | Dynamic and adaptive |
| User Context Awareness | Low | Moderate | High |
| Security Strength | Basic | Strong | Advanced |
| User Experience | Often inconsistent | Controlled | Optimized and adaptive |
| Alignment with Zero Trust | Limited | Strong | Full |
This approach aligns directly with Zero Trust principles. Every request is evaluated independently. Trust is not assumed based on past behavior, and access is continuously reassessed.
Of course, this model introduces new considerations. It requires the right licensing, integration with identity protection services, and ongoing monitoring to ensure that risk signals are accurate and meaningful. It also requires a shift in mindset, moving away from static rules toward adaptive decision-making.
But when implemented correctly, it represents a significant step forward in both security and usability.
Why No Single Approach Is Enough
It might be tempting to view these approaches as competing models, but in practice, they are stages in an evolution.
Firewall-style policies provide the foundation. They establish baseline protections and address the most obvious risks. Persona-based design brings structure and aligns policies with how organizations actually operate. Risk-based controls add intelligence, allowing decisions to adapt in real time.
A well-designed Conditional Access strategy combines all three.
At the base, you enforce universal protections such as MFA and blocking legacy authentication. On top of that, you layer persona-specific controls that reflect the different levels of access and risk across your user population. Finally, you introduce risk-based policies that dynamically adjust enforcement based on behavior and threat signals.
This layered approach is what allows Conditional Access to scale without becoming unmanageable.
What Microsoft Best Practices Emphasize
Across Microsoft’s guidance and the broader security community, a few themes consistently emerge.
The first is that baseline protections are essential. Every environment should enforce MFA, block legacy authentication, and protect privileged accounts. These are not advanced configurations; they are foundational requirements.
The second is that identity must be the primary focus. Network-based thinking does not translate well to cloud environments. Trust cannot be based solely on location or IP address. It must be based on who the user is, the state of their device, and the associated risk of their activity.
The third is the importance of simplicity and clarity. Overly complex policies are difficult to maintain and even harder to troubleshoot. A smaller number of well-designed policies is far more effective than a large number of granular rules.
Finally, there is a strong emphasis on testing and iteration. Conditional Access policies should be deployed in report-only mode first, validated with test users, and gradually rolled out. This reduces the risk of unintended consequences and ensures that policies behave as expected.
Bringing It All Together
The evolution of Conditional Access mirrors the broader shift in security. It starts with control. Simple rules, clearly defined boundaries, and predictable behavior. Then it moves toward understanding. Recognizing that users are different, that roles matter, and that policies should reflect that reality. Finally, it becomes adaptive. Decisions are made in real time, based on context, behavior, and risk.
The organizations that succeed with Conditional Access are not the ones with the most policies. They are the ones with the most intentional design.
They do not ask, “What rule should we add next?”
They ask, “What decision are we trying to make, and what information do we need to make it correctly?”
That is the difference between managing access and truly controlling identity.
And in a world where identity is the new perimeter, that difference is everything.