At the end of the build you have a tenant full of Conditional Access policies that do nothing. Every one of them is in report-only. That is the correct state, and it is also the most dangerous moment in the whole exercise, because the temptation is to flip them all on and be done. Do that and you will either lock someone important out or break a workflow nobody remembered existed, and in both cases you will do it to everyone at once. Enablement is not a switch. It is an order, and the order is the point of this article.
The framework enables in four rings, and the sequence is deliberate. Each ring turns on a related group of policies, and no ring goes on until the one before it has spent time in report-only with its evidence reviewed. The principle behind the ordering is simple to state: turn on the things that stop attacks and affect almost nobody first, and save the things users will actually feel for last, once the ground under them is solid. If you internalize nothing else, internalize that the rings run from lowest user impact and highest security value toward highest user impact, not the other way around.
Report-only is data, not a holding pattern
Before the rings, a word about the state everything ships in. Report-only is not a waiting room. It is an instrument. A policy in report-only evaluates every sign-in exactly as it would if enforced, and records what it would have done, without doing it. That record is your evidence. Before you enable any ring, you read the report-only results for its policies in the Conditional Access insights workbook and in the sign-in logs, and you look for the sign-ins the policy would have blocked or challenged. Every one of those is a question. Is that a legitimate workflow I am about to break, or is it exactly the thing I want to stop? You do not get to skip this reading. It is the difference between a controlled rollout and a guess.
Two weeks is the floor I use per ring, longer if the tenant is large or the report-only data is noisy. Two weeks catches the weekly and fortnightly patterns, the person who only touches a system on payroll day, the integration that runs on a schedule. A day or two does not. And What-If is your companion throughout: before you enable a policy, run the What-If tool against a pilot user and against an admin and against a guest, and confirm the result matches your intent. Reading report-only tells you what has been happening. What-If tells you what will happen. You want both.
Ring one: the foundation blocks
The first ring turns on the blocks that close the paths most compromises actually use, and it affects almost no legitimate user. Legacy authentication. Device code flow and authentication transfer. The MFA catch-all. These are the controls that stop password spray against old protocols, the token-phishing flows, and the sign-ins with no second factor at all. The reason they go first is that their blast radius on real users is near zero while their security value is near total. Nobody legitimate is authenticating with IMAP in 2026, and the report-only data will tell you whether that is true in this specific tenant before you commit.
The gate before ring one is the full prerequisite pass from the build, break-glass populated and verified, and report-only data that shows no legitimate legacy-auth traffic, or shows it with a migration plan attached. The classic finding here is a multifunction printer scanning to email over SMTP, or a line-of-business integration still speaking a legacy protocol. Those are real, and the answer is to fix the sender, a mail relay or a move to modern auth, not to weaken the policy. The one exception worth calling out is device code flow. Microsoft Teams devices, the Teams Rooms, phones, displays, and panels, use it legitimately for registration and reauthentication, and in a corporate tenant they are the case you will actually meet. The pattern is the one Microsoft documents: the device resource accounts, meaning the account assigned to the room or shared device and not the technician who set it up, go into that policy’s exclusion group, and the Device Registration Service resource is excluded from the policy as well so device registration itself is not caught. Both are owned and audited like any exception, rather than the policy coming off.
Ring two: session and registration hygiene
The second ring is the hygiene layer. Sign-in frequency and persistent browser limits. Device registration and security-info registration behind MFA. Blocking unknown platforms. Guest MFA, guest session limits, and the guest admin-portal block. These are visible to users in the sense that they may see a prompt they did not see before, but they do not stop anyone from doing their job. They tighten the edges.
The gate that matters for ring two is onboarding, because two of these policies, the registration-protection policy and the enrollment MFA policy, depend on the Temporary Access Pass flow being in place. If you enable them before you have a TAP issuance process, you protect the registration moment for existing users and simultaneously make it hard to onboard new ones. So the standing order is that the TAP onboarding process exists and is documented before ring two, and that frontline or phoneless users have a registration path that does not assume a smartphone. That is the subject of the next article, and it is a genuine dependency, not a nicety.
Ring three: privileged, control plane, and risk
The third ring is where the framework starts demanding real things of real people, and it is aimed at the accounts and resources that matter most. Phishing-resistant MFA for admins. Compliant device for admin roles. The Tier 0 control-plane policy that requires both, for everyone, against Azure management and the admin portals. The guest default-deny. Service-account IP fencing. And on a P2 tenant, the risk-based policies, scoped to all users.
This ring has the longest lead time, and it is not because the policies are hard to enable. It is because the gate is a human one. Every admin must have a registered phishing-resistant method and either a compliant device or a documented privileged-access workstation before this ring goes on. If you flip phishing-resistant MFA for admins before your admins hold passkeys or security keys, you lock out your own administrators, which is a memorable way to learn the lesson. So the passkey enrollment for admins starts weeks before this ring, not the morning of. The service-account fences want their own evidence too: thirty days of report-only data from the fencing policy, each would-be block explained, before you trust the IP ranges you have configured. Rushing ring three is how good deployments produce their worst outages.
Ring four: device trust and the BYOD path
The last ring is the one users feel most, which is exactly why it goes last. Windows and macOS compliance. Mobile app protection. The contained browser path for unmanaged devices. When this ring enables, a personal laptop that used to open a thick client stops being able to, and a personal phone that used to reach mail without an app protection policy stops reaching it. That is the intended behavior, and it is also a change people notice, so it goes on when the ground is ready and the users have been told.
The gate is device health and communication. Compliance has to be healthy across the managed fleet, on the order of ninety-five percent of the user population compliant or in active remediation, before device trust becomes an access requirement, because the policy turns non-compliance into a locked door. The app protection policies must be assigned, iOS and Android through their unmanaged-device filters and Windows unfiltered, and the mobile users need to have the protected apps installed. And the BYOD mode decision, contained browser or hard block, has to be made and recorded rather than discovered at enforcement time. This ring displaces people onto a different way of working, so you tell them before you enable it, not after they file a ticket.
The policies that sit outside the rings
A few policies do not belong to a ring, because their timing is a decision rather than a sequence. The geo-fence is one, and it enables when the customer has made a deliberate call about it and set a real country list, not before. The agent policies are report-only until an approved-agent inventory exists to enable them against, and turning on default-deny for agents without that inventory is a self-inflicted outage. Token protection is a pilot you run with the admin persona before you consider it broadly. And the per-app templates instantiate one application at a time as you classify the customer’s estate. These are not laggards. They are controls whose right moment is defined by a condition, not by the ring in front of them.
The thing that makes all of this safe is the one habit underneath every ring: export before you change. Every enablement is preceded by an IntuneManagement export of the current state, so that reverting is a restore rather than an act of memory. And reverting, when you need it, means setting a policy back to report-only, not deleting it, because the report-only history is the evidence you will want when you work out why the ring bit. Enablement is the part of a Conditional Access deployment where patience is the whole skill. The policies are already written. The order is what keeps them from hurting anyone.
Repo: github.com/VirtualCaffeineIO/vcio-ca-framework
Conditional Access
‹ Previous: [CA 4.1] Building the Framework: From Zip to Green Gate
Next: [CA 4.3] Day One: TAP, Autopilot, and Protecting the Bootstrap ›
