The Conditional Access policies you never wrote are already in your tenant

Open the Conditional Access policy list in your tenant and look at the Created by column. If any row says Microsoft, nobody in your company wrote that policy. It sits in Report-only, which sounds harmless, and isn't quite: it's a countdown. Microsoft is going to switch it on.

The mechanics are documented, word for word: "The policy is automatically created in your tenant in a Report-only state" and "Microsoft enables these policies no less than 30 days after they're introduced in your tenant if they're left in the Report-only state". You get an email and a Message center post two weeks in advance. And there is a note worth reading to the end: "In some cases, policies might be enabled faster than 30 days".

That number has moved, and in the direction that suits you least if you are cutting it fine. When Microsoft started this, in November 2023, the promise was different: "you'll have 90 days to review and customize (or disable) them before we turn them on". Today their documentation no longer promises a window, it promises a floor: "no less than 30 days", plus the note that it can be sooner. Practical conclusion: don't plan around the number, plan around the mechanism.

The ten that exist today

This is the list Microsoft publishes as of writing. It changes: they keep adding.

Two of that list —"require phishing resistant authentication for admins" and "block legacy authentication"— also belong to Baseline security mode in the Microsoft 365 admin center, and there is a difference there that matters when assigning blame: those are created by the administrator, not by Microsoft. They appear in the same screen, but with Baseline security mode in the Created by column, and they are managed elsewhere. We wrote about Baseline security mode, and why its impact report comes back as zero almost every time, here.

The only thing you can change is the exclusion list

Their words: "Organizations can't rename or delete any Microsoft-managed policies". You can exclude identities, you can move them from Report-only to On or Off, and you can duplicate them if you need more room —with the warning the page itself carries: "Be careful not to lower your security posture with those changes"—. That's it.

Which gives you the first task, and it's a today task, not a next-month one: your emergency account. Microsoft says it plainly —"Exclude your break-glass or emergency access accounts from managed policies just like other Conditional Access policies"— and they're right. A break-glass account that isn't excluded from every policy, including the ones you didn't write, isn't a break-glass account: it's just another account. You find out the difference on the day you can't log in to fix why you can't log in. When we take over a tenant somebody else was running, this is the first thing we look at: before the Secure Score, before any policy of our own.

The three that break things

None of these policies is a bad idea. What they have is concrete side effects in concrete places, and the places aren't the ones people expect.

1. Block device code flow

Microsoft sums up the argument in a sentence that is hard to argue with: "Device code flow is rarely used by customers, but is frequently used by attackers". It's the sign-in where you start on one device and finish on another, and it exists precisely because some hardware has nowhere to type a password. Hardware like a meeting room with a Teams device. The day that policy flips to On, what falls over isn't "a user": it's the big room, on a Monday at nine, with people in it. Microsoft publishes specific guidance for scoping the Teams device exception without turning off the whole policy, and that is the right way to do it.

2. Block legacy authentication

Microsoft's figure here is brutal: "more than 99 percent of password spray attacks use these legacy authentication protocols". What falls in scope is, in their words, "older clients like Office 2010, or clients that use protocols like IMAP, SMTP, or POP3", and out of that second half comes a small company's real inventory — which is us talking now, not Microsoft: the multifunction printer that scans to email, the ERP that sends invoices, the script that reads a mailbox over IMAP to load orders. None of it has a face or complains in Teams: it simply stops working, and you usually find out from the customer who never got the invoice.

3. MFA for all users

What breaks here isn't people. People have Authenticator, or install it in five minutes. What breaks are the service accounts somebody created as if they were people: licensed, with a mailbox, with the password in a config file, and nobody behind them who can reach for a phone. The documentation itself warns about this for the risk policy —"All Users could include service accounts or break-glass accounts, so you might want to exclude them"— and the warning applies just as well here. If you don't know how many you have, that's the inventory to do this week, not the policy.

The detail almost nobody has read: your licenses draw the perimeter

The risky sign-in policy needs Entra ID P2. And here comes the interesting part, which is written down and nobody quotes. The policy covers all users only if two conditions hold at once: "If all your active users have MFA and your P2 licenses equal or exceed the total active users". One is enough to fail —some users without MFA or not enough licenses— for Microsoft to create a security group called "Conditional Access: Risky sign-in multifactor authentication", cap it to what you own —"capped to your available P2 licenses"— and populate it itself: "we select users who can satisfy MFA, prioritizing users with a directly assigned P2 license". Guest users are out either way.

It isn't a trick: it's the unavoidable consequence of protection being sold per user, and Microsoft explains it openly. But the operational result does deserve a minute: who is covered against a risky sign-in in your company is decided by a license count and an MFA registration state, not by your risk assessment. If your finance director doesn't have a directly assigned P2, they may not be in that group. It's an ordinary group, you can edit it. But you have to look, not assume.

There is a second threshold in the same vein. The policy that picks up users still on the old per-user MFA only targets organizations with fewer than 500 users in that state. It makes sense —nobody wants five thousand people surprised at once— and it still leaves an irony worth saying out loud: the bigger your inherited mess, the less automatic help you get. There the work is yours, and consolidating that old MFA into Conditional Access remains one of the best effort-to-result tasks in any tenant.

How to find out what you got, without assuming

Four places, from least to most useful:

If you are on security defaults, several of these never reach you

Several of these policies explicitly target organizations "where security defaults aren't enabled", and the prerequisites that same page lists for Conditional Access are Entra ID P2 or Microsoft 365 Business Premium. So there are two worlds: the one with security defaults —all or nothing, no fine-grained exceptions— and the one with Conditional Access. For anyone coming from the first, Microsoft offers another set of four starter policies: block legacy authentication, MFA for admins, MFA for all users, and MFA for Azure management. Not a bad place to start, and nothing needs inventing.

And even so, this is a good thing

This post shouldn't be read as a complaint. Microsoft is switching on by default things we have spent years recommending one at a time, client by client, and losing the argument more often than we'd like. Their argument, incidentally, is in the first line of the same page: MFA "continues to reduce the risk of compromise by more than 99%". Admin MFA arriving on its own is good news, and it takes an uncomfortable conversation off our hands.

The part that does need saying is different, and it's the usual one in this trade: a policy you didn't design and can't delete is still yours on the day it fires. Whoever gets locked out calls your phone, not Redmond's. And the one lever they left you —the exclusion list— has to have been used beforehand. That isn't a criticism; it's a task with a date on it.

What we are not claiming

When this isn't about you

If you are twelve people, everyone has Authenticator, there is no scan-to-email printer, no fifteen-year-old ERP and no Teams meeting rooms: log in, look at the list, exclude your emergency account and go do something else. Twenty minutes, not a project. And we say that knowing what we are saying: we sell managed Microsoft 365 and consulting; if there is nothing to exclude after you look, we are glad and there is no invoice.

If instead you have licensed service accounts, devices that sign in without a keyboard, or an old MFA setup nobody ever consolidated, then there is work to do —and the work isn't "turn the policies off": it's getting the exclusion list right and clearing out whatever survives only because nobody has blocked it yet. Same reasoning as when we looked at which connected apps get into your Microsoft 365 without going through MFA: what decides your exposure isn't the control you switched on, it's what slips past it.

Sources (verified on 28 September 2026): policy list, initial Report-only state, the "no less than 30 days" window, two-week notice, inability to rename or delete, exclusion of emergency accounts, the 500 per-user MFA threshold, the group capped to P2 licenses, custom controls and the audit query — Microsoft Learn, "Microsoft-managed Conditional Access policies" (updated 8 August 2026); original announcement with the 90-day window — Microsoft Security Blog, 6 November 2023.