RSA: Secure Today, Scheduled for Retirement

Published: February 2026. Updated: August 2026. Reviewed by Encryption Consulting’s PQC advisory team.

RSA remains one of the most widely deployed public-key cryptographic algorithms in modern security infrastructure. It continues to support Transport Layer Security (TLS) certificates, digital signatures, and identity systems across enterprise and government environments. However, its continued presence increasingly reflects backward compatibility requirements rather than forward-looking cryptographic design choices.

From a security architecture perspective, RSA is no longer a preferred choice in forward-looking cryptographic designs. It persists because it continues to function under classical computing assumptions and remains widely supported, not because it aligns with evolving threat models.

To understand this transition clearly, it is necessary to examine RSA’s mathematical foundation, operational behavior, and its limitations in the context of post-quantum cryptography (PQC).

RSA Key Sizes, Security Levels, and Algorithm Equivalence

The security provided by an RSA key is determined not by the algorithm name but by the key size, and the relationship between key size and security strength is not linear. SP 800-57 Part 1 Revision 5, Table 2 defines comparable security strengths across algorithm families. RSA falls under the IFC (Integer Factorization Cryptography) column, where a 2048-bit modulus (k=2048) provides 112-bit security, a 3072-bit modulus provides 128-bit security equivalent to AES-128, a 7680-bit modulus provides 192-bit security equivalent to AES-192, and a 15360-bit modulus provides 256-bit security equivalent to AES-256.

The table itself carries a note on the IFC and ECC columns stating that these security-strength estimates will be significantly affected when quantum computing becomes a practical consideration.

This comparison reveals a core efficiency gap. To achieve 128-bit security, RSA requires a 3,072-bit modulus, while an elliptic curve key achieves the same level at 256 bits. To match P-384, RSA requires 7,680 bits. The size differential grows substantially at higher security levels, which is why elliptic curve algorithms are increasingly preferred over RSA in forward-looking protocol designs, particularly for key exchange, where equivalent security at significantly smaller key sizes reduces computational overhead.

This sizing guidance, however, applies only within classical computing contexts. Under NIST IR 8547 (Initial Public Draft, November 2024), all RSA key sizes are subject to disallowance after 2035 because Shor’s algorithm factors integers in polynomial time regardless of key length. Increasing an RSA key from 2048 to 7680 bits does not change its quantum vulnerability.

Security Assumptions Behind RSA

Every cryptographic recommendation depends on a stated threat model. For RSA, the classical security assumption is that no adversary bounded by classical, non-quantum computation can factor a large semiprime modulus in feasible time. That assumption holds for RSA-2048 today: the best known classical attack, the General Number Field Sieve, has sub-exponential running time and remains computationally infeasible at current key sizes when combined with correct padding (OAEP for encryption, PSS for signatures) and secure key generation.

• Adversary model: bounded to classical probabilistic polynomial-time computation, with no access to a cryptographically relevant quantum computer.
• Hardness problem: integer factorization of a large semiprime modulus, known as the RSA problem, not formally proven but stable under decades of cryptanalysis.
• Implementation dependency: security holds only with correct padding (OAEP, PSS), secure random key generation, and constant-time operations resistant to side-channel leakage.
• Primary standards: NIST SP 800-57 Part 1 Revision 5 defines the key-size-to-security-strength mapping; NIST IR 8547 (Initial Public Draft, November 2024) defines the proposed transition timeline away from RSA as the threat model changes.
• The assumption that fails under quantum computation: Shor’s algorithm solves integer factorization in polynomial time on a sufficiently large, fault-tolerant quantum computer, which removes the classical hardness assumption entirely rather than merely weakening it.

Why RSA Still Works Under Classical Computing Models

RSA remains secure in classical computing environments because no known efficient classical algorithm can factor large semiprime integers at cryptographically relevant key sizes. The security assumption is specifically tied to the hardness of integer factorization over classical probabilistic polynomial time models.

