RSA replacement in Teleport shows why signature suites matter

At a glance

What this is: This analysis explains why Teleport moved from RSA to ECDSA and Ed25519, and shows that the change cut benchmarked CPU use and latency while reducing key-management complexity.

Why it matters: IAM teams running short-lived certificates, workload access, or JIT access should treat signature algorithm choice as part of identity lifecycle design, not just cryptographic hygiene.

By the numbers:

• Teleport says the switch from RSA to modern signature algorithms reduced benchmarked CPU usage by 77% and latency by 37%.
• Generating a 2048-bit RSA keypair can take about 10000x longer than an Ed25519 or ECDSA keypair with comparable security.
• Teleport's tests moved from 4022 RSA keys per run to 1557 after the default change, a 61% reduction.
• Teleport's benchmark dropped proxy CPU usage from 71% to 16% when switching from RSA to ECDSA.

👉 Read Teleport's analysis of RSA replacement and signature algorithm performance

Context

RSA remains widely supported, but it is operationally expensive and easy to misuse when teams must choose key size, hash, and padding combinations under pressure. In identity systems that issue many short-lived certificates or keys, those choices become a governance problem because every extra decision increases the chance of compatibility failure or weak cryptography.

Teleport's move to a signature algorithm suite is really a response to identity lifecycle complexity. The article shows that when access infrastructure issues certificates at scale, the question is not only which algorithm is strongest, but which choice can be made consistently across SSH, TLS, and regulated environments without creating brittle exceptions.

For identity and access teams, the important lesson is that cryptographic modernisation and NHI governance are now tightly linked. If the certificate authority, access proxy, or workload identity layer is still anchored to legacy algorithm assumptions, the result is higher operational cost and more room for human error than the access programme should tolerate.

Key questions

Q: How should security teams migrate identity systems from RSA to modern signature algorithms?

A: Start with an inventory of every client, proxy, browser, database connector, and hardware-backed integration that validates your certificates. Then introduce modern algorithms through a controlled profile model, keep legacy support only where required, and test issuance, authentication, and rollback before changing defaults in production.

Q: When does RSA create more operational risk than it reduces?

A: RSA becomes a risk when the organisation issues many short-lived identities, has mixed client support, or needs administrators to make repeated choices about hash, padding, and key size. In that environment, the operational variance itself becomes a security problem because it invites weak configurations and compatibility exceptions.

Q: What do teams get wrong about modern certificate algorithms?

A: They often focus on cryptographic strength alone and ignore operational support. Ed25519 and ECDSA can reduce compute cost and simplify policy, but they still require careful compatibility checks across SSH, TLS, HSM, KMS, and regulated environments before they can replace older defaults safely.

Q: How do access teams decide between performance and compatibility in certificate governance?

A: Use compatibility as the exception and performance as the scaling constraint. If a legacy algorithm is only needed for a shrinking set of systems, isolate it into a managed profile and keep the modern default for all new issuance so the broader identity estate is not dragged backward.

Technical breakdown

Why RSA becomes a bottleneck in identity infrastructure

RSA's security depends on several implementation decisions: key length, hash function, and padding scheme. That flexibility is also the problem, because each decision can be made incorrectly, and incorrect choices can render the system weak or incompatible. In environments that mint many certificates or keys, RSA also creates heavy CPU and latency overhead because generation is computationally expensive. For identity systems that act as certificate authorities or access brokers, this makes RSA a poor fit for high-volume issuance.

Practical implication: treat RSA as a compatibility mode, not the default choice, in systems that issue frequent certificates or workload credentials.

Ed25519, ECDSA, and signature algorithm suites

Ed25519 and ECDSA were designed for smaller keys and faster signing operations than RSA. Ed25519 is simpler because it removes most algorithm-choice ambiguity, while ECDSA still requires curve and hash selection. Teleport's algorithm suite approach packages those choices into a single administrative decision, reducing the number of per-certificate judgment calls. That matters in identity infrastructure because the more surfaces that depend on signing, the more operational value comes from narrowing the decision set.

Practical implication: standardise signature choices at the platform layer so access administrators are not making one-off cryptographic decisions per certificate type.

Compatibility risk in SSH and TLS migration

Algorithm migration in identity systems is never just a cryptography upgrade. SSH clients, TLS libraries, hardware keys, HSMs, cloud KMS integrations, and browser trust stores all have different support timelines, and those differences determine whether a new algorithm actually works in production. Teleport's opt-in model for existing clusters reflects that reality. For any certificate-issuing system, compatibility must be tested against the full chain of dependent tools, not assumed from cryptographic strength alone.

Practical implication: inventory every downstream consumer of issued certificates before changing algorithms, especially where third-party tools or regulated environments are involved.

NHI Mgmt Group analysis

Cryptographic choice is now an identity governance decision, not a backend implementation detail. When an access platform mints short-lived certificates at scale, algorithm selection changes the cost, reliability, and lifecycle of every issued credential. That makes signature policy part of IAM and NHI governance, because the signing layer shapes how access is provisioned, validated, and retired.

