A rotation record is not a map of leaked credentials
Lifecycle records show intended access. Secret findings show copies in scanned sources. Compare both before deciding who should replace a key.
On this page(6)
Table of Contents
A lifecycle record can say who requested a machine credential, when it should be replaced and whether its account should remain. It does not tell you every place a copy landed. A secret scan can show a copy in a connected source; it cannot prove that every copy was found. An earlier version of this article promised real-time visibility across the entire digital footprint and complete clean-up. Those claims exceeded what the evidence can show.
Keep the identity, key and copy separate
A service account or workload is an identity. An API key or token is one way it authenticates. A repository line, S3 object or ticket is a location where credential material might appear. One identity may have several credentials, and one credential may have several copies. Record which of these you are discussing before counting or rotating anything.
Compare two records
The lifecycle side asks: Which workload still needs access? Who can approve a replacement? Which issuer account and permissions belong to the key? What is the documented retirement plan? These records describe intended access and responsibility, not actual exposure.
The discovery side asks: Which connected source and object contained the string? When was it found? Who could read that source? Were related sources, histories or backups outside the scan? A match is a location clue. It does not by itself show that the key is active, that anyone used it, or that the original owner has left.
Use the issuer to decide what still works
For a supported credential type, check current validity with the issuer. For an AWS or GCP key with a supported permission integration, review available access context separately. Consult issuer activity logs where available to investigate use; a missing log or an unchecked key leaves uncertainty. Do not wait for a complete source map before containing a credibly exposed active key.
For example, suppose a team replaces an AWS access key but leaves the old string in a repository. The copy is still an exposure record and may have spread, even if the issuer has deactivated the old key. Conversely, removing a string from the latest file does not deactivate a key that still works. AWS describes a staged replace, test, deactivate and delete process; the steps have different effects.
Close with evidence, not a clean-scan label
Assign one responder to confirm the workload, replace or revoke the key at its issuer, test the dependent service and document the result. Review accessible copies and available issuer logs under the organization’s retention policy. State which connected sources were searched and which were skipped. “No finding” in those sources is not proof that every historical copy was removed.
Where Cremit fits
Cremit finds credential patterns in supported connected repositories, packages, cloud storage and collaboration sources. It checks issuer validity for supported types, can add supported AWS or GCP permission context, and lets a team assign follow-up work. It does not watch every NHI action, scan unconnected systems, rotate keys at every issuer or certify complete eradication.
Sources
Read next
Eight credential exposure patterns and how to respond
A practical summary of eight NHI credential exposure patterns, the evidence to check, and what Cremit Platform can help investigate.
How to count live credentials without confusing matches and keys
Count observed locations, distinct credential records and verification states separately. Define scope and check time before reporting exposure.
From exposed credentials to Cremit Platform: the workflow we support
How Cremit Platform finds exposed credentials, verifies supported types, and routes findings to an owner, with clear limits.
Get the next one in your inbox
Monthly NHI security brief from Cremit. One email, high signal.