Insider NHI Misuse Breaches Lessons Guide: What Leavers Kept and How to Stop It

When an engineer leaves, disabling their account does not revoke the keys, tokens and publishing rights they handled, and several of the most damaging insider incidents of recent years used exactly those machine credentials. This guide reads across the breach pages in the NHI Mgmt Group database where a current or former insider misused, or failed to give up, a non-human identity: a token signing key, a package registry publishing token, and provider API keys hard-coded in source code. It draws out what the cases share, what each organisation's offboarding missed, and which controls would have broken the chain. It is written for identity, security engineering and insider risk teams who own leaver processes. The step-by-step offboarding process is in the NHI Offboarding and Decommissioning Guide, and the response runbook is the Insider Data Theft Response Playbook; this page covers the lessons, not the procedure.

Key takeaways

• The account is not the access. In both the Coupang and Ledger cases the person's corporate access was removed or their employment had ended, yet a machine credential they had touched still worked.
• Reach, not ownership, defines the leaver's risk. OWASP calls this the "partially offboarded employee": someone who could see a credential they did not own and left without it being rotated.
• Long-lived keys turn a leaver into a long-term threat. Coupang's signing keys reportedly had multi-year validity, so misuse could start months after departure and run for months more.
• External identities escape HR-driven offboarding. Registry, SaaS and code host accounts sit outside the corporate directory and need their own leaver step.
• Secrets in code leave with the code. Rabbit's provider keys were exposed because an employee leaked a copy of a codebase that contained them; any copy of code is a copy of its secrets.

Case table: insider NHI misuse breach pages

The table lists the breach pages where an insider's access to a non-human identity was central, plus one contrast case where a departed insider leaked code with no credential misuse reported. Each entry links to the full analysis.

The set is small, which is itself a finding: insider misuse of machine credentials is rarely disclosed in detail, and is often reported as an external attack until investigators trace the credential back. For human-access insider incidents, such as bribed support agents using the tools they were given, see the Insider Data Theft Guide.

What the cases share

Two motives appear. In Coupang the former insider used the key himself. In Ledger the former employee was a victim, and their stale access was the doorway for an outsider. Controls must cover both: a leaver who is hostile and a leaver who is simply targeted because their old access still works. See Malicious vs Negligent vs Compromised Insider.

Lesson 1: offboard by reach, not by account

OWASP NHI1:2025 Improper Offboarding names three ways NHIs outlive their purpose: the service is retired, the owner leaves and the NHI is orphaned, or a non-owner who had access to the credential leaves without it being revoked. The third case, the partially offboarded employee, is the insider pattern. A key the leaver never owned in any inventory can still be in their shell history, password manager or laptop.

• Build a reach map: for each engineer, record which vaults, key stores, CI/CD variables and production secrets they could read, not only which they own. Vault audit logs and key management access logs supply this.
• Rotate on reach: at departure, rotate every secret the leaver could read in the last access period, prioritising signing keys and anything that mints access for others.
• Reassign ownership first: OWASP recommends transferring needed NHIs to a new owner and rotating credentials the employee could access. Without a new owner, rotation stalls.

The comparison of human and machine leaver steps is in NHI Offboarding vs Human Offboarding.

Lesson 2: keys that mint access need the shortest leash

A signing key is not one credential: it is the factory for all of them. Coupang's investigators found keys on developer machines, multi-year validity and forged tokens that were not checked against real issuance. Each is a separate control failure.

• Custody: keep signing keys in an HSM or managed key service so no person can export them. Engineers sign through the service, so there is nothing to take home. See the HSM Deployment and Operations Guide.
• Rotation: rotate token signing keys on a schedule and publish new keys through a key set so rotation does not break clients. The JWKS Signing Key Rotation Guide covers the mechanics.
• Issuance correlation: log every token issued and alert when a valid signature arrives with no matching issuance or login event. This catches forgery even when the key is genuine.
• Revocation versus rotation: know which you need. Rotating a key leaves old tokens valid until they expire unless verifiers stop trusting the old key; see Secret Rotation vs Secret Revocation.

Lesson 3: external identities need their own leaver step

HR-driven offboarding disables the directory account and, through SSO, the applications behind it. Package registries, code hosts, cloud marketplaces and many developer SaaS tools often have personal accounts outside SSO. Ledger removed internal access but not npm publishing rights.

• Inventory external accounts that hold organisational rights: registry maintainers, code host organisation members, domain registrar and DNS logins, app store publisher accounts.
• Remove membership, not just tokens: npm documents that a granular token cannot exceed its creator's permissions and loses access when the user loses access to a package or organisation, so removing the leaver from the organisation cuts their tokens too.
• Move publishing to pipelines: npm recommends trusted publishing for CI/CD over bypass-2FA tokens, and states that direct publishing with granular tokens is due to be removed in January 2027 in favour of stage-only tokens approved by a maintainer with 2FA. Workload-issued credentials leave nothing personal to forget at offboarding. See the npm Token Changes and Trusted Publishing Guide and the Package Registry Publishing Tokens Guide.

