Long-exposed credentials: what a 90-day source record tells you
An old source record and an active key do not establish key age. Check when the value appeared, issuer status, permissions, and dependencies.


On this page(5)
Updated October 4, 2026. An earlier version described an invented three-year-old key and a Seoul startup breach as a real incident. It also treated Cremit’s source-age signal as a key creation or rotation date. Those claims were unsupported. This guide explains the signal that actually appears in the product and the additional records needed before a response decision.
What the 90-day signal measures
Cremit’s CRE-003 checklist surfaces a credential whose last verification status is active or manually active when at least one associated scanned object has a creation timestamp older than 90 days. The timestamp belongs to the source record. It is not the key’s issue date, last rotation date, or proof that the key was present in that object for the full 90 days. A file may predate the commit that introduced the credential.
Treat the item as a prompt to inspect the source history and the issuer. Confirm when the credential first appeared in the connected source, whether the finding is still present, who owns the related workload, and whether the key still works. Where a safe issuer check is unavailable, mark the state as unverified rather than turning a source timestamp into a certainty about the key.
Four records to collect
1. Source record: the repository, file or object, relevant commit, access level, and earliest observed occurrence of the key. An old object timestamp alone may overstate the exposure window. Search connected and approved sources for other copies, and record which locations are outside scan coverage.
2. Issuer record: the issuing service, key creation date if available, current status, permissions, restrictions, and last-use information. For an AWS IAM user access key, IAM provides key management and a credential report with status and last-used fields. The report covers IAM-managed credentials and has stated limits; it is not a complete inventory of every service-specific credential.
3. Workload record: the current owner and systems that depend on the key. A source location is not necessarily a dependency map. Ask the owner which deployments, jobs, or services read the value before replacing it. Avoid assuming that a value copied into a document is still the one a live workload uses.
4. Activity record: issuer audit logs and other relevant evidence for the period in question. Last-used fields can guide the search, but they do not by themselves establish whether use was authorized. Record missing log coverage and separate observed access from a possible attack path.
Choose a response from the evidence
If a sensitive key is exposed and may still be valid, prioritize containment at the issuer. Coordinate a replacement for dependent workloads, deactivate or revoke the old value, and verify that the old value fails. The urgency comes from exposure, permissions, and current validity, not from a guessed creation date. If the credential is already invalid, document that result and still remove avoidable copies from approved sources.
For AWS IAM user keys, an administrator can create, deactivate, and delete access keys. AWS describes deactivation as reversible and deletion as final. Plan the handoff for live dependencies, but do not make “never revoke until every consumer has moved” an unconditional rule during suspected compromise. A 90-day source threshold is a triage choice in this checklist, not an AWS-mandated rotation interval or evidence that a key has aged 90 days.
What Cremit can and cannot answer
Within its connected sources and supported credential types, Cremit helps find the source occurrence, show the last verification status, and give a responder a starting point. The CRE-003 rule does not read the issuer’s key-creation date or infer a complete dependency graph. AWS and GCP access-scope analysis is available for supported keys, but permissions still need to be interpreted in the context of the current principal and workload. Rotation and revocation happen at the issuer; the owner must verify completion.
Primary sources
AWS IAM — Manage IAM user access keys
Read next
Same key in a repository and ticket: investigating cross-platform findings
Two source types show two observed locations, not how a credential moved. Check access, issuer status, owner, and actual consumers.
One API key in three repositories: investigating shared credentials
Three observed locations are not a complete dependency map. Check key type, issuer status, permissions, and actual consumers before replacement.
API keys in incident chats and tickets: what to investigate
A credential outside a repository needs a source-access review, issuer check, owner, and verified response. A finding alone does not prove misuse.
Get the next one in your inbox
Monthly NHI security brief from Cremit. One email, high signal.