Orphaned API keys after offboarding: what the evidence shows

Updated October 4, 2026. An earlier version described a constructed breach with exact times, people, and key ages. Those details were not evidence of a real incident. This guide explains the records a team can check when a credential is linked to an inactive account.

The signal: an active key and an inactive author

A key found in a connected source may still be active even when the account associated with its commit author is marked inactive. That mismatch deserves investigation. It does not by itself establish that the person still owns the key, that an attacker obtained it, or that anyone used it after offboarding.

OWASP describes improper offboarding of non-human identities as leaving unnecessary or orphaned machine identities in place. Its example attack paths illustrate possible risks; they are not measurements of any company’s incident. The person who committed a key and the current owner of the service may be different.

Keep four records separate

First, check the directory record: which account is inactive, when its status changed, and whether the match to the commit author is reliable. Second, check the source record: where the credential was found, its exposure, and whether copies remain in branches or artifacts. A commit author match is a lead about the source, not proof of current ownership.

Third, identify the issuer and verify the key using a supported, safe method. Record its status, permissions, restrictions, and dependent workload. For an AWS access key, the IAM credential report can show status and last-used fields, subject to AWS’s reporting limits. These fields do not replace a review of relevant audit logs for actual activity.

Fourth, find the current service owner and agree on the response. Confirm whether a workload still needs the credential, who can replace it, and what will break if it is disabled. Preserve the evidence that supports each conclusion. An unknown owner is a reason to escalate the investigation, not a reason to label an unverified breach as confirmed.

Contain and close the gap

If a credential is exposed and may still work, coordinate prompt containment. Issue a replacement where needed, update dependent workloads, then deactivate or delete the old key at its issuer and check that it no longer works. AWS distinguishes deactivation, which can be reversed, from deletion. The right order depends on the live dependency and incident risk; there is no universal 90-day clock in this finding.

Review issuer logs for use during the relevant window and note gaps in coverage. Then remove unnecessary copies from approved sources, assign an owner, and record the final disposition. Removing a credential from a repository or changing an employee’s directory status does not itself revoke a key at the issuer.

What Cremit shows

Cremit’s Ghost Key checklist flags a finding when its credential verification status is active or manually active and at least one matching source record has an author marked inactive. This is a triage signal within the connected sources and supported checks. It does not verify the current service owner, detect every copy, prove misuse, or revoke the credential automatically. Use the issuer and its logs to confirm status and activity.

Primary sources

OWASP Non-Human Identities Top 10 — Improper Offboarding

AWS IAM — Manage access keys

AWS IAM — Credential reports