RSA encryption, the backbone of internet security for over four decades, is approaching its end of life. Not because of a flaw discovered by cryptographers, but because of physics. Quantum computers running Shor's algorithm will be able to factor the large prime numbers that RSA depends on, rendering every RSA key ever generated breakable. NIST has mandated that all federal systems migrate away from RSA by 2030. The replacement is here: ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), formerly known as CRYSTALS-Kyber.

If you are a developer using RSA anywhere in your stack -- TLS certificates, API authentication, data encryption at rest, JWT signing -- this article explains what is coming, when it matters, and how to migrate.

Shor's Algorithm: The RSA Killer, Explained Simply

RSA security rests on a single mathematical assumption: factoring the product of two large prime numbers is computationally infeasible for classical computers. A 2048-bit RSA key is the product of two ~1024-bit primes. The best classical algorithms would take billions of years to factor it.

In 1994, mathematician Peter Shor published a quantum algorithm that factors integers in polynomial time. On a sufficiently powerful quantum computer, Shor's algorithm can break a 2048-bit RSA key in hours, not billions of years.

How it works (no PhD required)

Classical computers try to factor numbers by testing divisors one by one or using mathematical shortcuts like the General Number Field Sieve. Quantum computers exploit quantum superposition to evaluate many possibilities simultaneously. Shor's algorithm specifically:

Converts the factoring problem into a period-finding problem
Uses quantum superposition to find the period of a mathematical function exponentially faster than classical methods
Extracts the prime factors from the discovered period using classical math

The key point: this is not a theoretical curiosity. It is a proven algorithm. The only barrier is building a quantum computer with enough stable qubits to run it against real-world key sizes.

Timeline: When Does RSA Actually Break?

Estimates for when a cryptographically relevant quantum computer (CRQC) will exist range from 2030 to 2040. IBM, Google, and several national laboratories are racing to build one. Current quantum computers have around 1,000-1,500 qubits; breaking RSA-2048 requires roughly 4,000 logical qubits (or millions of noisy physical qubits with error correction).

But the real threat is already here: Harvest Now, Decrypt Later

Nation-state adversaries are already intercepting and storing encrypted traffic. The strategy is simple: capture RSA-encrypted data today, store it, and decrypt it once quantum computers become available. This is not speculation. Intelligence agencies have confirmed this practice.

If your application handles data that needs to remain confidential for more than 5-10 years -- financial records, medical data, trade secrets, government communications -- the quantum threat is not a future problem. It is a present one.

"The threat of a CRQC demands that we begin migrating to post-quantum cryptography now. Waiting is not an option." -- NIST Special Publication 800-227, November 2025

Key dates

2024: NIST publishes final PQC standards (FIPS 203, 204, 205)
2025: NIST deprecates RSA for new federal systems
2030: NIST mandates full migration; RSA disallowed in federal systems
2030-2035: Industry compliance frameworks (PCI DSS, SOC 2) expected to follow
2030-2040: Estimated window for cryptographically relevant quantum computers

ML-KEM vs RSA: A Technical Comparison

ML-KEM (FIPS 203) is a key encapsulation mechanism based on the Module Learning With Errors (MLWE) problem, a mathematical problem that is believed to be hard for both classical and quantum computers. It is not simply a larger RSA. It is a fundamentally different mathematical approach.

Key size comparison

RSA-2048 public key: 256 bytes
ML-KEM-768 public key: 1,184 bytes
ML-KEM-1024 public key: 1,568 bytes

ML-KEM keys are larger, but this is a manageable trade-off. The performance comparison tells a more interesting story:

Performance comparison

RSA-2048 key generation: ~200ms
ML-KEM-768 key generation: ~0.1ms (2,000x faster)
RSA-2048 encryption: ~0.3ms
ML-KEM-768 encapsulation: ~0.15ms (2x faster)
RSA-2048 decryption: ~5ms
ML-KEM-768 decapsulation: ~0.15ms (33x faster)

ML-KEM is not only quantum-safe but dramatically faster than RSA for key generation and decapsulation. The larger key sizes add marginal bandwidth overhead, but the computational savings more than compensate.

