How to Eliminate Static Credentials from Trading Infrastructure

Tatu Ylonen, the inventor of the SSH protocol, has long warned that a single stolen SSH key "can in many cases lead to compromise of the entire server environment."

But in the bare-metal and private cloud infrastructure of high-frequency or quantitative trading firms, privileged access to trading infrastructure often depends on shared or static credentials like SSH keys or hardcoded API tokens. These credentials routinely carry root-level or admin access to production servers handling trading execution, market data, and order routing, meaning that a single key stolen from one of these environments opens a path to all of them.

As trading firms grow, so do the amount of keys distributed via Ansible or similar tools across hundreds or thousands of servers. This means that any engineer who onboards, CI pipeline that deploys, or contractor who receives "temporary" access expands the attack surface further.

---

Why static credentials like SSH keys are dangerous in trading infrastructure

Static credentials problems expand the attack surface of trading infrastructure across three dimensions, including permissions granted too broadly, keys that never expire, and access events that cannot be traced back to a specific identity.

Long-standing and over-privileged access

In sensitive or highly regulated environments, engineers may be required to request access through complex, time-consuming processes, causing many to opt for the path of least resistance. This is often long-standing access to multiple production resources, including ones unrelated to their role or task. As a security lead at one trading firm framed this challenge: "Once you have exchanged a token, how do you prevent people from using that token in other environments?"

Trading firms and exchanges may operate several thousand SSH servers and database instances. Without resource-level restrictions or enforced, label-based restrictions, any engineer who authenticated may be able to reach databases in each cluster, rather than just the ones required for the task at hand.

SSH keys outlive their purpose

SSH keys carry a fatal flaw: they do not expire by default. Instead, an SSH key pair remains valid until someone proactively removes the public key from the target server.

This means that SSH keys distributed to bare-metal servers via configuration management may carry the same admin-level access they were created with, and may be left unrevoked when a project ends or the owner’s role changes. This creates keys that persist indefinitely, and continue to accumulate with each new deployment, engineer, or vendor engagement. In an environment with thousands of servers and hundreds of engineers, tracking which keys remain active (or which ones are due for revocation) requires governance capabilities that go beyond traditional manual processes.

---

Why traditional credential management models can’t scale

There are two traditional methods for managing SSH key sprawl: rotating keys on a schedule and storing them in a vault.

Both approaches reduce exposure (relative to doing nothing), but neither eliminate the underlying vulnerability of persistent credentials that can be stolen, shared, and subsequently reused. Understanding why each of these methods struggle at the scale of modern infrastructure helps explain why trading firms increasingly look to certificate-based authentication instead.

Key rotation at the scale of trading infrastructure

Key rotation is the most commonly recommended mitigation for SSH key sprawl. But at the scale of modern, high-frequency trading infrastructure, it can also be the most disruptive. For a trading firm with heterogeneous infrastructure (such as systemd-based hosts, legacy init systems, and bare-metal servers across multiple cloud providers and regions), maintaining consistent rotation or fast incident response becomes resource-intensive.

For example, if an engineer pushes a risky config to a bare-metal server in an exchange cage, revocation and rotation may require hours of out-of-band, manual procedures. In many ways, this operational burden also de-incentivizes future rotations. Infrastructure teams that have experienced a failed rotation across hundreds of nodes will simply learn to avoid triggering another one, even if that means leaving un-rotated keys in place far longer than they should be.

Vaults centralize the credential problem, but don’t eliminate it

Typically associated with privileged access management (PAM), credential or secrets vaults centrally store and rotate credentials on behalf of applications and users.

However, these credentials (and the standing privileges they carry) exist as artifacts in transit between the vault and the consuming application. They may be cached in local configurations, embedded in CI/CD environment variables, or stored in memory on the hosts that consume them, all of which are intermediate locations that can be compromised. You can read more about these risks in our recent blog, Zero Standing Privileges vs Credential Vaulting.

Credential vaults themselves are also vulnerable to compromise. In 2025, 14 “Vault Fault” vulnerabilities were discovered across multiple secret and credential vaulting tools, including CyberArk Secrets Manager (CVE-2025-49827), HashiCorp Vault (CVE-2025-6000), and others. These vulnerabilities ranged from authentication bypasses and privilege escalation all the way to complete vault takeover. If the goal is eliminating static credentials and standing privileges as an attack vector, rotation and vault-based processes simply treat the symptoms rather than the root cause.

Untraceable identities in audit logs

The third dimension of the static credential problem is identity attribution. Simply put, SSH keys and shared API tokens are anonymous by design. When an SSH key pair authenticates a connection, it does not encode who initiated the session, what role they hold, or why they requested access. In environments where multiple engineers share the same key to access a production server, this makes every session indistinguishable from the next.

This anonymity creates a major compliance gap that auditors will scrutinize and can place trading and other financial services firms in a challenging position. For example, PCI DSS assessors, ISO/IEC 27001 auditors, and SOC 2 evaluators will expect organizations to demonstrate who accessed a given resource, when, and with what level of privilege. However, when access is brokered through anonymous SSH keys or shared service account credentials, that evidence does not exist in a single, attributable record. Instead, compliance teams must reconstruct access events by correlating logs across identity providers like Okta, cloud audit services like AWS CloudTrail, and bastion host access logs. This audit preparation process can take weeks of manual work and still leave evidence gaps.

This lack of identity traceability also slows incident response. If a configuration change causes a production outage or a database is accessed outside of normal operations, the immediate priority is identifying exactly who caused it. In trading infrastructure, where a single unauthorized action on a server handling order execution or market data can have regulatory and financial consequences, the inability to attribute access to a specific identity creates unacceptable risk.