Lesson 4: a copy of the code is a copy of its secrets

Rabbit's provider keys were exposed through a leaked codebase, and the company said some secrets had not been placed in its secrets manager. Twitter's source code leak shows the same path without reported credential loss. Either way, insiders who copy code take whatever is embedded in it.

• Keep secrets out of code: inject at runtime from a secrets manager; scan commits and history and block on findings. See the Git Secret Scanning Guide.
• Scope keys narrowly: Rabbit's email key could only send to the company's own domain, which limited damage. Narrow scope per service and environment is cheap insurance.
• Rehearse rotation: Rabbit's rotation caused brief device downtime and one key was revoked improperly. A practised rotation runbook avoids choosing between exposure and outage.
• Treat a code leak as a secrets incident: the Source Code Leak Response Playbook starts with a secret sweep of the leaked tree.

Lesson 5: detection must look at the credential, not the person

Insider risk tools watch human behaviour, but after departure there is no human session to watch. The misuse shows up on the machine credential.

Protect the logs too: the Coupang analysis notes that around 13% of logs for the attack period were lost. Ship identity and key logs to a store the engineering team cannot delete. The UEBA Guide covers behavioural baselines for entities as well as users.

Implementation: closing the leaver gap in phases

1. Week 1, triage current leavers: list everyone who left in the past 12 months with access to signing keys, publishing rights or production secrets; rotate what they could reach, starting with keys that mint tokens.
2. Weeks 2 to 4, external accounts: inventory registry, code host and other external memberships; remove former staff and enforce 2FA on remaining maintainers.
3. Month 2, reach map: generate per-person secret reach from vault and KMS audit logs; add a "rotate on reach" step to the leaver workflow driven by HR events. See the Joiner Mover Leaver Guide.
4. Month 3, custody and lifetime: move signing keys into HSM or KMS custody and set rotation periods; move publishing to trusted publishing. Pilot on one service, keep the old key trusted for a short overlap and roll back by re-publishing it to the key set if clients fail.
5. Month 4, detection: deploy the signals in the table above, starting with issuance correlation and out-of-pipeline publishing alerts, in alert-only mode before blocking.
6. Ongoing, recertify: quarterly NHI ownership attestation, as OWASP recommends, with orphaned NHIs decommissioned. See NHI Ownership Attestation Campaigns.

Decision guidance

• Rotate everything or rotate by reach: small teams where every engineer reaches every secret should rotate the full set at each senior departure; larger organisations should invest in reach mapping so rotation is targeted and affordable.
• Hostile versus routine leaver: for dismissals or departures to a competitor, rotate before notice is given where lawful; for routine leavers, rotate on the last day. Coordinate with HR and legal, as the Security During Layoffs and Restructuring guide describes.
• Contractors and outsourced engineers: treat their end of engagement as a leaver event with the same reach rules.

Framework mapping

Measuring progress

• Leaver rotation coverage: percentage of departures where every reachable high-value secret was rotated within one working day.
• External account hygiene: number of former staff still holding registry, code host or other external organisational rights (target zero).
• Signing key custody: share of token and code signing keys held in HSM or KMS with no export.
• Key age: oldest active signing key and API key, against the rotation policy.
• Secret findings in code: new hard-coded secrets per month and median time to remove and rotate.

Common failure patterns

• Directory-only offboarding: the HR ticket closes when the SSO account is disabled, while keys and external accounts stay live, as in Coupang and Ledger.
• Ownership without reach: inventories record an owner but not the colleagues who could read the secret, so non-owner leavers are never triggered.
• Multi-year signing keys: rotation is avoided because it might break clients, leaving one key valid for years.
• Personal publishing accounts: releases depend on one engineer's registry login and token, so their departure or phishing becomes a supply chain event.
• Secrets left in code "temporarily": a few keys never make it into the secrets manager and travel with every clone.
• Deletable logs: the people who could misuse a key can also remove the evidence.

Practitioner checklist

• Add "rotate every secret the leaver could read" to the leaver workflow, not just "disable account".
• Map per-person secret reach from vault and KMS audit logs.
• Remove leavers from registry, code host and other external organisations on their last day.
• Hold signing keys in HSM or KMS custody with scheduled rotation.
• Correlate presented tokens with issuance events and alert on mismatches.
• Publish packages from pipelines through trusted publishing, not personal tokens.
• Block hard-coded secrets at commit and sweep history.
• Alert on publishing or credential use after a related person's departure.
• Send identity and key logs to storage the engineering team cannot delete.
• Run quarterly NHI ownership recertification and decommission orphans.

Standards and references

• OWASP: Non-Human Identities Top 10, NHI1:2025 Improper Offboarding
• npm Docs: About access tokens
• npm Docs: Trusted publishing
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: T1606 Forge Web Credentials

Related NHI Mgmt Group resources: OWASP NHI Top 10 NHI1 Improper Offboarding Guide · Employee Offboarding Security Guide · Leaver Retained Access Incident Playbook · Signing keys and certificates in breaches