Compromised credential dwell time is the period between a secret becoming exposed and the organisation invalidating or changing it. Shortening that window matters because valid credentials are often the fastest route from theft to account abuse.
Expanded Definition
Compromised credential dwell time is the elapsed time between secret exposure and revocation, rotation, or invalidation. In NHI security, that window is especially important because API keys, tokens, certificates, and service account credentials often authenticate automatically and can be reused at machine speed.
The term covers both accidental exposure, such as secrets in code repositories or logs, and compromise through phishing, malware, supply-chain abuse, or database leakage. It excludes the broader lifecycle of a credential unless the focus is specifically on the period it remains usable after exposure. The practical boundary is simple: once a secret is exposed, every minute before action increases the chance of reuse.
Industry usage is still evolving around whether dwell time should be measured from first disclosure, first malicious use, or first internal detection. For governance and comparison, the most useful definition is the operational one: the time until the credential is no longer valid. The OWASP Non-Human Identity Top 10 treats exposed machine credentials as a core failure domain.
Examples and Use Cases
Compromised credential dwell time shows up anywhere exposed secrets can still authenticate after discovery. The shorter the window, the less opportunity there is for automated abuse, lateral movement, or silent persistence.
- A GitHub token is committed to a public repository, and the response team revokes it before scanners or attackers can reuse it.
- An AWS access key leaks in build logs, and automated monitoring forces rotation before anyone can call cloud APIs with it.
- A container image contains embedded database credentials, and the organisation invalidates them before they are reused against production.
- An application secret is shared through messaging, and the team replaces it after confirming the message history is no longer a durable trust path.
- A certificate private key is exposed on a compromised host, and the certificate is reissued before the key can be used for impersonation.
A useful tradeoff appears in high-availability systems: rapid rotation reduces exposure, but only if the application can tolerate the change without breaking service. That is why short dwell time depends on both detection speed and credential replacement mechanics.
Security Implications
Long dwell time turns a single secret leak into a reusable access path. Valid credentials often bypass perimeter controls, so an exposed token may let an attacker authenticate as a trusted workload, call cloud APIs, access data stores, or pivot into automation pipelines.
The main failure mechanism is simple: exposure happens first, but invalidation happens later, and the gap gives the attacker time to test, persist, and expand access. If the secret is shared across environments, reused in multiple services, or stored without expiration, the blast radius increases quickly. This is why dwell time is not just a hygiene metric; it is a direct measure of how long trust remains available to anyone who finds the secret.
NHIMG research on LLMjacking reports that when AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, which shows how little time defenders may have before abuse begins. That pattern is consistent with observed secret scanning and opportunistic credential replay across public code and cloud workloads.
Domain and Governance Relevance
In NHI governance, compromised credential dwell time is a practical indicator of whether machine identities are actually controlled after exposure. It links discovery, alerting, ownership, rotation, and revocation into one operational question: how long can a workload, agent, or integration keep using a secret after it should have been dead?
For autonomous systems and service accounts, this matters because compromise often does not look like a human login anomaly. A token can keep working until it expires or is explicitly revoked, which means governance must account for secret propagation, backup locations, CI/CD copies, and forgotten integrations. The strongest programs treat dwell time as a lifecycle metric, not just an incident-response afterthought.
Where teams manage many non-human credentials, the term becomes a control quality signal for ownership and offboarding. If revocation is slow or uncertain, every exposed secret becomes a standing trust relationship that outlives the original event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secrets and Credential Management | Exposed machine secrets remain usable until rotated or revoked. |
| NHI-01 — NHI Inventory and Ownership | Fast invalidation depends on knowing which non-human identities own each secret. | |
| Recommendation — Reduce exposed-secret dwell time by enforcing rapid rotation and revocation for machine credentials. Assign clear ownership so exposed NHI credentials can be disabled without delay. | ||
| CIS Controls v8 | 5.6 — Account Management | Dormant or exposed credentials must be removed or disabled quickly to limit abuse. |
| 6.3 — Access Control Management | Least-privilege access limits what a stolen credential can do during its dwell window. | |
| Recommendation — Disable or replace exposed accounts and secrets before attackers can replay them. Restrict credential scope so any exposed secret has less usable access. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Secret exposure and reuse are a direct ATT&CK credential-access mechanism. |
| Recommendation — Hunt for exposed secrets and block credential reuse paths in your detections. | ||
