Every signed commit, every verified package, every TLS handshake between your CI runner and a registry rests on math that quantum computers will eventually break. RSA and elliptic-curve cryptography — the algorithms securing npm, PyPI, Maven Central, container registries, and code-signing certificates — are vulnerable to Shor's algorithm on a sufficiently large quantum computer. That machine doesn't exist yet, but adversaries are already recording encrypted traffic and signed artifacts today to decrypt or forge later, a strategy called "harvest now, decrypt later." In August 2024, NIST finalized its first three post-quantum cryptography standards, starting a clock that NSA's CNSA 2.0 policy turns into hard deadlines for federal software by 2030 and 2033. For software supply chains specifically — where signatures must remain verifiable for years and package provenance chains can't be silently rotated — post-quantum migration is now a concrete, dated engineering problem, not a theoretical one. Here's what security and platform teams need to know.
What Is Post-Quantum Cryptography, and Why Does It Matter for Software Supply Chains?
Post-quantum cryptography (PQC) is a set of cryptographic algorithms designed to remain secure against attacks from both classical and quantum computers, and it matters for supply chains because nearly every trust mechanism in modern software delivery — package signatures, TLS to registries, code-signing certificates, commit signing via GPG/SSH — is built on RSA or elliptic-curve math that quantum computers can theoretically break using Shor's algorithm. Unlike a typical vulnerability that gets patched in a dependency, a cryptographic break invalidates the trust anchor itself: every historical signature made with a broken algorithm becomes forgeable in principle. For an ecosystem like npm (over 3 million packages) or Sigstore, which now signs a significant share of open-source releases via cosign and Fulcio using ECDSA, that's not a bug fix — it's a re-architecture of how provenance is established and re-verified.
When Will Quantum Computers Actually Break Today's Encryption?
No one has built a cryptographically relevant quantum computer yet, and most credible estimates put that milestone somewhere between 2030 and 2040, but the uncertainty itself is the risk driver for supply chain teams. Current quantum hardware (IBM's Condor, Google's Willow, and similar systems) has on the order of hundreds to a few thousand physical qubits with error rates far too high for Shor's algorithm against 2048-bit RSA, which researchers estimate requires roughly 1-20 million stable logical qubits depending on the implementation. The gap is large, but not so large that it's safe to ignore: artifacts signed today — a container image, a firmware binary, a long-lived code-signing certificate — may need to remain verifiably authentic for 10-15 years, which pushes the effective deadline for migration planning well before any quantum computer arrives.
What Is "Harvest Now, Decrypt Later," and How Does It Threaten Signed Artifacts?
"Harvest now, decrypt later" (HNDL) describes an adversary capturing encrypted data or intercepting signed material today with the intent of breaking it once quantum computing matures, and for supply chains this applies less to encryption-in-transit and more to long-lived signatures and embedded secrets. A build artifact signed in 2026 with RSA-2048, distributed through a registry, and still running in production in 2038 carries a signature that could be forged retroactively if RSA falls — meaning an attacker could later fabricate a "validly signed" malicious update against a still-trusted key. This is why NIST's IR 8547 (initial public draft, November 2024) explicitly calls out digital signature migration as more urgent in some respects than encryption migration: signatures underpin non-repudiation and authenticity claims that supply chain security programs depend on for SLSA provenance, SBOM attestations, and image signing.
What Has NIST Actually Standardized, and What Are the Deadlines?
NIST finalized three post-quantum standards on August 13, 2024: FIPS 203 (ML-KEM, based on CRYSTALS-Kyber, for key encapsulation), FIPS 204 (ML-DSA, based on CRYSTALS-Dilithium, for digital signatures), and FIPS 205 (SLH-DSA, based on SPHINCS+, a hash-based signature scheme as a conservative backup). A fourth algorithm, HQC, was selected in March 2025 as an additional KEM to diversify away from lattice-based math. On the policy side, the NSA's CNSA 2.0 suite requires software and firmware signing to support CNSA 2.0 algorithms by 2025 and to exclusively use them by 2030, with browsers/servers and traditional networking equipment following on a 2033 timeline. For teams building or consuming a software supply chain, this means the artifacts you sign in the next two to three years need a credible migration path to ML-DSA or SLH-DSA — not a five-year-out roadmap item.
Is the Software Supply Chain Industry — Including Sonatype — Actually Addressing This?
Coverage across the software composition analysis (SCA) and supply chain security market is inconsistent, and most vendors, Sonatype included, treat PQC today as a research or thought-leadership topic rather than a shipped control in their scanning and policy engines. Sonatype's public content has flagged quantum risk and "harvest now, decrypt later" concerns in its threat research, but its core Nexus platform and Sonatype Repository Firewall remain focused on identifying known-vulnerable open-source components (CVE/malicious-package detection) rather than assessing cryptographic algorithm inventory inside dependencies or signature chains. That gap matters: a component scanner that doesn't know whether a package's TLS library, JWT implementation, or signing routine still hardcodes RSA-1024 or a deprecated curve can't tell you your actual PQC exposure. The emerging answer across the industry is the Cryptography Bill of Materials (CBOM), an extension of CycloneDX that inventories exactly which cryptographic algorithms, key sizes, and libraries are in use across a codebase and its dependency tree — a capability still nascent across most commercial SCA tooling in 2026.
What Should Software Supply Chain Teams Do Right Now?
Teams should start by inventorying where RSA, ECDSA, and Diffie-Hellman actually live in their build and release pipeline, because you cannot migrate what you haven't mapped. Concretely: catalog code-signing certificates and their expiry/rotation cadence, identify which CI/CD systems and artifact repositories (Sigstore/cosign, JFrog, GitHub Attestations) generate signatures with what algorithms, and check whether your TLS termination points to registries support hybrid key exchange — Chrome and Cloudflare have already shipped hybrid post-quantum key exchange (X25519Kyber768, later X25519MLKEM768) in production since 2023-2024, showing the transition pattern of running classical and post-quantum algorithms in parallel rather than a hard cutover. Prioritize systems with long artifact lifetimes (firmware, embedded, long-term-support releases) since those inherit the most HNDL exposure, and track whether your dependencies' own crypto libraries (OpenSSL 3.5+, BoringSSL, liboqs-integrated stacks) have PQC support before you build migration tooling on top of ones that don't.
How Safeguard Helps
Safeguard treats cryptographic posture as part of the same supply chain risk model it applies to vulnerabilities, malicious packages, and provenance gaps — not a separate research track. Safeguard's dependency analysis surfaces the cryptographic libraries and signature mechanisms embedded in your open-source and first-party components, so security teams can see where RSA, ECDSA, or deprecated key sizes are load-bearing before a migration deadline forces a scramble. Because Safeguard ingests SBOM and provenance data as a first-class signal rather than an afterthought, it's positioned to extend that inventory into CBOM-style cryptographic tracking as CycloneDX support matures, giving teams a single place to correlate "which packages are vulnerable," "which packages are malicious," and "which packages use crypto that won't survive the 2030-2033 CNSA 2.0 timeline." For teams that already rely on Safeguard for continuous open-source risk monitoring, that means quantum-readiness assessment doesn't require a separate tool or a manual audit — it's a natural extension of the visibility Safeguard already provides into what's actually running in your software supply chain, and how it's trusted.