RSA replacement in Teleport shows why signature suites matter

At a glance

What this is: Teleport replaced RSA with ECDSA and Ed25519 for most new signing workflows and reported materially lower CPU and latency in its benchmarked proxy workload.

Why it matters: IAM and NHI teams should treat signature algorithm selection as an operational governance choice because it affects issuance speed, compatibility, and the trust model for short-lived credentials.

By the numbers:

• Teleport says benchmarked CPU usage fell by 77% after switching from RSA to ECDSA and Ed25519.
• Teleport says latency fell by 37% after switching from RSA to ECDSA and Ed25519.
• Teleport says its tests generated 4022 RSA keys per run before the default change.
• Teleport says the same tests now generate 1557 RSA keys per run, a 61% reduction.

👉 Read Teleport’s analysis of RSA replacement and signature algorithm suites

Context

Signature algorithms are the cryptographic methods used to prove identity and integrity when an issuer signs certificates or tokens. In this article, Teleport shows that the choice between RSA, ECDSA, and Ed25519 is not just a math preference, because it changes the cost and operational shape of certificate issuance.

That matters for identity programmes because Teleport sits in the path of SSH access, TLS tunnels, short-lived certificates, and just-in-time access workflows. When signing becomes slower or more error-prone, the friction shows up in workload identity, access brokering, and the governance of non-human credentials.

Key questions

Q: When does RSA become too costly for identity infrastructure?

A: RSA becomes too costly when identity systems mint certificates or keys frequently enough that signing time and handshake size become operational bottlenecks. That is common in access proxies, short-lived certificates, CI pipelines, and database tunnels. At that point, the performance cost is also a governance issue because slow issuance shapes availability and user experience.

Q: Why do signature algorithm choices affect IAM governance?

A: Signature choices affect IAM governance because they determine how access is issued, how reliably tools can consume certificates, and how much operator error is possible. A weak or awkward default can create compatibility exceptions, inconsistent trust boundaries, and unsafe legacy fallbacks. Governance has to cover the signing policy, not only the credential lifecycle.

Q: What are the signs that a signing approach is failing?

A: The signs are rising CPU use during issuance, longer login or connection setup times, repeated compatibility workarounds, and a growing number of legacy exceptions to keep old clients working. In certificate-heavy systems, those symptoms usually mean the signing model no longer fits the access pattern.

Q: What should teams do if they need both legacy compatibility and modern signing?

A: Use a policy-based signature suite that preserves a legacy option for constrained environments while moving new workloads to a modern default. That approach lets teams keep older integrations alive without forcing the whole platform to stay on an obsolete algorithm. The key is to make the exception explicit and bounded.

Technical breakdown

Why RSA became the bottleneck for certificate issuance

RSA is widely supported, but it is expensive to generate and awkward to operate at scale. Teleport describes 2048-bit RSA keys as slow to create, large to transport, and prone to implementation mistakes such as weak key sizes, outdated hashes, and fragile padding choices. In systems that mint fresh certificates frequently, the cost is not theoretical. It accumulates in CI, proxy services, and session-based access flows where every new issuance burns CPU and latency.

Practical implication: treat RSA-heavy issuance paths as a performance and governance liability, not just a legacy compatibility issue.

What ECDSA and Ed25519 change in signing workflows

ECDSA and Ed25519 both reduce key size and improve signing speed, but they differ in operational trade-offs. ECDSA still requires curve and hash selection, which keeps some decision burden in place. Ed25519 removes most of that choice set, which lowers configuration risk and avoids many implementation footguns. Teleport’s article shows why that matters in identity systems: fewer algorithm decisions mean fewer ways to misconfigure signing, especially when certificates are generated automatically for SSH and TLS access.

Practical implication: prefer algorithm suites that minimise operator choice when access infrastructure needs to issue credentials repeatedly and consistently.

Why signature suites are a governance control, not just a crypto setting

Teleport’s move to a signature algorithm suite shows that organisations often need a policy layer above individual cryptographic primitives. A suite can standardise the default algorithm, preserve compatibility options, and keep regulated or hardware-backed environments on different rails without forcing every team to decide separately. That matters because access systems are not isolated crypto libraries. They are governance systems that issue identity assertions into SSH, TLS, OIDC-adjacent, and certificate-based workflows.

Practical implication: govern signing as a cluster-wide policy decision so identity, compliance, and compatibility trade-offs are handled once rather than per workflow.

NHI Mgmt Group analysis

Signature algorithm choice is now an identity governance decision, not a back-end implementation detail. Teleport’s example shows that the algorithm used to sign certificates changes how quickly identities are issued, how reliably access works, and how much operator judgment is required. That makes cryptographic selection part of access governance, especially where short-lived certificates and just-in-time access depend on rapid issuance.

