Conditional Access: Advanced Controls & Troubleshooting

Beyond basic Conditional Access

The What If tool

The What If tool simulates a sign-in scenario and shows which CA policies would apply and what their outcome would be.

Where to find it: Entra admin center → Protection → Conditional Access → What If

Inputs you provide:

• User — which user or service principal
• Cloud app — which application they’re accessing
• IP address — simulate a specific location
• Device platform — Windows, iOS, Android, etc.
• Client app — browser, mobile app, desktop client
• Sign-in risk / User risk — simulate risk levels
• Device state — compliant, Entra Joined, etc.

Output shows:

• Policies that will apply (green check)
• Policies that will not apply (grey) — and why (which condition didn’t match)
• The combined result — would the user be granted or blocked?

ℹ️ Scenario: Dex troubleshoots a blocked sign-in

A nurse at Meridian Health reports she can’t access Outlook from her personal phone. The error says “Access has been blocked by Conditional Access.”

Dex uses What If:

1. Selects the nurse’s account
2. Sets cloud app = Exchange Online
3. Sets device platform = iOS
4. Sets client app = Mobile apps and desktop clients
5. Leaves device state = Not compliant (personal phone)

Result: What If shows that Policy 5 (“Require compliant device for Exchange and SharePoint”) blocks access. The nurse’s personal phone isn’t Intune-enrolled.

Resolution options:

• Option A: Nurse enrolls her phone in Intune (becomes compliant) — not ideal for personal devices
• Option B: Use Outlook Web Access (browser) which has a different session control (app-enforced restrictions limit what she can do)
• Option C: Add an exception for mobile app protection policy (if configured) — allows managed apps without full device enrollment

Dex recommends Option C and works with the Intune admin to configure it.

Session controls

Session controls determine what happens DURING a session, not just at sign-in.

Session Control	What It Does
Sign-in frequency	How often users must re-authenticate (e.g., every 4 hours, every time)
Persistent browser session	Whether the session survives closing the browser (Yes = stay signed in, No = re-auth on reopen)
Application enforced restrictions	Apps limit functionality based on device state (e.g., SharePoint read-only on unmanaged devices)
Conditional Access App Control	Routes sessions through Microsoft Defender for Cloud Apps for real-time monitoring
Customise continuous access evaluation	Disable CAE for specific scenarios if needed
Disable resilience defaults	Prevent Entra from extending sessions during outages

Sign-in frequency

Controls how often users must fully re-authenticate. Default: Entra asks for re-auth when the refresh token expires (rolling 90-day window with activity). You can override this:

• Every time — re-authenticate at every sign-in (highest security, worst experience)
• Custom hours/days — e.g., every 4 hours for sensitive apps, every 7 days for general apps

Common pattern: Require 4-hour sign-in frequency for the Azure portal and admin apps, but allow 30-day frequency for standard apps.

Application enforced restrictions

When enabled, Entra sends device state information to the app. The app decides what to restrict:

• SharePoint Online — can enforce read-only access (no download, no print) on unmanaged devices
• Exchange Online — can restrict attachment downloads on unmanaged devices

This requires the app to support it — not all apps do. SharePoint and Exchange are the main ones.

💡 Exam tip: app-enforced restrictions vs CA App Control

These are different:

• Application enforced restrictions — the app itself limits functionality based on device state signals. Native to SharePoint/Exchange. No third-party proxy.
• Conditional Access App Control — routes traffic through Microsoft Defender for Cloud Apps proxy. Can monitor/block actions in real-time, apply DLP, prevent downloads. Works with more apps but requires Defender for Cloud Apps licence.

If the exam asks about “limiting downloads from unmanaged devices in SharePoint,” both could work — but app-enforced restrictions is the simpler, native answer.

Continuous access evaluation (CAE)

Standard token flow: user authenticates → gets a 1-hour access token → token is valid until expiry, even if the account is disabled or the session is revoked.

CAE changes this. It creates a direct channel between Entra ID and resource providers (Exchange, SharePoint, Teams) so that critical events are enforced near-instantly (within minutes, not hours).

Critical events CAE responds to:

• User account is disabled or deleted
• User password is changed or reset
• MFA is enabled for the user
• Admin explicitly revokes refresh tokens
• User risk is elevated (detected by ID Protection)
• Network location changes (if location-based policies are in place)

How it works:

1. User gets a long-lived access token (up to 28 hours instead of 1 hour)
2. Resource provider (e.g., Exchange) subscribes to critical events from Entra
3. If a critical event fires, the resource provider rejects the token immediately
4. User must re-authenticate

Key benefit: Longer tokens (better UX, fewer sign-in prompts) with faster revocation (better security). Best of both worlds.

ℹ️ Scenario: Priya implements CAE at Meridian Health

Before CAE, when Dex disabled a compromised account and revoked sessions, the attacker’s existing access token could still work for up to an hour. With CAE:

1. Dex disables the compromised account
2. Entra fires a “user disabled” critical event
3. Exchange Online, SharePoint, and Teams receive the event within minutes
4. The attacker’s long-lived token is immediately rejected
5. The attacker is forced to re-authenticate — which fails because the account is disabled

Result: The window of exposure drops from up to 60 minutes to under 5 minutes.

Priya also configures a location-based CA policy. If a user signs in from the office and then their connection appears from another country (IP change), CAE triggers re-evaluation immediately.

Authentication context

Authentication context lets you require step-up authentication for specific actions WITHIN an application, not just at sign-in.

Example: A user signs in to SharePoint with MFA. They can browse files normally. But when they try to access a document library tagged “Confidential,” they’re prompted for phishing-resistant MFA because that library has an authentication context that requires stronger auth.