Decision fatigue is the hidden governance problem in certificate infrastructure. RSA forces teams to choose key sizes, hashes, and padding schemes repeatedly, and each choice creates a chance for inconsistency or weakness. Teleport's suite model is a useful pattern because it reduces administrative variance, but the broader lesson is that governance should remove avoidable cryptographic choice where the platform can safely standardise it.

Modern access systems should treat algorithm standardisation as a lifecycle control. The point is not simply to pick a stronger primitive, but to ensure that issued identities behave predictably across SSH, TLS, databases, and cloud-integrated tools. That is the same discipline NHI teams apply to rotation and offboarding: fewer ambiguous states, fewer exceptions, and less legacy drag.

Legacy compatibility debt: RSA survives longest where access systems fear breaking third-party dependencies. That assumption is designed for static trust chains and slow-changing clients. It fails when the access layer must serve mixed environments and high-volume issuance, because the organisation ends up preserving outdated cryptography to keep systems talking. The implication is that compatibility can quietly override security intent unless it is governed as a first-class constraint.

The performance gain matters because identity infrastructure is often an invisible compute tax. Teleport's benchmark shows that signature choice affects CPU and latency in live access flows, not just in lab benchmarks. In identity programmes, hidden cost is itself a governance signal, because a control that burns capacity is harder to scale and easier to postpone.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is why identity programmes still miss large parts of their non-human attack surface.
• For a broader view of the market direction, see Ultimate Guide to NHIs , 2025 Outlook and Predictions, which frames where NHI governance is heading next.

What this signals

Signature agility is becoming part of identity resilience. When an access platform issues certificates across SSH, TLS, databases, and tunnels, the signing primitive affects throughput, failure rates, and deprecation velocity at the same time. Teams that still treat cryptographic choice as a low-level implementation detail will find that legacy algorithms create hidden drag in their identity lifecycle.

Algorithm standardisation is the real control, not algorithm preference. The practical question is whether your IAM and NHI programme can change defaults without breaking downstream trust. That is where lifecycle governance, compatibility testing, and dependency mapping converge, and where the weakest legacy integration usually dictates the pace of modernisation.

Identity platforms should be measured on issuance efficiency as well as access policy coverage. If certificate generation is consuming disproportionate CPU or forcing operational exceptions, the programme is paying for cryptographic debt in the background. The organisations that will move fastest are those that can align access governance with platform performance instead of managing them as separate concerns.

For practitioners

• Inventory every certificate-issuing dependency Map SSH, TLS, database, and workload consumers that trust issued certificates, then identify which ones still depend on RSA or SHA-1 compatibility. Use that inventory to separate safe defaults from legacy exceptions.
• Standardise signature choices into managed suites Create a small number of approved algorithm profiles for different operating contexts, such as legacy, regulated, and hardware-backed use. This reduces per-admin decision fatigue and prevents inconsistent key policy across clusters.
• Benchmark certificate issuance under real load Measure CPU, latency, and failure rates when access systems generate keys at the pace they do in production, including web logins and database tunnels. Treat performance regressions as governance issues, not just infrastructure tuning.
• Plan deprecation paths before flipping defaults Move new clusters to modern algorithms first, then make existing environments opt-in only after dependency testing and rollback planning. That approach limits access breakage while still shrinking legacy exposure.

Key takeaways

• RSA's main problem in access infrastructure is not only weakness, but the number of decisions it forces teams to make correctly every time.
• Teleport's migration shows that modern algorithms can materially cut CPU and latency while simplifying certificate governance.
• For IAM and NHI teams, signature algorithm strategy should be handled as a lifecycle control with compatibility testing, not as a one-time cryptography choice.

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 Overhead: Certificate issuance overhead is the compute, latency, and operational cost created when identity systems mint many short-lived credentials. In high-volume access environments, expensive signing algorithms can become a hidden bottleneck that affects authentication speed and platform scalability.
• Compatibility Debt: Compatibility debt is the security cost of keeping older authentication, encryption, or workflow paths alive so users do not lose convenience. It often appears when vendors preserve legacy modes for migration or device support, but those paths can become persistent weaknesses that are hard to remove cleanly.
• Identity Lifecycle Governance: Identity lifecycle governance is the set of processes that create, change, review, rotate, and revoke access across human and non-human identities. It matters because access risk usually increases when lifecycle events are slow, incomplete, or disconnected from the systems that rely on them.

What's in the full article

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

• The article's full comparison of RSA, ECDSA, and Ed25519 trade-offs across SSH and TLS signing.
• Benchmark setup details showing how CPU and latency changed under sustained database-connection load.
• The algorithm-suite model Teleport uses to reduce decision fatigue for cluster administrators.
• Compatibility considerations for regulated and hardware-backed environments that still rely on legacy cryptography.

👉 Teleport's full post covers the benchmark setup, algorithm suite choices, and compatibility trade-offs in more 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 or NHI governance programme, it is worth exploring.