11.2 CA App Control & Session Policies
Key Takeaways
- App-enforced restrictions are Conditional Access session controls that rely on supported Microsoft apps to deliver a limited experience (for example constrained SharePoint/Exchange web behavior on unmanaged devices).
- Conditional Access App Control integrates Entra Conditional Access with Microsoft Defender for Cloud Apps so supported app sessions can be routed for real-time monitor and control.
- MDCA access policies govern whether a sign-in/session to a cloud app is allowed or blocked in real time under Conditional Access App Control scenarios.
- MDCA session policies refine an allowed session—monitor only, block downloads, control clipboard/print/upload-style actions (feature support varies by app)—at SC-300 conceptual depth.
- Identity admins configure the CA session control; Defender for Cloud Apps hosts the detailed access and session policy logic for reverse-proxy style enforcement.
From allow/block to governed sessions
Section 11.1 established visibility. Section 11.2 is real-time control of cloud app usage after identity is proven. On SC-300 you must separate three related ideas:
- Conditional Access grant controls — MFA, compliant device, authentication strength, block (whether access is allowed).
- Conditional Access session controls — how the allowed session is constrained (sign-in frequency, persistent browser, app-enforced restrictions, Use Conditional Access App Control).
- Defender for Cloud Apps access and session policies — the MDCA policy objects that implement monitor/block/control when CA App Control routes the session.
| Layer | Question it answers |
|---|---|
| CA grant | May this identity access this app given conditions? |
| CA session: app-enforced restrictions | Should supported Microsoft apps offer a limited experience? |
| CA session: Conditional Access App Control | Should the session be routed through Defender for Cloud Apps? |
| MDCA access policy | Allow or block this access in real time under MDCA evaluation? |
| MDCA session policy | What in-session actions (download, etc.) are monitored or blocked? |
App-enforced restrictions (Microsoft-app limited experience)
Use app enforced restrictions is a Conditional Access session control. It tells supported Microsoft cloud apps (classically scenarios involving SharePoint Online and Exchange Online limited web experiences) to enforce a restricted session consistent with device/client conditions—typically when the user is not on a fully managed/compliant path but is still allowed some access.
Mental model
- Grant might allow access with limited experience rather than hard-blocking unmanaged devices for all Microsoft 365.
- App-enforced restrictions instruct the app to honor limited mode (for example browser-only, reduced download/print/sync behaviors depending on app capabilities and configuration at the time of the exam).
| Scenario cue | Prefer |
|---|---|
| “Unmanaged devices get limited SharePoint/Exchange web access” with Microsoft-native limited experience language | App-enforced restrictions (+ appropriate grants/conditions) |
| “Block downloads for Salesforce/Box via cloud app security reverse proxy” | Conditional Access App Control + MDCA session policy |
| “Only compliant devices may open the app at all” | Grant: require compliant device (block otherwise) |
Exam trap: do not answer “Defender for Cloud Apps” for every download-limit stem. If the stem is pure Microsoft 365 limited access with app-enforced restrictions wording and no MDCA, choose app-enforced restrictions. If the stem names Defender for Cloud Apps, Cloud App Security, session policy, or monitor only / block download via CASB, choose Conditional Access App Control.
Conditional Access App Control integration
Conditional Access App Control routes user sessions for supported apps through Microsoft Defender for Cloud Apps (reverse-proxy style architecture). Identity still authenticates with Microsoft Entra ID; after successful evaluation, the browser session is brokered so MDCA can observe and control activities.
High-level flow
- Admin creates a Conditional Access policy targeting users, cloud apps, and conditions (for example unmanaged devices, specific groups, guest users).
- Under Session, select Use Conditional Access App Control.
- Choose a CA-facing mode such as Monitor only, Block downloads, or Use custom policy... (labels evolve; know the intents).
- User signs in to a supported app; session is redirected/proxied via MDCA.
- MDCA access and session policies evaluate in real time.
- Activities appear in MDCA for investigation; controls block or allow actions per policy.
| CA App Control intent (conceptual) | Meaning |
|---|---|
| Monitor only | Allow the session; record/monitor activities through MDCA |
| Block downloads | Allow access but prevent download-style exfiltration actions where supported |
| Custom / use MDCA policies | Defer detailed allow/block/control to Defender for Cloud Apps access & session policies |
What identity admins configure where
| Task | Typical surface |
|---|---|
| Who, which apps, which conditions, route to MDCA | Microsoft Entra Conditional Access |
| Detailed access allow/block rules for routed sessions | Defender for Cloud Apps access policies |
| Download, clipboard, print, upload controls (as supported) | Defender for Cloud Apps session policies |
| Onboard/confirm apps for CA App Control | MDCA Conditional Access App Control apps experiences + successful user sign-in onboarding patterns |
Support realities (exam-honest):
- Not every SaaS app supports every control. Catalog and Microsoft docs define support; SC-300 wants correct architecture, not memorizing every brand.
- Native mobile/client apps with noninteractive sign-in flows may not work with reverse-proxy session control the way browser sessions do.
- First-party Microsoft apps and major catalog SaaS are the usual examples; custom line-of-business apps may need onboarding via real routed sign-ins rather than inventing manual App ID hacks.
Access policies versus session policies in MDCA
Once Conditional Access App Control is in play, distinguish access policies from session policies inside Defender for Cloud Apps.
Access policies
Access policies provide real-time monitoring and control of user logins/access to cloud apps in the Conditional Access App Control path. Think of them as MDCA’s answer to “should this access be allowed right now?” with filters such as:
- User/group
- App
- Device tags / client app / location-style conditions (as exposed)
- Risk or other MDCA filters available in the product
| Access policy outcome | Typical use |
|---|---|
| Allow (often with audit) | Baseline monitor while building confidence |
| Block | Deny access to the app for matching conditions in real time |
| Require additional MDCA-driven responses where offered | Scenario-specific controls |
Compared with pure Conditional Access block: CA can already block an app entirely. MDCA access policies shine when the session is routed and you want CASB-context decisions and unified cloud-app policy management—especially across multiple SaaS targets under MDCA operations.
Session policies
Session policies assume the user is in the app (access allowed) and control what they can do during the session. SC-300 conceptual controls include:
| Session control theme | Intent |
|---|---|
| Monitor only | Visibility and alerting without blocking productivity |
| Block download / protect | Stop saving/exporting content from the session |
| Block upload (where supported) | Reduce unsanctioned data ingress into SaaS |
| Block clipboard / copy | Reduce copy-paste exfiltration from web sessions |
| Block print | Reduce physical/digital print exfil paths |
| Block send / share style actions (app-dependent) | Limit sharing from governed sessions |
| Educate / warn (where available) | User coaching before or instead of hard block |
Exact action names vary by app support and product UI. For the exam, map the business requirement to session policy (in-session data control) versus access policy (get in or not) versus CA grant (identity/device requirements).
Side-by-side comparison
| Dimension | Access policy | Session policy |
|---|---|---|
| Primary decision | Allow or block access | Constrain actions inside an allowed session |
| User experience | May never enter the app | Enters app with limited capabilities |
| Classic cue | “Block access from unmanaged devices to SaaS X via MDCA” | “Allow view but block download from SaaS X” |
| Pairs with | CA App Control routing | CA App Control routing |
| Not a substitute for | MFA grant controls (still use CA grants) | Network DLP appliances alone (complementary) |
Design patterns SC-300 loves
Pattern A — Monitor first
- CA policy: pilot group + target SaaS + Conditional Access App Control = Monitor only.
- MDCA: confirm activities appear; tune session/access policies in report-friendly modes.
- Expand scope; then enforce block download for sensitive groups.
Pattern B — Unmanaged device data control
- CA conditions: device platform / filter for noncompliant or unmanageable BYOD.
- Grants: require MFA (always useful) but do not require compliant device if business allows browser access.
- Session: CA App Control with block downloads or custom session policy.
- Result: productivity with reduced exfil risk versus a hard block that drives shadow IT elsewhere.
Pattern C — Privileged SaaS hardening
- Privileged users + admin-related SaaS scopes.
- Strong grants: phishing-resistant authentication strength, compliant device.
- Still add session monitoring for privileged SaaS to detect anomalous downloads.
- Pair with Identity Protection risky user signals and session revocation practices from Domain 2.
Pattern D — Microsoft 365 limited experience without full MDCA story
- Stem emphasizes SharePoint/Exchange limited access on unmanaged devices.
- Prefer app-enforced restrictions (+ device conditions) when MDCA is not mentioned.
- If stem explicitly requires MDCA session controls for M365 or catalog apps, use CA App Control.
| Business goal | CA grant | CA session | MDCA policy |
|---|---|---|---|
| No access unless compliant | Require compliant device | Optional | Optional |
| Access OK, no downloads on BYOD for catalog SaaS | MFA | CA App Control | Session: block download |
| Watch all sessions for anomalies | MFA | CA App Control monitor | Session/access monitor |
| Limited M365 web on personal PCs | Conditions for unmanaged | App-enforced restrictions | Not required by stem |
| Block risky country access entirely | Block grant or named location | — | Optional access policy |
Operational notes and common failures
| Symptom / mistake | Fix direction |
|---|---|
| CA App Control selected but no MDCA activities | Confirm licensing/integration, app support, user actually hit routed session, correct app targeting |
| Users break on mobile native apps | Session control is often browser-oriented; redesign for those clients |
| “Block download” but users still exfil via API/token apps | Combine with OAuth governance (11.3), device compliance, and DLP |
| Over-broad All cloud apps + block download | Pilot; exclude break-glass; expect app compatibility issues |
| Confused with sign-in frequency | Frequency forces reauth timing; it does not block downloads |
| Confused with CAE | CAE is event-driven token enforcement mid-session for supported apps—not MDCA reverse proxy |
Exam decision tree
- Does the stem need in-session control (download/clipboard) or only sign-in requirements? → Session path vs grant-only path.
- Does it name Defender for Cloud Apps / Cloud App Security / session policy? → CA App Control + MDCA.
- Is it Microsoft 365 limited experience without MDCA? → App-enforced restrictions.
- Is the problem third-party OAuth permissions, not browser session? → Jump to section 11.3, not session proxy.
- Is the problem unknown apps existing at all? → Cloud Discovery (11.1), not session policy.
A Conditional Access policy must route browser sessions for a supported catalog SaaS app through Microsoft Defender for Cloud Apps so downloads can be blocked. Which session control should be selected in Conditional Access?
Which statement best distinguishes an MDCA access policy from an MDCA session policy?
A stem requires limited SharePoint Online web experience on unmanaged devices using Microsoft’s app-side limited access behavior and does not mention Defender for Cloud Apps. Which Conditional Access session option is the best fit?
After enabling Conditional Access App Control in monitor-only mode for a pilot group, what is the primary security operations benefit before enforcing block-download session policies?