Configuration drift gets discussed as though it were a discipline problem — someone was rushing, someone skipped a checklist. That framing survives because it is comfortable and because it suggests an obvious fix: try harder.
It does not survive contact with the arithmetic.
The maths nobody runs
Take a security baseline of six settings: a Conditional Access policy set, named locations, authentication methods, a PIM role configuration, a session-lifetime rule, a legacy-authentication block. Apply it across two hundred tenants by hand.
Twelve wrong settings you will not find
The twelve are not distributed helpfully. They are invisible, because a misconfigured Conditional Access policy does not fail loudly — it silently does not apply, or applies to a slightly wrong group, and everything continues to work.
You find them in one of three ways. An audit surfaces one. A breach review surfaces one. Or a client asks a question specific enough that someone opens the tenant and looks. None of those is a monitoring strategy.
This is also why drift compounds. A setting that was wrong at onboarding stays wrong through every subsequent change, and the next engineer to touch that tenant reasonably assumes the existing state was intentional.
Pick three tenants at random and compare one Conditional Access policy across all three, field by field. Not whether the policy exists — whether it is identical. The result is usually informative.
The structural fix is a template, not a checklist
A checklist reduces the error rate per action. It does not reduce the number of actions, which is the term doing the damage.
The alternative is to make the baseline an artefact rather than a procedure: author it once, version it, simulate it against a specific tenant to see exactly what would change, then deploy it to whichever tenants you select. The number of human configuration events drops from 1,200 to one, and the remaining risk moves from "did somebody tick this box correctly two hundred times" to "is the template right", which is a question you can actually answer.
On this platform that covers Conditional Access policy sets, named locations, authentication methods, PIM role configuration and full security baselines. Each deployment is previewed per tenant before anything is written, and the outcome is recorded.
What to ask a vendor
Ask to see the propagation run, not a screenshot of the settings page. Specifically: across more than one tenant, with the simulation step shown, and with the record of what changed afterwards.
A platform that can only show you the settings screen is showing you the thing that produces the 1,200 events, not the thing that removes them.