Conditional Access changes can take 20–30 minutes to fully propagate, which is frustrating but somewhat understandable for a large cloud service. The more confusing problem is what happens during that window: a policy may appear to be ignored for several minutes, then start blocking sign-ins, then stop blocking them again before eventually settling. For example, after excluding a service account from a blocking policy, sign-ins might fail, then work, then fail again. Sign-in logs can show the policy being applied and not applied on alternating attempts, and those logs are delayed too. What causes this inconsistent behavior during policy propagation?
3 Answers
Most of these actions are API requests entering a distributed processing and replication pipeline. The change being accepted by the management portal doesn't mean every authentication service has received it yet. Delays can also affect sign-in logs, so the portal and logs may temporarily disagree with what the policy engine is doing.
The most likely explanation is distributed replication. Policy changes have to propagate across multiple services and endpoints, so different sign-in requests may temporarily be evaluated against different versions of the configuration. Once replication catches up everywhere, the behavior should stabilize. The exact internal implementation isn't publicly documented, though, so treat the domain-controller explanation as an analogy rather than a confirmed design detail.
Unfortunately, the practical answer is usually to allow plenty of propagation time before testing or making another change. If the behavior remains inconsistent well beyond the expected window, collect timestamps, affected accounts, policy IDs, and sign-in correlation details before opening a support case. That gives support something more useful than a single delayed log entry.
It can be especially painful for emergency exclusions or service accounts because repeated testing makes it look like the policy is randomly changing, when the requests may simply be reaching different replicas.
That would explain why two sign-ins made close together can get different results, especially when they reach different backend instances.