Microsoft Entra is a globally distributed service that provides identity and access management to millions of customers world-wide. To scale reliably and remain resilient during failures, Microsoft Entra uses an eventually consistent directory model.

Key takeaway

A successful write to Microsoft Entra does not guarantee that an immediate read will reflect that change. This article explains how eventual consistency appears in Microsoft Entra, why it exists, and the concrete patterns you should use when building applications that create, update, or manage directory objects. Eventual consistency applies regardless of the programmatic interface used. Applications built directly on Microsoft Graph or higher-level tools like PowerShell need to design for eventual consistency.

What eventual consistency means in Microsoft Entra

When you create or update a directory object such as a user, application, service principal, or group membership, the write is accepted first and replicated asynchronously across directory replicas. During this replication window, it is normal for:

• A read request to not return the latest data for entities that have been recently updated.
• A newly created object to return a “Not Found”
• A recently updated property to not yet be visible

This behavior is expected and documented for Microsoft Entra and should be handled explicitly by client applications.

Why Microsoft Entra behaves this way

Microsoft Entra operates on top of a multi-region, multi-replica directory architecture designed for scale, availability, and fault tolerance. Reads are served from nearby replicas for performance, while writes are replicated asynchronously.

App-only vs delegated access

Delegated access (app + user):

• Requests run on behalf of a signed-in user
• Consistency across requests is often observed

Application-only access (app-only):

• Requests run without a user context
• Common for background jobs and automation
• Consistency across requests is not guaranteed by design

Recommended design patterns

1. Prefer delegated flows when consistency is required. If your scenario is interactive and user-driven, delegated access may provide more predictable consistency behavior.
2. Trust successful write responses. If a write operation returns a success status, treat the operation as complete. Avoid immediate reads whose only purpose is confirmation.
3. Cache identifiers and properties you just wrote. Use IDs and properties returned in the response body of create calls instead of re-reading the object immediately.
4. Reduce multi-step workflows. Avoid create-read-update sequences when a single call or fewer operations can achieve the same outcome.
5. Poll with exponential backoff when a read is required. When a read is unavoidable, treat not found responses as transient and retry with exponential backoff.
6. Make retries idempotent. Design retries so repeated requests do not cause duplicate resources or unintended side effects.

What not to do

• Assume immediate visibility after a write
• Treat not found after creation as a permanent failure
• Use fixed sleep delays without retry logic
• Build workflows that depend on strict ordering across separate calls to Microsoft Entra

Final takeaway

Microsoft Entra is eventually consistent by design, particularly for application-only scenarios. Applications that trust successful writes, minimize read-after-write dependencies, and implement safe retries are more resilient, scalable, and production-ready.