7.2 Session Management, Device Restrictions & CAE

Exam SC-300: Microsoft Identity and Access Administrator Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts & Logistics 1.2 Audience Profile, Zero Trust & Role Scope 1.3 Skills Measured & Study Map

2 Entra Tenant Administration

2.1 Tenant Properties, Domains & Company Branding 2.2 Built-in & Custom Roles, Effective Permissions 2.3 Administrative Units

3 Users, Groups, Licenses & Devices

3.1 Create, Configure & Manage Users 3.2 Groups & Custom Security Attributes 3.3 Licenses, Bulk Operations & Device Join

4 External Identities & Cross-Tenant Access

4.1 External Collaboration & Guest Lifecycle 4.2 Cross-Tenant Access Settings 4.3 Cross-Tenant Sync & External Identity Providers

5 Hybrid Identity

5.1 Entra Connect Sync vs Cloud Sync 5.2 PHS, PTA & Seamless SSO 5.3 AD FS Migration & Connect Health

6 Authentication Methods & MFA

6.1 Authentication Methods Portfolio 6.2 MFA, SSPR & Password Protection 6.3 Passwordless, Session Control & Entra Kerberos

7 Conditional Access

7.1 Planning, Assignments & Controls 7.2 Session Management, Device Restrictions & CAE 7.3 Auth Context, Protected Actions, Templates & Troubleshooting

8 Identity Protection & Global Secure Access

8.1 User Risk & Sign-in Risk 8.2 MFA Registration Campaigns & Risky Workloads 8.3 Global Secure Access

9 Workload & Managed Identities

9.1 Selecting Identities for Apps & Azure Workloads 9.2 Create, Assign & Use Managed Identities 9.3 Service Principals Fundamentals

10 Enterprise Apps & App Registrations

10.1 Enterprise Applications Integration 10.2 App Registrations, API Permissions & App Roles 10.3 Application Proxy & Consent

11 Microsoft Defender for Cloud Apps

11.1 Cloud Discovery & Connected Apps 11.2 CA App Control & Session Policies 11.3 OAuth App Policies & Catalog Management

12 Entitlement Management

12.1 Catalogs & Access Packages 12.2 Access Requests & Terms of Use 12.3 Connected Organizations & External User Lifecycle

13 Access Reviews

13.1 Plan & Create Access Reviews 13.2 Monitor & Respond to Access Reviews

14 Privileged Identity Management

14.1 PIM for Entra Roles & Azure Resources 14.2 PIM for Groups, Approval & Audit 14.3 Break-Glass (Emergency Access) Accounts

15 Monitoring, Logs & Secure Score

15.1 Sign-in, Audit & Provisioning Logs 15.2 Diagnostics, KQL & Workbooks 15.3 Identity Secure Score

7.2 Session Management, Device Restrictions & CAE

Key Takeaways Explain This Topic AI

Session controls refine allowed sessions after grant: sign-in frequency, persistent browser session, app-enforced restrictions, Conditional Access App Control (Microsoft Defender for Cloud Apps), and related options.

Sign-in frequency forces periodic reauthentication; persistent browser session controls whether users stay signed in across browser restarts on managed devices.

App-enforced restrictions and device-based controls help limit download/print or require managed experiences for Exchange and SharePoint Online in supported scenarios.

Conditional Access App Control routes sessions through Microsoft Defender for Cloud Apps for monitor-only or block-download style session governance.

Continuous Access Evaluation (CAE) can revoke or challenge access mid-session for critical events such as user disablement, password change/reset, high user risk, and explicit session revocation—without waiting for access-token expiry alone.

Last updated: July 2026

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 mixed CA stems at /practice/azure-sc-300 .

Session control catalog

• Session control Purpose Typical SC-300 cue
• Sign-in frequency How often the user must reauthenticate “Reauth every 4 hours for admins on Azure portal”

Persistent browser session Allow or prevent browser sessions that survive close/reopen “Do not persist browser sessions on unmanaged PCs”

Use app enforced restrictions Honor app-side limited experiences (for example limited web access for SharePoint/Exchange when device is not compliant) “Prevent download on unmanaged devices for SharePoint” (with supported app behavior)

Use Conditional Access App Control Route through Microsoft Defender for Cloud Apps (MDCA) for monitor/block actions “Monitor sessions” or “block download via session control”

