Conditional Access Exclusions: The List Nobody Reviews

Open any one of your Conditional Access policies and look at its exclusions. That is a list of people this particular policy does not apply to, and you almost certainly have several such lists, one per policy, which is part of why they are easy to lose track of. Each one probably started with three names. A regional manager travelling somewhere your policy blocks. A contractor on a device your policy will not accept. An executive who could not get through multifactor authentication on the morning of a board meeting and needed to be working in the next ten minutes.

Every one of those exceptions was the right call at the time. The business needed those people signing in and doing their jobs, and a security control that stops work is a security control that gets removed. So the exception was granted, the person got back to work, and everyone moved on to the next thing.

The problem is not that the exception was granted. The problem is what happens next. By default a Conditional Access exclusion carries no expiry date, no reminder, and no owner: it persists until an administrator or a governance process you have deliberately configured removes it. Microsoft does provide that governance process, and we will come to it, but it is not on by default and it is not included in every licence. Absent it, the list only grows, and for everyone on it the policy you believe you enforce is not enforced.

Why Exclusions Exist in the First Place

It is worth being clear that exclusions are not a mistake. Microsoft designs for them, documents them, and expects you to use them. Its own guidance describes exactly the situation most institutions recognize: you deploy a policy requiring multifactor authentication or limiting sign-ins to certain networks and devices, and then you discover that not everyone can meet it. Remote staff outside the internal network. People on unsupported hardware waiting for a replacement. Travellers who need access from a country the policy blocks.

In each case the institution has a genuine choice between two costs: the security exposure of an exception, or the productivity loss of an employee who cannot do their job. Granting the exception is frequently the correct answer. Lending does not pause because a loan officer is at a conference.

What Microsoft is equally clear about is what the exception does to the policy.

That sentence is the whole issue in one line. A Conditional Access policy is not a property of your tenant. It is a property of the people it applies to. Your policy summary can read "require multifactor authentication, all users" and be entirely accurate, while a group of named individuals signs in every day without it.

Three Ways Exclusions Go Wrong, in Microsoft's Words

Microsoft's documentation is unusually direct about how exclusions go wrong, particularly when they are configured as a raw list of users or through legacy on-premises security groups rather than a managed Entra group. Under the heading asking why exclusions are challenging, it lists three consequences. The paraphrases below are ours; the underlying points are Microsoft's.

People do not know they are excluded. An excluded user experiences a tenant with weaker protection than their colleagues and has no reason to notice. They are not warned, and they will not report it. If their credentials are stolen, they are also the least likely person to recognize that something that should have blocked the attacker did not.

People can add themselves. Where the exclusion is driven by a security group that permits self-service membership, the exclusion is self-service too. The control that decides who bypasses your multifactor requirement becomes a group anyone in scope can join.

People stop qualifying and stay on the list. This is the one that produces almost all real-world drift. The contractor's engagement ends. The unsupported laptop is replaced. The trip finishes. The reason evaporates and the exception does not, because nothing is watching it.

Microsoft describes the pattern of accumulation plainly: an exclusion starts as a shortlist of users who bypass the policy, more users get added over time, the list grows, and at some point somebody needs to review it and confirm each person is still eligible. Every institution reaches that point. Very few schedule it.

The Fix Microsoft Recommends, and the Licence It Needs

Microsoft's recommended answer is specific and good. Configure the exclusion as a Microsoft Entra group rather than a loose list of users, then run access reviews against that group. Microsoft describes access reviews here as a compensating control, and says they let an administrator avoid oversight of policy exceptions and give auditors proof that the exceptions are reviewed regularly. Microsoft treats this as a headline use case rather than an edge case: maintaining a policy exception list appears by name in its own list of situations where access reviews should be used.

Run properly, a review of an exclusion group can require each member to attest that they still need the exception, route the decision to a business owner rather than to IT, remove anyone who does not respond, and leave an audit trail of every decision. That is precisely the recertification discipline examiners look for, applied to the one population that most needs it.

Here is the catch, and it is the reason this article exists.

Read that alongside the failure modes above and the position is uncomfortable but clear. A typical community bank, credit union, or mortgage lender on Business Premium has every condition Microsoft describes, and does not have the remedy Microsoft prescribes. The exception list grows exactly as documented, and the tool designed to keep it honest is behind a licence upgrade.

