By NHI Mgmt Group Editorial TeamBased on Entro Security: “Secure IT onboarding and offboarding checklists” (November 30, 2023)

TL;DR: Delayed de-provisioning, orphan secrets, and shared access are the core failure patterns in IT onboarding and offboarding, according to Entro Security, with its checklist guidance showing why employee lifecycle steps now double as identity security control points. Lifecycle governance, not just user provisioning, is where secrets exposure and residual access are won or lost.


At a glance

What this is: This is an analysis of IT onboarding and offboarding as NHI control points, with the key finding that delayed de-provisioning and orphan secrets create avoidable exposure.

Why it matters: It matters because IAM, IGA, and PAM teams increasingly have to govern employee lifecycle events as credential lifecycle events, especially where service accounts, API keys, and shared access are involved.


Context

IT onboarding and offboarding are identity governance processes, not just HR workflows. When employees receive access, create secrets, or inherit shared credentials, the real control question is whether those permissions and tokens are traceable, limited, and removed on departure.

In NHI terms, the failure mode is simple: secrets and tokens often outlive the person who created or used them. That turns offboarding into a lifecycle and ownership problem for the identity stack, not a one-time admin task.

The article frames this through employee access, but the same governance pattern applies wherever credentials are created, shared, and forgotten across systems, collaboration tools, and cloud environments.


Key questions

Q: What breaks when offboarding only disables the primary account?

A: The lifecycle control remains incomplete. Users may still have active sessions, linked app permissions, or residual access through connected systems, which means the organisation records termination without actually ending access. That is a governance failure because it creates a false sense of closure and leaves exposure behind.

Q: Why do delayed offboarding processes create security risk?

A: Delayed offboarding creates security risk because access can remain active after the business relationship ends. Former users may still reach email, files, CRM, or admin tools, which expands the window for data theft or disruption. The issue is not the departure itself, but the period during which stale access still works.

Q: How can security teams prevent orphan secrets after employee departures?

A: Security teams should maintain a complete inventory of secrets ownership, map every dependency before offboarding, and rotate any token or key that the departing employee created or used. Without dependency mapping, revocation becomes guesswork and live services can break unexpectedly or remain exposed.

Q: What is the difference between user deprovisioning and secret revocation?

A: User deprovisioning removes the person’s ability to authenticate as a user, while secret revocation invalidates the machine credentials that may still exist in applications, scripts, or cloud services. Both are needed because a disabled account does not automatically kill the access paths created during work.


Technical breakdown

Why onboarding becomes a secrets governance problem

Onboarding is the point at which identities are provisioned, permissions are scoped, and credentials begin to accumulate. For non-human identity governance, that matters because developers and administrators often create API keys, tokens, and shared access paths before ownership metadata is complete. If secrets are issued without clear inventory and lifecycle state, the organisation cannot reliably answer who owns them, what they can reach, or when they should be removed. The control failure is not only over-permissioning. It is the absence of durable linkage between a person, the NHI assets they created, and the systems those assets can touch.

Practical implication: tie every newly created secret or token to a named owner and an offboarding trigger before production access is granted.

How offboarding fails when access revocation is partial

Offboarding breaks when account deactivation happens but token revocation, shared credential rotation, and downstream access cleanup do not. A departing employee can lose their login yet still leave behind active secrets in AWS, collaboration tools, or shared repositories. That creates zombie access, where the account is gone but the credential remains valid. In governance terms, the problem is incomplete revocation across all access surfaces, not just directory disabling. The article correctly treats secrets as part of the offboarding scope, because credential validity is what determines residual access, not employment status alone.

Practical implication: revoke all dependent credentials, not just the user account, and verify that shared secrets have been rotated after departure.

Why shared secrets create orphaned access paths

Shared secrets become orphaned when multiple teams use the same token, key, or password but no one can prove ownership after a departure. This is common when collaboration speed outruns governance discipline, especially in development and IT operations. Once the original owner leaves, the organisation inherits an access path without a clear custodian, making revocation risky because the token may still support live services. That is a classic NHI lifecycle weakness: the identity exists, but its operational ownership does not. Without an inventory of where the secret is used, revocation becomes guesswork rather than control.

Practical implication: maintain a current secrets inventory that records every dependency before you remove or rotate a credential.


Threat narrative

Attacker objective: The objective is to preserve usable access after the employee relationship changes, so sensitive systems and data remain reachable through stale credentials.

  1. Entry begins with routine employee onboarding or ongoing use of shared access, where tokens and keys are created as part of normal work.
  2. Escalation occurs when those credentials are reused, copied, or left unrotated across tools and environments that outlive the original user.
  3. Impact follows after offboarding, when the departed user can no longer be supervised but the orphan secret or shared credential still permits access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Onboarding is where NHI ownership starts, not where access merely begins. The article shows that provisioning, training, and credential creation are inseparable from lifecycle governance. Once API keys, tokens, and shared access paths are introduced without ownership metadata, the organisation has already created future offboarding risk. The practical conclusion is that secrets lifecycle design must start at issuance, not at departure.

