Static SSH keys and API tokens create risk because they are reusable, hard to track, and often survive long after the task or user changes. Once copied into laptops, repositories, or spreadsheets, they become standing privileges that expand the blast radius of a compromise and weaken auditability.
Why This Matters for Security Teams
Static ssh key and API tokens are risky because they behave like standing credentials: once issued, they can be copied, reused, and forgotten long after the original business need changes. That creates a persistence layer attackers love, especially when secrets drift into code repositories, ticketing systems, laptops, or chat tools. NIST Cybersecurity Framework 2.0 emphasizes continuous access governance, which is the right direction for secrets that never expire on their own.
The practical problem is that these credentials often outlive the human or workload that first requested them. A copied token can still authenticate from anywhere, and an SSH key can remain valid even after the underlying job, vendor relationship, or employee offboarding event has ended. NHIMG research on the Guide to the Secret Sprawl Challenge shows how quickly secrets spread once they are embedded in normal workflows. In practice, many security teams encounter the compromise only after the credential has already been reused across multiple systems.
How It Works in Practice
Static keys and tokens create risk across the full lifecycle: issuance, storage, distribution, use, and retirement. If a secret is long-lived, every copied instance becomes an additional attack path. If it is embedded in a script or CI pipeline, revocation becomes operationally painful, so teams delay action and leave the credential active longer than intended. That is why modern guidance increasingly favors short-lived credentials, workload identity, and just-in-time access over permanent secrets.
For human and machine access alike, the safer pattern is to authenticate the workload first, then issue scoped, time-bound access only for the task at hand. That means using strong identity primitives, such as workload identity backed by cryptographic proof, and pairing them with policy decisions that are evaluated at request time rather than granted once and assumed forever. Standards guidance from NIST Cybersecurity Framework 2.0 supports continuous monitoring and least privilege, while incident analysis in the Salesloft OAuth token breach shows how a single exposed token can become a broad access path. In practice, this means:
- issuing secrets only when a task starts, then revoking them when the task ends
- preferring short TTLs over reusable long-lived tokens
- binding credentials to workload identity, not just a shared secret string
- tracking where secrets are stored, copied, and rotated
- enforcing policy checks at runtime instead of relying on a one-time grant
These controls tend to break down in legacy environments where SSH access is embedded in admin habits, shared scripts, or flat network trust because revocation and identity binding were never designed into the workflow.
Common Variations and Edge Cases
Tighter secret controls often increase operational overhead, requiring organisations to balance reduced blast radius against deployment friction and support burden. There is no universal standard for this yet, especially in mixed environments where some systems still require SSH, long-running service accounts, or third-party integrations that cannot easily support ephemeral credentials.
Best practice is evolving toward replacing static credentials with short-lived alternatives wherever possible, but exceptions do exist. Some break-glass access paths may need carefully monitored long-lived credentials, and some legacy systems may require compensating controls such as vaulting, rotation automation, and session recording. NHIMG breach coverage such as the JetBrains GitHub plugin token exposure and the Dropbox Sign breach illustrates the same pattern: once a secret is portable, every downstream system becomes part of the risk surface.
For teams modernising access, the key decision is not whether a secret is convenient, but whether it is acceptable for it to remain valid after the original task, user, or system context has changed.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Static secrets that persist beyond need are a core NHI credential lifecycle risk. |
| NIST CSF 2.0 | PR.AC-1 | Persistent SSH keys and tokens undermine access control and least privilege. |
| NIST AI RMF | Autonomous or tool-using workloads need governance for dynamic secret use. |
Replace long-lived secrets with rotated, short-lived credentials and verify every secret has an owner and expiry.