There are two honest routes forward, and which one fits depends on the institution. The first is manual: keep the P1 licence and run the review yourself on a fixed calendar, with a named owner and a written record. That works, and it is far better than nothing, but it depends entirely on somebody remembering, which is the failure mode you are trying to fix.

The second is to license the capability. Microsoft publishes an add-on called Microsoft Defender Suite for Microsoft 365 Business Premium, which it describes as providing enhanced identity and access controls with Microsoft Entra ID P2, adding advanced security and governance features with Microsoft Entra ID Protection and Microsoft Entra ID Governance. That covers both entitlements named above, so it resolves the licensing question whichever way your specific review falls. Microsoft lists working with a Microsoft partner as one of the ways to obtain it. Business Premium and its add-ons are sized for organizations up to 300 users, which covers most community institutions but not all.

We would rather you make that decision on the arithmetic than on a sales pitch, so the relevant comparison is straightforward: the annual cost of the upgrade against the exposure carried by an exception nobody has reviewed. For most institutions that math is not close.

What an Open Exception Actually Costs

The security firm Huntress named this failure mode directly in guidance titled What Good Identity Hardening Looks Like, published on August 25, 2026. It advises organizations to close temporary exceptions instead of letting them become permanent, and to track every exception along with who approved it, why it exists, and when it must be reviewed or closed.

The case Huntress describes to illustrate it is worth reading carefully, because the shape of it is familiar to anyone who works with financial institutions. A real estate chief executive did not like using multifactor authentication and persuaded his managed service provider to disable it on his account. An attacker then ran a business email compromise, impersonating the chief executive to authorize fraudulent wire transfers, escalating the amounts until the executive noticed them while reviewing account balances.

As Huntress describes it, no vulnerability was exploited and no malware was involved. The attacker used the front door, because for that one account the lock had been taken off and never put back.

"If an employee's MFA-approved session gets stolen, that token walks straight past every policy already in place."

That observation, also from the Huntress guidance, describes a different mechanism from the case above rather than an explanation of it. In the wire fraud case the control had been switched off outright. Session token theft is the opposite situation: the control is on, the user genuinely completed it, and the attacker steals the resulting session instead. They belong in the same article because they arrive at the same place, an account that authenticates successfully while somebody else is driving. Huntress groups trusted device abuse, risky app consent, and emergency multifactor exceptions together as quiet paths around a control you believe is on, and recommends checking for configuration drift monthly. The word doing the work there is "quiet." Neither failure announces itself, and your policy list looks correct throughout both.

Your Next 30 Days: The Exception Sweep

You do not need a licence upgrade to start. The first pass is manual work that any institution can do this month, and it is worth doing before you decide whether to buy anything, because it tells you how big the problem actually is.

Most institutions that run this sweep for the first time are surprised twice: once by how many exclusions exist, and once by how many nobody can explain. Both surprises are useful, and both are much better discovered by you than by an examiner or an attacker.

What Examiners Expect to See

Nothing in this article is exotic from a supervisory standpoint. The FFIEC IT Examination Handbook's Information Security booklet sets out the expectations that access is granted with documented approval and reviewed periodically, and that where an issue cannot be immediately resolved it is handled deliberately, through interim actions, compensating controls, and documented acceptance of the risk. An undocumented, unowned, unreviewed permanent exception to your own multifactor policy sits awkwardly against all three of those expectations, and it is the kind of item that is easier to resolve before it is raised than after.

The distinction that matters in an examination is not whether you have exceptions. Every institution has exceptions, and a mature institution can defend them. The distinction is whether you can produce the list, name the owner of each item, show the business justification, and show the date it was last reviewed. That is a documentation problem long before it is a technology problem, which is genuinely good news: the hardest part is affordable at any licence tier.

To be precise about what running access reviews does and does not do for you, Microsoft's position is that they provide auditors with proof that exceptions are reviewed regularly. Evidence of a process is not the same as a guaranteed examination outcome, and no vendor can promise the second thing. What it removes is the specific and avoidable finding of an exception nobody could account for.

If you want the fuller picture of how these controls fit together, our guide to Conditional Access policies for financial institutions covers the baseline policy set, and our article on Entra ID access reviews goes deeper on the recertification process itself. For the identity layer underneath all of it, see phishing-resistant multifactor authentication, and for the fraud outcome this is ultimately about, stopping business email compromise and wire fraud. If you have already worked through your policy set, our write-up of the Conditional Access password spray gap covers a different way a policy that looks correct can fail to protect you.

Frequently Asked Questions