TTechclick ⚡ XP 0% All lessons
Microsoft · Identity & Access · Conditional AccessInteractive · L1 / L2 / L3

Microsoft Entra Conditional Access — Signals, Conditions, Controls & Zero Trust

Conditional Access is the Zero Trust policy engine in Microsoft Entra ID — one big if-then statement. IF these users on this resource under these conditions (risk, device, location, client app) THEN require MFA, a compliant device, or block. This lesson teaches you to read the signals, write the if-then, test it in report-only first, and back it with strong MFA and Continuous Access Evaluation.

📅 2026-06-19 · ⏱ 16 min · 5 infographics · live policy demo · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

A clear, interactive guide to Microsoft Entra Conditional Access (2026): the if-then Zero Trust policy engine — assignments (users, target resources), conditions (sign-in risk, device platform, location, client app), grant controls (require MFA, compliant device, managed app) and session controls — plus report-only mode, MFA methods, Continuous Access Evaluation (CAE) and security defaults vs CA.

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

The if-then engine

Signals to decision: assignments, conditions, controls.

 2

Conditions & controls

Risk, device, location, app to MFA or block.

 3

Test, MFA & CAE

Report-only, MFA methods, near-real-time revoke.

 4

Baselines & defaults

Security defaults vs CA, common starter policies.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. What shape is a Conditional Access policy?

Answered in The if-then engine.

2. Which control forces a compliant device or MFA?

Answered in Conditions & controls.

3. How should you turn on a brand-new CA policy in production?

Answered in Test, MFA & CAE.

Most engineers think…

Most people think Conditional Access is 'the thing that nags you for MFA'. That mental model is too small for an interview and for real design work.

Conditional Access is the Zero Trust policy engine of Microsoft Entra ID — one big if-then statement. The IF half collects signals (who the user is, which app, and conditions like sign-in risk, device platform, location and client app); the THEN half is the decision (grant access but require MFA or a compliant device, limit the session, or block). MFA is just one possible control. Understanding the signal-to-control flow is what lets you write a precise policy, test it in report-only first, and explain exactly why a given sign-in was challenged or blocked.

① What Conditional Access actually is — one if-then policy engine

The core idea: a Conditional Access policy is an if-then statement. If a set of assignments are met, then apply the access controls. Entra combines signals — user, device, location, app, risk — to make a decision and enforce your organisation's policy. That is exactly how Microsoft frames the engine that underpins Zero Trust: verify explicitly, use least privilege, assume breach.

Every sign-in is evaluated in two phases. Phase 1 collects session details (network location, device identity). Phase 2 enforces: if a block control applies it stops there; otherwise the user is prompted for any missing grant controls (MFA, compliant device, and so on) in order until the policy is satisfied. Multiple policies can apply to one sign-in, and all of them must be satisfied — assignments are combined with AND.

Figure 1 — The Conditional Access loop — signal, decision, enforce
Every sign-in runs the same if-then loop: gather signals, evaluate policy, enforce the access controls, log the result.The Conditional Access loop — signal, decision, enforceSign-inuser hits an appSignalsrisk/device/loc/appEvaluateif-then policyEnforceMFA / block / allowLogsign-in + report
Every sign-in runs the same if-then loop: gather signals, evaluate policy, enforce the access controls, log the result.
Figure 2 — Anatomy of one CA policy
A policy is assignments + conditions (the IF) and access controls (the THEN) — read top to bottom.Anatomy of one CA policyAssignmentsUsers/groups + target resources (apps)ConditionsRisk, device platform, location, client appGrant controlsRequire MFA / compliant device / blockSession controlsSign-in frequency, persistent browser
A policy is assignments + conditions (the IF) and access controls (the THEN) — read top to bottom.
Quick check · Q1 of 10 · Understand

A Conditional Access policy is best described as…

Correct: b. CA combines signals (user, app, risk, device, location, client app) into an if-then decision. If the assignments and conditions match, it enforces grant or session controls — block, require MFA, require a compliant device, etc.
👉 So far: Conditional Access = the Zero Trust if-then engine. If assignments + conditions match, then apply access controls. Evaluated every sign-in; all applicable policies must pass (AND).

② Conditions and controls — signals in, decision out

The IF half has two parts. Assignments = which users/groups (always exclude your break-glass emergency-access accounts) and which target resources (apps, user actions, or authentication contexts). Conditions refine it: sign-in risk and user risk (from Identity Protection), device platform (Windows/iOS/Android/macOS), location via named locations (trusted IP ranges or countries), and client app (browser, mobile/desktop, or legacy clients).