How to set it up:

1. Create authentication context values in Entra (e.g., C1 = Sensitive Data Access, C2 = Admin Action)
2. Create a CA policy targeting that authentication context (instead of a cloud app)
3. Assign the authentication context to the resource:
   • SharePoint — sensitivity labels on sites/libraries
   • Defender for Cloud Apps — session policies
   • Custom apps — via claims in the token

ℹ️ Scenario: Priya protects sensitive patient records

Meridian Health has a SharePoint site for patient records. Standard staff access SharePoint daily — requiring phishing-resistant MFA at every sign-in would be disruptive.

Priya’s approach:

1. Creates authentication context C1 = "Access patient records"
2. Creates a CA policy: IF authentication context = C1, THEN require phishing-resistant MFA
3. Applies a sensitivity label with auth context C1 to the “Patient Records” SharePoint site

Result: Staff sign in to SharePoint normally with standard MFA. When they navigate to the Patient Records site, they’re prompted for phishing-resistant MFA (FIDO2 key or WHfB). Other SharePoint sites work without the extra step. Security where it matters, convenience everywhere else.

Protected actions

Protected actions require step-up authentication before performing critical admin operations in Entra ID itself.

Examples of protectable actions:

• Deleting a Conditional Access policy
• Modifying named locations used by CA policies
• Removing a trusted CA certificate
• Changing authentication methods policy settings
• Modifying cross-tenant access settings

How it works:

1. Admin signs in normally with MFA
2. Admin tries to delete a CA policy
3. Entra checks: “Is ‘delete CA policy’ a protected action?”
4. If yes, the admin must satisfy an additional authentication context (e.g., phishing-resistant MFA)
5. Only after step-up auth can the admin complete the action

Why it matters: Even if an admin account is compromised, the attacker can’t easily dismantle your security posture. Deleting CA policies or removing trusted certificates requires proving identity again with a strong method.

💡 Exam tip: protected actions vs PIM

Protected actions and Privileged Identity Management (PIM) are different layers:

• PIM — controls WHO can activate admin roles and WHEN (just-in-time access)
• Protected actions — controls WHAT authenticated admins can DO (step-up auth for critical operations)

They complement each other. An admin might need PIM to activate Global Admin, and then protected actions to step-up auth before deleting a CA policy.

🎬 Video walkthrough

🎬 Video coming soon

CA Advanced Controls — SC-300 Module 13

CA Advanced Controls — SC-300 Module 13

~13 min

Flashcards

Question

What is the What If tool in Conditional Access?

Click or press Enter to reveal answer

Answer

A simulation tool that evaluates which CA policies would apply to a hypothetical sign-in scenario. You input user, app, device, location, and risk level — it shows which policies match, which don't (and why), and the combined result. Found in Entra admin center → Protection → Conditional Access → What If.

Click to flip back

Question

How does Continuous Access Evaluation (CAE) improve security?

Click or press Enter to reveal answer

Answer

CAE creates a direct channel between Entra and resource providers (Exchange, SharePoint, Teams). Critical events (account disabled, password changed, tokens revoked, risk elevated) are enforced within minutes instead of waiting for token expiry. Tokens can be longer-lived (up to 28 hours) because revocation is near-instant.

Click to flip back

Question

What is authentication context and when would you use it?

Click or press Enter to reveal answer

Answer

Authentication context requires step-up authentication for specific ACTIONS within an app (not just at sign-in). Example: browsing SharePoint = standard MFA, but accessing a 'Confidential' library = phishing-resistant MFA. Created in Entra, linked to CA policies, and assigned to resources via sensitivity labels or app configurations.

Click to flip back

Question

What are protected actions in Entra ID?

Click or press Enter to reveal answer

Answer

Protected actions require step-up authentication before critical admin operations (deleting CA policies, modifying named locations, removing trusted CAs). Even authenticated admins must re-verify identity with a stronger method. Different from PIM: PIM controls who/when for role activation, protected actions control what authenticated admins can do.

Click to flip back

Knowledge Check

Knowledge Check

A user reports they can access SharePoint on their work laptop but not on their personal phone. Dex wants to identify which CA policy is blocking the phone. What should he use?

AUse the What If tool with the user's details, device platform set to iOS/Android, and device state set to non-compliantBCheck the user's sign-in logs for the error code and look it up onlineCTemporarily disable all CA policies and re-enable them one by oneDAsk the user to try a different browser on their phone

Check Answer

Knowledge Check

Meridian Health wants SharePoint documents labelled 'Confidential' to require phishing-resistant MFA, but standard SharePoint access should only require regular MFA. What should Priya configure?

ATwo CA policies — one for SharePoint requiring MFA, one requiring phishing-resistant MFA for all SharePoint access with a user-group filterBA Defender for Cloud Apps session policy that blocks access unless using FIDO2CConfigure SharePoint site-level permissions to only allow users with FIDO2 keys registeredDAn authentication context linked to a CA policy requiring phishing-resistant MFA, applied via a sensitivity label to the Confidential sites

Check Answer

Knowledge Check

An organisation disables a compromised admin account and revokes all sessions. With CAE enabled, how quickly is the attacker's existing access to Exchange Online terminated?

AWithin minutes — CAE propagates the critical event to Exchange Online, which rejects the tokenBImmediately — the access token is invalidated in real-timeCWithin 1 hour — when the standard access token expiresDWithin 24 hours — at the next refresh token evaluation

Check Answer

---

Next up: Entra ID Protection: Risk-Based Security — configure user risk policies, investigate risky sign-ins, and protect against identity-based attacks with Microsoft Entra ID Protection.