Topic starter
17/08/2026 4:39 pm
TL;DR: Teleport says replacing RSA with ECDSA and Ed25519 cut benchmarked CPU usage by 77% and latency by 37%, while also reducing certificate-signing decision complexity across SSH and TLS workflows. The lesson is that signature algorithm choice is now an identity governance decision, because performance, compatibility, and trust boundaries move together.
Editorial analysis by NHI Mgmt Group, based on content published by Teleport: “How Ditching RSA Made Teleport 77% More CPU-Efficient”.
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.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: RSA-heavy signing can become an access bottleneck when certificates are generated at high volume, especially in proxy and automation workflows.
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
👉 Read Teleport’s analysis of RSA replacement and signature algorithm suites →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
17/08/2026 4:45 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: RSA replacement in Teleport shows why signature suites matter