The THEN half: grant and session controls

Grant controls either block or grant with requirements: require MFA, require authentication strength (e.g. phishing-resistant), require a compliant (Intune) or hybrid-joined device, require an approved client app or app-protection policy, require a password change, or accept terms of use. Session controls shape the experience: sign-in frequency, persistent browser, app-enforced restrictions, and Conditional Access App Control via Defender for Cloud Apps. A classic example: finance users on the payroll app must do MFA and use a compliant device; anyone else is blocked.

Figure 3 — Signals that feed the decision
Conditional Access combines these signals, then chooses grant controls — write once, enforce at every sign-in.Signals that feed the decisionCA engineif-then decisionUser / groupTarget appSign-in riskDevice platformLocationClient app
Conditional Access combines these signals, then chooses grant controls — write once, enforce at every sign-in.
🧩
Assignments
tap to flip

The IF target — which users/groups (minus break-glass exclusions) and which target resources/apps the policy applies to.

🚦
Conditions
tap to flip

Signals that refine scope: sign-in/user risk, device platform, location (named locations) and client app (incl. legacy).

✅
Grant controls
tap to flip

The THEN: block, or require MFA / authentication strength / compliant or hybrid device / approved app. AND or OR across controls.

⏱️
Session controls
tap to flip

Shape the session — sign-in frequency, persistent browser, app-enforced restrictions, and Conditional Access App Control.

Separate the IF from the THEN

In an interview, say it cleanly: Assignments + Conditions are the IF (who, which app, under what signals); Access controls are the THEN (grant with MFA / compliant device, or block, plus session limits). Conditions decide WHEN a policy fires; controls decide WHAT happens. That split is the whole engine.

Quick check · Q2 of 10 · Apply

You want users on the payroll app to do MFA AND use a compliant device. Where does that live?

Correct: c. Require MFA and require a compliant device are both Grant controls. Set 'Require all the selected controls' so the user must satisfy MFA and the compliant-device check. Conditions only decide when the policy applies.
👉 So far: IF = assignments (users + target apps) and conditions (sign-in risk, device platform, location/named locations, client app). THEN = grant controls (MFA, compliant device, block) and session controls.

③ Test it safely — report-only, MFA methods and CAE

Never flip a new policy straight to On. Save it in report-only mode: Entra evaluates the policy on real sign-ins but does not enforce it, logging what would have happened in the sign-in logs and the Insights workbook. The What If tool simulates a specific user, app and conditions so you can see which policies apply before anyone is affected. Baseline, confirm there are no surprises, then switch to On.

Strong MFA and Continuous Access Evaluation

A grant control is only as strong as the method behind it. Entra MFA methods run from SMS/voice and the Microsoft Authenticator app up to phishing-resistant options — passkeys (FIDO2), Windows Hello for Business and certificate-based auth — and users register these on the My Security Info page. Continuous Access Evaluation (CAE) then closes the gap that token lifetime leaves: services like Exchange Online, SharePoint and Teams subscribe to critical events (account disabled, password reset, high user risk, admin token revoke) and to CA policy changes, so access is revoked in near real time instead of waiting up to an hour for the token to expire. CAE lets Entra issue longer-lived tokens (up to ~28 hours) safely.

Figure 4 — How CAE revokes access in near real time
A critical event (e.g. account disabled) is signalled to the resource, which rejects the live token instead of waiting for it to expire.How CAE revokes access in near real timeToken issuedlong-lived w/ CAECritical eventdisable / risk / resetSignal sentEntra to serviceToken rejected401 + claim challengeReauthre-evaluate policy
A critical event (e.g. account disabled) is signalled to the resource, which rejects the live token instead of waiting for it to expire.
Forgetting the break-glass exclusion

The most expensive CA mistake is locking every admin out with one bad policy. Always exclude dedicated emergency-access (break-glass) accounts from every policy, test in report-only, and use the What If tool before you enforce. A misconfigured 'block' control hits everyone, including you.

▶ Watch a risky sign-in get challenged for MFA

How one sign-in is evaluated end-to-end. Press Play for the healthy path, then Break it to see the classic failure.

① Sign-inA user signs in to Outlook on the web from an unusual country, with valid username and password.
▼
② SignalsEntra collects signals: sign-in risk = medium (atypical location), device unmanaged, client = browser.
▼
③ EvaluateThe CA policy 'risky sign-ins require MFA' matches the assignments and the medium-risk condition.
▼
④ Grant + MFAAccess is granted only after the user passes MFA in the Authenticator app; the sign-in log records it.
Press Play to step through the healthy challenge path. Then press Break it.
Quick check · Q3 of 10 · Analyze

