Rivest-Shamir-Adleman is a public-key cryptographic algorithm used for encryption and digital signatures. Security teams rely on it for identity, key exchange, and trust validation, but weak key sizes, poor padding, or obsolete implementations can undermine it. They should enforce modern key lengths and migrate away from deprecated configurations.
What RSA is doing for security teams
RSA matters because it solves a hard problem that symmetric cryptography cannot solve on its own: how two parties can establish trust without first sharing a secret. In practice, that means it underpins certificate-based identity, secure key exchange, and software signatures. Security teams should think of RSA as trust infrastructure, not just a math primitive.
That distinction matters operationally. If RSA is used only as “the thing behind TLS,” teams often miss where it is embedded in certificate chains, signing workflows, legacy VPNs, admin access, and code-signing paths. The algorithm’s value is not just confidentiality, it is also proof of origin and reliance on a public key that others can verify.
For teams managing older environments, the main question is often whether RSA is still the right choice for a given use case, or whether it is retained because of compatibility. The answer is usually “retain where necessary, but harden and plan the migration path,” because the risk sits in stale key sizes, weak padding choices, and older implementations that do not meet current expectations.
Where RSA creates trust, and where it can fail
RSA is most useful when an organisation needs cryptographic trust that can be checked by many parties: a browser validating a server certificate, a service validating a signing key, or a security tool checking whether a binary or package was signed by a known publisher. That broad verification model is why it remains important even as newer algorithms gain ground.
The failure mode is rarely “RSA is broken everywhere.” It is more often that RSA is deployed in an unsafe configuration. Weak key lengths, poor padding choices, or obsolete libraries can turn a sound algorithm into a fragile control. Cryptography Basics Guide is a useful reference point for the surrounding choices, including RSA key sizing, signature padding, and where public-key cryptography fits among other primitives.
Another common issue is overreliance on RSA for too many roles. It can be part of identity validation, but it should not become a default answer for every trust problem. Teams need to separate certificate trust, signature verification, key exchange, and long-term key management, because each one has different failure conditions and operational owners.
What security teams should standardise around RSA
Security teams should standardise on approved key sizes, approved padding schemes, and an explicit retirement plan for obsolete RSA configurations. The key point is to treat RSA as a controlled dependency with lifecycle rules, not as a static compatibility setting.
That means keeping certificate and signing use cases aligned with the organisation’s current cryptographic baseline, especially where external trust is involved. It also means watching for legacy dependencies that silently force weak settings, such as old devices, older middleware, or integrations that have never been re-baselined. In those cases, the technical issue is often not the algorithm itself but the exception that lets it stay weak.
When RSA is used for trust validation, teams should also verify where revocation, certificate issuance, and key storage are handled. A secure algorithm does not compensate for poor private-key protection, bad certificate governance, or a signing process that allows unauthorised use of the key. Those surrounding controls determine whether RSA actually contributes to security.
Risk and Threat Considerations
RSA becomes risky when organisations assume “cryptographic” automatically means “secure.” Weak keys, legacy padding, downgrade paths, and obsolete implementations can create exposure even when the algorithm is formally correct. The practical risk is loss of trust, not just loss of confidentiality.
Failure mechanism: Attackers or misconfigured systems exploit weak RSA parameters, brittle certificate handling, or outdated libraries to undermine verification, impersonate trusted parties, or weaken protected sessions and signatures.
Impact: That can lead to forged trust decisions, compromise of signed software or content, and broader authentication failure where RSA is part of the identity or validation chain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST SP 800-57 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-12 — Cryptographic Key Establishment and Management | RSA use depends on sound key establishment and lifecycle management. |
| IA-5 — Authenticator Management | RSA-backed certificates and signatures often support authentication and trust validation. | |
| Recommendation — Enforce approved key establishment and rotation practices for RSA-based trust services. Manage RSA-backed authenticators and retire weak or obsolete credentials promptly. | ||
| NIST SP 800-57 | Key Management | RSA safety hinges on key size, cryptoperiods, and lifecycle handling. |
| Recommendation — Set RSA key lifecycle policy, including approved sizes, rotation, and retirement. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | RSA is a cryptographic control that must be governed by approved use and configuration. |
| Recommendation — Define approved RSA uses and require secure configuration for each deployment. | ||
| CIS Controls v8 | CIS-3 — Data Protection | RSA protects data and trust decisions through encryption and signatures. |
| Recommendation — Standardise cryptographic protections and eliminate obsolete RSA configurations. | ||
Practitioner Guidance
What to verify: Confirm where RSA is still in active use for certificates, signatures, and key exchange, then check whether those deployments meet the organisation’s current cryptographic baseline. The biggest operational mistake is assuming older configurations are safe because they still “work.”
Decision rule: If RSA is tied to a trust boundary, prefer modern, approved configurations and remove any legacy fallback that enables weaker padding or smaller keys. If a system cannot be upgraded immediately, treat it as a managed exception with an expiry date rather than a permanent accommodation.
What good looks like: RSA use is intentional, documented, and limited to places where it is still justified by compatibility or trust requirements. Teams can show which services depend on it, which keys are protected, and which retirement path applies when a replacement is available.
Practitioner takeaway: RSA is still important, but only when it is governed as a trust control with explicit crypto hygiene, not left as inherited legacy infrastructure.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org