7.2 Session Management, Device Restrictions & CAE

Beyond allow/block: session controls matter

Grant controls answer whether access is allowed. Session controls answer how constrained the allowed session is. On SC-300, candidates who only memorize “require MFA” miss stems about reauthentication every hour, disabling “keep me signed in,” blocking downloads through Defender for Cloud Apps, or tokens dying mid-day after an account disable.

Session controls appear on the Conditional Access policy under access controls (alongside grant). Not every control applies to every app—Microsoft documents which apps support app-enforced restrictions, CAE, and CA App Control. Exam answers should match supported capability + scenario intent, not invent universal support for every SaaS app.

/practice/azure-sc-300Practice questions with detailed explanations

Session control catalog

Think of grants as the front door lock and session controls as how long the visitor may stay and what rooms they can enter once inside.

Sign-in frequency

Sign-in frequency defines the time period after which a user is required to sign in again when accessing a resource. Examples:

• Default Microsoft token lifetimes may allow long-lived refresh behavior; frequency policies force earlier interactive reauthentication.
• Admins accessing Microsoft Azure Management might reauthenticate every 1 hour or 4 hours.
• Privileged sessions after PIM activation may still benefit from tighter CA frequency on sensitive apps.

Exam balance: security vs friction. “Every time” for all users on all M365 apps is usually operationally harsh; targeted admin or high-risk policies are more realistic. Sign-in frequency is not the same as MFA registration, and it is not Continuous Access Evaluation—frequency is periodic reauth policy; CAE is event-driven evaluation.

Persistent browser session

Persistent browser session controls whether the browser may remain signed in after the user closes and reopens it (the classic “Stay signed in?” behavior, governed by policy).

SC-300 cue: shared nursing-station PCs or factory-floor browsers → never persistent plus short sign-in frequency. Executive phishing-resistant MFA on a personal compliant laptop may still disable persistence for admin portals.

App-enforced restrictions and device-oriented session limits

App-enforced restrictions tell supported Microsoft cloud apps to enforce a limited, device-aware experience. Classic pairing:

1. Conditional Access policy requires compliant device (or hybrid joined) or allows access with limited experience on unmanaged devices.
2. For Exchange Online / SharePoint Online (supported scenarios), app-enforced restrictions can result in limited web-only experiences that restrict download/print/sync style actions depending on app capabilities and configuration.

Related device themes you must keep straight:

Device-enforced restrictions in exam language often means: use CA so only managed/compliant/hybrid devices get full access, and unmanaged devices are blocked or get a restricted session. Do not confuse this with on-premises Active Directory device restriction policies or Group Policy software restrictions—those are not Entra Conditional Access.

Practical design patterns

Conditional Access App Control (Microsoft Defender for Cloud Apps)

Conditional Access App Control integrates Conditional Access with Microsoft Defender for Cloud Apps (MDCA) (formerly Microsoft Cloud App Security). Instead of a pure allow, the session can be reverse-proxied/monitored for supported apps so you can:

• Monitor only — visibility into user activities in the session.
• Block downloads — prevent download of sensitive content in session.
• Apply other MDCA session policies aligned to your Defender for Cloud Apps configuration.

MDCA is a security product integration, not a free checkbox on Entra ID P1 alone in every licensing bundle—exam stems that mention Defender for Cloud Apps session control are pointing at this integration. If the stem only has Entra ID P1 and SharePoint limited access language, prefer app-enforced restrictions / device grants over inventing MDCA.

Continuous Access Evaluation (CAE)

Historically, once a client held a valid access token, resource access could continue until the token expired—even if the user was disabled minutes earlier—unless other revocation paths intervened. Continuous Access Evaluation improves this by enabling near real-time enforcement of critical events for supported apps and clients.

Why tokens get revoked mid-session

With CAE, critical events can cause the resource to reject the token and force reauthentication or deny access before the normal access-token lifetime ends.

Not every app and not every event is universal. Microsoft documents CAE support for key first-party experiences (for example Microsoft Graph / Exchange / SharePoint / Teams patterns as published) and client support requirements. SC-300 wants the concept: CAE closes the gap between identity state change and resource enforcement so you do not wait solely on access-token expiry.

CAE vs sign-in frequency vs revoke sessions

Exam story: “Admin disables a contractor at 10:05; contractor still opens SharePoint files at 10:07.” Modern answer space includes CAE-supported enforcement and ensuring sessions revoked / account blocked correctly—not “wait eight hours for the access token to die.” Another story: “Require reauthentication every hour for PIM-capable admins on Azure portal” → sign-in frequency, not CAE critical events.

Operational implications for identity admins

1. Prefer disable account + revoke sessions as the human response to compromise; CAE improves how quickly supported resources honor identity changes.
2. Do not promise CAE for every third-party OIDC app—support varies.
3. Network location policies with CAE have specific design notes (strict location enforcement trade-offs); know that location-based CAE scenarios exist at concept level.
4. Pair CAE understanding with earlier token knowledge: access tokens are short-lived API credentials; refresh tokens renew them; CAE and revocation target the gap between “identity says no” and “API still says yes.”

Device restrictions in end-to-end Zero Trust access

A complete SC-300 device story for Conditional Access usually chains:

1. Device join/registration — Microsoft Entra joined, hybrid joined, or registered (Workplace Join).
2. MDM compliance — Intune marks device compliant/noncompliant.
3. CA grant — require compliant and/or hybrid joined and/or app protection.
4. CA session — limited experience or MDCA controls when full grant is not met.
5. CAE / revoke — when the user or device posture changes critically, sessions do not linger blindly.

Common misconfigurations:

• Requiring compliant device before any devices are enrolled → mass lockout (use report-only first).
• Forgetting macOS/iOS/Android platform conditions when only Windows is ready.
• Using hybrid joined requirement for cloud-only contractors who will never hybrid join.
• Expecting app protection policy to mark the device compliant—it does not; MAM ≠ device compliance.

Scenario drills

Summary of section 7.2

Session management turns a binary allow into a managed session. Configure sign-in frequency and persistent browser for privileged and shared-device scenarios; use app-enforced restrictions and device grants for Microsoft 365 device-aware limits; use Conditional Access App Control when the scenario names Defender for Cloud Apps session governance; and rely on Continuous Access Evaluation plus session revocation so critical identity events invalidate access mid-session for supported apps. Next, section 7.3 covers authentication context step-up, protected actions, templates, and how to troubleshoot CA with logs and insights.