Decision fatigue is a security control failure when identity systems force too many cryptographic choices. Teleport’s RSA experience illustrates how multiple knobs, key size, hash, padding, curve, and environment-specific support, create more chances for unsafe configuration. The result is not just operational friction but inconsistent trust posture across clusters and tools. Practitioners should recognise that reducing decision space can be a governance objective in itself.

Algorithm suites are a useful pattern for standardising trust without freezing the environment. A suite gives administrators a bounded policy choice instead of a series of low-level cryptographic decisions for every certificate type. That is especially relevant for NHI and access-broker platforms where the same control plane serves SSH, TLS, databases, and automation. The broader lesson is to govern cryptographic defaults at the policy layer.

Performance and security do not have to be traded off at the point of issuance. Teleport’s reported CPU and latency improvements show that a modern signing stack can reduce overhead while also removing weak legacy combinations such as RSA with SHA-1. That does not eliminate compatibility work, but it changes the default assumption that stronger identity controls must be slower. Practitioners should evaluate issuance cost as part of control design, not after deployment.

Signature agility is becoming a long-term resilience requirement. Teleport’s forward-looking note about post-quantum transitions is the right lens for identity platforms that sign at scale. If a control plane can move from one signature family to another without breaking issued credentials, it is better positioned for future cryptographic shifts. The implication is that identity architecture should assume algorithm change will happen again.

What this signals

Teleport’s change illustrates a broader identity control shift: signing policy is no longer a low-level cryptography choice hidden inside implementation teams. Once credentials are issued at high volume, the default algorithm becomes part of access governance, because it affects issuance throughput, compatibility boundaries, and the reliability of short-lived identity.

Cryptographic agility is the real design requirement here. Systems that can move between signature families without breaking access are better positioned for future transitions, including post-quantum migration, while systems locked into one brittle default will keep paying for every exception.

From a programme perspective, the most useful question is whether certificate issuance has been standardised at the policy layer or left to individual teams. If every access path makes its own signing choices, the organisation has already accepted unnecessary drift in trust behaviour.

For practitioners

• Standardise certificate signing into an algorithm suite Set a cluster-wide policy that chooses approved signing algorithms once, rather than asking teams to pick key types, hashes, and curves for each access path.
• Map issuance hotspots in access infrastructure Identify where your environment generates the most short-lived certificates or keys, especially proxy services, CI jobs, and database tunnels, then measure their CPU and latency cost.
• Remove high-risk legacy RSA combinations Audit for RSA with weak hashes, small key sizes, or outdated client dependencies that still force unsafe compatibility exceptions into production.
• Separate regulated and hardware-backed signing paths Keep FIPS or HSM-backed needs in a distinct algorithm profile so compliance requirements do not leak into every other access workflow.

Key takeaways

• RSA-heavy signing can become an access bottleneck when certificates are generated at high volume, especially in proxy and automation workflows.
• Teleport reported 77% lower CPU usage and 37% lower latency after moving to modern signature algorithms in its benchmarked setup.
• The practical control lesson is to govern signing through a cluster-wide policy so compatibility, performance, and trust are managed together.

Key terms

• Signature Algorithm Suite: A signature algorithm suite is a managed set of approved cryptographic signing choices for an identity platform. Instead of forcing administrators to choose key type, hash, and padding each time, the platform standardises those decisions so access issuance stays consistent and supportable.
• Certificate Issuance: Certificate issuance is the process of approving and creating a certificate for a specific identity or system. Strong issuance controls help prevent unauthorised or fraudulent certificates from being created, which can otherwise enable impersonation, phishing, or interception of traffic. Issuance should be governed by policy, approval, and audit.
• Cryptographic agility: The ability to change cryptographic algorithms, key lengths, or trust models without reworking every application. For machine identities, it reduces the risk that long-lived services will fail when standards shift or when post-quantum migration becomes necessary.
• Authenticator Lifecycle Management: Authenticator lifecycle management is the governance of a credential from issuance to renewal, replacement, and retirement. For human identity programmes, it ensures that keys, smart cards, and certificates stay tied to the right user and are removed when the user, role, or device is no longer trusted.

What's in the full article

Teleport's full blog post covers the implementation detail this post intentionally leaves for the source:

• The RSA, ECDSA, and Ed25519 trade-offs behind the signature algorithm suite decision
• Benchmark setup details showing how the proxy workload was tested under sustained connection churn
• Compatibility considerations for existing clusters, regulated environments, and hardware-backed signing
• The reasoning behind keeping the change opt-in for existing Teleport clusters

👉 Teleport’s full post covers the benchmark setup, compatibility trade-offs, and suite design choices in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.