The best known general-purpose classical attack is the General Number Field Sieve (GNFS), which has sub-exponential complexity. While GNFS is asymptotically the fastest known method, its practical cost grows super-polynomially with key size, making 2048-bit RSA still computationally infeasible under current classical computing capabilities when properly implemented with modern padding and secure key generation.

It is also important to note that RSA security depends not only on factoring difficulty but also on correct implementation. Padding schemes such as Optimal Asymmetric Encryption Padding (OAEP) for encryption and the Probabilistic Signature Scheme (PSS) for signatures are essential. Without them, RSA becomes vulnerable to structural or padding oracle attacks even if the underlying key is mathematically strong.

Importantly, RSA has no known shortcut algorithm that reduces security to anything easier than integer factorization in the classical model. Its security is grounded in a well-studied hardness assumption that has remained stable for decades, though not formally proven.

However, this stability applies strictly within classical computation. It does not extend to quantum computational models.

Where RSA Is Still Used in Modern Systems

RSA remains present in several critical infrastructure layers, but its role is increasingly constrained to compatibility and trust anchoring rather than active protocol innovation.

In TLS ecosystems, RSA is still widely used for certificates and signature validation, particularly in systems that require backward compatibility with older clients.

In public key infrastructure (PKI) systems, RSA continues to secure certificate authority (CA) hierarchies, including root and intermediate certificates. These systems change slowly due to their dependency on long-term trust anchors.

RSA is also used in software and firmware signing systems, where it verifies the authenticity of operating system updates, firmware images, and application binaries.

In Secure Shell (SSH) environments, RSA support still exists, although it is increasingly replaced by ECC-based algorithms such as Ed25519.

Where RSA Creates Exposure First

RSA does not carry equal risk across all contexts in which it is deployed. The exposure profile depends on whether RSA is being used for key establishment or digital signatures, and on how long the protected data or signed artifacts remain in active use.

The highest-priority exposure is RSA used in key establishment, specifically in TLS 1.2 configurations that rely on RSA key transport. In this model, the client encrypts a pre-master secret directly with the server’s RSA public key, and the server decrypts it with the corresponding private key. This design has no forward secrecy. If an adversary captures and records the encrypted session traffic today and later gains access to the server’s RSA private key, whether through a breach or through a quantum computer recovering the RSA private key via Shor’s algorithm, they can decrypt the recorded pre-master secret, derive the session keys, and read the traffic.

This threat is active now because adversaries can harvest ciphertext today and decrypt it when quantum capability becomes available. TLS 1.3, defined in RFC 8446 (August 2018), addressed this by removing RSA key exchange entirely. Forward secrecy through ephemeral key exchange is mandatory in TLS 1.3. TLS 1.2 deployments that still negotiate TLS_RSA_WITH_* cipher suites retain this exposure and represent the most time-sensitive migration target.

RSA used for digital signatures in authentication presents a different risk profile. An authentication event that was valid at the time it occurred does not become retroactively compromised when RSA can eventually be broken. A correctly validated login or access grant in 2025 is not undone by a quantum attack in 2035.

NIST IR 8547 IPD reflects this, noting that authentication systems can continue using classical algorithms until a cryptographically relevant quantum computer exists, at which point they must be disabled. The concern shifts from retrospective compromise to future forgery: a quantum-capable adversary could forge RSA signatures to impersonate services or entities, making the migration timeline for authentication systems tied to quantum hardware readiness rather than data longevity.

Code signing and firmware signing carry a longer exposure window than authentication. RSA-signed firmware may remain deployed and actively trusted on devices for many years after the signing event. If an adversary can forge RSA signatures during that window, they can produce fraudulent firmware or software updates that pass legacy verification. This makes RSA in long-lived signing pipelines a higher migration priority than short-lived session credentials.

RSA in PKI trust anchors compounds all of the above. Root CA certificates carrying RSA keys typically have validity periods measured in years. If the RSA key protecting a root CA were compromised by a quantum adversary within its validity window, every certificate issued under that hierarchy loses its trust basis, affecting all dependent use cases simultaneously.

