When does directory synchronisation fall short for access governance?

Why directory synchronisation is not the same as governance

Directory synchronisation is useful for keeping identities, attributes, and group membership aligned across systems, but it is not a complete access control model. Governance starts where replication ends: proving that a user, service, or account no longer retains access in every place it was granted, including applications, SaaS entitlements, local groups, and endpoint permissions. For the broader identity lifecycle view, see IAM and IGA Basics and the Joiner-Mover-Leaver (JML) Guide.

In practice, synchronisation can keep a directory current while downstream access remains stale. That gap matters because many entitlements are granted outside the directory itself, through application roles, local admin groups, tokens, caches, delegated admin paths, or account-specific exceptions. The result is an identity record that looks accurate while effective access is still broader than intended.

As a governance control, synchronisation is only one input to lifecycle management. It supports provisioning and deprovisioning, but it does not verify that revocation actually propagated to each enforcement point. That is why access governance usually needs explicit review, certification, and closed-loop removal, not just attribute sync. Access Reviews and Certification Guide is the natural next step when you need to close that loop, and the IGA Buyer's Guide is useful when evaluating platforms that must connect those revocation paths.

Where synchronisation breaks down across the stack

The failure mode is usually partial coverage. A directory update may remove a group assignment, but the application may still hold a local role, an API token, a cached session, a synced-but-not-removed entitlement, or a secondary account in a different system. In endpoint contexts, old admin group membership or persisted local privileges can survive even after the source directory has changed.

This is why governance has to treat access as a distributed state, not a single source-of-truth field. If the control only checks whether the directory changed, it misses whether the downstream system actually enforced that change. The same issue appears with movers and leavers: a move may preserve too much access, and a leaver may be removed from the directory while residual permissions continue to function elsewhere.

That is also where role and entitlement design matters. If access is granted too widely at the role level, synchronisation can faithfully replicate the wrong access everywhere. The Role Mining and Role Design Guide is relevant because overbroad roles make downstream cleanup harder, not easier, and SoD conflicts can survive directory updates if the real grant lives in the target system.

What good access governance requires beyond sync

Good governance needs authoritative lifecycle events, connector coverage, and evidence that removal succeeded in the target system. That usually means revocation workflows, entitlement reconciliation, periodic access review, and exception handling for systems that cannot be fully automated. The directory should be treated as one control plane, not the whole control plane.

Practitioners should verify three things before trusting sync-based governance: first, that every important downstream system is connected; second, that revocation is authoritative rather than advisory; and third, that any delay or failure in propagation is visible and remediated. Where applications keep their own roles or caches, the organisation needs a reconciliation process that compares intended access with effective access, not just directory state.

When this gets overlooked, the problem is usually not that the directory was wrong. The problem is that the access model was fragmented. The Identity Visibility and Intelligence Platforms (IVIP) Guide is useful here because visibility over effective access is what exposes the gap between synced identity data and actual permissions.

Practitioner Guidance

What to verify: Treat any system that can grant access outside the directory as a separate revocation target. If you cannot prove that removal from the directory also removed access in the application, endpoint, or privileged context, the control is incomplete.

Decision rule: If a system issues its own roles, tokens, local groups, or cached access, require explicit deprovisioning or reconciliation there rather than assuming directory sync will clear it.

Practitioner takeaway: Synchronisation is evidence that records match, not evidence that access is gone; governance is only real when every place that can exercise the privilege has been checked or revoked.

Related resources from NHI Mgmt Group

• What is the difference between role-based access and API key governance for NHI security?
• Why do traditional secrets vaults fall short for cloud access governance?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?