What should teams check before centralising multiple client directories?

What to check before centralising client directories

Before consolidating client directories, teams should test whether the new design still keeps each client’s identities, permissions, and administrative actions isolated. Centralisation can reduce duplication and simplify oversight, but it only works if the control plane does not become a shared trust boundary that makes mistakes wider and harder to reverse.

It is also worth checking whether the directory model supports distinct ownership, expiry, review, and revocation for each client. If one client’s lifecycle events are handled through a common store, the operational benefit is real only when those events remain attributable and reversible at client level.

Why tenant separation and revocation are the deciding tests

The core question is not whether centralisation is technically possible, but whether it preserves tenant separation under normal operations and during failure. A central directory can improve consistency, yet it also concentrates access paths, so a mis-scoped role, shared group, or inherited permission can expose more than one client at once.

Clean offboarding is the other decisive test because directory consolidation often hides stale access until a client relationship ends. If you cannot remove a client’s access without touching unrelated tenants, the directory has become an operational dependency rather than a controllable management layer.

That is why the right design usually includes explicit boundaries for ownership, object scope, and delegation. A central view should help operators manage the estate, but it should not collapse the separation between clients or make revocation depend on manual exception handling.

What good centralisation looks like in practice

Well-designed consolidation keeps the administration model simple while keeping the security model narrow. Each client should still have clearly defined administrative scope, distinct lifecycle rules, and a reliable way to prove which identities, groups, and entitlements belong to which tenant.

Teams should also verify that logging and audit trails still distinguish actions by client, because shared directories often blur accountability if every event lands in the same administrative namespace. That matters most where onboarding, permission changes, and emergency access are handled centrally but must still be reviewed per client.

In many environments, the practical standard is to centralise control without centralising trust. That means shared operations, but isolated permissions; shared monitoring, but tenant-specific revocation; and shared tooling, but no implicit access across client boundaries.

Risk and Threat Considerations

Centralising multiple client directories creates a concentration point for misconfiguration and abuse. If tenant boundaries are weak, a single directory error can leak access across clients, and a delayed offboarding process can leave dormant paths open long after a relationship should have ended.

Failure mechanism: Shared administration collapses object scope, group membership, or delegated authority across tenants, so a mistaken update or compromised admin path can affect multiple clients at once. Weak separation also makes it easier for stale entitlements to survive because removal has to be coordinated through one common control plane.

Impact: The result can be cross-client exposure, slower revocation, and audit difficulty when you need to prove which identities belonged to which tenant. The more the model depends on manual cleanup, the more likely centralisation becomes a source of persistent access risk rather than operational efficiency.

Practitioner Guidance

What to verify: Confirm that every client can be identified, scoped, and removed independently in the directory model, including groups, delegated admins, service principals, and any inherited permissions. If any one of those cannot be cleanly separated, treat that as a design flaw rather than an implementation detail.

Decision rule: Centralise only when the shared platform improves governance without creating cross-tenant authority or weakening offboarding. If the central view is simpler but revocation becomes ambiguous, the design has traded operational convenience for excess access risk.

Practitioner takeaway: The right test is not whether one directory can hold everything, but whether each client still has a bounded lifecycle and a reversible exit when central management is removed.

Related resources from NHI Mgmt Group

• How should compliance teams verify business registration across multiple states before onboarding a vendor or client?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?