Why can Continuous Access Evaluation revoke access before the token would normally expire?

Correct: b. CAE lets services like Exchange, SharePoint and Teams subscribe to critical events (disable, password reset, high risk, admin revoke) and CA policy changes, so they reject an unexpired token with a 401 + claim challenge — near-real-time revocation, not waiting for expiry.
👉 So far: Test in report-only + What If before enforcing. Back grant controls with strong MFA (passkeys/Authenticator). CAE revokes access in near real time on critical events, not at token expiry.

④ Security defaults vs CA — and the baseline policies to ship

Two ways to enforce identity hygiene. Security defaults are a free, one-click on/off baseline for tenants without premium licences: require everyone to register MFA, force MFA when needed, block legacy authentication and device code flow, and protect privileged portals. No customisation, no exclusions. Conditional Access needs Entra ID P1 (risk-based policies need P2 / Identity Protection) and is fully customisable — but you can't run both at once, so creating CA policies means disabling security defaults.

The starter set everyone should ship

Microsoft's secure-foundation templates are the baseline: block legacy authentication, require MFA for admins (ideally phishing-resistant), require MFA for all users, require MFA for Azure management, secure the security-info registration page, and require a compliant or hybrid-joined device. Add risk-based policies on P2: require MFA on risky sign-ins, force a password change for high-risk users. Always exclude break-glass accounts, deploy in report-only, then enforce in phases.

Figure 5 — Security defaults vs Conditional Access
Same goal — block attacks at sign-in — but defaults are a free on/off switch, CA is the granular P1/P2 engine.Security defaults vs Conditional AccessSecurity defaultsFree, all tenantsOne-click on/offNo exclusions or scopingGood starting pointConditional AccessEntra ID P1 (risk = P2)Fully customisable if-thenPer-user/app/condition scopeReport-only + What If testing
Same goal — block attacks at sign-in — but defaults are a free on/off switch, CA is the granular P1/P2 engine.

Priya, an IT admin at a Pune fintech, faces this

She switches a new 'require compliant device for all users' policy straight to On at 9am and the helpdesk is flooded — staff on personal laptops and macOS users are all locked out.

Likely cause

The policy went live with no report-only baseline, no device-platform scoping, and break-glass accounts weren't excluded.

Diagnosis

Sign-in logs show 'Failure' with the compliant-device grant control unmet for hundreds of users; many devices were never enrolled in Intune.

Entra admin center ▸ Conditional Access ▸ Policies + Sign-in logs (Report-only tab)
Fix

Roll the policy back to report-only, exclude break-glass accounts, pilot on one group, enrol devices in Intune, and use 'require compliant OR hybrid-joined OR MFA' so unmanaged users can still reach low-risk apps. Then enforce in phases.

Verify

Re-check the Insights workbook: enrolled users pass silently, the pilot group is clean, and only genuinely non-compliant high-risk sign-ins are challenged.

Prove impact from the logs, not a hunch

Never close a CA ticket on 'should be fine'. The sign-in log shows the exact policies applied, which grant controls were unmet, and (in report-only) what would have happened. That single read explains most access denials without guessing.

Quick check · Q4 of 10 · Evaluate

A tenant with Entra ID P1 wants per-app, per-location MFA rules. Defaults or Conditional Access?