Customize continuous access evaluation Configure CAE-related behavior where exposed Strict location / CAE customization scenarios

Disable resilience defaults (when present) Trade availability during certain outages for stricter evaluation Rare advanced stems

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.

• Setting idea Effect
• Frequency = 1 hour User must reauthenticate at least hourly for matching apps
• Frequency = every time Strongest reauth posture for highly sensitive scenarios (user friction high)
• Frequency not configured Relies on default token/session behavior

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).

Configuration intent When to use

Always persistent Only in carefully controlled kiosk/managed scenarios—usually not the secure default for privileged access

Never persistent Privileged users, shared devices, high-security tenants

Compatible with “Stay signed in” user choice when allowed Standard workforce on managed devices where UX matters

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:

Conditional Access policy requires compliant device (or hybrid joined) or allows access with limited experience on unmanaged devices.

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:

• Concept Control plane Outcome
• Require compliant device (grant) Intune compliance Unhealthy devices fail grant
• Require hybrid joined device (grant) Hybrid join state Non-hybrid devices fail that control
• App protection policy (grant) Intune MAM Org data protected in app on BYOD
• App-enforced restrictions (session) App + CA Limited session on non-compliant/unmanaged paths
• Device filters (condition) CA filtering Target policies by device attributes

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

Business requirement Prefer

Only healthy corporate Windows PCs open finance app Grant: compliant device (and phishing-resistant strength if needed)

Hybrid Windows still rolling out Intune Grant: require one of compliant or hybrid joined

BYOD phones need Outlook with data protection Grant: app protection policy; consider approved clients where still relevant

Unmanaged browsers may read SharePoint but not download Session: app-enforced restrictions / MDCA block download patterns

Contractors on personal PCs must not keep browser sessions Session: never persistent + shorter sign-in frequency

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.

• Exam phrase Likely control
• “Route sessions through Defender for Cloud Apps” Conditional Access App Control

“Block download for unmanaged devices for Salesforce/Box” (catalog app support dependent) CA App Control + MDCA session policy

“Limited access for SharePoint on unmanaged devices” using Microsoft 365 native limited experience Often app-enforced restrictions (verify support)

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.

• Critical event (conceptual) Why it matters
• User account deleted or disabled / blocked sign-in Leaver or compromise response must stop ongoing access
• Password changed or reset Old sessions should not continue with pre-reset credentials posture
• Multifactor authentication enabled for the user (scenario-dependent) Elevate assurance; force fresh auth
• Admin explicitly revokes refresh tokens / sessions Compromise response (“Revoke sessions”)
• High user risk detected (Identity Protection) Risk-based mid-session reaction for supported paths

Token replay / location policy scenarios (where CAE location scenarios apply) Session no longer matches trusted network assumptions

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

• Mechanism Trigger style Primary goal
• Sign-in frequency Time-based policy Periodic reauthentication

Revoke sessions (admin action) Explicit operator action Invalidate refresh tokens / force reauth after compromise or offboarding

Continuous Access Evaluation Event-driven evaluation Near real-time reaction to critical identity events for supported apps

Access token lifetime alone Clock expiry Weak as the only control after disablement

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

Prefer disable account + revoke sessions as the human response to compromise; CAE improves how quickly supported resources honor identity changes.

Do not promise CAE for every third-party OIDC app—support varies.

Network location policies with CAE have specific design notes (strict location enforcement trade-offs); know that location-based CAE scenarios exist at concept level.

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:

Device join/registration — Microsoft Entra joined, hybrid joined, or registered (Workplace Join).

MDM compliance — Intune marks device compliant/noncompliant.

CA grant — require compliant and/or hybrid joined and/or app protection.

CA session — limited experience or MDCA controls when full grant is not met.

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

• Stem summary Best control focus
• CFOs must reauth every hour to Azure portal Sign-in frequency on Azure Management
• Users on shared browsers must not stay signed in Persistent browser session = never persistent
• Unmanaged devices get read-only style M365 web access App-enforced restrictions + device grants
• Marketing SaaS sessions need download block via cloud app security Conditional Access App Control / MDCA
• Disabled user still has a valid-looking client session CAE critical events + revoke sessions
• High user risk should kill ongoing access quickly Identity Protection risk + CAE-supported response
• 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.