They should redesign lifecycle workflows around the real control surface: operating systems, app types, and identity stores actually in use. The goal is to reduce exception paths and make provisioning and deprovisioning reach every place where access decisions matter. That often requires reclassifying some systems as governed exceptions until automation can cover them.
Why a directory model has to follow the estate, not the other way around
The practical problem is usually not directory software itself, but a mismatch between how the directory is modeled and how access is actually granted. If operating systems, application types, or identity stores differ from the assumed model, lifecycle actions miss real control points. Teams then end up managing accounts in one place while access decisions still happen somewhere else.
When that gap exists, provisioning and deprovisioning become partial controls. The directory may still look orderly, but it no longer represents the full access surface, so ownership, joiner-mover-leaver handling, and exception handling all drift apart. The right response is to redesign the lifecycle around the systems that actually enforce access, then reduce any remaining exceptions over time.
In practice, that means treating the directory as one part of the control plane rather than the whole control plane. Different estate segments often need different authoritative sources, different automation paths, and different recertification logic. The key question is whether a lifecycle event reaches every place where an access decision can still be effective.
What changes when systems do not share one clean directory model
A directory model that assumes uniformity often breaks first at the boundaries: mixed operating systems, legacy applications, separate admin stores, cloud identities, or business systems that do not rely on the central directory for authorization. If teams try to force those systems into a single pattern, they create manual workarounds and hidden accounts that bypass normal lifecycle controls.
The cleaner approach is to classify the estate by control surface, then map each class to the identity store or workflow that actually governs it. That may mean one workflow for human users, another for privileged accounts, and another for application or service access where the application itself is the authority. The objective is consistency of control, not sameness of implementation.
That is also why exception handling matters. A governed exception is preferable to pretending the model is universal, because it makes ownership, review cadence, and expiry visible. Over time, those exceptions become the backlog for automation and rationalization rather than a permanent shadow process.
How to decide what to redesign first
Start with the places where access changes have the highest operational or security impact. Systems that hold privileged access, production data, or externally exposed credentials should be first in line because lifecycle failure there is hardest to absorb. If the directory cannot reach those systems directly, teams should redesign the workflow before expanding any more scope.
Then separate systems by the kind of control they require. Some platforms need account creation and removal only, while others need entitlement-level changes, role mapping, or periodic revalidation. A single generic workflow usually fails because it does not respect the real differences between OS-level access, application authorization, and identity-store sync.
For the same reason, redesign work should include deprovisioning verification, not just ticket closure. If an account is disabled in one store but still active in another, the lifecycle is incomplete. Good redesign replaces assumptions with measurable end states, so teams can prove access was actually removed where it mattered.
Risk and Threat Considerations
When the directory model lags the estate, the main risk is incomplete control coverage. Access can persist in unmanaged systems, service paths, or legacy stores after it has been removed from the central directory, which creates over-retention, orphaned access, and a wider blast radius during compromise.
Failure mechanism: Lifecycle events terminate in the directory but do not propagate to the real enforcement points, so removed users, stale accounts, or exceptions remain active where access is actually decided. That gap is especially dangerous when a platform has local authorization or cached credentials outside the central model.
Impact: Teams can lose confidence that joiner-mover-leaver controls are complete, audit evidence becomes weaker, and attackers or insiders have more places to hide persistent access. In the worst case, the estate develops a parallel identity plane that is harder to see, govern, and recover.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Lifecycle redesign depends on controlling credential issuance, change, and revocation across the estate. |
| AC-2 — Account Management | The question is about aligning provisioning and deprovisioning with the systems that actually hold accounts. | |
| IA-9 — Service Identification and Authentication | Mixed estates often include services or applications that authenticate outside the main directory model. | |
| Recommendation — Apply IA-5 to ensure credential lifecycle actions reach every active access path. Use AC-2 to govern account creation, modification, review, and removal across all identity stores. Apply IA-9 where non-human or service access must be governed by its real authentication path. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | The topic is fundamentally about matching identity lifecycle processes to the live estate. |
| A.5.18 — Access rights | Redesign must ensure access rights are granted, changed, and removed wherever control is enforced. | |
| Recommendation — Define authoritative identity sources and lifecycle ownership for each system class. Review and revoke access rights across every system that still enforces its own access decisions. | ||
Practitioner Guidance
What to prioritise: Rebuild the lifecycle around the systems that can still grant or deny access, not around the directory org chart. The first redesign target should be the highest-impact estates where a missed deprovisioning event would matter most.
What to verify: For each system class, verify the authoritative identity source, the actual deprovisioning path, and the evidence that revocation has completed. If you cannot prove those three points, treat the system as a governed exception until the workflow is fixed.
Common mistake: Teams often declare victory when synchronization exists, even though sync is not the same as control. Replication without lifecycle coverage still leaves stale access behind if an application or platform can make its own access decisions.
Practitioner takeaway: The goal is not a single tidy directory, it is complete lifecycle reach across the real estate, with every exception made visible, owned, and eventually eliminated.
Related resources from NHI Mgmt Group
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- How should security teams investigate cloud incidents when the current configuration no longer matches the failure state?
- How should teams plan an OAuth or OIDC provider upgrade when the release includes schema changes, token model changes, and directory sync changes?
- How can teams tell whether their serverless security model matches the real Lambda execution model?