Conditional Access: When 'All Users' Stops Meaning All Users

On 15 September Microsoft announced, in Message Center notice MC1472591, that Outlook attachments now run as their own internal application. The notice has been updated twice, most recently on 29 September, so the text below is the version in force today and not necessarily the one anyone acted on first.

Two routes put a policy in force on the new application. A policy assigned to the Exchange and Office cloud applications is inherited by the attachment application by default, which is the route the notice describes. A policy that targets All resources includes the attachment application directly, because it is a separate application and an exclusion that names Exchange Online does not name it. That second route is my reading of how All resources works; the notice states only the inheritance. Then comes the sentence that matters:

If you've intentionally excluded Exchange online from a policy, that exclusion doesn't carry over to attachments, so users in scope can reach their mail but will be blocked from downloading, previewing, or uploading attachments.

Read that as a policy author. You excluded Exchange Online from a policy for a reason, perhaps a shared mailbox scenario or an unmanaged-device exception. The policy has not been edited. The population of people it blocks has changed, and the change falls on the users you exempted from Exchange Online enforcement. Their mail still opens and their attachments fail, and when the notice was written there was no prompt to sign in again and recover. Microsoft listed that prompt as follow-up work. The scope is Outlook on the web and the new Outlook, and inline images count as attachments. Continuous access evaluation (CAE) is not supported for the new application yet.

To exclude attachments you target an application called OwaDownloadAttachments, and a service principal for it has to exist in your tenant first. That is a one-time step, and nothing prompts you to take it. Prefer not to exclude it. Excluding it from an All resources policy that requires MFA or a compliant device reopens the gap that policy closed: attachment download from unmanaged devices, with no continuous access evaluation. If you need the exclusion, cover the application with an equivalent policy of its own, which the notice allows.

The opening policy, All resources with a resource exclusion, is also in scope of the baseline scopes enforcement that the next post covers.

I read this notice through a community archive of Message Center, because Message Center needs a tenant login. The text is the archive's copy of Microsoft's. The archive keeps three versions, from 15, 23 and 29 September; the second changed the body and tags, and the third the body. Opening a past version needs a sign-in to the archive's comment service, which I did not make, so I have not compared the first version with the current one. Session, Not Sign-In uses the same notice for the missing continuous access evaluation; the point here is the exclusion.

My own Conditional Access baseline post has the human version of this. Its first mistake is a break-glass exclusion group that is missing from a policy someone added six months later. The mechanism there is a person forgetting. Here the policy set grew a new application without anyone adding a policy at all, and the exclusion did not travel.

The previous post covers these accounts from the inventory side; this section is about policy.

An agent user account is a user object in the directory. It can hold a licence, a mailbox, a calendar and custom roles, and it can join groups, including dynamic ones, according to the agent user account page. It cannot hold a password or a passkey and it cannot sign in interactively, because it authenticates only with a token issued to its parent agent identity. Microsoft describes its permissions as typically similar to a guest's, with more capability for enumerating users and groups.

So a licensed, mailbox-holding principal exists in the directory, and a policy that says "all users" does not cover it. Scoping by group membership is listed as unsupported too. The page also says a policy that targets agent identities does not cover the agent's user account, and the reverse.

The fix is a separate target. Under the policy's users, agents or workload identities assignment, select Agents and then target all agent users or specific ones. That target needs a licence: Microsoft 365 E7, or a Microsoft Agent 365 licence with at least Microsoft Entra ID P1 or Microsoft 365 E3. A baseline written before the target existed still reads as covering everyone and does not.

Conditional Access custom controls are the older route for sending a user to an external MFA provider. Microsoft's custom controls page says adding or editing them is not allowed from September 2026, with full retirement scheduled for early 2027. The route it points to for replacement is external MFA.

The external MFA method page is explicit about what the replacement cannot do:

Grant controls based on authentication strengths, including the built-in MFA strength, aren't satisfied by the external MFA method. Policies should only be configured with Require multifactor authentication.

