Article • September 7, 2026 • 7 minute read

Advanced Zero Trust: What Has To Be in the Path

Zero Trust promise that control follows the thing its protecting, the real-time session control and the data. Both are true only while "something" is in the path to enforce them. This article works out precisely what that "something" is in each case, what routes around it entirely, and how long a cached decision keeps working after you revoke it.

Summary

We begin with a spreadsheet, "Pricing-FY27". It lives in a finance site in SharePoint, it carries the Confidential label so its contents are encrypted, and a good deal of what is in it was exported from a pricing tool that nobody ever sanctioned. A session policy would have blocked the export if the session had gone the right way. The label travels with the file wherever it goes next. Zero Trust promises that protection follows the thing rather than the perimeter, and both are true with a condition attached. "Something" has to be sitting in the path at the moment of the action. This article is about identifying that "something" in each case, and being honest about the traffic that never meets it.

Unsanctioned Does Not Mean Blocked

Sanction, monitor and block are not three equivalent actions. Two of them are labels you apply to a row in a report. Only one of them stops anybody doing anything, and it does not live in Defender for Cloud Apps.

Verb	What the action itself does	What has to exist for it to bite
Sanction	Tags the app as approved and shapes your discovery filters	Nothing. It is a bookkeeping state.
Monitor	The same tag, plus your attention	A log source feeding cloud discovery, so the app appears at all.
Unsanctioned	Marks the app as unwanted. Microsoft's own wording is that it does not block use	Nothing, and this is the row people misread.
Block	Not an action on the app record. It is an outcome produced somewhere else	Defender for Endpoint with cloud protection and network protection on, and the browser add-on installed in every non-Microsoft browser. Or a supported proxy such as Zscaler. Or a block script you generate and import into your own appliance.

Table 1 – Describes the unsanctioned as a decision. Blocking is an integration, and the enforcement point is always somewhere else.

Two smaller things are worth carrying into a design review. A set of Microsoft services cannot be blocked at all, Intune and Purview and the Defender portals among them, which is sensible and occasionally surprises someone building a deny-by-default list. And where a manual sanction decision and a discovery policy disagree, the last operation applied wins, so an automated policy can quietly undo a considered human judgement made last month.

The Consent Half

Governing OAuth grants is the part of this lifecycle that ages best, because it is the one attackers actually use. The default posture is permissive: every user may consent to any permission that does not itself require an administrator. Changing that to allow user consent only for apps from verified publishers, and only for permissions classified as low impact, is a single setting and an admin consent workflow to catch the rest.

What makes reviewing grants hard is that two very different situations look identical in the enterprise applications list. The app name is the same. The blast radius is not.

Figure 1. Delegated and application permissions are different products wearing the same name in the portal. — *Figure 1. Describes the delegated and application permissions that are different products wearing the same name in the portal.*

Only Some Session Controls Reach The Proxy

Session controls apply to interactive browser sessions, reached either through the reverse proxy, where users see the .mcas.ms suffix appended to the URL, or through in-browser protection when the browser is Microsoft Edge, which avoids the proxy and its associated limitations. Anything that is not an interactive browser session is not covered. Microsoft's guidance on this is blunt, and it is the sentence to take away: to prevent bypassing the protection, configure access policies that block native client access and allow only browser-based sessions. The control does not fail closed on its own.

Figure 2. The two blue paths are protected. The two red ones are only protected if a separate policy blocks them. — *Figure 2. - Describes the two blue paths that are protected. The two red ones are only protected if a separate policy blocks them.*

There is a size ceiling as well, and it is low enough to matter for a file like "Pricing-FY27". Session policies evaluate files up to 50 MB. Above that the tenant setting decides whether the file is allowed or blocked, regardless of any policy you wrote, so a large export is governed by a fallback rather than by your rule. On the protocol side, controls apply to interactive single sign-on over SAML 2.0, and over OpenID Connect for Microsoft Entra applications, which is a real constraint when someone asks why a particular tool cannot be onboarded.

One configuration detail catches people out. The Protect action in a session policy applies a sensitivity label on download, and a label only appears in that list if it has been configured to apply encryption. A marking-only label is not offered, which is a small thing until you have spent an afternoon looking for a label that was never eligible.

What a Label Actually Ships

*Figure 3. – Describes the data file that carries the lock. The key arrives separately, and then it stays.*

When somebody opens a protected item, Rights Management issues them a certificate containing their usage rights and the content key. That certificate is cached locally and remains valid for its stated period. If no expiry has been set on the label, the tenant default is 30 days, and the Allow offline access setting is what actually drives that number. So the encryption genuinely does travel with "Pricing-FY27". What also travels, on the last laptop that opened it, is a working key with a month left on it.

None of that makes labels weak. It makes them a different shape of control than the slide's phrasing suggests. Encryption binds protection to the file. It does not give you a revocation switch with immediate effect, and designing an offboarding runbook as though it does will produce a nasty surprise during the first real incident.

Where The Chain Breaks

*Figure 4. – Shows the amber segment as the interesting one, because nothing about it looks different to the person holding the file.*

Let's walk through three settings, that we could do differently. First, set Allow offline access explicitly on any label that carries encryption, because accepting the 30-day default is a decision you are making whether or not you know it. Change user consent to verified publishers and low-impact permissions, and turn on the admin consent workflow so the change generates requests rather than complaints. Then, before writing a single session policy, add the access policy that blocks native clients for the apps you intend to govern, because until that exists the session policy is optional from the user's point of view.

Insider risk levels become a condition that other controls read, so a person whose risk has risen gets tighter handling automatically instead of waiting for a case to be opened. It is the same architectural move as risk-based Conditional Access, applied to data rather than sign-in, and it inherits the same caveat: the level is a summary, and it arrives when it arrives.

Conclusion

Every control in this article is an intermediary that has to be present at the moment of the action. For sessions that intermediary is a browser path you routed deliberately, and native clients walk around it unless you close that door yourself. For files it is an application asking Rights Management for a key, and once the key has been handed over it is out of your reach for as long as you allowed. "Pricing-FY27" is protected in both senses and controlled in neither, until somebody sets those two numbers on purpose.