Security guarantees

ML-KEM-512: Roughly equivalent to AES-128 security (NIST Security Level 1)
ML-KEM-768: Roughly equivalent to AES-192 security (NIST Security Level 3) -- recommended default
ML-KEM-1024: Roughly equivalent to AES-256 security (NIST Security Level 5)

Code Migration: Node.js RSA to ML-KEM

Here is what a typical RSA key exchange looks like in Node.js today, and how to replace it with ML-KEM.

Before: RSA key exchange

const crypto = require('crypto');

// Generate RSA key pair
const { publicKey, privateKey } = crypto.generateKeyPairSync('rsa', {
  modulusLength: 2048,
  publicKeyEncoding: { type: 'spki', format: 'pem' },
  privateKeyEncoding: { type: 'pkcs8', format: 'pem' },
});

// Encrypt a shared secret with RSA public key
const sharedSecret = crypto.randomBytes(32);
const encrypted = crypto.publicEncrypt(publicKey, sharedSecret);

// Decrypt with RSA private key
const decrypted = crypto.privateDecrypt(privateKey, encrypted);

After: ML-KEM key encapsulation

// Using the oqs (Open Quantum Safe) library for Node.js
// npm install oqs-node
const { KEM } = require('oqs-node');

// Initialize ML-KEM-768 (recommended security level)
const kem = new KEM('ML-KEM-768');

// Generate key pair (server side)
const { publicKey, secretKey } = kem.generateKeypair();

// Encapsulate: generate shared secret + ciphertext (client side)
const { ciphertext, sharedSecret: clientSecret } = kem.encaps(publicKey);

// Decapsulate: recover shared secret from ciphertext (server side)
const serverSecret = kem.decaps(ciphertext, secretKey);

// clientSecret and serverSecret are now identical 32-byte keys
// Use them with AES-256-GCM for symmetric encryption

The conceptual shift is important: RSA uses public-key encryption (encrypt with public key, decrypt with private key). ML-KEM uses key encapsulation (generate a shared secret that both parties can derive). The shared secret is then used with a symmetric cipher like AES-256-GCM. This is actually how TLS works in practice today; the migration primarily affects the key agreement step.

What About Digital Signatures?

ML-KEM replaces RSA for key exchange and encryption. For digital signatures, NIST has standardized:

ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium): General-purpose digital signatures
SLH-DSA (FIPS 205, formerly SPHINCS+): Hash-based signatures, conservative fallback

If you use RSA or ECDSA for JWT signing, code signing, or certificate verification, you will need to migrate those to ML-DSA or SLH-DSA as well.

Finding RSA in Your Codebase

The first step in any migration is discovery. You need to know everywhere RSA (and other quantum-vulnerable cryptography like ECDSA, ECDH, and DH) appears in your codebase. This includes:

Direct calls to crypto libraries (crypto.generateKeyPairSync('rsa', ...))
TLS/SSL certificate configurations
JWT libraries configured with RS256 or ES256
SSH key configurations
Third-party API clients using RSA for authentication
Hardcoded certificates and keys in configuration files

Manually searching a large codebase for all these patterns is time-consuming and error-prone. A single missed instance means a single point of quantum vulnerability.

Start Your Migration Today

The migration from RSA to ML-KEM is not optional. It is a matter of when, not if. Starting now gives you the advantage of migrating on your own timeline rather than scrambling to meet a compliance deadline.

CodeShield.sh scans your entire codebase and identifies every instance of quantum-vulnerable cryptography: RSA, ECDSA, ECDH, DH, and weak symmetric algorithms. It generates a Cryptographic Bill of Materials (CBOM) showing exactly what needs to migrate and provides AI-powered fix suggestions to replace vulnerable code with post-quantum alternatives.

Find all RSA in your codebase in 30 seconds -- connect your GitHub repos and get a complete inventory of quantum-vulnerable cryptography in your first scan.

RSA Is Dead: Why Every Developer Needs to Migrate to ML-KEM Now