Conditional Access
In plain English
Plain definition
Conditional Access is a policy engine that evaluates sign-in signals and enforces access controls in real time; safe rollout requires report-only validation, explicit scope, and a documented rollback path before enforcement.
Technical Definition
Conditional Access is an identity access-control capability, most commonly associated with Microsoft Entra ID, in which administrators define policies composed of assignments (who and what the policy applies to) and access controls (what happens when conditions are met). A policy typically specifies signals to evaluate—user or group membership, cloud application, device platform, client type, network location and sign-in risk—and a corresponding grant or block decision. Policies can run in report-only mode, which logs the decision the policy would have made without enforcing it, or in enforced mode, which actively blocks or challenges access.
Operational Relevance
Conditional Access sits at the point where identity, device management and application access intersect, making it a primary control for reducing unauthorised access without blocking legitimate users. It is used to require stronger authentication for risky sign-ins, restrict access to managed or compliant devices, and limit sensitive application access to trusted networks. Because policies evaluate live signals, incorrect configuration can silently lock out an entire population or, conversely, leave a gap that permits unintended access; the operational discipline required is proportional to that risk.
Architecture Relationship
Conditional Access depends on an underlying identity provider to supply the signals it evaluates, and it typically sits alongside device compliance systems and multi-factor authentication as complementary controls rather than a replacement for them. It does not authenticate users on its own; it intercepts an authentication request already in progress and applies additional conditions before granting a token. This means Conditional Access policy design must account for how it interacts with break-glass accounts, legacy authentication protocols that may not carry the required signals, and any downstream application that expects a specific claim shape in the resulting token.
Example
A bounded, recoverable Conditional Access workflow for a single scoped policy:
- Identify the exact target population and application (for example, a specific security group accessing one line-of-business application) rather than an entire tenant.
- Create the policy in report-only mode with the intended grant control (for example, require multi-factor authentication).
- Review report-only sign-in logs for the target population over a defined observation window to confirm the policy evaluates as expected and does not affect out-of-scope accounts.
- Confirm a break-glass or emergency access account exists and is explicitly excluded from the policy assignment.
- Switch the policy from report-only to enforced only after the observation window shows no unexpected blocks.
- Retain the ability to immediately disable the policy or revert it to report-only if enforcement produces an unplanned lockout.
Misunderstanding
A common misunderstanding is treating Conditional Access as a firewall-style network control. It is not a network boundary; it is a decision layer evaluated during authentication, and it has no effect on traffic that does not pass through the identity provider’s sign-in flow. Another common error is assuming report-only mode carries zero risk of misconfiguration discovery gaps: report-only logs only show what the policy would have done for sign-ins that actually occurred during the observation window, so a policy with a narrow observation period may not surface every affected scenario before enforcement.
Related Terms
- Zero Trust — the broader security model in which Conditional Access is one enforcement mechanism.
- Multi-Factor Authentication — a common grant control invoked by Conditional Access policies.
- Identity Provider — the system that authenticates the user and supplies signals to Conditional Access.
- Device Compliance — a signal source used by Conditional Access to gate access by device state.
Further Reading
The authoritative source for policy structure, signal types and grant controls is the vendor’s Conditional Access documentation, which should be checked against the tenant’s current release before any enforcement change is made, since navigation paths and available signals evolve between releases.
- Conditional Access documentation — canonical reference for assignments, conditions and access controls.
Verified Operational Checks and Next Decision
Before treating a Conditional Access policy as production-ready, confirm three things with direct evidence: the report-only sign-in log shows the expected decision for representative accounts in scope, a break-glass account is confirmed excluded and independently tested, and a documented step exists to disable or revert the policy without waiting on a change window. If any of these cannot be confirmed, the safe next decision is to hold the policy in report-only mode and escalate to a human reviewer with access to the tenant’s sign-in logs rather than proceeding to enforcement.