Microsoft 365 Configuration Drift, CA Readiness and Response
What changed in Microsoft 365 configuration drift templates and pushes, how to see who a Conditional Access policy would block, and what Response adds.
Most of the risk in managing Microsoft 365 at scale sits in the moment you change something. A push overwrites an exception a tenant needs. A Conditional Access policy goes On and blocks people nobody counted. A compromised account gets "fixed" in a way Microsoft never registers.
TL;DR: Three updates follow one rule: see what a change will do, let a person decide, and treat nothing as done until Microsoft shows it. Config Drift now previews every push and respects what each tenant keeps as its own. The Conditional Access Analyzer names who a policy would block before it goes On. Response, coming soon, lets IT teams contain a compromised user or isolate a device across every tenant, with every step approved, logged and reversible.
Config Drift: one standard that bends where tenants differ
Drift standards fail when one template has to cover everything and every scan repeats the same accepted exceptions until nobody reads it. Config Drift templates now cover only what you choose: configuration profiles, compliance, app protection or Conditional Access, per platform. A tenant can follow several, such as a Windows standard and a macOS standard. Coverage also grew to compliance policies, app protection policies, the Enrollment Status Page and Windows Autopilot profiles, which are compared but never pushed because Microsoft does not let an app change them.
The scan page now shows what a push would do with each policy, and why:
| Push outcome | Example |
|---|---|
| Update | A policy switched to Report-only goes back to On |
| Create | A compliance policy the tenant never got is written |
| Delete | An old copy of a standard policy is removed |
| Keep | A setting you accepted as a deviation stays as it is |
| Skip | A Conditional Access policy waits for its missing target group |
Your decisions now bind the push: it no longer overwrites, deletes or creates what you accepted. A template can let each tenant keep its own assignments, and a Conditional Access template can let each tenant keep its own included and excluded users and groups while the rest of every policy is still compared. Groups, named locations, authentication strengths and assignment filters are matched by name, and a new Conditional Access policy arrives in the template's state, which the preview shows before you confirm.
Conditional Access Analyzer: who a policy would block
Report-only mode shows what a policy would have done to sign-ins during the test. It cannot judge a policy you have not created yet, and it misses users who did not sign in.
The Conditional Access Analyzer answers one question per policy, existing or not yet written: who is in scope, who satisfies it today and who would be blocked, with names. It only reads, and it checks each user against the sign-in methods they have actually registered. When the answer depends on the sign-in, such as a location condition, the user reads Conditional, never silently blocked or safe.
Scope is not reach
In one tenant, a policy protecting the Microsoft admin portals targeted All users. Over its scope, 5,705 users would be blocked. In the sign-in logs, 16 people had actually opened an admin portal. Both numbers are true: one says what the policy could do, the other who it would interrupt this month. The Analyzer now shows both, with names.
Coming soon: Response
Response handles the change an attacker made. It brings what Microsoft Defender and Entra ID Protection flag across your tenants into one queue: incidents, risky users and isolated devices.
From there you contain a user or isolate a device. Containment is built from the user's real state: sign out everywhere, remove sign-in methods added since the first risk detection, reset a cloud account's password, issue a Temporary Access Pass, and optionally block sign-in. Devices are isolated by default only where Defender rates their risk medium or high, because a stolen password does not compromise every PC the user owns.
- A person approves every step. Nothing runs from an email.
- Everything can be undone. Unblock, dismiss the risk, delete the pass, release the device.
- Everything is logged: who started it, who approved it and what Microsoft answered. A protected list keeps break-glass and service accounts out of every run.
Response builds on Defender's automatic attack disruption instead of racing it. It shows what Microsoft already did, fills in what it leaves, and never acts twice.
A race worth knowing about
Microsoft confirms at its own pace, so a step reads "waiting for Microsoft" until Microsoft shows the result. Testing showed why that matters. When we confirmed a user compromised and reset their password a second apart, Microsoft processed the confirmation about two minutes after the reset. The reset cleared nothing and the user stayed at high risk. A reset alone clears the risk, so Response leaves the confirmation off when a run resets the password.
Response is rolling out to early access partners first and is included in every plan. To join, ask us through the chat on this page.
Written by Lora, Implora's AI. Reviewed and approved by the Implora team.