IT onboarding and offboarding are now NHI control points

At a glance

What this is: This is a lifecycle security guide showing how onboarding and offboarding decisions affect access, secrets, and residual privilege.

Why it matters: It matters because IAM teams must govern human, NHI, and delegated access with the same lifecycle discipline, or exposure persists after role changes and departures.

By the numbers:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.

👉 Read Entro Security's checklist for secure IT onboarding and offboarding

Context

IT onboarding and offboarding are identity governance processes, not just HR handoffs. When access is granted or removed late, the result is lingering privilege, orphaned secrets, and unclear ownership across systems, collaboration tools, and cloud accounts. For IAM and security teams, the real issue is whether lifecycle controls actually keep pace with where credentials live and how quickly they can be reused.

The article focuses on employee access, but the governance lesson extends to non-human identities as well. Service accounts, tokens, and other secrets often outlive the people who created or used them, which is why lifecycle design needs explicit ownership, revocation, and verification steps. That is typical in organisations with weak lifecycle discipline and incomplete secrets inventories.

Key questions

Q: How should organisations manage onboarding and offboarding for secrets and service accounts?

A: Treat onboarding and offboarding as lifecycle controls for every identity that can access data, not just employee accounts. Build an inventory of all issued secrets, assign ownership, and require revocation checks across cloud, collaboration, and code systems before access is considered closed. The control objective is verified retirement, not administrative intent.

Q: Why do offboarding failures create such a large security risk?

A: Offboarding failures matter because access often survives in places the directory does not govern, especially tokens, API keys, and shared secrets. That means a former employee can still reach systems even when the primary account is disabled. The risk grows when multiple applications reuse the same credential, because one missed revocation can expose several services.

Q: What do security teams get wrong about secrets shared in collaboration tools?

A: Teams often treat chat, ticketing, and documentation platforms as harmless convenience layers, but those systems become part of the identity surface once secrets are pasted there. The mistake is assuming the secret is governed only where it was created. In reality, every copy creates another revocation point and another chance for exposure.

Q: Who is accountable when residual access remains after an employee leaves?

A: Accountability sits with the identity, security, and system owners who control issuance, use, and retirement of the credential. Human offboarding is not complete until the organisation can show that access was removed everywhere it existed. For regulated environments, that evidence should be auditable and tied to the same lifecycle record as the original entitlement.

Technical breakdown

Why onboarding creates standing access debt

Onboarding often front-loads access before the organisation has a stable view of job scope, tool usage, and data sensitivity. That creates standing access debt, which is the gap between the permissions a new joiner receives and the minimum they actually need over time. In practice, the debt grows when accounts are created in bulk, permissions are copied from peers, and secrets are shared into collaboration tools for convenience. The operational problem is not provisioning itself but unreviewed access persistence after day one.

Practical implication: provision only to a defined role baseline and force a follow-up entitlement review once the user’s actual workflow is known.

How orphan secrets persist after offboarding

Orphan secrets are credentials that remain valid after the person associated with them has left or changed role. They persist because tokens, API keys, and shared secrets are often created outside a central lifecycle record, then reused across tools, repositories, and cloud services. If offboarding only disables the primary account, downstream access can remain untouched. The technical failure is incomplete revocation across all secret-bearing systems, not just the directory or email account.

Practical implication: tie exit workflows to a complete inventory of issued secrets, then verify revocation across every system where those secrets were used.

Why shared accounts and duplicated secrets widen blast radius

When multiple applications share the same identity or when the same secret is stored in several places, ownership becomes ambiguous and blast radius expands. A single exposed token can affect multiple workflows, making incident response slower and containment more expensive. This is a classic lifecycle and secrets management problem because the organisation loses the ability to prove who created the credential, where it is used, and when it should be retired. The risk is structural, not just operational noise.

Practical implication: eliminate shared identities where possible and require traceable ownership for every secret that can access production systems.

Threat narrative

Attacker objective: The attacker aims to exploit residual access and unrevoked secrets to keep reaching systems after the legitimate user should no longer have access.

1. Entry begins when onboarding or collaboration workflows expose credentials in places such as tickets, chat, or shared repositories.
2. Escalation happens when those credentials remain active after role change or departure, allowing continued access through stale accounts or tokens.
3. Impact follows when orphan secrets or zombie access are reused for data theft, service abuse, or lateral movement across systems.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Standing access is the real lifecycle failure, not just delayed offboarding. The article shows that access removal only works when the organisation knows every place a credential was issued, copied, or reused. That is a lifecycle governance problem, not a directory problem, because the same identity can persist in email, cloud, chat, and code. Practitioners should treat residual access as an entitlement accounting failure, not an isolated admin task.

