Standing Credential

A standing credential is any secret that works until someone deliberately revokes it: a database password, a cloud access key, a long-lived API token, a service account key checked into configuration.

Its defining property is that the window of compromise is unbounded. A credential leaked into a log file three years ago is still valid today, and nothing about the leak is observable — the attacker's use of it is indistinguishable from legitimate use, because it is the same credential doing the same things.

Why it matters

Standing credentials are the mechanism by which minor compromises become major breaches. An attacker who gains limited access to one system finds credentials there, and those credentials work elsewhere, indefinitely, with whatever privileges they carry. The escalation path in a large fraction of published breach narratives is exactly this.

The important and frequently missed point: a secrets manager does not address this. It improves where the secret is stored and who can retrieve it, and the credential itself is unchanged — still permanent, still present in application memory, still liable to appear in a stack trace, still fully valid to anyone who obtains it. Storing a liability carefully is a smaller improvement than not holding one.

Implementation patterns

• Workload identity as the replacement. The workload proves what it is — through platform attestation, a signed token, or a mounted certificate — and exchanges that for short-lived credentials. There is no secret to store, distribute, rotate or accidentally commit. This is the structural fix and it is available on every major platform.
• Short lifetimes where a secret is unavoidable: minutes or hours. This turns a leak from permanent access into a bounded window, and it makes rotation continuous rather than an event that might fail.
• Automatic rotation that is actually exercised on a schedule, because rotation configured and never run fails on first use — which is during an incident, when it must work.
• Narrow scope, since a credential that reads one table is a far smaller event than one with administrative rights. Most credentials are over-scoped because scoping precisely was work at creation time.
• Distinct credentials per environment and per service, so a test-system leak is not production access.
• Redaction in logging and error handling, since stack traces and request dumps are the most common leak path and are almost never in the threat model.
• Detection: repository and CI secret scanning, plus anomaly detection on credential use — unusual source, unusual time, unusual operation.
• A rehearsed revocation path with a measured time-to-rotate-everything.

Industry example

The pattern recurs across published incidents in the 2021–2025 period: an initial foothold obtained through a compromised dependency, a phished account or an exposed development system, followed by discovery of long-lived cloud keys or service account credentials that provided far broader access than the initial foothold.

The corresponding industry response has been consistent — cloud providers now offer workload identity federation specifically to remove static keys, CI systems provide short-lived OIDC tokens instead of stored credentials, and platform teams increasingly treat the presence of a static cloud key as a finding in itself, regardless of how well it is stored.

Failure scenarios

• Cloud access keys in configuration, CI variables or developer machines, valid indefinitely.
• A credential shared across services, so its blast radius is every service that holds it.
• Rotation that has never been performed, discovered to be broken at the moment it is needed.
• Over-scoped service accounts, granted broad permissions during development and never narrowed.
• Secrets in stack traces and error reports, shipped to a third-party error-tracking service.
• A secrets manager treated as the solution, with the underlying credential still permanent.
• No inventory, so the answer to "what would we have to rotate?" is unknown.
• Third parties holding long-lived credentials to your systems, which is the same problem outside your control.

Trade-offs

Eliminating standing credentials requires platform capability and migration effort, and it introduces a new dependency: the identity and token-issuance path is now on the critical path of everything, so its outage is a broad outage. That path must be highly available and must have a defined behaviour when it is not.

Short-lived credentials also complicate long-running operations — a batch job that runs for six hours must refresh mid-flight, which is straightforward and is a change every consumer must make.

And some systems simply cannot participate: legacy software, third-party integrations, and appliances that accept only a static password. Those become the exceptions, and the exceptions are then the attack path — which is an argument for isolating them aggressively rather than for abandoning the effort.

The trade is migration cost and a new availability dependency in exchange for bounding the consequence of every future leak. Given that leaks are certain over a long enough period, this is one of the few security investments whose value does not depend on predicting the attack.

Interview question

"A developer laptop is compromised. Walk me through what an attacker gets, how long they keep it, and how you would know. Then tell me what would have to be true for the answer to be 'about fifteen minutes of read access to one service'."