TL;DR: Access onboarding and termination policies are meant to enforce least privilege, automate offboarding, and prevent internal misuse, but StrongDM’s guidance shows they still fail when role changes, third-party systems, and manual handoffs are left outside the process. The real issue is that access review cadences assume lifecycle events are captured consistently, which is often untrue.
At a glance
What this is: This is a lifecycle governance analysis showing that onboarding and termination policies break down when access changes are not captured consistently across internal and external systems.
Why it matters: IAM and IGA teams need to treat onboarding, role change, and offboarding as one control surface, because missed handoffs leave excessive access in place across human and non-human estates.
By the numbers:
- Employees and other internal users were the cause of 60% of data breaches in 2016.
Context
Access onboarding and termination policy is a governance control for granting, changing, and removing access as people move through an organisation. The article argues that the control fails when lifecycle events are handled manually, when external systems are left out of the process, and when role changes do not trigger entitlement review.
For identity teams, the problem is not policy intent but lifecycle coverage. If HR, IT, app owners, and third-party platforms do not follow the same access state changes, least privilege becomes a paper standard rather than an operating control.
The article frames SOC 2-relevant access governance as an operational discipline, not a documentation exercise. That makes it directly relevant to IAM, IGA, and PAM teams responsible for joiner-mover-leaver processes across internal platforms and partner systems.
Key questions
Q: What breaks when access onboarding and termination is only managed in one directory?
A: The control breaks when access exists in more than one system. A central directory can be updated while third-party portals, support tools, and managed service accounts still retain active access. That leaves former users or moved employees with permissions that no longer match their role, which defeats least privilege and creates audit gaps.
Q: Why do role changes create so much access creep?
A: Role changes create access creep because organisations are faster at adding new access than removing old access. The old permissions are often still usable, carry no immediate operational pain, and therefore survive the transition. The result is accumulated access from previous roles that expands blast radius and weakens least privilege.
Q: How can security teams tell whether termination controls are actually working?
A: Look for complete revocation evidence across every system that can authenticate the user, not just the HR or primary directory record. If any support portal, vendor platform, or privileged tool still shows active access after termination, the control is failing. Effective termination is demonstrated by full closure, not by a completed ticket.
Q: Who should prioritise access governance over access management first?
A: Organisations with heavy regulation, complex role structures, or weak visibility into entitlements should usually prioritise governance first. That includes environments that must prove access decisions to auditors or manage many role changes across business units. If enforcement already exists but oversight is thin, governance closes the policy, review, and evidence gap that operational tools do not solve.
Technical breakdown
Why onboarding checklists fail when access is provisioned by hand
Onboarding policies often rely on a chain of human handoffs. HR informs IT, IT creates access, and app owners approve permissions, but every manual step creates a place where role scope can drift from job scope. Least privilege is not just about initial assignment; it depends on accurate entitlement mapping across internal systems and any external portals tied to work. When onboarding is treated as a one-time event instead of a governed lifecycle, excessive access gets embedded before anyone notices.
Practical implication: map each onboarding approval to a named entitlement owner and remove any access path that is not tied to the role model.
Why termination policies miss third-party and external systems
Termination controls often assume a central directory is the only place access exists, but the article notes that managed service providers, support portals, and other external systems may use different authentication systems. That means deprovisioning is incomplete if it stops at the primary directory. The control failure is not just slow revocation; it is incomplete revocation across disconnected identity domains. In practice, the same person can remain active in one environment long after they are disabled in another.
Practical implication: inventory every system that can grant access and require termination sign-off from each system owner, including third-party platforms.
How role changes create privilege creep without recertification
Role changes are lifecycle events, not exceptions, but many organisations treat them as informal transitions. When an employee is promoted or moved, old permissions often survive because no one re-runs the access decision against the new job scope. That is classic privilege creep. Access review cadence matters, but only if reviews actually compare current duties to current entitlements. Without that comparison, recertification becomes a calendar event rather than a control that removes stale access.
Practical implication: recertify access on mover events, not just on quarterly cycles, and remove inherited entitlements that no longer match job function.
Threat narrative
Attacker objective: The objective is to retain or abuse access after lifecycle change so data and systems remain reachable beyond the intended employment or role window.
- Entry begins with legitimate onboarding or a role change that grants access broader than the new job requires, often through manual provisioning.
- Credential access persists after termination when revocation is delayed, incomplete, or limited to the central directory instead of all connected systems.
- Escalation occurs when former users retain privileged or support access in external portals, giving them reach into systems that were supposed to be closed.
- Impact follows when an internal or former user can still view, modify, or export data after their access should have ended.
Breaches seen in the wild
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Lifecycle control fails first as a governance design problem, not an implementation gap. Access onboarding and termination policies assume that identity state changes are captured once and propagated everywhere that access exists. That assumption breaks when HR, IT, app owners, and third-party platforms maintain different records of who should still have access. The implication is that lifecycle governance must be measured by actual entitlement closure, not by policy existence.
Offboarding is only real when it reaches every downstream system. A central directory can be clean while support portals, managed service providers, and niche business applications still retain active access. That is why a termination process that ends at the directory boundary creates a false sense of control. Practitioners need to think in terms of access surface completeness, because partial revocation still leaves an identity live where it matters.
Role change is the most neglected lifecycle event in entitlement governance. Organisations often focus on joins and leaves while treating promotions and internal transfers as low-risk admin tasks. In reality, movers are where excess privilege survives longest because old access is rarely challenged with the same urgency as termination. This is where recertification, entitlement ownership, and job-function alignment either work together or fail together.
Named concept: lifecycle coverage debt. The gap is not simply poor offboarding speed, but the accumulated mismatch between where access is granted and where access is revoked. That debt grows whenever external systems, manual tickets, or ad hoc approvals sit outside the formal lifecycle workflow. The practical conclusion is that access governance must be designed around complete lifecycle coverage, or excess privilege will persist by default.
SOC 2 access control evidence is only credible when lifecycle evidence is complete. Policies that describe least privilege are weaker than audit trails that show onboarding, mover, and leaver actions across all relevant systems. StrongDM’s article points back to a common compliance problem: organisations document the process but do not prove every access path follows it. Practitioners should treat lifecycle evidence as an audit object, not an afterthought.
From our research library:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- Read next: NHI Lifecycle Management Guide
What this signals
Lifecycle coverage debt: The real issue is not whether an access policy exists, but whether every access path is bound to the same joiner, mover, and leaver workflow. As organisations add support portals, MSP tooling, and cloud services, the chance of orphaned access rises unless governance is designed around complete closure rather than central directory updates.
StrongDM’s guidance reinforces a practical truth for IAM and IGA teams: role change is where entitlement drift hides most effectively. If mover events are not treated as mandatory reauthorization points, privilege creep becomes a normal state instead of a control failure.
For practitioners
- Map every access-bearing system Build a complete inventory of internal applications, external portals, support tools, and managed service platforms that can grant or retain access after onboarding or termination.
- Tie mover events to entitlement reset Require every role change to trigger an entitlement review against the new job scope, with old access removed before new access is confirmed.
- Automate termination closure checks Use workflow triggers to confirm that access has been revoked in every system listed for the user, not only in the central directory.
- Require application owner approval for high-risk access Make app owners validate privileged or sensitive permissions during onboarding and after role changes so access aligns with current business need.
- Review lifecycle controls on a fixed cadence Run periodic reviews of onboarding and termination evidence, looking for missing offboarding steps, stale permissions, and systems excluded from the workflow.
Key takeaways
- Access onboarding and termination only works when it governs every place access can exist, not just the primary identity store.
- Role changes are a major source of privilege creep because old permissions often survive transitions into new jobs.
- The strongest control is full lifecycle closure across internal and third-party systems, backed by evidence that access was actually removed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article centres on failed termination and incomplete access revocation. |
| NHI-05 — Overprivileged NHI | Role changes and weak onboarding leave users with permissions beyond current need. | |
| Recommendation — Audit offboarding workflows for every access-bearing system and close any path that survives termination. Re-baseline entitlements at mover events and remove permissions that no longer match the role. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about governing who retains what access across lifecycle events. |
| Recommendation — Apply PR.AA-05 to ensure authorisations are reviewed, updated, and revoked as identities change. | ||
| CIS Controls v8 | CIS-5 — Account Management | Lifecycle onboarding and termination are core account management controls. |
| Recommendation — Use account management controls to inventory, provision, and disable accounts across all connected systems. | ||
Key terms
- Lifecycle coverage: Lifecycle coverage is the degree to which an identity programme controls access from joiner to mover to leaver, including provisioning, revocation, and review. For mixed environments, it must follow the identity across directories, SaaS apps, and delegated admin paths, not just the login point.
- Privilege Creep: Privilege creep is the gradual accumulation of access rights beyond what an identity actually needs. It usually happens when permissions are added for convenience and never removed. For NHIs, privilege creep expands blast radius and makes old credentials far more dangerous than their original purpose suggests.
- Credential Revocation: Credential revocation is the process of disabling a secret, token, or key so it can no longer authenticate or authorize action. It is the operational half of detection, because exposed credentials remain dangerous until they are invalidated and replaced across every dependent system.
- Joiner-Mover-Leaver Lifecycle: The joiner-mover-leaver lifecycle describes the access changes that should happen when a person or account is created, changes role, or exits the organisation. It is the basic operating model for keeping entitlements aligned to current need, and it becomes critical when automation replaces manual ticket handling.
Deepen your knowledge
NHI governance, identity lifecycle, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org