4.1 Conditional Access Purpose

What Conditional Access actually is

Conditional Access is the policy engine of Microsoft Entra ID that brings signals together to make access decisions and enforce organizational policy. Microsoft describes every Conditional Access policy as an if-then statement: if a set of conditions (assignments) is met, then the policy applies a set of access controls. It is the mechanism that turns the abstract Zero Trust principle "verify explicitly" into an enforced rule at the moment a user tries to reach an application.

Conditional Access is not free with every tenant. It requires at least a Microsoft Entra ID P1 license; risk-based conditions additionally require P2. This licensing distinction is a favorite SC-900 trap, so remember that basic MFA can be turned on in free tenants via security defaults, but policy-driven MFA requires Conditional Access (P1).

• It is an Entra capability — not a Sentinel analytics tool, not a Defender product.
• It enforces least privilege and explicit verification on each access attempt.
• It can block access outright or grant access only when extra requirements are met.
• Security defaults is the simpler, free, all-or-nothing alternative; Conditional Access is the granular, licensed version.

The two-phase decision flow

Microsoft enforces every policy in two phases. Knowing this flow makes scenario questions much easier.

Phase 1 — collect session details. Entra gathers the context it needs: who the user is, what app they want, the network location, the device identity and state, the client app, and any risk level supplied by Microsoft Entra ID Protection. Phase 1 runs even for policies set to report-only mode, which lets admins test a policy's impact before enforcing it.

Phase 2 — enforcement. Entra compares the gathered details against the policy. If any policy uses the block control, evaluation stops and the user is denied. Otherwise the user is prompted to satisfy any unmet grant controls, always in this fixed order:

After all grant controls pass, session controls (sign-in frequency, persistent browser, app-enforced restrictions) shape the resulting session.

Where Conditional Access sits in the identity story

Conditional Access lives between authentication and resource access. It does not create user accounts (that is identity administration in Entra ID), it does not prove who you are by itself (that is the job of authentication methods and MFA), and it does not classify or label data (that is Microsoft Purview). Instead, it consumes the result of authentication plus contextual signals and decides whether the access should be allowed under the current conditions.

A critical exam fact: when multiple Conditional Access policies apply to the same user, all of them must be satisfied. Microsoft combines all assignments with logical AND. So a user hit by one policy requiring MFA and another requiring a compliant device must satisfy both. There is no "most permissive policy wins."

• Account creation → identity administration in Entra ID.
• Proving identity at sign-in → authentication / MFA.
• Deciding access by policy and context → Conditional Access.
• Labeling and retaining data → Microsoft Purview.

Minimum policy and product-matching guardrails

Microsoft states a Conditional Access policy must contain at least: a name, assignments (users/groups and target resources), and access controls (a grant or block decision). If a question lists policy pieces, those are the required ones.

The safest way to pick the right answer is to name the problem before the product. If the scenario is about who may reach a cloud resource under which circumstances, stay in the Entra Conditional Access lane. Defender protects and investigates workloads; Sentinel does SIEM and SOAR; Purview handles compliance and data governance.

• Entra / Conditional Access: policy-based access decisions on cloud resources.
• Defender: protection and threat investigation.
• Sentinel: SIEM, SOAR, hunting, incidents.
• Purview: compliance, classification, retention, audit.

If the problem says "require stronger sign-in only from untrusted networks" or "block legacy authentication," that is textbook Conditional Access.

Why Conditional Access is the heart of Zero Trust

Conditional Access is the place where the three Zero Trust guiding principles become real enforcement. Verify explicitly means every access request is authenticated and authorized using all available data points — that is exactly the signal collection Conditional Access performs. Use least-privileged access is supported because a policy can grant only limited or time-bound sessions rather than open-ended access. Assume breach is honored because access is re-evaluated on each request instead of being trusted forever after one logon.

For SC-900 it is worth stating plainly: Conditional Access is the operational engine that an organization uses to implement Zero Trust for identity and access.

A related concept is continuous access evaluation (CAE). Traditionally an access token is valid for about an hour, so a user who is disabled or whose risk spikes could keep access until the token expires. CAE lets Entra and supporting services (like Exchange Online and SharePoint Online) react in near real time to critical events — a user being disabled, a password reset, or an elevated risk detection — by revoking the session almost immediately. CAE is enabled by default and reinforces the "assume breach" idea that trust must be re-checked, not granted once.

Finally, remember the report-only capability: before enforcing a policy, admins set it to report-only so Entra logs what would have happened without blocking anyone, letting them measure impact and avoid lockouts.

• Verify explicitly → collect and evaluate signals each time.
• Least privilege → grant limited or time-bound sessions.
• Assume breach → re-evaluate access continuously (CAE).
• Report-only → test policy impact before enforcement.