Conditional Access

These signals form the primary identity context for a request.

• User Risk Level: Calculated by identity protection services based on leaked credentials, anomalous travel, or impossible travel patterns.
• Sign-in Risk: Real-time assessment of the current authentication attempt (e.g., from an anonymous IP, unfamiliar location).
• Group Membership: The user's assigned security groups, which define baseline roles and permissions.
• Job Function: A formal attribute often used in HR systems to derive high-level access requirements.

These signals assess the security posture and trustworthiness of the endpoint and network path.

• Device Compliance: Whether the device is managed (e.g., via Intune, Jamf) and adheres to policies (encryption enabled, OS version minimum).
• Hybrid Azure AD Join: Indicates the device is registered with both on-premises Active Directory and Azure AD.
• Network Location: Derived from IP address, used to identify corporate networks, named locations, or blocked countries.
• Client Application: The specific application making the request (e.g., browser, mobile app, legacy desktop client).

These signals define the sensitivity and requirements of the target being accessed.

• Application Sensitivity: A classification (e.g., low, medium, high business impact) assigned to the SaaS app or on-premises application.
• Data Classification Labels: If the resource (like a SharePoint file or Teams message) has Microsoft Purview sensitivity labels applied.
• Authentication Context: A custom tag that can be sent by an application to request a higher level of assurance for specific actions within the app.

These signals provide continuous evaluation during an active session.

• Persistent Browser Session: Indicates if the user selected 'Stay signed in'.
• Sign-in Frequency: Time elapsed since the user's primary authentication.
• User Behavior Analytics: Deviations from established baselines for typical access patterns (e.g., accessing unusual resources, atypical volume of activity).

These are the primary actions taken when policy conditions are met to allow access, typically by requiring additional proof.

• Require Multi-Factor Authentication (MFA): Forces a second factor via an authenticator app, SMS, or FIDO2 key.
• Require Device to be Marked as Compliant: Blocks access unless the device meets health and configuration policies.
• Require Hybrid Azure AD Joined Device: Restricts access to corporate-managed devices only.
• Require Approved Client App: Forces the use of managed applications like Microsoft Edge or the Outlook mobile app.
• Require App Protection Policy: Ensures a mobile app has Intune app protection policies applied (e.g., data encryption, prevent copy/paste).

These controls restrict what a user can do during an active session without blocking the initial sign-in.

• App-Enforced Restrictions: Limits user actions within specific applications (e.g., block download, allow only web view).
• Conditional Access App Control: Routes traffic through a secure proxy (like Microsoft Defender for Cloud Apps) for real-time monitoring and control, enabling features like block copy/paste, download restriction, and session revocation.
• Sign-in Frequency: Forces re-authentication after a specified time period, regardless of session token validity.

A static authorization model where permissions are assigned to roles, and users are assigned to roles. It provides the foundational entitlements that Conditional Access policies evaluate and enforce dynamically.

• Static Foundation: Defines what a user is allowed to do (e.g., "Editor," "Viewer," "Admin").
• Dynamic Layer: Conditional Access adds when, where, and how they can do it based on real-time signals.
• Example: A user may have the "Finance-App-User" role, but a Conditional Access policy could block access if they are connecting from an unmanaged device.

An authentication method that requires a user to provide two or more verification factors from distinct categories (knowledge, possession, inherence). It is a critical action enforced by Conditional Access policies.

• Common Signals: A Conditional Access policy might trigger MFA based on location (unfamiliar network), device (unmanaged), or application sensitivity (accessing HR systems).
• Factor Types: Something you know (password), something you have (security key/phone), something you are (biometric).
• Enforcement: Policies can require MFA for specific conditions while allowing seamless access for low-risk scenarios.

The structured data within an access token that communicates the authenticated user's identity, permissions, and context to a resource server (API). Conditional Access policies directly influence the claims issued in tokens.

• Key Claims: acr (Authentication Context Class Reference) can indicate MFA was performed. amr (Authentication Methods References) lists methods used.
• Policy-Driven: A policy might add a device_compliant: true claim only if the accessing device meets corporate security standards.
• Scope Enforcement: Policies ensure tokens are only issued with approved OAuth scopes (e.g., mail.read) for the given context.

The architectural components that separate the logic of an access decision from its enforcement, as defined in standards like XACML. Conditional Access systems implement this pattern.

• Policy Decision Point (PDP): The Conditional Access engine itself. It evaluates all signals (user, device, location, app, risk) against defined policies to make an Allow/Deny decision.
• Policy Enforcement Point (PEP): The gateway or service (e.g., Azure AD, a ZTNA gateway) that enforces the PDP's decision by blocking the request, requiring MFA, or granting a token.
• Clear Separation: This separation allows centralized policy management and decentralized enforcement across different resources.