Performance and Scalability Limitations

RSA introduces performance and scalability limitations that become more noticeable in modern high-scale and latency-sensitive systems. Its security strength is primarily increased by enlarging key sizes, which directly impacts computational cost. As key sizes grow from 2048-bit to 3072-bit and beyond, operations based on modular exponentiation become more expensive, particularly for private key operations such as signing and decryption.

RSA also exhibits an inherent asymmetry in operational cost. Public key operations such as signature verification and encryption are relatively efficient due to the use of small public exponents like 65537. In contrast, private key operations require significantly heavier computations, since they involve large exponent modular arithmetic. This imbalance can become a bottleneck in systems that perform frequent signing operations, such as authentication services or CAs.

In addition, RSA produces larger keys and signatures compared to ECC, which increases bandwidth consumption during certificate exchange and TLS handshakes. While this overhead may be marginal in isolated transactions, it becomes more relevant in large-scale distributed systems with high connection churn. As a result, RSA is generally less efficient than ECC-based algorithms in modern protocol and infrastructure designs.

Post Quantum Cryptography and the Fundamental Break in RSA

RSA’s most critical limitation is not performance but its incompatibility with quantum computing models. PQC is based on the recognition that widely used public key schemes, including RSA and ECC, rely on mathematical problems that are vulnerable to quantum algorithms under specific computational models.

In the case of RSA, the primary concern is Shor’s algorithm, which can factor large integers in polynomial time on a sufficiently powerful quantum computer. Since RSA security is based on the hardness of integer factorization in classical computing models, the existence of such an algorithm invalidates that underlying assumption in a quantum environment. This does not imply that RSA is currently broken in practice, but it does mean its security guarantees do not extend to adversaries with large-scale quantum capabilities.

Because of this shift in threat model, increasing RSA key sizes does not provide meaningful protection against quantum attacks. The issue is not computational scaling but the change in the underlying problem class. According to NIST IR 8547 (Initial Public Draft, November 2024), RSA-2048 and P-256, operating at the 112-bit security level, are proposed to be deprecated after 2030 under the draft, with all quantum-vulnerable public key algorithms including higher key sizes disallowed after 2035. Instead, modern PQC algorithms such as ML-KEM and ML-DSA are designed around mathematical structures, particularly lattice-based problems, that currently have no known efficient quantum solutions.

This transition does not represent an upgrade path for RSA. It represents a cryptographic replacement driven by a fundamentally different security assumption. However, in practice, organizations are not expected to migrate all systems at once. Existing RSA deployments will continue to operate in classical environments while PQC algorithms are introduced in parallel through hybrid modes during the transition phase. These hybrid approaches are temporary mechanisms intended to maintain interoperability and reduce migration risk.

Worked Example: RSA-2048 in Concrete Numbers

Abstract statements about RSA’s eventual quantum vulnerability are easier to evaluate with concrete figures attached. A 2048-bit RSA modulus is a composite number roughly 617 decimal digits long, formed as the product of two 1024-bit primes. Classically, the General Number Field Sieve attacking this modulus has an estimated work factor on the order of 2 to the 112th power operations, which is why NIST rates RSA-2048 at 112-bit security in SP 800-57. At that work factor, factoring a single RSA-2048 modulus with the best known classical methods and realistic hardware remains outside practical reach.

The quantum picture is different in kind, not just degree. A widely cited 2019 analysis by researchers Craig Gidney and Martin Ekera estimated that factoring a 2048-bit RSA integer would require approximately 20 million noisy qubits running for about 8 hours, using optimized circuit constructions for Shor’s algorithm. As of 2026, the largest publicly known quantum processors operate with hundreds to low thousands of physical qubits, several orders of magnitude short of that estimate, and physical qubits still require substantial error-correction overhead to become the stable logical qubits the estimate assumes. This gap is precisely why NIST frames the RSA transition as time-boxed risk management rather than an emergency: the algorithm is not broken today, but data encrypted today with RSA key exchange can be harvested now and decrypted later once a cryptographically relevant quantum computer exists.

