Conditional Access Essentials: Introduction, use cases, the art of possible
- welka2111
- 3 days ago
- 4 min read
Introduction
Conditional Access plays a central role in safeguarding Microsoft 365, Entra, and Azure - acting as the gatekeeper that controls who gets in and under what conditions. Done right, it’s the gatekeeper that decides who gets in, what they can do, and under what conditions. Done wrong, it’s a wide-open door inviting in token theft, data loss from unmanaged devices, and a whole range of security headaches.
In the Microsoft ecosystem, Conditional Access is where much of the decision-making magic happens. Want to require multi-factor authentication (MFA) for certain users? Restrict access to devices that are compliant and hybrid joined? Block sign-ins from specific locations? Demand a password reset when a user’s sign-in is flagged as risky? Stop sensitive files being downloaded to unmanaged devices? Conditional Access can handle all of it.
The good news is you don't need to jump between multiple admin centres to utilise the capabilities of conditional access (think enforcing MFA, using identity protection, etc.). It’s all in one place, the Entra portal - giving you a centralised way to manage and protect identities, devices, and data.
Table of Contents
What is Conditional Access?
Conditional Access (CA) is a feature within Microsoft Entra that applies authentication and authorisation rules based on factors such as a user’s identity, device, location, and other context signals.
It helps organisations safeguard their resources by blocking or restricting access when a sign-in appears unauthorised or high-risk. Think of Conditional Access as a security checkpoint for your organisation’s digital resources. It makes decisions based on signals like:
Who the user is
What device they’re on
Where they’re signing in from
What they’re trying to access
How risky their sign-in appears to be
It’s not about simply allowing or blocking access; it’s about applying the right conditions so that access is granted in a safe, controlled way.
Real-world examples and use cases
Conditional Access can be used to:
Strengthen logins with phish-resistant authentication methods, such as FIDO2 keys/ passkeys or Windows Hello for Business (WHfB).
Reduce the risk of phishing attacks, including advanced adversary-in-the-middle (AiTM) techniques.
Limit SaaS application access to trusted, organisation-managed devices.
Manage and monitor guest user access to corporate resources.
Control personal device (BYOD) access to keep it secure without blocking productivity.
Require users to accept your terms of use before granting access.
Minimise the impact of token theft by applying targeted protections.
The Conditional Access Zero Trust approach
Conditional Access for Zero Trust (CAZT) is a framework for building a scalable, maintainable Conditional Access setup. The CAZT baseline follows a persona-based approach developed by Claus Jespersen, formerly of Microsoft. Although Claus has since retired, his framework remains a solid foundation for designing clear, consistent, and effective policies.
The framework is built around two main principles:
Personas: grouping users with similar roles, responsibilities, and access needs so you can apply consistent, tailored policies.
Specific over broad: preferring more, smaller policies with targeted requirements rather than fewer, wide-scoped ones.
This approach makes it easier to troubleshoot, customise, and maintain policies over time.
Personas: grouping users the smart way
Personas are about defining user types, such as “internals" (aka standard employees), “contractors”, or “admins”,and giving each type the right set of policies. This avoids one-size-fits-all rules that can either be too strict for some or too lenient for others.
More about personas in a future post.
Why granular policies beat broad ones?
Smaller, specific policies allow you to:
Identify exactly why a sign-in succeeded or failed in the logs
Make targeted exclusions without removing other protections
Account for different requirements across personas or sub-personas
The result: more precision and fewer unintended side-effects.
Lightning round: key facts you should know
Conditional Access is a post-authentication capability that protects token issuance.
It does not protect the initial authentication of password sign-ins, but it can require additional checks such as:
MFA requirements
Device requirements
Network requirements
Risk requirements
Session rules
Entra tenants have a 195 policy limit - worth keeping in mind if using a fine-grained policy approach.
Conditional Access focuses on protecting web services (APIs) and websites that use OpenID Connect/OAuth 2.0 confidential clients or SAML.
For example, you can enforce Conditional Access on the sign-in token for Exchange Online in the cloud.
It does not directly control applications installed locally on a device (OpenID Connect/OAuth 2.0 native clients).
For instance, Outlook installed on a laptop won’t be blocked until it attempts to authenticate to a cloud service.
Device conditions can be determined using:
Device platforms: based on user agent string (can be spoofed).
Filter for devices: based on device properties in Entra (requires the device to be registered).
Policy controls: application order
Policy controls are applied in this order:
MFA or authentication strengths (e.g., Authenticator app, passkeys)
Application protection policies
Device state (e.g., compliance)
Custom controls (e.g., terms of use)
Session requirements (e.g., sign-in frequency)
Current conditional access controls
The image below, (also available for download as a PDF), illustrates the Conditional Access controls and options available at the time of writing. It provides a visual overview of how the different controls fit into the Conditional Access framework, helping you understand the range of conditions and actions you can configure. While Microsoft frequently updates and expands these capabilities, this snapshot reflects the current feature set, offering a useful reference for policy planning and design.
Conclusion
Conditional Access is here to stay, and Microsoft keeps adding features. If you’re not using it, or you are, but without full confidence - now is the time to learn. The more comfortable you are with the tool, the less likely it is that policy changes will cause unexpected downtime or late-night troubleshooting.
When properly configured, Conditional Access is one of the strongest defences available in Microsoft 365 and Entra. It ensures the right people get the right access at the right time, and keeps everyone else out. Over this series, we’ll take a closer look at each aspect so you can design and maintain a setup that’s secure, efficient, and fit for the modern workplace.