Correct: d. Security defaults are a free on/off baseline with no scoping or exclusions. Granular per-app, per-location, per-condition rules need Conditional Access (P1; risk-based needs P2). You can't run both, so enabling CA means turning defaults off.
👉 So far: Security defaults = free on/off baseline; Conditional Access = P1/P2 granular engine (can't run both). Baseline: block legacy auth, MFA for admins + all users, secure registration, compliant device.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

📝 Wrap-up assessment — six more

You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.

Q5 · Remember

Which two halves make up a Conditional Access policy?

Correct: b. A CA policy is an if-then statement: the IF half is assignments plus conditions, and the THEN half is the access controls (grant or session). That split is the foundation of the whole engine.
Q6 · Understand

Which of these is a CONDITION (a signal), not an access control?

Correct: a. Sign-in risk is a condition/signal that decides when a policy applies. Require MFA, require a compliant device and block are access controls — the outcome the policy enforces.
Q7 · Apply

A user copies sensitive files; you want unmanaged devices to get read-only access in SharePoint. Which control?

Correct: c. App-enforced restrictions is a session control that passes device state to Exchange/SharePoint to grant limited (e.g. read-only/no-download) access on unmanaged devices. Grant controls allow or block; conditions only scope.
Q8 · Analyze

What is the single most important account type to EXCLUDE from CA policies?

Correct: b. Dedicated break-glass (emergency-access) accounts must be excluded from every policy so a misconfiguration — especially a block control — can never lock all administrators out of the tenant.
Q9 · Evaluate

Why deploy a new CA policy in report-only mode first?

Correct: d. Report-only evaluates the policy on real sign-ins and logs what would happen, but does not enforce grant or session controls. You baseline impact (Insights workbook, What If), then switch to On — avoiding a mass lockout.
Q10 · Evaluate

An interviewer asks how access can be revoked before a token expires. Best answer?

Correct: c. CAE has resource services subscribe to critical events (disable, password reset, high risk, admin revoke) and CA policy changes, so they reject an unexpired token with a 401 + claim challenge — near-real-time revocation that also lets Entra issue longer-lived tokens safely.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: why is Conditional Access called an 'if-then policy engine' rather than just 'MFA'? Then compare with the expert version.

Expert version: Because it makes a decision from signals, not just a yes/no MFA prompt. The IF half — assignments (users + target apps) and conditions (sign-in risk, device platform, location, client app) — describes exactly when the policy applies. The THEN half — grant controls (require MFA, a compliant or hybrid device, an approved app, or block) and session controls (sign-in frequency, persistent browser) — describes what happens. MFA is one possible control among many. That is why it is the Zero Trust policy engine: it verifies explicitly from context, and you test it in report-only before enforcing.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📖 Glossary

Conditional Access (CA)
Microsoft Entra's Zero Trust policy engine — an if-then statement of assignments/conditions and access controls, evaluated at sign-in.
Assignments
The IF target of a policy: which users/groups (minus exclusions) and which target resources (apps, user actions, auth contexts).
Conditions
Signals that refine scope: sign-in/user risk, device platform, location (named locations) and client app, including legacy clients.
Grant controls
The decision: block, or grant while requiring MFA, authentication strength, a compliant/hybrid device, or an approved/managed app.
Session controls
Limits on the session — sign-in frequency, persistent browser, app-enforced restrictions, Conditional Access App Control.
Report-only mode
A policy state that evaluates sign-ins and logs the result without enforcing, so you can baseline impact before turning it On.
Named location
A reusable label for IP ranges or countries/regions used in the location condition (e.g. mark the office network as trusted).
Continuous Access Evaluation (CAE)
Near-real-time revocation: services reject live tokens on critical events (disable, password reset, high risk) instead of at expiry.
Security defaults
A free, one-click baseline (MFA registration, MFA when needed, block legacy auth/device code flow) for tenants without premium licences.
Authentication strength
A grant control that requires a specific class of MFA method, e.g. phishing-resistant (passkeys/FIDO2, Windows Hello, CBA).

📚 Sources

  1. Microsoft Learn — What is Conditional Access? (overview, Zero Trust, P1/P2 licensing). learn.microsoft.com/entra/identity/conditional-access/overview
  2. Microsoft Learn — Build a Conditional Access policy (assignments, conditions, grant & session controls, two-phase evaluation). learn.microsoft.com/entra/identity/conditional-access/concept-conditional-access-policies
  3. Microsoft Learn — Analyze Conditional Access policy impact: report-only mode & the What If tool. learn.microsoft.com/entra/identity/conditional-access/concept-conditional-access-report-only
  4. Microsoft Learn — Continuous Access Evaluation (critical events, claim challenge, ~28-hour tokens). learn.microsoft.com/entra/identity/conditional-access/concept-continuous-access-evaluation
  5. Microsoft Learn — Security defaults in Microsoft Entra ID (vs Conditional Access). learn.microsoft.com/entra/fundamentals/security-defaults
  6. Microsoft Learn — Conditional Access policy templates & authentication methods (passkeys/FIDO2, Authenticator). learn.microsoft.com/entra/identity/conditional-access/concept-conditional-access-policy-common

What's next?

Got the policy engine? Next, go deep on Identity Protection and PIM — how user-risk and sign-in-risk are actually calculated (the signals CA consumes here), and how just-in-time privileged roles cut standing admin access.

Next · All interview lessons → Practice on exam.techclick.in →