Put in comparative terms: an ECC P-256 key reaches the same 128-bit security tier that a 3072-bit RSA key reaches, at roughly one-twelfth the key size, while a lattice-based ML-KEM-768 key establishment provides comparable classical strength plus resistance to Shor’s algorithm entirely, at the cost of larger public keys and ciphertexts than ECC (roughly 1.1KB versus 65 bytes for a P-256 public key). This size and performance trade-off is the practical reason hybrid classical-plus-PQC modes exist during migration: they let systems keep ECC’s efficiency for the classical guarantee while adding ML-KEM’s structure for the quantum guarantee.

Why RSA Is Becoming a Legacy Algorithm

RSA is gradually moving into a legacy role due to a combination of factors: performance characteristics, scalability limitations, and the emergence of PQC. While ECC already provides equivalent security with smaller key sizes and improved efficiency, RSA continues to exist primarily for compatibility with existing systems and trust infrastructures.

At the protocol level, modern security designs increasingly rely on ECC-based mechanisms for key exchange and digital signatures, while RSA remains primarily in use for certificate compatibility and legacy validation paths. This creates a transitional state where RSA is maintained not as a preferred primitive, but as a compatibility layer within mixed environments.

Post Quantum Migration in Practice

Transitioning to PQC is not a direct algorithm swap but an operational migration process. It begins with discovering where quantum-vulnerable cryptographic assets exist across infrastructure, including TLS endpoints, identity systems, hardware security modules (HSMs), applications, and embedded devices. This is followed by building a structured cryptographic inventory that captures not only certificates and keys, but also dependencies across systems and trust chains.

Once the inventory is established, organizations must perform dependency mapping to identify systems that cannot immediately support PQC algorithms or ECC replacements. This includes legacy clients, constrained devices, and vendor systems that require updates before supporting newer cryptographic primitives.

Migration itself is typically phased. Hybrid cryptographic configurations are used during the transition period to maintain compatibility while introducing PQC algorithms. Hybrid cryptography refers to the combined use of classical algorithms such as RSA or elliptic curve cryptography alongside PQC algorithms in a single protocol exchange, ensuring security against both classical and quantum adversaries during the migration window.

This approach allows systems to remain interoperable while gradually validating and deploying quantum-resistant mechanisms. However, this is not intended to be a permanent state. It is a transitional strategy designed to ensure continuity of security during migration, with the long-term objective of fully adopting PQC as ecosystem support matures.

Over time, as ecosystem support matures, RSA is progressively removed from systems that require long-term security guarantees. In this context, RSA is not evolving into PQC. It is being gradually retired as systems transition toward cryptographic models designed for a different computational threat landscape.

Limitations

• NIST IR 8547 remains an Initial Public Draft as of this update; the 2030 deprecation and 2035 disallowance dates for RSA and other quantum-vulnerable algorithms are proposed, not finalized, and may shift as NIST reviews public comments.
• CNSA 2.0’s mandatory milestones (new National Security Systems acquisitions supporting CNSA 2.0 by 2027, legacy equipment phased out by 2030, mandatory adoption by 2031) apply directly only to systems supporting US national security missions; commercial enterprises are not bound by CNSA 2.0 but frequently use it as a planning reference.
• No cryptographically relevant quantum computer exists today. Timeline estimates for when one might exist vary across the security community, which is why harvest-now-decrypt-later risk assessments should be based on how long protected data must remain confidential, not on a specific predicted breakthrough date.
• Hybrid classical-plus-PQC configurations add computational and bandwidth overhead compared to classical-only or PQC-only modes, which some constrained or legacy systems may not yet support without additional engineering work.

Enterprise Decision Table: What To Do With RSA Right Now

