A workable IAAM process starts with a trusted source of entity data, feeds that data into provisioning, and automates account creation in the identity provider and required applications. It should also establish access management and single sign-on, support periodic reauthorisation as the entity’s role changes, and ensure that exit notifications trigger immediate disablement and identity retirement.
How to structure IAAM from joiner to leaver
An effective IAAM process starts with a trusted source of entity data, then uses that source to drive provisioning, access assignment, periodic reauthorisation, and rapid offboarding. The design goal is consistency: every account, entitlement, and access path should be created, reviewed, changed, and retired from the same controlled lifecycle rather than through ad hoc tickets or manual exceptions.
The first design choice is the authoritative source of truth. If onboarding data comes from HR, a vendor master, or a contractor registry, that record should trigger the identity workflow instead of a separate manual request chain. Joiner-Mover-Leaver (JML) Guide is the clearest model for this because it ties onboarding, role change, and offboarding to one lifecycle. The practical test is whether the source can consistently tell you who the entity is, what role it has, who owns it, and when it should no longer exist.
Once the source is trusted, provisioning should be policy-driven rather than bespoke. A good IAAM process creates the identity in the identity provider, assigns the minimum required baseline access, and then extends access to applications through group membership, roles, or entitlement rules. IAM and IGA Basics supports this model well because it distinguishes authentication from authorization and connects provisioning to governance. Workforce Identity Security Guide is also useful where the process must include SSO, federation, and automated user provisioning across applications.
How access should change as the entity moves
IAAM should not treat access as static after day one. As a person, contractor, or service role changes, the workflow should remove obsolete access before adding new access, so privilege does not accumulate across roles. Reauthorisation and access review matter here because they force the organisation to confirm that standing access still matches current need, not historical convenience. That is especially important where access is grouped by function, project, or environment.
In mature designs, mover events also drive entitlement cleanup, not just new provisioning. The system should recalculate access from the current role or relationship and flag anything that falls outside the new policy. This is where lifecycle and governance converge, because the control objective is not only speed, but correctness: the entity should keep what it still needs and lose what it no longer should have.
For non-human entities, the same logic applies, but the control emphasis shifts to credentials, tokens, keys, and service access rather than HR status alone. Ultimate Guide to NHIs and NHI Lifecycle Management Guide both reinforce that lifecycle events must cover provisioning, rotation, offboarding, and visibility, not just account creation.
What offboarding must do before access becomes a liability
Offboarding should be event-driven and immediate. Exit notifications need to disable the identity, revoke active sessions where possible, retire credentials and keys, and remove the entity from all access paths that were granted through the lifecycle. Delayed deprovisioning is one of the clearest ways for a well-designed onboarding process to turn into a retention problem later.
The most common weakness is treating offboarding as an HR closeout step rather than an access-control event. If accounts remain enabled after departure, the organisation inherits unnecessary exposure through dormant access, stale credentials, and forgotten integrations. Top 10 NHI Issues and Coupang Signing Key Breach both illustrate why unrecovered credentials and missed deprovisioning steps can persist well beyond the original event that created them.
Risk and Threat Considerations
The main risk in IAAM is lifecycle drift: access is granted once, then retained too long, duplicated across systems, or never fully revoked. That creates exposure for both misuse and compromise, because attackers often benefit more from durable standing access than from sophisticated initial exploitation.
Failure mechanism: Weak source data, delayed provisioning rules, incomplete mover handling, or missed offboarding leaves active accounts, stale entitlements, or valid credentials in place after the business relationship has changed.
Impact: The result is overprivilege, orphaned access, and a larger blast radius if a credential is abused, a session is stolen, or a former user or integration remains trusted after it should have been retired.
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 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IAAM depends on lifecycle control of credentials, tokens, and keys. |
| AC-2 — Account Management | IAAM is fundamentally about account creation, change, and disablement across lifecycle events. | |
| IA-2 — Identification and Authentication (Organizational Users) | Onboarding and access setup rely on establishing and authenticating workforce identities. | |
| Recommendation — Manage authenticators through issuance, rotation, revocation, and retirement. Automate account provisioning, modification, and deactivation from authoritative source data. Authenticate organizational users through controlled identity proofing and sign-on. | ||
Practitioner Guidance
What to verify: Confirm that every lifecycle event is tied to a trusted source record and that the workflow reaches the identity provider, downstream applications, and any credential store or token system that can still authenticate the entity. If any one of those layers is manual, the process is not truly end-to-end.
Decision rule: If the entity can still authenticate after the offboarding event, treat the process as failed until disablement, session termination, and credential retirement are confirmed. If a mover event changes role or sponsorship, remove old access before granting new access.
Practitioner takeaway: The strongest IAAM designs are lifecycle systems, not ticket workflows: they make access creation, change, review, and retirement follow the entity’s real status with as little human delay as possible.
Related resources from NHI Mgmt Group
- How should organisations design an IAM workflow that covers onboarding, changes, and offboarding without creating unnecessary operational overhead?
- How should organisations assign ownership for onboarding and offboarding non-employee identities in an IAAM program?
- How can organisations reduce the risk of stale API keys and machine tokens?
- How should organisations govern API partner onboarding as a non-human identity process?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
