What breaks when offboarding does not include secret revocation?

Why This Matters for Security Teams

Offboarding failures are not just an HR hygiene issue. When secret revocation is skipped, the organisation can remove the person from IAM while leaving behind a still-valid credential, token, or key that continues to authenticate on its own. That breaks the basic assumption that identity lifecycle and access lifecycle move together. In practice, the risk is amplified by secret sprawl: Guide to the Secret Sprawl Challenge shows how secrets persist in tickets, code, CI/CD tools, and shared docs long after ownership changes. OWASP also treats orphaned and unmanaged non-human credentials as a core control failure in the OWASP Non-Human Identity Top 10.

NHIMG research is blunt on the scale of the issue: in The 2025 State of NHIs and Secrets in Cybersecurity, 91% of former employee tokens remain active after offboarding. That kind of residue turns a routine workforce change into an access persistence event. In practice, many security teams encounter secret reuse only after a former contractor, a stale pipeline, or a neglected integration has already been used to move laterally.

How It Works in Practice

The breakage starts with trust anchoring. IAM offboarding removes the human or service account record, but the downstream system often authenticates with a separate secret that was never tied to the lifecycle event. If the token is long-lived, duplicated, or embedded in code, the deletion of the directory object does nothing to stop authentication. That is why lifecycle management must include both account disablement and credential invalidation, as outlined in the NHI Lifecycle Management Guide.

Operationally, strong offboarding usually needs three moves:

• Revoke the secret at the source of truth, not just in the directory.
• Rotate any dependent credentials, including API keys, certificates, and refresh tokens.
• Search for copies in CI/CD, source control, ticketing, and secret stores, then invalidate every known instance.

This is where secret inventory matters. NHIMG notes that 96% of organisations store secrets outside of secrets managers, and 62% of secrets are duplicated in multiple locations in the same research set. That means revocation has to be both technical and investigative. The fastest route is to pair vault events, cloud audit logs, and code scanning with a revocation workflow so a former identity cannot keep using a credential after separation. The Guide to the Secret Sprawl Challenge is useful here because it treats sprawl as an exposure problem, not just an inventory problem.

These controls tend to break down in environments where secrets are hard-coded into legacy applications or copied into unmanaged automation because there is no single authoritative revocation point.

Common Variations and Edge Cases

Tighter revocation often increases operational overhead, so organisations have to balance rapid offboarding against the risk of breaking dependent workloads. That tradeoff is real, especially where one credential supports multiple integrations or an older service lacks short-lived token support. Current guidance suggests treating those cases as technical debt, not an excuse to leave secrets alive indefinitely.

One common edge case is shared service credentials. If a single secret is used by several applications, revoking it for one departing owner can impact unrelated workloads. NHIMG flags this pattern in its research on overused NHIs, and it is one reason Top 10 NHI Issues emphasizes ownership clarity and rotation discipline. Another edge case is pipeline credentials: if a CI/CD token survives offboarding, it can still deploy, sign, or exfiltrate even after the person is gone. The CI/CD pipeline exploitation case study shows why pipeline identity must be handled as a live workload, not as a static user extension.

Where autonomy increases, the problem gets harder. For AI agents and other autonomous workloads, static secret models are already fragile because behaviour changes at runtime. In those cases, best practice is evolving toward JIT credentials, workload identity, and real-time policy evaluation rather than perpetual access. That aligns with OWASP Non-Human Identity Top 10 and the broader direction of Zero Trust, but there is no universal standard for every platform yet.

Related resources from NHI Mgmt Group

• What breaks when single logout is treated as the same thing as offboarding?
• What breaks when a secret is deleted from Git but not rotated?
• What breaks when human offboarding is used as the only control for NHIs?
• What breaks when service accounts have no clear owner or offboarding process?