The right response to RSA’s quantum exposure depends on the deployment scenario, not on RSA as a single category. The table below maps common enterprise scenarios to a recommended action and rough timeline, informed by NIST IR 8547’s draft dates and the CNSA 2.0 milestones many enterprises use as an external planning reference.

Scenario	Recommended Action	Priority Window
TLS 1.2 endpoints still negotiating RSA key transport (TLS_RSA_WITH_*)	Disable RSA key exchange cipher suites; require ECDHE or move to TLS 1.3, which removes RSA key exchange entirely	Immediate to 12 months
New PKI build or greenfield certificate authority hierarchy	Issue with ECC (P-256 or P-384) today; pilot hybrid certificates as CA/Browser Forum and vendor support matures	Immediate
Long-lived code or firmware signing keys (5+ year trust window)	Prioritize migration to ML-DSA or hybrid RSA/ML-DSA signing; forged signatures on long-lived artifacts carry the longest exposure window	Now through 2030
Root and intermediate CA keys in existing PKI hierarchies	Begin dependency mapping and re-issuance planning; a compromised root invalidates every certificate beneath it	Now through 2030 to 2033
FIPS 140-3 validated HSM environments	Confirm HSM firmware and vendor roadmap support ML-KEM and ML-DSA modules before mandating their use in production	12 to 24 months
Short-lived session authentication (login, API tokens)	Lower immediate priority; retrofit as ECC/PQC support becomes standard in identity providers, since forgery risk only begins once a quantum computer exists	2027 to 2030

How Encryption Consulting Can Help

Transitioning away from RSA and toward PQC requires more than algorithm selection. It depends on understanding how cryptography is actually deployed across systems, how dependencies are structured, and where operational risk exists during migration. This is where Encryption Consulting helps organizations move from assessment to execution in a controlled and risk-informed manner.

PKI Assessment

Encryption Consulting’s PKI Assessment is a structured engagement that evaluates your entire PKI environment across technical, operational, and governance dimensions. It begins with discovery: mapping your current PKI architecture across on-premises, cloud, and hybrid environments to establish a complete picture of what exists, how it is configured, and where it connects.

This includes CA hierarchy validation, certificate template review, key management practices, and an end-to-end test of your revocation infrastructure, verifying that CRL Distribution Point (CDP) and Authority Information Access (AIA) extensions in issued certificates point to responders and distribution points that are actually reachable from the network segments where certificates are validated.

Beyond configuration, structured stakeholder workshops and architecture review sessions are used to understand operational reality. These discussions often surface gaps that are not visible in documentation alone, such as PKI policies that exist but are not consistently enforced, Online Certificate Status Protocol (OCSP) responders that are deployed but not tested under real conditions, and certificate templates that no longer align with current security requirements.

The output is a prioritized risk and gap analysis report. Findings are ranked by severity and mapped to specific remediation actions, giving your team a clear roadmap rather than a generic checklist.

PQC Advisory Services

Encryption Consulting supports organizations throughout this journey with end-to-end PQC migration services covering discovery, assessment, planning, validation, and deployment.

Our PQC Advisory Services help organizations identify certificates, keys, algorithms, protocols, and cryptographic dependencies across cloud environments, applications, infrastructure, HSMs, source code repositories, containers, APIs, and CI/CD pipelines. Using this visibility, we assess exposure to quantum-vulnerable cryptography, identify high-priority remediation areas, and develop risk-based migration roadmaps aligned with NIST standards, regulatory requirements, and business objectives.

Beyond planning, Encryption Consulting assists with vendor readiness assessments, proof-of-concept validation, interoperability testing, hybrid cryptography deployments, crypto-agile PKI architecture design, and enterprise-scale implementation programs. This structured approach enables organizations to move from fragmented cryptographic visibility to a governed, measurable, and sustainable PQC migration program.

CBOM Secure

A successful post-quantum transition begins with visibility. Encryption Consulting’s CBOM Secure provides continuous discovery and inventory of cryptographic assets across enterprise infrastructure, cloud environments, applications, and cryptographic services.

