Conditional Access

What it is

Conditional Access (CA) is Entra ID’s policy engine that evaluates signals (who, where, what device, what app, sign-in risk) against policies and grants the right controls (require MFA, block, require compliant/hybrid-joined device, force password change).

Why it exists

A one-size-fits-all “always require MFA” is heavy-handed. Conditional Access applies context-aware rules — e.g. “require MFA only for risky sign-ins from outside the corporate network,” or “block legacy protocols.” It’s the modern replacement for per-user MFA forcing.

Key ideas

• Policy components — Assignments (users/groups, cloud apps/actions, conditions like location/device/risk) → Access controls (grant or session control) + Enable policy.
• Grant controls — require MFA, require device to be compliant/hybrid Azure AD joined, require approved client app, require password change.
• Session controls — app-enforced restrictions, sign-in frequency (per-session), persistent browser session.
• Report-only mode / What-If tool — test policies safely before enforcement.
• Best practice — assign to groups, exclude break-glass admin accounts, and enable policies in phases.

How it fits (diagram)

Diagrams courtesy of Microsoft Learn / Azure docs: entra/identity/conditional-access/overview

Exam notes

• CA is per policy, evaluated at sign-in, with conditions and controls.
• Break-glass account exclusion is a known best practice + exam point.
• Used heavily in AZ-400 for pipeline/service-account protection too.

Related

entraid · mfa · user-account · azure-ad-roles

📘 Source: Microsoft Learn — Conditional Access