Offboarding exposes the real failure mode: access revocation is often incomplete across identity surfaces. Disabling a directory account does not neutralise downstream tokens, shared credentials, or cloud access that was created during employment. That is why offboarding must be treated as a control plane problem across user accounts, NHI assets, and collaboration systems. Practitioners should judge offboarding by residual reach, not by ticket closure.

Orphan secrets are a lifecycle failure, not just a hygiene issue. The article’s strongest insight is that secrets sprawl becomes dangerous when ownership and dependency mapping are weak. A secret with no known custodian cannot be safely revoked on demand, which means the organisation is carrying hidden privilege. The implication for NHI programmes is clear: inventory quality is a security control, not an administrative preference.

Manual review does not scale to lifecycle assurance for secrets. The article correctly notes that automated verification is needed when multiple tokens and keys may be tied to one person. That is a governance statement, not a tooling claim. For identity teams, the field should now treat offboarding verification as a repeatable control outcome, especially where service credentials can persist after the human owner has gone.

Identity lifecycle governance now spans human, NHI, and collaboration surfaces together. IT onboarding and offboarding are no longer isolated employee processes because modern work creates machine-like access artefacts during human activity. This widens the governance boundary for IAM, IGA, and PAM teams. Practitioners should align lifecycle controls so that a person’s departure also closes every credential path their work created.

From our research library:

What this signals

Lifecycle control is now the security boundary: onboarding creates access pathways and offboarding must close every one of them. Teams that still treat secrets as a separate operational domain will keep missing the moment where a human departure turns into lingering NHI exposure.

The practical shift is from user exit checklists to credential exit assurance. That means integrating access review, secret inventory, and rotation verification into the same workflow so a departed employee cannot leave behind live access in cloud, collaboration, or development systems.


For practitioners

  • Define secrets ownership at creation Require every API key, token, or shared credential created during onboarding to have a named owner, system dependency, and offboarding trigger before it is used in production.
  • Revoke credentials beyond the user account Treat offboarding as a full credential-lifecycle event by disabling user access, rotating downstream secrets, and confirming that all tokens tied to the departing employee are no longer active.
  • Inventory shared access paths before departure Map where each credential is used across cloud accounts, collaboration tools, and developer workflows so the team can rotate or delete the right secret without breaking live services.
  • Automate offboarding verification Add a control step that checks whether every known secret, token, and privileged credential associated with the leaver has been removed, rotated, or reassigned.
  • Train teams not to share secrets in collaboration tools Use onboarding training to stop the common habit of pasting credentials into Slack, Jira, or similar tools, since those channels often create the hidden exposure that offboarding later struggles to unwind.

Key takeaways

  • IT onboarding and offboarding now function as identity control points because they determine whether secrets and access paths are created, owned, and removed correctly.
  • The article’s core warning is that delayed de-provisioning and orphan secrets extend exposure beyond employment changes, especially when API keys and tokens are involved.
  • The control that matters most is complete lifecycle cleanup, including account revocation, secret rotation, and ownership mapping for every downstream credential.

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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-01 — Improper OffboardingThe article centres on leaving credentials active after employees depart.
NHI-02 — Secret LeakageSecrets shared in tools and left behind after exit are the article's main exposure pattern.
NHI-05 — Overprivileged NHIThe checklist stresses granting only role-appropriate access at onboarding.
Recommendation — Map offboarding checkpoints to NHI-01 and verify that every credential is removed or rotated before closure. Scan collaboration tools and developer workflows for leaked secrets and remove any exposed credentials immediately. Review onboarding grants against NHI-05 so new access is limited to the minimum needed for the role.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article is fundamentally about provisioning and removing access entitlements across the employee lifecycle.
Recommendation — Apply PR.AA-05 to align onboarding grants and offboarding removals with current job responsibilities.
CIS Controls v8CIS-5 — Account ManagementAccount creation, deactivation, and shared credential cleanup are central to the checklist.
Recommendation — Use CIS-5 to standardise account creation, deactivation, and periodic access review across employee lifecycle events.
MITRE ATT&CKTA0006;TA0008 — Credential Access; Lateral MovementThe article describes how stale credentials can be reused for access after departure.
Recommendation — Map stale tokens and shared secrets to TA0006 and TA0008 to prioritise cleanup paths that enable reuse and spread.

Key terms

  • Onboarding Lifecycle Controls: The governance checks that define what access, secrets, and devices a new employee receives at entry. In practice, these controls must bind identity issuance to ownership, scope, and review so newly created credentials do not become unmanaged future risk.
  • Offboarding verification: Offboarding verification is the proof that a third party’s access, secrets, and related assets have been removed or destroyed after the relationship ends. It goes beyond policy statements and requires evidence that permissions are no longer usable in practice.
  • Orphaned Secret: An orphaned secret is a credential that remains active without a clear owner, consumer, or business purpose. In NHI programmes, orphaning often appears after service changes, and it raises both security risk and operational uncertainty during rotation or revocation.
  • Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org