---

Three ways to eliminate static credentials and anonymous identities from your infrastructure

Eliminating static credentials rather than managing them more carefully requires an architecture based around one concept: short-lived certificates.

The following sections describe ways that trading, financial services firms, and other organizations with complex infrastructure environments can eliminate static credentials and ensure every session is attributed to a strong cryptographic identity, using certificate-based authentication, certificate IP pinning, and session recording.

1. Certificate-based authentication

Certificate-based authentication replaces the standing access risk of static credentials like SSH keys (which require manual revocation) with credentials that are time-bound and configured to automatically expire. A short-lived certificate, such as an X.509 certificate, is issued at runtime and encodes the user's identity, their permitted roles, the resources they can access, and a defined validity window. When the session or the validity window ends, the certificate expires and can no longer be used, leaving no static credentials or standing privileges behind to steal or reuse.

2. Certificate IP pinning

Certificate IP pinning adds a second constraint by encoding the source network into the credential metadata. Even if a certificate is exfiltrated during its validity window, it cannot be used from a different network location because the receiving server will validate the source IP against the embedded value.

Binding the credential to the originating network via certificate IP pinning also closes the window of opportunity for impersonation-based attacks. Even if a valid certificate is intercepted, any attempts to use it from a different IP address will be rejected at connection time.

3. Identity attribution

Certificate-based authentication eliminates the anonymity that static credentials like SSH keys or long-lived tokens provide by tying each session to a strong cryptographic identity rather than an anonymous key pair. This means that when an auditor asks who accessed a production database at a specific time, your answer can be unambiguous and readily available.

The complexity and scale of modern trading infrastructure also makes it challenging to provide evidence on how access to sensitive resources is being secured. For example, PCI DSS assessors auditors typically expect evidence of access control enforcement will be available and from a single source. Certificate-based authentication provides that evidence by logging and recording every session against the identity that requested and received the certificate for a consistent source of truth across infrastructure.

---

How Teleport secures identities and simplifies access to trading infrastructure

Teleport applies certificate-based authentication across SSH, Kubernetes, database, and cloud protocols like AWS, Azure, and GCP from a single platform.

Per-session, identity-bound certificates with automatic expiry

Teleport replaces SSH keys with a short-lived X.509 certificate issued per session. Each certificate is limited to the minimum required permissions, limited to specific resources via role-based access controls, and automatically expires when the session ends or the configured validity window closes. Engineers authenticate through their existing identity provider (Okta, Entra ID, or others) and receive a certificate that grants just-in-time privileges only to the resources their role permits, and for only as long as the session lasts.

In trading infrastructure, certificate-based authentication eliminates the need to rotate keys, vault secrets, or revoke credentials manually after a task is complete, an engineer leaves the firm, or a contractor engagement ends. Instead, issued certificates automatically expire on their own, ending access exactly when the session ends.

Certificate IP pinning

Teleport's certificate IP pinning encodes the source IP into the credential, preventing reuse from unauthorized network locations. If a certificate is exfiltrated during its validity window, Teleport rejects any attempt to use it from a different IP address, significantly reducing the blast radius of a stolen credential.

Role separation across business units

For firms operating across organizational boundaries, Teleport's trusted cluster architecture enables role separation across business units. These trusted clusters separate access along organizational lines rather than relying on a single flat set of roles applied across all infrastructure. Each trusted cluster maintains its own role definitions while the root cluster maps users to the appropriate roles in each leaf cluster based on their identity attributes.

In trading infrastructure, this trusted cluster separation prevents a DBA responsible for one cluster from accessing another. Teleport helps ensure that engineers in one business unit can only access the resources exposed to their specific roles, while all other resources remain invisible and inaccessible.

Machine and workload identity

For machine and workload identities in trading infrastructure, Teleport's tbot agent issues short-lived certificates to CI/CD pipelines, trading bots, and microservices. Like a human engineer, each workload authenticates using its identity and receives a certificate limited to the specific resources necessary for that job or pipeline run, eliminating long-lived keys and preventing secrets from being stored in environment variables or configuration files.

Replacing hardcoded secrets with certificates that expire after each job not only reduces the blast radius of a compromised CI/CD runner or bot process, it also eliminates an entire class of attack vectors. Keys that do not exist cannot be stolen, sessions tied to cryptographic identities cannot be anonymized, and credentials that expire automatically cannot provide the long-lived, unattributed access that complicates audits.

---

Static credentials are a liability that trading firms can eliminate

In on-prem, private cloud, or colocation infrastructure, static credentials persist for a simple reason: they’re the access path of least resistance. But that simplicity comes at a cost that trading, financial services, and other compliance-driven organizations cannot afford, including keys that never expire, permissions that never decrease, and audit events that can never be attributed to an individual. Using short-lived certificates issued per session eliminates these risks without requiring continuous manual governance because static credentials that do not exist cannot be compromised.

For trading firms operating across bare-metal servers, co-location facilities, and automated pipelines where these credentials are known to proliferate, the question is whether to continue managing the risk that static credentials create or shift to an approach that eliminates them as an attack vector entirely.

Learn how Teleport unifies identity and secures access across high-frequency trading, exchange, and financial services infrastructure.

---

About the author: Gus Luxton is a Principal Solutions Engineer at Teleport, and was formerly a Production Engineer at Facebook. Gus helps developers securely access their infrastructure, as well as deliver cloud-native applications to restricted and regulated environments. When he’s not working, Gus enjoys PC gaming, great food and craft beer.