The NHI Kill Chain Series
Eight credential risk patterns and how to respond
Explore how credentials stay active too long, spread across systems, or lose a clear owner. Eight risk patterns and a summary explain what to check and how to respond.
Why credentials fail in production, again and again
A key linked to a departed employee can remain active. A password can end up in a document outside its intended store. When several services share one key, replacing it takes coordination.
The series examines eight risk patterns, then brings their response steps together in a final post. The named companies and people in the opening stories are illustrative scenarios.
A single key can have several problems at once: it may be public, old, and ownerless. Check validity, permissions, and dependencies before replacing it.
One key can carry several risks
A key found in a public repository may also be old and shared by several services. That calls for Public, Aged, and Over-shared reviews together. To understand an actual incident, examine the issuer's access records and the affected workflows.
Use the pattern names to organize the investigation. Validity, permissions, exposure location, and dependent services determine the response priority.
Eight patterns and a summary
Orphaned API Keys
Credentials with no owner and no lifecycle, sitting in production indefinitely.
Shadow Service Accounts
Machine identities created outside your inventory, running privileged workloads.
Unrotated (Aged) Keys
Credentials years past their intended lifespan, still granting full production access.
Over-privileged Keys
Single credentials granting far more access than any single workload needs.
Zombie Keys
Credentials marked expired or revoked that still authenticate successfully.
Drifted Keys
Credentials that start in dev and drift into staging and production with no audit trail.
Publicly Exposed Keys
Credentials discoverable in public repositories, package registries, or client bundles.
Unattributed Keys
Credentials in use whose owner, purpose, or rotation cadence nobody can answer.
Eight Patterns and a Response Plan
A practical summary of what to verify, investigate, assign, and replace.
Where to start
Different starting points make sense for different goals. You do not have to read the series in order.
- If you just had an incident: Start with Zombie Key (#5) and Public Key (#7) to check whether the exposed key remains valid and where it was found.
- If you are heading into an audit: Ghost Key (#1), Unattributed Key (#8), and Aged Key (#3). They cover the three areas to review: inventory, ownership, and rotation policy.
- If NHIs are new to your team: Start with the Series Summary (#9). It shows all eight risk patterns and links into individual posts for the patterns most relevant to you.
- If you are focused on CI/CD security: Drifted Key (#6) and Over-shared Key (#4). Both walk through how pipelines flatten and duplicate credentials in ways that survive after the pipeline itself is gone.
Each post stands alone. They take the same kind of incident and decompose it from different angles, so reading two or three side by side gives you the pattern- recognition fastest.
Frequently asked questions
What exactly is a non-human identity (NHI)?
NHIs include service accounts and credentials used by systems to authenticate: API keys, OAuth tokens, certificates, and CI bot tokens. Their number and management vary by organization, so start with an actual inventory and named owners.
How is this different from the OWASP NHI Top 10?
The OWASP NHI Top 10 categorizes non-human identity risks. This series uses scenarios to show where credentials remain or become exposed, and what evidence and response steps to consider.
How long does it take to read the whole series?
Length varies by post. Start with the pattern you are investigating, then use the final summary for the shared response sequence.
Can these patterns be detected automatically?
Some patterns can be investigated by finding exposed credentials in supported connected sources and checking whether they still work. Cremit Platform scans connected repositories, storage, collaboration tools, and container images; it verifies supported key types with their issuers. Teams need the relevant provider logs to investigate actual use and permissions, and must rotate or revoke keys at the issuing service. This series explains the signals and response steps for each pattern.
Who wrote this and is the content peer-checked?
Cremit wrote the series using public sources and credential detection experience. Posts about external incidents link to sources readers can check. The patterns are ways to structure an investigation; the product does not automatically classify every case.
Check connected sources for exposed credentials
Cremit Platform scans supported connected sources and verifies supported credential types. Your team confirms ownership and rotates exposed keys.
Start for free