Conditional Access App Control not working nearly always arrives as the same complaint: the Entra policy is on, the session policy in Defender for Cloud Apps says Block download, and the user downloads the file anyway. The obvious move is to edit the session policy, and it rarely helps, because the fault usually sits one step earlier. Either the session never reached Defender for Cloud Apps at all, or it reached it in a form the policy does not match. This post separates those two cases, gives the checks Microsoft documents for each, and names the places where the documentation disagrees with itself.
The routing half of the problem lives in Entra, so it helps to be clear on how Conditional Access evaluates a sign-in before going further: a session control only exists for a sign-in that the policy’s conditions have already matched. Every Microsoft fact below was checked against Microsoft Learn on 30 October 2026.
Conditional Access App Control not working: is the session proxied at all?
Look at the address bar before anything else. A session going through the reverse proxy carries a suffix on the host name, and Microsoft’s troubleshooting article for access and session controls lists three: *.mcas.ms, *.mcas-gov.us and *.mcas-gov.ms. A session protected inside Microsoft Edge for Business has no suffix; the lock icon in the address bar shows a suitcase symbol instead. No suffix and no suitcase means Defender for Cloud Apps is not in the session, and no session policy can act on something it never sees.
| What you see | What it usually means | Where the evidence is |
|---|---|---|
| No suffix, no suitcase | The session was never routed | Entra sign-in log, Conditional Access tab |
| Suffix or suitcase present, policy never fires | Routed, but no session policy matches it | Defender for Cloud Apps activity log, policy filters |
| Controlled in the browser, not in the desktop app | Expected: session controls are browser only | An access policy with Client app set to Mobile and desktop |
| Controlled from a direct URL, not from the Microsoft 365 app launcher | A different app instance was matched (unconfirmed) | The app name recorded in the activity log |
| Edge works, Chrome is slow or errors | Chrome goes through the reverse proxy, Edge may not | Port 443, TLS 1.2, nonce handling |
The licence check, and the option that does not appear
If Use Conditional Access App Control is missing from the Session section of a Conditional Access policy, the tenant is short a licence. The troubleshooting article says to make sure you have a valid licence for Microsoft Entra ID P1 and a valid Defender for Cloud Apps licence. The session policy article repeats both and allows either to be standalone or part of another licence. Neither page names a bundle, so check the service plans actually assigned rather than reasoning from a SKU name on an invoice.
Two adjacent gaps look like licensing and are not. If the Protect action is missing from a session policy, that needs a Microsoft Purview licence and Microsoft Information Protection switched on in the Defender settings. If Data Classification Service cannot be chosen, the session control type is wrong: it has to be Control file download (with inspection).
Why the policy is on and the session is still not routed
Three causes account for most of these. I would check them in this order.
- The conditions did not match. A session control is evaluated only when the rest of the policy applies. In a Microsoft Q&A thread from May 2026, a policy scoped to high sign-in risk never enforced its session controls on ordinary sign-ins, and the moderator’s answer was that this is expected: session settings apply only after the policy’s conditions are met. App Control behaves the same way. A policy scoped to unmanaged devices, a risk level or a named location outside the trusted range routes only those sign-ins, and every other sign-in goes straight to the app.
- A block grant wins. The session policy article warns that a Conditional Access policy which selects Block access under Grant and targets the application prevents users from reaching protected applications through session controls. If another policy blocks the same app for the same users, there is no session left to control.
- The client is not a browser. Microsoft’s Conditional Access App Control overview states that session controls apply only to web browser based access and are enforced during interactive browser sessions. An installed app signs in through Entra, satisfies the policy, and is never redirected through the proxy.
The Conditional Access tab on the sign-in event settles the first two in one look. If the App Control policy shows as not applied, nothing in Defender for Cloud Apps is worth changing yet.
The desktop app gap, and the access policy that closes it
The overview is explicit about Teams. The desktop application is not supported for Conditional Access App Control session controls, and if desktop access is allowed, users might be able to download content through it even when browser session controls are configured. Microsoft’s recommendation is to configure access policies that block native client access and allow only browser based sessions.
That access policy has a default worth knowing before you rely on it. The session policy article says that unless the Client app filter is set to Mobile and desktop, the resulting access policy applies only to browser sessions. An access policy left on its defaults therefore blocks nothing in the client you were worried about. Set Client app to Mobile and desktop and the action to Block, which is also the troubleshooting article’s answer for apps whose controls you cannot configure.
Two more limits from the overview. Installed apps with noninteractive sign-in flows, such as the Authenticator app, cannot be used with access controls, and Microsoft’s advice there is a Conditional Access policy in Entra alongside the Defender access policy. And built-in client apps or browsers that do not support TLS 1.2 or later are not accessible at all once session control applies to them.
When the session is proxied and the policy still does not fire
Now Defender for Cloud Apps is in the session, so the evidence moves to its activity log at security.microsoft.com/cloudapps/activity-log, where the troubleshooting article sends you to find which policy matched. Four causes come up repeatedly.
The wrong app. The session policy article states that policies created for a host app are not connected to related resource apps, and gives the example that policies for Teams or Exchange are not connected to SharePoint or OneDrive. A separate policy is needed for the resource app. In practice I would not expect a Block download policy scoped to Teams to cover the SharePoint file a Teams channel links to.
The wrong instance of the right app. A Microsoft Q&A thread from August 2024 describes OneDrive and SharePoint opened from the Microsoft 365 app launcher never reaching the proxy, while the same sites opened by direct URL did. The poster saw the activity log record Microsoft SharePoint Online for one path and Microsoft SharePoint Online – General for the other. The thread was taken offline with no accepted answer, so treat the app-name mismatch as a lead, not a finding. The practical check is cheap: read the app name the activity log actually records and make sure the policy covers it.
The wrong control type. The session policy article says the Monitor only session control type monitors only the Login activity. A Monitor only policy will never stop a download. Blocking needs Control file download (with inspection) with the action set to Block.
The device was misidentified. A policy that filters on device tags such as Intune compliant or Hybrid Azure AD joined only works if Defender for Cloud Apps recognises the device. The troubleshooting article sends you to Settings, Cloud Apps, Conditional Access App Control, Device identification, and then to the Device info on the Entra sign-in to see whether the device showed as Managed or Compliant. It also notes that some browsers need extra configuration, such as an extension. If Entra never saw the device as registered, the fault is upstream, and it is the same one behind device filters that match nothing on an unregistered device.
One more check if the app is missing from the Conditional Access App Control apps list entirely. Entra apps are onboarded automatically, but the troubleshooting article says they appear only after they are configured in at least one policy, or when there is a policy with no app specified and a user has signed in to the app. Sign in to it in a fresh private session and look again.
The newsletter
Get the next Entra ID fix like this one by email
Subscribe and get the free 8-page Intune troubleshooting field guide (PDF), then new fixes about twice a month. From a Microsoft MVP.
Edge for Business and the reverse proxy are different paths
The in-browser protection article, which Microsoft still labels a preview, sets out when Edge handles the session itself: Windows 10 or 11 or macOS, Microsoft Entra ID as the identity platform, the last two stable Edge versions, the user in the browser’s work profile, and a commercial tenant. The switch is on by default at System, Settings, Cloud apps, Conditional Access App Control, Edge for Business protection.
Everything else falls back to the reverse proxy. The article lists Google Chrome, Edge on Android, Edge in InPrivate mode, older Edge versions, B2B guest users, users scoped to a protect file download policy, and sessions scoped to a Conditional Access policy defined in the Microsoft Entra ID portal. A user served by several policies, one of which Edge does not support, always gets the reverse proxy.
That last list contains a line I cannot fully resolve. Every App Control session starts from an Entra Conditional Access policy, so a sentence saying sessions scoped to an Entra policy use the proxy cannot mean all of them. I read it as the built-in options chosen inside Entra rather than a custom policy built in Defender, but the page does not say so.
There is a second disagreement, between products. Entra’s Conditional Access session article, last updated 24 March 2026, still says Conditional Access App Control uses a reverse proxy architecture. The Defender in-browser protection article, updated 3 July 2026, says Edge users are protected without being redirected to a reverse proxy. Both are current. The consequence is practical: in Edge, a missing .mcas.ms suffix is not evidence of failure, and the troubleshooting article itself says its proxy steps are only relevant for sessions not configured for in-browser protection.
The failure modes
The error text, what it really means, and the documented fix.
- This website is blocked by your organization. Check for the proxy suffix or the suitcase first. If neither is there and the whole domain is blocked, the cause may be an app marked Unsanctioned and enforced through Defender for Endpoint, not App Control. Admins can use Bypass experience on the Admin View toolbar to confirm whether the proxy is responsible.
- This site isn’t secure, or There’s no internet connection. A network problem on the proxy path. Microsoft’s fix is outbound port 443 to the Defender for Cloud Apps data centre IP addresses and DNS names, then a restart of the device and browser, and TLS 1.2 enabled in the browser.
- You don’t have any apps deployed with conditional access app control. The Conditional Access App Control apps page shows no apps connected. Onboard one, which for an Entra app means getting it into a policy and signing in.
- Slow sign-ins. Usually proxy chaining or an unnecessary forward proxy. For apps that do not use nonces, the article describes clearing Enable nonce handling on the app’s edit page, then signing out and closing every browser session.
- Everything passes during an outage. The Default behavior setting under Conditional Access App Control decides whether access is allowed or blocked during a service disruption. Set to Allow, a disruption looks exactly like a policy that stopped working.
- Policy not recognised. A Tech Community thread from October 2024 reports a correctly built Entra policy that Defender for Cloud Apps never recognised. Microsoft support’s only stated lead was a mismatch between the Entra tenant and the Exchange tenant, and no fix was posted. If every check above passes, that is a support case, not a configuration you can see.
What I would do differently
I would build the access policy before the session policy. A Block download policy with the desktop apps still allowed is a control with a documented hole in it, and Microsoft says as much about Teams. Scope the access block to unmanaged devices, though, because on a managed device the desktop apps are the point.
I would test in Report-only first, as the session policy article’s own steps do, and sign out of every existing session before re-testing, which the same article recommends. A test run inside a session that started before the policy existed proves nothing.
I would scope by the app names the activity log records, not by the names in the catalogue, until the launcher question in the August 2024 thread has a documented answer.
And I would ask whether App Control is the right tool at all. If the real goal is a stronger sign-in rather than control over what happens after it, an authentication strength requirement does that without a proxy in the path.
I have not run this in production. My tenant is a lab with no enrolled devices, so everything above comes from the Microsoft sources named and the dated community threads. Where I would expect Conditional Access App Control not working to bite hardest is an estate that blocks downloads in the browser and leaves the Teams and OneDrive desktop clients open on unmanaged devices.
Last verified: 30 October 2026.
