Skip to main content
NEW · Blast Radius: a field playbook for leaked API keys on AWS, GCP and Azure
Back to Blog

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.

Ben Kim
Written by
Ben Kim
Published
Updated
6 min read657 words
Share:
Long-exposed credentials: what a 90-day source record tells you

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

AWS IAM — Credential reports and coverage limits

GitHub Docs — Secret scanning scope and remediation

Share it with your networkLinkedInX

Read next

Get the next one in your inbox

Monthly NHI security brief from Cremit. One email, high signal.

We never sell your email. Unsubscribe anytime.

Long-exposed credential: source age versus key age | Cremit