A departed identity can still mint or use trusted access, which means the system may treat the session as legitimate even though the human relationship is gone. The failure is not just authentication. It is offboarding that does not fully revoke dependent credentials, tokens, and application trust paths, leaving a standing exposure window.
Why a Valid Signing Key Becomes a Post-Departure Trust Problem
When a signing key survives an employee’s departure, the organisation has not just missed a credential cleanup step. It has preserved a trust anchor that can continue to assert identity, authorise actions, or sign artefacts that downstream systems still accept. If that key is used for code signing, API authentication, or token minting, the departed person’s former access path can keep working long after HR offboarding is complete.
This is especially dangerous because signing keys often sit above ordinary login controls: they do not merely open a session, they can create durable proof that other systems treat as legitimate. That is why the issue is usually broader than account disablement. Offboarding must terminate the full chain of trust, including dependent secrets, certificates, tokens, service relationships, and any automation that still trusts the key. NHI Mgmt Group’s guidance on lifecycle control reflects that many organisations still struggle to fully revoke these assets in time.
In practice, many security teams discover this only after a key continues to authenticate cleanly in production, rather than during the departure workflow itself.
How the Failure Shows Up in Production Systems
The failure usually appears in one of three ways. First, an application or pipeline continues to trust the departed employee’s key because the key was never revoked, expired, or removed from the trust store. Second, downstream systems still accept signed requests or artefacts because validation is based on the key’s technical validity, not the person’s employment status. Third, automation continues to use a key stored in code, CI/CD, or a vault, so the key remains active even if the human owner is gone.
- Signing keys can outlive accounts when revocation is not tied to lifecycle events.
- Certificates and tokens may remain valid until explicit expiration or revocation is enforced.
- Service dependencies often trust the credential, not the employee relationship behind it.
- Audit trails may show legitimate use, which can delay detection if ownership metadata is stale.
For control design, the key question is whether offboarding reaches every place the key is accepted, not just where it was issued. NIST SP 800-53 Rev. 5 helps frame this as a control problem around access enforcement, revocation, and ongoing monitoring rather than a one-time HR task. The operational implication is that a key should be treated as a living trust path with an owner, scope, expiry, and revocation procedure.
NIST SP 800-53 Rev 5 Security and Privacy Controls
These controls tend to break down when keys are embedded in automation, because the system still sees a valid cryptographic assertion even after the employee relationship has ended.
Common Variations, Exceptions, and Control Gaps
Tighter key revocation often increases operational friction, so teams have to balance fast offboarding against the risk of breaking production integrations. That tradeoff becomes sharper when signing keys are shared across applications, inherited by pipelines, or used by third parties that are slow to update trust records.
One common edge case is a key that is valid but no longer should be trusted because ownership changed. Another is a key that was rotated in the source system but not in every downstream verifier, leaving an inconsistent trust state. A third is long-lived certificates or signing keys with no practical expiry window, which makes “valid” indistinguishable from “still supposed to be trusted” unless there is separate governance.
Current guidance suggests treating these conditions differently from ordinary password issues. Password resets address interactive login, but signing keys often require revocation, trust-store cleanup, token invalidation, and validation of all consumers that cache or mirror trust decisions. The deeper problem is not just access persistence, but trust persistence across systems that may not share the same identity lifecycle.
Only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why this gap is so persistent when credentials are tied to people but operated like infrastructure.
Risk and Threat Considerations
A still-valid signing key creates a standing exposure window because it preserves the ability to authenticate, sign, or mint trusted artefacts after the human relationship has ended. That is both an operational risk and a threat path: an insider, a compromised former workstation, or any party that obtained the key before departure may continue to use it until revocation reaches every trust boundary.
Failure mechanism: The risk materialises when validation depends on cryptographic validity alone while ownership, revocation, and downstream trust updates lag behind. Signed artefacts, API calls, and token exchanges remain acceptable because verifiers trust the key material, not the departed identity context. If revocation is incomplete, stale certificates, cached trust, and embedded secrets can all prolong unauthorised access.
Impact: The organisation can lose control of who can act as an authorised identity, what artefacts are trusted, and which systems accept them. That can lead to unauthorised release of code, data access, fraudulent transactions, privilege persistence, or delayed incident containment across multiple dependent services.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Departed signing keys are non-human credentials that must be revoked and inventoried. |
| NHI-03 — Access Review and Offboarding | The issue is failed offboarding of a trusted non-human access path. | |
| NHI-06 — Monitoring and Detection | Still-valid keys can keep generating legitimate-looking activity after departure. | |
| Recommendation — Inventory signing keys and revoke every credential tied to the departed identity. Tie offboarding to trust-path removal, not just account deactivation. Alert on post-departure use of signing keys and related trust artefacts. | ||
| CIS Controls v8 | 5.6 — Account Management | Departed identities require removal of active access and associated credentials. |
| 6.3 — Access Control Management | Trust must be withdrawn from keys that still authorize systems or workflows. | |
| 8.2 — Audit Log Management | Post-departure key use should be visible in logs for investigation and containment. | |
| Recommendation — Remove or disable every account and credential linked to the departed employee. Revoke access paths that still accept the key as valid proof. Retain and review logs for any use of the departed key after offboarding. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | This is a lifecycle failure in authentication and access trust control. |
| DE.CM — Continuous Monitoring | Ongoing monitoring is needed to detect continued use of stale signing keys. | |
| Recommendation — Enforce lifecycle-based revocation for identities and their dependent credentials. Monitor for valid-looking activity that persists after identity departure. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | A still-valid signing key functions as continued legitimate access after departure. |
| T1552 — Unsecured Credentials | Signing keys become exposed when stored or retained without timely revocation. | |
| Recommendation — Hunt for continued use of valid credentials after ownership changes. Search for exposed signing material in code, pipelines, and shared storage. | ||
Practitioner Guidance
What to prioritise: Treat departure as a trust-revocation event, not just an account disablement event. The first verification is whether any signing key, certificate, API token, or automation credential can still produce trusted actions in production.
What to verify: Confirm that every consumer of the key has received the revocation signal or trust-store update, and check for any parallel copies in code, CI/CD variables, vaults, device stores, or partner integrations. If the key can still authenticate anywhere, the offboarding is incomplete.
Decision rule: If a departed identity’s key can sign production actions, prioritise revocation and blast-radius review before investigating whether the key has already been abused. If the key is only locally unused, shorten its validity window and remove it from every trust policy that still recognises it.
Practitioner takeaway: The real control objective is not “delete the user”; it is “ensure no remaining system can still trust the departed person’s cryptographic proof.”
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