Orphan secrets are a governance blind spot because ownership disappears faster than validity. A secret can remain technically usable long after the employee who created it has left, moved, or changed role. When that happens, accountability and technical access diverge, which is exactly why offboarding needs inventory, verification, and revocation evidence. The implication is that lifecycle programmes must track secrets as governed assets, not as incidental by-products.

Secret sharing in collaboration tools is a lifecycle anti-pattern, not a user habit. The article’s warning about Slack and Jira reflects a broader structural issue: teams move credentials to the fastest available channel, then lose revocation control. That behaviour creates hidden dependency chains that traditional IAM review cycles rarely see. Practitioners should regard collaboration tools as part of the identity surface, not as neutral communication infrastructure.

52 NHI Breaches Analysis is the right lens for understanding why lifecycle controls fail at scale. The repeated pattern across NHI incidents is not one bad secret, but a missing ownership model for issuance, reuse, and retirement. That same pattern shows up here in employee onboarding and offboarding, which is why human lifecycle discipline and NHI lifecycle discipline cannot be managed as separate conversations. Security teams should unify them under one governed lifecycle model.

NHI lifecycle management must be built for verification, not assumption. The article correctly notes that manual review alone is not enough for airtight security. That is a signal that lifecycle governance has to prove secrets were revoked, not merely request that they be revoked. Practitioners should use the NHI Lifecycle Management Guide as the control model for proving closure across human-created and machine-used credentials.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• The same research found 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, showing how fast identity-bearing configuration can spread.
• For the lifecycle angle, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding controls that close the gap between issuance and retirement.

What this signals

Residual access is becoming the programme-level risk signal for identity teams. When 91% of former employee tokens remain active after offboarding, the problem is no longer whether a process exists but whether it actually terminates use across the full credential estate. That should push IAM and security leaders to measure closure evidence, not completion claims.

The next maturity step is to treat secrets as governed assets with lifecycle status, ownership, and retirement rules. Organisations that still rely on manual cleanup will continue to miss the copies that live in chat, tickets, and code.

For a broader control model, the OWASP Non-Human Identity Top 10 remains a useful reference point for overuse, duplication, and rotation failures that show up in both human and machine lifecycle flows.

For practitioners

• Build a complete credential inventory before every offboarding event Track all accounts, tokens, API keys, secrets, and shared credentials associated with the departing person, including items created in chat, tickets, repositories, and cloud consoles.
• Require revocation proof for every secret-bearing system Do not close an exit workflow until each credential has a recorded revocation status across the directory, cloud platforms, collaboration tools, and any connected automation.
• Separate shared access from named ownership Replace shared credentials with individually owned identities wherever possible, and keep a documented mapping from each secret to a business owner and a retirement date.
• Use onboarding to enforce least-privilege baselines Start new users on role-specific minimum access, then review entitlements after the first workflow cycle instead of copying permissions from prior employees.

Key takeaways

• Onboarding and offboarding are security control moments, not administrative afterthoughts, because they decide how long access and secrets remain usable.
• The scale of residual token and secret exposure shows that lifecycle gaps persist even when organisations believe they have completed de-provisioning.
• Verified revocation across every system, not just account deletion, is the control that limits blast radius and closes the lifecycle gap.

Key terms

• Orphan Secret: A credential that remains usable after the person, system, or workflow that created it is no longer accountable for it. Orphan secrets are dangerous because they often survive account closure, move across tools unnoticed, and bypass ordinary offboarding checks unless the organisation tracks issuance, ownership, and retirement explicitly.
• Standing Access Debt: The accumulation of permissions that remain active longer than the user actually needs them. In lifecycle terms, standing access debt grows when onboarding is over-granted, revocation is delayed, or access reviews do not catch unused entitlements before they become a security liability.
• Secret Sprawl: The uncontrolled spread of credentials across repositories, chat tools, tickets, documents, and cloud services. Secret sprawl makes governance difficult because no single system can prove where a secret exists, who can use it, or whether it has been retired everywhere it was copied.

What's in the full article

Entro Security's full blog covers the operational detail this post intentionally leaves for the source:

• The complete onboarding and offboarding checklist for access, devices, and secrets
• The article's step-by-step handling of account deactivation, token rotation, and data wiping
• Practical examples for remote workers, developers, and collaboration-tool secret sharing
• The full set of security checklist items for provisioning, revocation, and exit interviews

👉 Entro Security's full post covers the onboarding, offboarding, and secrets handling checklist in detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 NHI governance in your organisation, it is worth exploring.