Quantum computers capable of breaking RSA-2048 and ECC don't exist yet — but the encrypted data your applications generate today is already being harvested by adversaries betting that they will. This "harvest now, decrypt later" strategy means TLS sessions, code-signing artifacts, and stored credentials protected by classical public-key cryptography are exposed the moment a cryptographically relevant quantum computer (CRQC) comes online, regardless of when that happens. In August 2024, NIST finalized its first three post-quantum cryptography standards — FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) — starting a clock that regulators and standards bodies have already converted into hard deadlines. The NSA's CNSA 2.0 mandate requires national security systems to support PQC by 2027 and exclusively use it by 2033. For application security teams, this isn't a cryptography research problem anymore; it's a dependency, certificate, and code-signing inventory problem that most organizations have not started solving.
When Do Applications Actually Need to Be Quantum-Safe?
The honest answer is sooner than most roadmaps assume, because "harvest now, decrypt later" collapses the traditional migration timeline. Security researchers estimate a CRQC capable of breaking RSA-2048 could plausibly emerge sometime in the 2030-2035 window, but data with a long confidentiality shelf life — health records, financial transactions, government communications, source code, trade secrets — is vulnerable the moment it's intercepted today. Mosca's theorem frames this as a simple inequality: if the sum of your data's required shelf life and your migration time exceeds the time until a CRQC arrives, you're already too late. A healthcare company signing 10-year data retention agreements in 2026 needs cryptographic agility now, not in 2032. NIST's own guidance (SP 1800-38) recommends organizations complete a full cryptographic inventory by 2025 and begin active migration well before 2030, treating the CNSA 2.0 2033 deadline as a backstop for federal systems, not a target for everyone else.
What Actually Breaks When Quantum Computers Arrive?
Public-key cryptography breaks first, and that's precisely what secures your software supply chain. Shor's algorithm efficiently solves the integer factorization and discrete logarithm problems underlying RSA, Diffie-Hellman, and elliptic-curve cryptography (ECDSA, ECDH) — the exact primitives used in TLS 1.2/1.3 handshakes, SSH key exchange, code-signing certificates (Authenticode, GPG, Sigstore), and JWT/OAuth token signatures. Symmetric cryptography like AES-256 is comparatively resilient, since Grover's algorithm only halves its effective key strength, meaning AES-256 still offers roughly 128 bits of post-quantum security. This asymmetry matters for prioritization: your encryption-at-rest and VPN tunnels using AES-256 are lower urgency than your public-key infrastructure. A single compromised code-signing key retroactively undermines the integrity of every artifact ever signed with it — which is why code-signing and certificate authorities are consistently ranked as the highest-priority PQC migration targets across NIST, CISA, and industry guidance published since 2023.
Which Algorithms Should Replace RSA and ECC Today?
For key encapsulation, ML-KEM (formerly CRYSTALS-Kyber, standardized as FIPS 203) is the current default, offering three security levels (ML-KEM-512/768/1024) that map roughly to AES-128/192/256 equivalence. For digital signatures, ML-DSA (formerly CRYSTALS-Dilithium, FIPS 204) is the primary recommendation, with SLH-DSA (formerly SPHINCS+, FIPS 205) as a stateless hash-based backup algorithm favored for its conservative, well-understood security assumptions despite larger signature sizes (7.8KB-49KB versus ML-DSA's 2.4KB-4.6KB). A fourth algorithm, HQC, was selected by NIST in March 2025 as a structurally different backup for key encapsulation, expected to be finalized around 2027. In practice, most organizations aren't switching cold — Google, Cloudflare, and AWS have already deployed hybrid key exchange (classical X25519 combined with ML-KEM) in TLS 1.3, giving quantum resistance today without dropping compatibility with systems that haven't migrated, a pattern IETF standardized in RFC 8446bis-track drafts through 2024.
How Do You Inventory Cryptography You Don't Know You Have?
You build a Cryptography Bill of Materials (CBOM), the crypto equivalent of an SBOM, because most enterprises cannot currently answer "where is RSA-2048 used in our stack" without one. A typical mid-size SaaS application touches cryptography in TLS termination, database encryption, JWT signing libraries, package manager signature verification (npm, PyPI, Maven all rely on RSA or ECDSA), internal service-to-service mTLS, and dozens of transitive dependencies bundling their own crypto implementations — OpenSSL forks, vendored TLS stacks, and hardcoded algorithm choices in third-party SDKs. The Linux Foundation's OpenSSF and CycloneDX added formal CBOM support in CycloneDX 1.6 (released in 2024) specifically because manual cryptographic asset discovery doesn't scale past a handful of services. Without an automated, continuously updated inventory tied to your existing SBOM and dependency graph, teams discover quantum-vulnerable algorithms the way they discover Log4Shell-style vulnerabilities: reactively, after an advisory forces the question.
What Should a Realistic Migration Roadmap Look Like?
A realistic roadmap has four phases, and skipping the first one is why most PQC pilots stall. Phase one is discovery: generate a CBOM across all applications, dependencies, certificates, and infrastructure to identify every instance of RSA, ECC, and DH, prioritized by data sensitivity and shelf life. Phase two is cryptographic agility: refactor hardcoded algorithm choices behind abstraction layers so that swapping ML-KEM in for RSA later doesn't require touching every call site — a lesson many organizations learned the hard way during the years-long, still-incomplete migration off SHA-1 and TLS 1.0. Phase three is hybrid deployment: adopt hybrid classical/PQC schemes for TLS and VPN traffic first, since libraries like OpenSSL 3.2+, BoringSSL, and AWS-LC already support ML-KEM hybrids in production. Phase four is code-signing and PKI migration, the slowest phase because it requires coordinating certificate authorities, hardware security modules, and every downstream consumer that validates your signatures — Microsoft, Adobe, and DigiCert have all published PQC certificate roadmaps targeting 2025-2027 pilot issuance ahead of broader 2030 adoption.
How Safeguard Helps
Safeguard treats post-quantum migration as a software supply chain integrity problem, not just a cryptography upgrade, because the two are inseparable: the same artifacts, dependencies, and signing keys that need SBOM-level visibility for vulnerability management are the ones that need cryptographic inventory for quantum readiness. Safeguard continuously scans your build artifacts, container images, and dependency trees to surface every use of RSA, ECC, DH, and other quantum-vulnerable algorithms, mapping them directly to the services and data classifications that depend on them — turning "where is RSA-2048 in our stack" from a multi-week manual audit into a queryable inventory.
That inventory feeds directly into prioritization: Safeguard flags code-signing keys, certificate authorities, and long-lived data paths as high-urgency migration targets, consistent with NIST and CISA guidance, so security teams aren't guessing which of hundreds of findings to fix first. As package ecosystems and CI/CD pipelines begin shipping PQC-signed artifacts and hybrid TLS configurations, Safeguard verifies signature validity and provenance across both classical and post-quantum schemes, ensuring your software supply chain security posture doesn't regress during the multi-year transition. And because CBOM data lives alongside your existing SBOM and vulnerability data in Safeguard, tracking PQC migration progress becomes part of the same continuous monitoring workflow your teams already use — not a separate spreadsheet project that goes stale the moment NIST finalizes its next algorithm.