Session control is the only place Defender for Cloud Apps reaches inside a live session and changes what a person can do while they are in it: blocking a download, stopping a copy to the clipboard, labeling a file on its way out, forcing a second authentication mid-session. It is the most powerful thing the product does and the most easily misconfigured, because it does not stand on its own. It rides Conditional Access, it is held up by two dependencies that will lock your users out if you get them wrong, and its most modern delivery path is still in preview. This is the honest account of what it does and what it costs.
It rides Conditional Access, it does not replace it
The architecture is one sentence, and holding it exactly right saves a great deal of confusion later. A Conditional Access policy in Entra, with its session control set to Use Conditional Access App Control, hands the user’s session to Defender for Cloud Apps; from there, the access and session policies you build in Cloud Apps decide what happens inside that session. Conditional Access is the router. Cloud Apps is what sits in the path once traffic is routed to it. This is why the licensing is Cloud Apps plus Microsoft Entra ID P1, as the anchor noted: P1 is not incidental, it is the license for the Conditional Access rail this whole capability is delivered on. For applications that authenticate to Entra, onboarding to this control is now automatic, they are simply available to target, though that automatic onboarding is itself still labeled preview; only apps behind a non-Microsoft identity provider need to be onboarded by hand. The design of the Conditional Access policy itself, who it targets, what conditions gate it, how break-glass accounts are excluded, is not this pillar’s to teach. That belongs to the Intune guide and the identity series, and session control borrows their rail rather than rebuilding it.
Access versus session, and the gap between them
There are two kinds of policy and the difference is not cosmetic. An access policy makes an allow-or-block decision at authentication, at the moment of sign-in, and it reaches both browsers and native desktop and mobile clients. A session policy operates inside the session and only in a web browser, watching and shaping activity as it happens. Session policies come in four types, monitor only, block activities, control file download with inspection, and control file upload with inspection, and their actions are to audit, to block with a message shown in the browser, or to protect, which applies a Purview sensitivity label to a file on download and, worth knowing before you rely on it, cannot overwrite a label the file already carries. Where two session policies touch the same activity, the more restrictive one wins. There is also a step-up action that bounces the session back to Conditional Access to re-check an authentication context, a fresh multi-factor prompt or a compliance check partway through a session rather than only at its start, which needs nothing beyond the P1 you already have, though invoking step-up from inside a protect-on-download action is still marked preview.
The gap that matters is that a session policy governs the browser and nothing else. A native client, the Teams desktop app, a sync client, a mobile app, does not pass through the browser-based session and is not shaped by these controls at all. So a session policy that blocks downloads in the browser while the same user syncs the same files through a desktop client has closed the front door and left the side one open. The discipline is to pair a session policy with an access policy that blocks native and desktop clients wherever the session control actually matters, forcing the interaction into the browser where the control can see it. One more piece of precision: a policy written for a host application does not automatically cover the resource applications behind it. A policy on Teams or Exchange does not extend to SharePoint or OneDrive; if you need the resource protected too, you write a separate policy for it, and the older guidance that suggested one policy covered the whole family no longer holds.
In-browser or reverse proxy, told straight
How session control actually intercepts traffic is the part most worth being honest about, because there are two mechanisms and the newer, cleaner one is not yet general. The older mechanism is a reverse proxy: the session is routed through Cloud Apps, and the user sees it, because the application’s address is rewritten with an added suffix, the familiar tail on the URL that tells you a session is proxied. The proxy modifies the application’s traffic as it passes, which is exactly why it carries a long list of limits. The newer mechanism is in-browser protection, which enforces the controls natively inside Microsoft Edge for Business with no proxy, no rewritten address, and developer tools disabled so the session cannot be tampered with from inside. It is genuinely nicer, and it is still in preview as of mid-2026, its documentation title still carrying the preview label, with no general-availability announcement behind it. That status is the single most important thing to get right about this feature, because the field has believed it was generally available for two years and it is not.
The field has believed in-browser protection was generally available for two years. Its own documentation still says preview.
The catch that undoes naive designs is the fallback rule. In-browser protection covers a specific set of controls, and the moment a session is scoped by even one policy it cannot serve, a content-inspection policy, a label-on-download policy, a non-Edge browser, Edge on Android, an app behind Okta, an InPrivate window, a guest, the entire session falls back to the reverse proxy. You do not get the clean Edge experience for the parts it supports and the proxy for the rest; one unsupported policy sends the whole session to the proxy. So designing as though in-browser protection is your enforcement path, when your policy set includes a single DLP-inspecting policy, means you are really running on the proxy and inheriting all of its constraints. Those constraints are real and specific: files over fifty megabytes follow whatever default you set rather than being inspected, content inspection runs only on files under thirty megabytes and a million characters, files that are already encrypted with a label cannot be read at all, the IP-based conditions are IPv4 only and silently ignore IPv6 in both the proxy and the Edge path, TLS below 1.2 is refused, the Teams desktop application is unsupported, and dragging a mixed batch of files where any one is sensitive blocks the whole batch. None of these are bugs; they are the physics of intercepting somebody else’s application, and a design that pretends they are absent breaks in ways that are miserable to diagnose. Note too that certificate pinning, which older write-ups cite as a proxy limitation, has dropped out of the current documentation entirely; the durable framing is simply that native and built-in clients are unsupported and should be blocked with an access policy so users land in the browser.
The two dependencies that lock people out
Two failure modes here are worth more attention than any feature, because both are silent and both cut off real users. The first is that a session policy does nothing on its own. Without a Conditional Access policy actually routing sessions to Cloud Apps through Use Conditional Access App Control, the session policy you carefully wrote simply never engages, and it fails quietly, with no error and no effect, which is the worst way for a control to fail. The second is the more dangerous. Cloud Apps routes protected sessions through an internal enterprise application named Microsoft Defender for Cloud Apps - Session Controls, and if that application is caught by a Conditional Access policy that blocks access, users cannot reach the protected applications at all. A broad block policy, or a location-scoped one that does not account for this app, will lock people out of the very services you were trying to protect, and the symptom looks nothing like its cause. The rule is to exclude that session-controls application from any blocking policy and to include it explicitly in location-scoped ones. This is the single most common way a session-control rollout takes down access, and it is entirely avoidable once you know the app is there.
Device state, and one boundary to name
Session control is often the answer to a question the compliance work could not reach: how to constrain what an unmanaged device can do without enrolling it. Where a device is Intune-compliant or hybrid-joined, that signal arrives through Conditional Access and you can shape the session on it. Where it is neither, Cloud Apps can still infer management from a client certificate chained to a root you have uploaded, which is how a personal or contractor machine can be recognized well enough to be treated differently without ever being enrolled. That pairs directly with the compliance loop the endpoint block built, extending it to the population enrollment cannot cover. Finally, a boundary to state and leave: in the same Conditional Access session blade sits a separate control, Use Global Secure Access security profile, which delivers network-layer security through Entra’s secure access service rather than app-level session control. The two are independent and coexisting, and nothing in the documentation positions Global Secure Access as a replacement for Cloud Apps session control. When you see both in the blade, they are two different tools, not two versions of one, and that product is the identity side’s to cover.
That closes the SaaS block. Across it we mapped what Defender for Cloud Apps is now that file protection is leaving, discovered and enforced against the shadow-IT and shadow-AI estate, governed the OAuth grants users made, and finally reached inside the live session to control what happens in a sanctioned app. What every one of these produces, a discovery signal, an OAuth-app disable, a session block, a posture finding, does not stay inside Cloud Apps. It flows outward into the exposure picture the whole organization is scored on and into the incidents the correlation fabric assembles, where an OAuth compromise here and an identity alert there and an endpoint detection somewhere else become one story that the platform can disrupt on its own. Those are the pillars the suite anchor promised, and they are where the series goes from here.
Defender XDR
‹ Previous: [D 5.2] App Governance: The OAuth Consent Control Plane
Next: [D 6] Vulnerability and Exposure Management: Three Instruments, One Estate ›