Unlike a point-in-time inventory, CBOM Secure continuously generates and consumes Cryptographic Bills of Materials (CBOMs) while tracking certificates, keys, algorithms, and cryptographic dependencies across the environment. It provides visibility into what is deployed, where it is running, and how those dependencies evolve over time.

The platform supports policy-driven governance by validating cryptographic configurations against organizational standards, identifying deviations, and highlighting security, operational, and compliance risks. For organizations preparing for PQC migration, CBOM Secure helps identify systems that rely on quantum-vulnerable algorithms, prioritize remediation efforts, and establish the continuous cryptographic governance required to achieve long-term crypto-agility.

Whether your organization is beginning its post-quantum journey or expanding an existing cryptographic modernization program, Encryption Consulting combines advisory expertise with purpose-built solutions to help you discover cryptographic assets, assess migration readiness, and build a scalable, crypto-agile foundation for the future. Learn more about our PKI Advisory Services, PQC Advisory Services, and CBOM Secure at encryptionconsulting.com or contact our team to discuss your post-quantum migration strategy.

Conclusion

PQC represents a fundamental shift in cryptographic assumptions, and RSA remains secure only within classical computing boundaries. As organizations prepare for this transition, the challenge is not limited to replacing algorithms but extending visibility and control across complex and distributed cryptographic ecosystems.

RSA will continue to exist in legacy and compatibility roles for some time, but long-term cryptographic strategy is increasingly defined by PQC requirements, ECC alternatives, and crypto-agile architectures. Success in this transition depends on accurate discovery, structured inventory, dependency mapping, and controlled migration execution.

Frequently Asked Questions

Is RSA broken today? No. RSA-2048 remains secure against every known classical attack when implemented correctly with proper padding and key generation. Its exposure is to future quantum computers running Shor’s algorithm, not to any currently practical classical or quantum attack.

When should we stop using RSA-2048 for new deployments? Now, where alternatives are already supported. ECC (P-256 or P-384) is a drop-in classical replacement with smaller keys and better performance, and it can run in hybrid mode with ML-KEM or ML-DSA where PQC support exists. NIST IR 8547’s draft timeline proposes RSA-2048 deprecation after 2030, which should function as a hard outer deadline, not a starting point.

What replaces RSA for key exchange and digital signatures? For key exchange, ECDHE today and ML-KEM (FIPS 203) as PQC support matures. For digital signatures, ECDSA or EdDSA today and ML-DSA (FIPS 204) for quantum resistance. Many enterprises run these in hybrid mode during the transition to hedge against both classical and quantum risk simultaneously.

If no quantum computer can break RSA yet, why migrate now? Because of harvest-now-decrypt-later risk: encrypted traffic captured today using RSA key exchange can be decrypted retroactively once a quantum computer capable of running Shor’s algorithm exists. Any data that must stay confidential for years, such as health records, trade secrets, or classified material, is exposed today even though the decryption capability does not exist yet.

Does increasing RSA key size to 4096 or 8192 bits solve the quantum problem? No. Shor’s algorithm factors integers in polynomial time regardless of modulus size, so larger RSA keys only raise classical attack cost, not quantum attack cost. The only mitigation against a quantum adversary is replacing the algorithm family entirely, with ECC as an interim step and PQC (ML-KEM, ML-DSA) as the quantum-resistant destination.

References

• NIST SP 800-57 Part 1 Revision 5, Recommendation for Key Management: https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r5.pdf
• NIST IR 8547 (Initial Public Draft, November 2024), Transition to Post-Quantum Cryptography Standards: https://csrc.nist.gov/pubs/ir/8547/ipd
• RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3: https://www.rfc-editor.org/rfc/rfc8446
• Gidney and Ekera (2019), How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits: https://arxiv.org/abs/1905.09749
• NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) guidance: https://www.nsa.gov/Resources/Commercial-National-Security-Algorithm-Suite-2-0/