This case is narrower than it first looks. A custom control and an authentication strength are separate grants, and I found no source saying a custom control ever delivered a phishing-resistant strength. The supported point is this. A tenant that wants a third-party factor and an authentication strength has to choose, and migrating a policy from a custom control to external MFA means editing it to Require multifactor authentication. So this case differs from the first two: the policy object does change, by the edit Microsoft's migration steps tell you to make. What drifts is what the policy can ask for. It can no longer say which kind of factor must satisfy it.

The export of the migrated policy is valid, and nothing in it records that a strength could not be combined with the method. Varonis Threat Labs described the trust involved in its TrustSink research, published on 16 September 2026: Entra accepts a signed token from a registered external method without checking what the provider showed the user. The attack needs a privileged account, so it is a post-compromise technique, and the design point stands without it.

What to check: keep phishing-resistant requirements on native authentication strengths, and do not migrate those policies to external MFA. For policies that still use a custom control, plan the edit before early 2027.

The legacy user risk and sign-in risk policies in ID Protection were due to retire on 1 October 2026. The concept page says they "are retiring on October 1, 2026" and the configuration page says they "will be retired on October 1, 2026". Both were fetched five weeks after that date and both are still in the future tense, with last-updated dates of 14 August and 28 April. Neither says what happens to a legacy policy that was not migrated: whether it stops enforcing, disappears, or stays visible and inert. The configuration page's migration section tells you to move to Conditional Access and disable the old policies, and does not describe what happens to a policy left in place.

I found no Microsoft statement that the retirement ran, so I will not say the policies stopped. What I can say is that the pages an administrator would consult have no description of the after state. From the portal, a policy that quietly stopped enforcing and one that still evaluates may look identical. Only a test sign-in with a risky signal tells them apart.

What to check: confirm that equivalent risk-based Conditional Access policies exist and are enabled, and do not rely on the legacy ones.

That records what the policies say. It does not record what they cover, so beside the file write the coverage in plain words for your three broadest policies: which applications, which kinds of account, which clients. Then do six things with it.

1. Read every policy that has an application exclusion and ask whether it names a parent application that has gained a child. Exchange Online and the Office cloud applications are the case above. If a policy excludes OwaDownloadAttachments, check that another policy covers that application.
2. Read every policy meant to cover everyone and decide whether agent user accounts are in scope for it. If they are and you hold the licence, add the agent users target deliberately, in report-only mode first. Without the licence, inventory the agent user accounts as the previous post describes, and keep a sign-in log query on them.
3. Subscribe to Message Center, or its archive, and read notices about new application identities and new principal types as scope changes. Ask of each one what inherits, and who told you.
4. For any control that has been migrated or retired, test with a dedicated test user and device, never a break-glass account. Run the What If tool first, then make the sign-in that should fail and check the Conditional Access tab of the sign-in log to confirm it did. Do not rely on the policy list for this.
5. Keep your break-glass exclusions. A scope review must not remove them, and every new policy needs them.
6. List the policies that use a custom control, using the CustomControls column, and plan their migration before early 2027.

I read each source below on 8 November 2026. A source marked as an archive copy is a community mirror of Message Center, not Microsoft's own page.

• MC1472591, the Outlook attachment notice and the quoted sentence: confirmed, archive copy, current version last updated 29 September. The archive lists three versions, but opening past versions needs a sign-in, so the first version was not compared with the current one. The OwaDownloadAttachments application and its one-time service principal step are in the current text.
• Conditional Access for agents: confirmed at Microsoft Learn, including the quoted statements, the API key clause, the security defaults clause and the unsupported group scoping. It documents the Agents target for all agent users, and its licensing.
• The agent user account page: confirmed at Microsoft Learn, including the licence, mailbox, group, role, credential and guest-like permission claims.
• The external MFA method page and the custom controls page: confirmed at Microsoft Learn, both quotes present.
• The ID Protection pages: confirmed, with the future tense still in place. The retirement itself is unconfirmed, and no source describes the behaviour afterwards.
• The baseline scopes page: confirmed at Microsoft Learn, 8 October.
• The Varonis TrustSink research: read on varonis.com. It supports the statement about the signed token and the privileged account, and nothing more is claimed from it.