Conditional Access

authoredWhat it is

Conditional Access is the policy engine that sits at the front door of every Microsoft Entra-protected resource. Instead of a binary “is this the right password?”, it asks a richer question at sign-in: given who this is, what they’re reaching for, where they are, what device they’re on, and how risky the attempt looks, what should we require before letting them through?

A policy reads as a sentence: if these users reach for these resources under these conditions, then grant access only with these controls (or block). The classic example: “if anyone signs in to the admin portals, then require multifactor authentication.”

authoredWhy it matters

Conditional Access is where a Zero Trust posture stops being a slogan and becomes enforcement. It is the single most important lever an Entra administrator has for the day-to-day security of an organization: it is how you actually require MFA, demand a compliant or hybrid-joined device, block legacy authentication protocols that can’t do MFA, or force a fresh sign-in for sensitive actions. Get it right and most credential-based attacks die at the door; get it wrong and you either lock out your own staff or leave the door open.

authoredHow it relates

Conditional Access sits between authentication and the resource: identity is proven first, then Conditional Access decides what else is required before access is granted. It consumes signals from across the identity model - sign-in and user risk from Identity Protection, device state from Intune/Entra device registration, named locations and IP ranges, and authentication strength. Those same policies extend to guests and customers, so it overlaps with Azure AD B2C and External ID when you protect external-facing access. It is a peer of the authentication-methods and Identity Protection concepts and a building block of Governance scenarios.

cited / groundedCurrent state

A Conditional Access policy has two halves: assignments (the if - target users/groups, target resources or apps, and conditions such as sign-in risk, device platform, location, or client app) and access controls (the then - grant controls like require MFA, require a compliant device, require an approved app, or require an authentication strength; and session controls like sign-in frequency or app-enforced restrictions) - see the policy building blocks. Policies are additive: every policy that applies must be satisfied, and an explicit block always wins. Best practice is to exclude break-glass/emergency-access accounts from every policy and to roll out in report-only mode first, per the Conditional Access overview.

cited / groundedLicensing

Conditional Access requires Microsoft Entra ID P1 for every user the policy applies to, per the Conditional Access overview. Risk-based Conditional Access - policies that use sign-in risk or user risk as a condition - additionally requires Microsoft Entra ID P2, because the risk signals come from Identity Protection. P1/P2 are available standalone and bundled (for example in Microsoft 365 E3/E5). As of 2026-06-16; licensing and bundling change - verify against the linked Microsoft sources before relying on this for a purchasing or compliance decision.

cited / groundedHistory

Conditional Access began life as an Azure Active Directory capability. With the July 2023 rename of Azure AD to Microsoft Entra ID it became “Microsoft Entra Conditional Access” - the same engine and policies, under the new brand. Older guidance, blog posts, and PowerShell/Graph references that say “Azure AD Conditional Access” describe the same feature. The rename did not change policy behavior, the Graph resource model, or licensing.

authoredSee also

• Azure AD B2C and External ID - Conditional Access controls extend to external and customer identities.