4.4.2. Conditional Access App Control and Session Policies
💡 First Principle: Between "allow the app" and "block the app" lies the interesting middle: allow the session but constrain what happens inside it. Routing the session through a reverse proxy lets policy watch and intervene in real time — block this download, watermark that file, cut the session if risk spikes — decisions made during use, not just at sign-in.
The plumbing: a CA policy's session control Use Conditional Access App Control sends the app session through MDCA's proxy (URLs get the suffix treatment; modern in-browser protection with Edge reduces the proxy friction). Then two MDCA policy types act on the routed traffic. Access policies gate the session's start with app/user/device/location conditions — e.g., block access to the app from unmanaged devices entirely (overlapping CA's job but with MDCA's richer client-context tests). Session policies act inside: control file downloads/uploads (block, or protect via sensitivity-label application on download), block copy/paste/print, monitor-only (record activities), step-up authentication on sensitive actions (authentication context, 2.2.3, invoked mid-session).
| Access policy | Session policy | |
|---|---|---|
| Decision point | Session start | Continuously, per activity |
| Can do | Allow / block session | Allow but limit: block download, protect file, monitor |
| Classic scenario | Block unmanaged devices from app | Unmanaged devices: view online, no download |
The signature scenario — "contractors on personal devices may use SharePoint in the browser but must not download" — composes: CA policy scoped to unmanaged devices with session control routing to MDCA + a session policy blocking downloads (optionally by sensitivity label). Compare the neighboring answer: app-enforced restrictions (2.2.2) achieve a similar end for SharePoint/Exchange specifically, enforced by the app rather than a proxy — the tell for MDCA is any proxy-capable app, activity-level granularity, or label-aware actions.
⚠️ Exam Trap: Session policies apply only to sessions routed through the proxy by a matching CA policy — a session policy authored in MDCA while no CA policy sends traffic there polices nothing. When a stem's session policy "isn't working," check the CA side first.
Reflection Question: Why does step-up authentication mid-session (touching a labeled file triggers MFA) require the session-policy architecture rather than an ordinary CA grant control evaluated at sign-in?
