TL;DR: Static SSH keys and hardcoded API tokens in trading infrastructure can persist at root level, expand across thousands of servers, and leave no attributable audit trail, according to Teleport. The core issue is not rotation speed but the broken assumption that access remains stable long enough to be reviewed, revoked, and traced.
At a glance
What this is: This is a Teleport analysis of why static credentials in trading infrastructure create excessive blast radius, anonymous access, and governance gaps.
Why it matters: It matters because IAM, PAM, and NHI programmes must govern both human and machine access where long-lived secrets undermine traceability, revocation, and least privilege.
By the numbers:
- In 2025, 14 “Vault Fault” vulnerabilities were discovered across multiple secret and credential vaulting tools.
👉 Read Teleport's analysis of static credentials in trading infrastructure
Context
Static credentials create a governance problem because they outlive the task, the role, and sometimes the environment they were issued for. In trading infrastructure, that can mean SSH keys and hardcoded tokens with root-level or admin-level access spread across bare metal, private cloud, and CI pipelines.
The identity issue is not only exposure. It is attribution. When shared keys or long-lived tokens are used, access cannot be cleanly tied back to a person, a role, or a purpose, which weakens both incident response and compliance evidence in regulated environments.
Key questions
Q: How should security teams replace static SSH keys in trading infrastructure?
A: Security teams should replace static SSH keys with short-lived, identity-bound access that expires automatically at the end of the session or task. The goal is to remove standing privilege, reduce reuse risk, and keep every access event attributable to one identity rather than a shared key.
Q: Why do static credentials create more risk than vaults can solve?
A: Static credentials create more risk because the secret still exists as a reusable artifact even when it is stored in a vault. Once a credential can be copied, cached, or shared, the control problem becomes where the secret is used and how long it remains valid, not just where it is stored.
Q: What do security teams get wrong about rotating SSH keys?
A: Teams often assume rotation solves the underlying access problem, but rotation only shortens exposure if it is executed reliably and quickly everywhere the key exists. In distributed trading environments, a slow or inconsistent rotation process can leave stale keys active long after the operational event that required removal.
Q: Who is accountable when anonymous credentials are used in production?
A: Accountability sits with the organisation because anonymous credentials remove the ability to prove who accessed a system, when they accessed it, and under what authority. In regulated environments, that creates an evidentiary gap that affects audit readiness, incident response, and policy enforcement.
Technical breakdown
Why static SSH keys create standing privilege
Static SSH keys are persistent authenticators, not time-bound authorisations. In practice, they often behave like standing privilege because the public key remains trusted on the target host until someone removes it manually. In large trading estates, distribution through configuration management multiplies exposure across many servers and creates a long tail of forgotten access. The key technical failure is that the credential and the permission are separated only by administrative cleanup, not by cryptographic expiry or session bounds.
Practical implication: Treat every long-lived SSH key as standing privilege that must be modelled, inventoried, and reduced.
Why vaulting does not remove the credential problem
Vaults centralise secrets, but they do not eliminate secret use. The credential still exists in transit between the vault and the workload, and may be cached in memory, environment variables, local configuration, or CI/CD systems. That means the attack surface shifts rather than disappears. In regulated infrastructure, this creates a second-order governance problem: the vault becomes a control point, but not a proof that the secret never existed outside the vault boundary.
Practical implication: Use vaulting as a containment layer only when you can also prove where the credential lives, moves, and expires.
How short-lived certificates change identity evidence
Short-lived certificates replace durable secrets with session-scoped cryptographic identity. The certificate encodes who requested access, what it can reach, and how long it remains valid. That changes auditability because the access event itself becomes attributable, timestamped, and naturally expires. For trading infrastructure, the important architectural shift is that identity evidence moves from scattered logs and shared credentials to a single issuance-and-session record that can be correlated without reconstruction.
Practical implication: Design access around session evidence, not post-hoc log correlation across several systems.
Threat narrative
Attacker objective: The attacker aims to gain persistent, unattributed control over trading infrastructure that can affect execution, market data, or administrative systems.
- Entry occurs when a static SSH key, shared API token, or hardcoded secret is copied from a build pipeline, repository, or host and reused in trading infrastructure.
- Escalation follows because the credential often carries root or admin-level access across multiple production servers, databases, or order-routing systems.
- Impact is broad because the same static identity can be reused silently, leaving weak attribution and a large blast radius across regulated trading operations.
Breaches seen in the wild
- Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
- Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Static credentials are a standing-privilege problem, not just a rotation problem. The article makes clear that SSH keys, hardcoded tokens, and vaulted secrets can all persist far beyond the task they were meant to support. That means the real governance failure is the continued existence of durable access artifacts in environments that need session-scoped control. Practitioners should treat long-lived credentials as a structural access-risk category, not an operational nuisance.
Identity attribution breaks when access is shared or anonymous. Trading infrastructure often needs proof of who accessed what, when, and under which role. Shared SSH keys and anonymous tokens erase that evidence at the point of authentication, which means audit, incident response, and accountability all depend on reconstruction after the fact. That is a weak control model for regulated environments where traceability is part of the access requirement itself.
Certificate-based access exposes the limits of static credential governance. A short-lived certificate model aligns identity, privilege, and expiry in a way static keys cannot. The significance for IAM and PAM is that access control shifts from revocation-heavy maintenance to issuance-bound governance, which is closer to how modern non-human identity should be managed in high-frequency and private-cloud estates. Practitioners should re-evaluate whether their control plane is governing sessions or just cleaning up after them.
Dynamic infrastructure needs dynamic identity, and trading is a good example of why. The article shows that scale, heterogeneity, and operational urgency make manual key rotation fragile. In that setting, standing privilege accumulates faster than governance teams can remove it, so the organisation ends up normalising exception-based access. The practical conclusion is that lifecycle governance for machine access must be designed around expiry and attribution from the start.
Vaulting, rotation, and shared credentials all preserve the same broken premise. They assume the credential is the right object to manage. That assumption fails when the environment needs access to be identity-bound, short-lived, and attributable at session start rather than credential lifecycle end. The implication is that control design must move from managing secrets longer to removing the need for static secrets in the first place.
From our research:
- In 2025, 14 “Vault Fault” vulnerabilities were discovered across multiple secret and credential vaulting tools, according to the 2026 Infrastructure Identity Survey.
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments.
- That finding connects directly to Ultimate Guide to NHIs , Static vs Dynamic Secrets, which helps teams move from secret management to session-bound identity control.
What this signals
Static credentials persist because organisations still treat secret storage as the control, when the real control is expiry, attribution, and scope. In trading and other regulated infrastructure, that distinction matters because a secret can be vaulted and still remain operationally dangerous. With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, the governance pattern is broader than one sector and one use case.
Session-bound identity is the more durable programme signal for infrastructure teams. When access is issued per session and tied to a cryptographic identity, incident response becomes simpler and audit evidence becomes native to the access path. That is a better fit for zero trust thinking than long-lived secrets hidden behind manual rotation cycles, especially where bare metal, CI/CD, and private cloud all coexist.
Trading teams should watch for a shift in control ownership from operations to identity governance as access becomes more dynamic. The operational question is no longer how often to rotate a key, but how to prove that access never became standing in the first place.
For practitioners
- Map every standing credential path Inventory SSH keys, hardcoded API tokens, and shared service credentials across trading hosts, pipelines, and contractor access paths. Classify each by privilege level, expiry behaviour, and whether access can be attributed to a single identity.
- Reduce blast radius with session-scoped access Replace durable credentials with short-lived certificates for human engineers and workloads, and enforce least privilege at issuance time rather than after deployment. Bind access to specific resources and session windows so reuse outside the task becomes impossible.
- Make audit evidence native to the access event Ensure every privileged session produces an issuance record and a session log that can be correlated without manual log stitching across IdP, bastion, and cloud logs. This is especially important where auditors require a single source of truth for access evidence.
- Retire shared access patterns in regulated environments Eliminate shared SSH keys and anonymous tokens from trading infrastructure, especially where production servers handle execution, market data, or order routing. Shared identities should be treated as an accountability defect, not just a convenience.
- Test rotation failure as an operational control If rotation remains in use during transition, measure how long revocation actually takes across bare metal, legacy init systems, and multi-cloud hosts. A control that cannot be executed reliably at scale is not a reliable control.
Key takeaways
- Static SSH keys and shared tokens create standing privilege that scales poorly in trading infrastructure.
- Vaulting and rotation reduce exposure, but they do not remove the underlying problem of reusable credentials.
- Short-lived, attributable access is the governance model that aligns better with regulated infrastructure and audit demands.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Static credential persistence is a core NHI issue in this article. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access scoping are central to reducing trading infra blast radius. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires continuous, identity-bound access decisions instead of shared keys. |
Use zero trust access brokering to eliminate standing secrets and enforce session-level authorisation.
Key terms
- Static Credential: A static credential is a long-lived secret such as an SSH key, token, or API key that remains valid until someone manually removes it or rotates it. In identity governance, the problem is not just exposure but persistence, because the credential can be reused, shared, or stolen long after its original purpose has ended.
- Standing Privilege: Standing privilege is access that remains continuously available instead of being issued for a specific task or session. For non-human identities and infrastructure access, it creates a durable attack path because the permission outlives the immediate operational need and can be abused without a fresh authorisation step.
- Short-Lived Certificate: A short-lived certificate is a time-bound credential issued at runtime that authenticates an identity for a limited period and scope. For infrastructure access, it binds the session to a cryptographic identity and expires automatically, which reduces reuse risk and improves traceability compared with long-lived secrets.
- Identity Attribution: Identity attribution is the ability to tie an access event back to a specific person, workload, or agent with enough certainty for audit and incident response. Where shared keys or anonymous tokens are used, attribution weakens because the system can no longer prove who initiated the session or under what authority.
What's in the full article
Teleport's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of why SSH key rotation becomes brittle across bare metal, legacy init systems, and multi-cloud trading estates.
- Detailed breakdown of certificate-based authentication for SSH, Kubernetes, database, and cloud access in production environments.
- Examples of how certificate IP pinning changes the blast radius of a stolen credential during an active session.
- Case study context showing how a trading firm can eliminate permanent database credentials and support compliance evidence.
Deepen your knowledge
Static credentials, standing privilege, and session-based access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for trading infrastructure or other regulated environments, it is worth exploring.
Published by the NHIMG editorial team on 2026-05-20.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org