Quantum Computers and Cryptography: Post-Quantum Migration Explained

A large, error corrected quantum computer running Shor's algorithm would break the public key cryptography the internet runs on today: RSA, Diffie-Hellman and elliptic curve schemes such as ECDH and ECDSA. It would not practically break AES or SHA-2, because Grover's algorithm only gives a square root speedup. The fix is moving to NIST's post-quantum standards of 13 August 2024, starting with an inventory of your cryptography.

This post bridges physics and security for non-specialists, then covers the standards, the deadlines and commands to check your own systems.

Key takeaways

• Quantum computers are not faster classical computers. They win on problems with hidden structure, such as factoring and discrete logarithms.
• Shor's algorithm (posted to arXiv on 30 August 1995) breaks RSA, Diffie-Hellman and elliptic curve cryptography once a machine is large and reliable enough. Agencies call that machine a cryptographically relevant quantum computer (CRQC).
• Grover's algorithm (posted 29 May 1996) only square roots brute force search. NIST's transition draft counts approved symmetric algorithms with at least 128 bit classical security as meeting its lowest post-quantum category.
• "Harvest now, decrypt later" makes key exchange urgent today. Long lived signing keys make signatures urgent next.
• NIST published FIPS 203 (ML-KEM), 204 (ML-DSA) and 205 (SLH-DSA) on 13 August 2024 and picked HQC as a backup KEM on 11 March 2025.
• NIST's draft IR 8547 disallows quantum vulnerable public key algorithms after 2035; the NSA and the UK NCSC set earlier milestones.
• Hybrid TLS key exchange is standardised in RFC 10024 (August 2026), with X25519MLKEM768 as the recommended group.
• A cryptographic inventory, recorded in a format such as a CycloneDX CBOM, is the first step in every agency's plan.

A dated timeline from Shor to the 2035 deadline

Future dates are targets set by the documents in Sources, not predictions of when a CRQC will exist.

What is a quantum computer, in terms a security engineer can use?

A classical bit is 0 or 1. A qubit can be in a superposition, a weighted combination of 0 and 1 described by two numbers called amplitudes. Measuring it gives a single 0 or 1, with probabilities set by the amplitudes. Qubits can also be entangled, so n qubits together are described by 2 to the power n amplitudes.

A quantum computer does not usefully "try every answer at once": measuring returns one random answer. The real trick is interference. Amplitudes can be negative or complex, so a well designed sequence of operations makes wrong answers cancel and right answers reinforce. Grover's abstract puts it this way: "successful computations reinforce each other while others interfere randomly."

Interference only helps when a problem has exploitable structure, so quantum computers give huge speedups on a narrow set of problems, modest ones on unstructured search, and little elsewhere.

The other concept a non-specialist needs is physical versus logical qubits. Physical qubits are noisy. Quantum error correction spreads one reliable logical qubit across many physical ones and corrects errors continuously. Breaking RSA needs a long computation on many logical qubits, so when you read about a new chip, the useful question is how many error corrected logical qubits it sustains and for how long, not the raw physical count.

Nobody can date a CRQC. NIST's August 2024 release reports that some experts expect one "could appear within a decade"; its 2016 report notes experts disagree. Agencies have stopped waiting for consensus and set migration dates instead, because migrations take longer than anyone expects.

Why does public key cryptography depend on problems a quantum computer can solve?

Public key cryptography rests on one way functions. Multiplying two large primes is easy; recovering them from the product is believed hard classically. That is RSA. Raising a number to a power in a group is easy; recovering the exponent, the discrete logarithm, is believed hard. That is Diffie-Hellman and DSA, and in elliptic curve groups, ECDH, ECDSA and EdDSA.

Both problems hide a repeating pattern. Take a number a and compute a to the power x modulo N for x = 1, 2, 3 and onward: the results eventually cycle. The length of that cycle, the period, reveals the factors of N with a little classical arithmetic. Finding the period classically means walking the sequence, which takes exponential time at cryptographic sizes.

Shor showed a quantum computer can find the period efficiently. It prepares a superposition over many values of x, computes the modular exponentiation into a second register, then applies the quantum Fourier transform. Like a spectrum analyser turning a repeating sound into a clean tone, the Fourier transform turns the periodic state into sharp peaks related to the period. Amplitudes that fit the period line up and the rest cancel, so a measurement yields the period with high probability. Shor's abstract states the result: the algorithms take "a number of steps polynomial in the input size".

Polynomial versus exponential is the whole story. Doubling an RSA key makes classical factoring vastly harder but makes Shor's algorithm only modestly more expensive. Bigger keys buy time against classical attackers and almost nothing against a CRQC, so the answer is new mathematics, not longer keys.

The same method solves discrete logarithms in any group, including elliptic curves. Because elliptic curve keys are much shorter for the same classical strength, they are expected to fall to a smaller quantum computer than RSA.

What would a CRQC break?

Anything that uses RSA, Diffie-Hellman or elliptic curves for key establishment or signatures: TLS key exchange and certificates, SSH, IPsec and most VPNs, code, package, container and firmware signing, S/MIME and PGP, and secure boot chains that verify firmware with keys fixed in hardware. NIST's 2016 impact table lists RSA, ECDSA and ECDH as "no longer secure".

What would it not break, and how much does Grover matter?

Symmetric ciphers and hashes lack the periodic structure Shor exploits. The best generic quantum attack is Grover's search, which finds a marked item among N in roughly the square root of N steps. Against a 128 bit key, that turns about 2 to the 128 trials into about 2 to the 64 Grover iterations.

That is less alarming than it sounds. The iterations run one after another on an error corrected machine, parallelise poorly, and each one evaluates the whole cipher. And NIST's draft IR 8547 says approved symmetric primitives with at least 128 bits of classical security are believed to meet Category 1, the lowest of its five post-quantum strength categories, which is itself defined by key search on AES-128. The same draft says NIST's few 112 bit symmetric standards will be disallowed in 2030 anyway.

NIST's 2016 report took the conservative view that AES needs larger keys and SHA-2 and SHA-3 larger outputs, not replacement. The NSA applies that view to national security systems: CNSA 2.0 requires AES-256 and SHA-384 or SHA-512.

For more on the symmetric side, see does quantum computing break AES-256.

What is "harvest now, decrypt later", and why does it make the problem urgent today?

In a TLS 1.3 handshake, both sides use ephemeral elliptic curve Diffie-Hellman to agree a session key, then encrypt traffic with AES or ChaCha20. Anyone who records the handshake and ciphertext today can store it, run Shor's algorithm on the key exchange later, recover the session key and read everything.

The CISA, NSA and NIST factsheet calls this a "catch now, break later or harvest now, decrypt later" operation and warns that attackers may be collecting data today that still needs protection in the future. The risk depends on secrecy lifetime. A session token that expires in an hour is not worth harvesting; health records, trade secrets, long lived credentials and personal data that stays sensitive for decades are.

Every agency timeline rests on simple addition: how long the data must stay secret plus how long migration takes. If that exceeds the time to a CRQC, you are already late, and NIST's 2016 report notes that deploying today's public key infrastructure took almost two decades.

Signatures differ: forging one needs a CRQC at that moment, so nothing is harvested. The urgency is lifetime: a firmware signing key in boot ROM or a twenty year root certificate will still be trusted when a CRQC might exist. That is why the NSA put software and firmware signing first in CNSA 2.0, and why the NCSC's 2028 milestone calls out long lived hardware roots of trust. Key exchange is urgent because of data you send today; signatures because of devices you ship today.

What did NIST standardise, and what does each algorithm do?

NIST's open process began in 2015. Its August 2024 release says it assessed 82 algorithms from 25 countries, selected four in 2022, released drafts in 2023 and published three final standards on 13 August 2024, with a fourth, based on FALCON, planned as FN-DSA.

FIPS 203: ML-KEM for key establishment

ML-KEM, derived from CRYSTALS-Kyber, is a key encapsulation mechanism. One side publishes an encapsulation key; the other uses it to produce a ciphertext and a 32 byte shared secret; the first side decapsulates to recover the same secret. FIPS 203 ties its security to the Module Learning with Errors problem: recovering a secret from linear equations with small random errors added, a lattice problem with no known efficient quantum attack. Its three parameter sets, ML-KEM-512, 768 and 1024, run "in order of increasing security strength and decreasing performance". ML-KEM-768 is the common internet default; CNSA 2.0 requires ML-KEM-1024.

FIPS 204: ML-DSA for general purpose signatures

ML-DSA, derived from CRYSTALS-Dilithium, is the lattice based general replacement for RSA and ECDSA signatures in certificates, code signing and protocols. FIPS 204 defines ML-DSA-44, 65 and 87. CNSA 2.0 requires ML-DSA-87 and allows it for any signature use, including firmware.

FIPS 205: SLH-DSA, the conservative hash based backup

SLH-DSA is based on SPHINCS+. Its security rests only on hash functions, an older and better understood foundation than lattices. The cost is large, slow signatures, which suits rarely used, long trusted keys such as roots and firmware. It is stateless, unlike LMS and XMSS (NIST SP 800-208), which CNSA 2.0 approves for firmware and software signing but which require careful tracking of one time key state.

HQC: a backup KEM built on different mathematics

On 11 March 2025 NIST picked HQC, a code based KEM built on error correcting codes, as a backup for ML-KEM because it "is based on different math than ML-KEM", which matters if lattices ever show a weakness. NIST said HQC needs more computing resources, planned a draft in about a year and expects a final standard in 2027. It also told organisations to keep migrating to the 2024 standards rather than wait.

Why the sizes matter

The bridge from mathematics to operations is size. Post-quantum keys and signatures are far larger than elliptic curve ones, which affects packets, handshakes, certificate chains, firmware images and constrained devices.

Key exchange grows by about a kilobyte each way, which most networks absorb. Signatures are harder: a certificate chain carries several keys and signatures, so moving the web PKI to ML-DSA adds kilobytes to every new connection. The NCSC names the web PKI as an area where migration will be harder than a simple swap, which is a large part of why key exchange is moving first.

What deadlines have NIST, the NSA, CISA and the NCSC set?

NIST IR 8547: deprecated after 2030, disallowed after 2035

NIST's IR 8547 initial public draft (12 November 2024, comments closed 10 January 2025) lists ECDSA, EdDSA, RSA and finite field and elliptic curve key establishment as deprecated after 2030 at the 112 bit level and "disallowed after 2035" at every level. In NIST's terms, deprecated means the algorithm may still be used but carries risk the user must accept; disallowed means it is no longer allowed for the stated purpose. The draft ties 2035 to National Security Memorandum 10. It was still a draft in the version fetched for this post, so treat its dates as NIST's stated direction. They bind US federal systems; everyone else will feel them through vendors, auditors and customers.

NSA CNSA 2.0: national security systems first

The NSA's September 2022 advisory said CNSA 2.0 "will effectively deprecate the use of RSA, Diffie-Hellman (DH), and elliptic curve cryptography" once mandated. The current FAQ lists the suite:

The 2022 advisory set prefer by and exclusive by targets per category: software and firmware signing 2025 and 2030; browsers, servers and cloud 2025 and 2033; VPNs and routers 2026 and 2030; operating systems 2027 and 2033; niche equipment and large PKI 2030 and 2033; custom and legacy systems replaced by 2033.

FAQ version 2.2 (October 2026) adds firmer dates from the updated CNSSP 15: CNSA 2.0 required in all new national security acquisitions from 1 January 2027; equipment that cannot support it phased out by 31 December 2030 unless excepted; CNSA 2.0 mandated by 31 December 2031. The NSA says it sets no requirements outside national security systems, though its requirements may serve as guidance. If you sell into US defence, these are your dates; if not, they show where vendor roadmaps are heading.

CISA, NSA and NIST: build a quantum readiness roadmap

The joint factsheet of 21 August 2023 tells organisations to form a project team, run cryptographic discovery, inventory quantum vulnerable systems, assess risk with data lifetime in mind, and ask vendors for their roadmaps. It names systems that create and validate signatures, including software and firmware updates, as assets to inventory, and notes that organisations are often unaware how widely their products depend on public key cryptography.

UK NCSC: 2028, 2031, 2035

The NCSC's timelines (20 March 2025) set three milestones. By 2028: define goals, complete discovery and build an initial plan, including supplier dependencies and long lived hardware roots of trust. By 2031: finish the highest priority migrations. By 2035: complete migration of all systems, services and products, accepting a tail of harder technologies.

How does hybrid key exchange work in TLS?

The fastest progress is in TLS key exchange, and it is hybrid: client and server run classical ECDHE and ML-KEM together and combine the results. RFC 9954 (July 2026) states the goal as security "even if a way is found to defeat the encryption for all but one of the component algorithms". If ML-KEM has a flaw, X25519 still protects against today's attackers; if a CRQC arrives, ML-KEM still protects the session.

RFC 10024 (August 2026, Proposed Standard) defines X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024 for TLS 1.3. In its IANA registrations, only X25519MLKEM768 is marked Recommended. Its client share is the ML-KEM-768 encapsulation key followed by the X25519 share, 1,216 bytes; the server returns an ML-KEM ciphertext plus its X25519 share, 1,120 bytes. The RFC notes the share order is reversed relative to RFC 9954's convention for historical reasons, and it requires the FIPS 203 encapsulation key check and the usual elliptic curve validity checks, aborting the handshake if either fails.

Hybrid TLS fixes harvest now, decrypt later for that connection. It does not change authentication: the certificate and handshake signature stay RSA or ECDSA. The walkthrough below shows exactly that, a post-quantum group next to an ECDSA signature. That is the right order of work, but turning on hybrid TLS is the start of migration, not the end. For deeper protocol trade offs, see should you use hybrid post-quantum key exchange.

The NSA's FAQ takes a different line for its own systems: it will not require hybrid products, warns they add complexity, and says something marketed as hybrid is not necessarily quantum resistant in CNSA terms. Hybrid is a hedge for the general internet; pure ML-KEM-1024 is the NSA's rule for systems it governs.

Is quantum key distribution an alternative?

Quantum key distribution (QKD) is often confused with post-quantum cryptography. QKD uses physics, usually single photons over fibre or free space, to deliver a symmetric key so that eavesdropping disturbs the signal. Post-quantum cryptography is new mathematics running on ordinary computers.

The NSA FAQ says QKD's sole function is distributing keys, making it only one part of a cryptographic system, and that the NSA "does not generally consider QKD a practical security solution" for national security systems. The NCSC's August 2025 white paper makes the core objection: QKD provides no authentication, so it must be combined with other cryptography and should not be relied on for substantial security value. The NCSC will not support QKD for government or military use.

Why is a cryptographic inventory the first step?

Every agency puts discovery first because cryptography is not one system. It sits in TLS terminators, load balancers, service meshes, databases, SSH, VPNs, signing pipelines, HSMs, identity providers, firmware, mobile apps and your own code, mostly through a few libraries that arrived as dependencies rather than decisions. For each item, record the algorithm and parameter set, where it is used, which library or device implements it, who owns it, and how long the data or trust it protects must last. The last field turns an inventory into a priority list.

What is a CBOM?

CycloneDX added a Cryptography Bill of Materials (CBOM) so cryptographic assets can be recorded alongside software components. Its CBOM page says it can represent "algorithms, keys, certificates, and their relationships to software components". In the CycloneDX 1.6 schema, a component of type cryptographic-asset carries cryptoProperties with an assetType of algorithm, certificate, protocol or related-crypto-material. Algorithm entries record the primitive (such as kem, signature, key-agree or block-cipher), parameter set, functions used (keygen, encapsulate, sign and others), classical security level and a NIST quantum security level from 0 to 6. An SBOM tells you a service ships a given TLS library version; a CBOM tells you which algorithms it negotiates and which certificates it presents. You need both. More detail: the cryptographic bill of materials (CBOM).

Step by step: find where your cryptography stands

These commands are read only and change no keys or configuration. Run them only against systems you own or are authorised to test, and replace your-server.example with your own hosts.

1. Check what your crypto library supports

A TLS stack can only negotiate what its library implements. With OpenSSL 3:

openssl version
openssl list -kem-algorithms
openssl list -signature-algorithms | grep -Ei 'ml-dsa|slh-dsa'

A build with post-quantum support lists ML-KEM-768, the hybrid groups X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024, and ML-DSA and SLH-DSA signature variants. If they are missing, that host cannot negotiate post-quantum key exchange however it is configured.

2. Test whether a TLS endpoint negotiates hybrid key exchange

openssl s_client -connect your-server.example:443 \
  -groups X25519MLKEM768 -brief </dev/null 2>&1 | \
  grep -E 'Protocol version|Negotiated TLS1.3 group|Signature type'

On a server that supports it, the output looks like this:

Protocol version: TLSv1.3
Signature type: ecdsa_secp256r1_sha256
Negotiated TLS1.3 group: X25519MLKEM768

Read the lines together. The group is hybrid post-quantum, so recorded traffic is protected against harvest now, decrypt later. The signature is still classical ECDSA, so authentication has not migrated. A failed handshake or a different group means the server, or a middlebox in front of it, does not support the hybrid group yet. Run the test through the same proxies and load balancers your users go through.

3. Check SSH key exchange

ssh -V
ssh -Q kex | grep -E 'mlkem|sntrup'
ssh -G your-server.example | grep -i '^kexalgorithms'

If mlkem768x25519-sha256 or sntrup761x25519-sha512 is supported but missing from what you offer, a KexAlgorithms override may be pinning you to classical methods. On servers, sshd -T | grep -i kexalgorithms as root shows the effective list. Host and user keys are signatures and stay classical for now.

4. Inventory certificates and their algorithms

openssl s_client -connect your-server.example:443 -servername your-server.example \
  </dev/null 2>/dev/null | openssl x509 -noout -text | \
  grep -E 'Public Key Algorithm|Public-Key|Signature Algorithm|Not After' | sort -u

For files, use openssl x509 -in cert.pem -noout -text with the same filter. Flag long lived roots and intermediates, code signing certificates and any key embedded in devices or firmware.

5. Find cryptography in your own code

rg -n -g '!node_modules' -g '!vendor' \
  -e 'RSA|ECDSA|secp256|prime256v1|X25519|Ed25519|DiffieHellman|ECDH' \
  -e 'generateKeyPair|GenerateKey|KeyPairGenerator|createSign|createECDH' . \
  > crypto-callsites.txt

Treat hits as leads: confirm the runtime algorithm, whether it is configurable, and what data it protects. Code that reads its algorithm from configuration can migrate with a deployment; hard coded choices need a release.

6. Find the crypto libraries in your dependency tree

Given a CycloneDX SBOM in JSON, list common crypto libraries and versions:

jq -r '.components[]? | select(.name | test("openssl|boringssl|libressl|wolfssl|bouncycastle|bcprov|cryptography|pycryptodome|libsodium|tink|golang.org/x/crypto|ring|rustls|node-forge|jose"; "i")) | "\(.name)\t\(.version)"' sbom.cdx.json | sort -u

This shows which projects must reach a post-quantum capable library version. It does not show which algorithms they use; steps 2 to 5 do that.

7. Record findings as a CBOM and rank them

A minimal CycloneDX 1.6 fragment for the hybrid TLS group on one service:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "cryptographic-asset",
      "bom-ref": "crypto/algorithm/ml-kem-768",
      "name": "ML-KEM-768",
      "cryptoProperties": {
        "assetType": "algorithm",
        "algorithmProperties": {
          "primitive": "kem",
          "parameterSetIdentifier": "768",
          "cryptoFunctions": ["keygen", "encapsulate", "decapsulate"],
          "nistQuantumSecurityLevel": 3
        },
        "oid": "2.16.840.1.101.3.4.4.2"
      }
    },
    {
      "type": "cryptographic-asset",
      "bom-ref": "crypto/protocol/tls13-api-gateway",
      "name": "TLS 1.3 on api-gateway",
      "cryptoProperties": {
        "assetType": "protocol",
        "protocolProperties": {
          "type": "tls",
          "version": "1.3",
          "cryptoRefArray": ["crypto/algorithm/ml-kem-768"]
        }
      }
    }
  ]
}

The object identifier is the one OpenSSL reports for ML-KEM-768. Add the X25519 half and the ECDSA certificate so the record shows what has not migrated. Then sort by data lifetime and trust lifetime: long lived confidential traffic gets hybrid key exchange first, long lived signing keys get a signature plan next, short lived data behind short lived keys goes last.

How should you decide what to migrate first?

Where Safeguard fits, honestly

Safeguard is a software supply chain security platform, not a cryptographic discovery tool, and its fit here is indirect. It does not discover which algorithms your services negotiate, does not build a CBOM of algorithms, keys and certificates, and does not migrate your cryptography. Steps 2 to 5 and 7 are your work or a dedicated discovery tool's.

The overlap is the libraries. Post-quantum support arrives as new versions of TLS libraries, SSH implementations, crypto packages and base images, and old versions carry ordinary vulnerabilities too. Safeguard generates SBOMs in SPDX and CycloneDX formats and scans repositories, container images and SBOM files [GA], matches components against vulnerability databases with EPSS and KEV enrichment [GA], and shows which projects contain a given component and version. That answers step 6 at scale. Policies and gates [GA] can stop a build that pins an old library version from shipping again.

Common mistakes

• Treating bigger RSA or ECC keys as a quantum fix. Shor scales polynomially; the fix is new algorithms.
• Panicking about AES. Grover does not break it. Use AES-256 where policy such as CNSA 2.0 requires it.
• Calling hybrid TLS "done". It protects confidentiality only. Certificates and signatures are still classical.
• Swapping algorithms before taking inventory. Cryptography hides in dependencies, appliances and vendor services you never chose.
• Ignoring signing keys in hardware. Boot chain and firmware keys outlive their assumptions; the NSA and NCSC both prioritise them.
• Buying QKD as a post-quantum strategy. It lacks authentication and is not endorsed by the NSA or NCSC for government use.
• Forgetting middleboxes. An older proxy or load balancer negotiates classical groups even when both endpoints support hybrid ones.

FAQ

Can quantum computers break encryption today?

No publicly known quantum computer can break RSA or elliptic curve cryptography today. The concern is a future CRQC, and data recorded now that must stay secret until then.

What encryption will quantum computers break?

Public key algorithms based on factoring or discrete logarithms: RSA, Diffie-Hellman, DSA, ECDH, ECDSA and EdDSA, which protect key exchange and signatures in TLS, SSH, VPNs and code signing.

Is AES-256 quantum safe?

As far as anyone knows, yes. Grover's algorithm only gives a square root speedup, leaving AES-256 a large margin. CNSA 2.0 requires it for US national security systems.

What is harvest now, decrypt later?

Recording encrypted traffic today and decrypting it once a quantum computer can break the key exchange. It threatens data that must stay confidential for many years.

What are ML-KEM, ML-DSA and SLH-DSA?

NIST's first post-quantum standards, published 13 August 2024: ML-KEM (FIPS 203) for key establishment, ML-DSA (FIPS 204) for general signatures and SLH-DSA (FIPS 205) as a hash based signature backup.

What is HQC and do I need it?

A code based KEM NIST selected on 11 March 2025 as a backup for ML-KEM, with a final standard expected in 2027. Keep migrating to ML-KEM now.

When do organisations have to migrate to post-quantum cryptography?

NIST's draft disallows quantum vulnerable public key algorithms after 2035. The NSA requires CNSA 2.0 in new national security acquisitions from 1 January 2027. The NCSC targets 2028, 2031 and 2035.

Is hybrid post-quantum TLS safe to turn on?

RFC 10024 standardised the hybrid groups in August 2026 and recommends X25519MLKEM768. Test through every proxy and load balancer first; older middleboxes cause most failures.

Is quantum key distribution better than post-quantum cryptography?

Not for general use. QKD only distributes keys, needs dedicated hardware and lacks authentication. The NSA and NCSC do not endorse it for government systems.

Where do I start a post-quantum migration?

With a cryptographic inventory of algorithms, libraries, certificates, keys, protocols and owners, ranked by how long the data and trust must last. CycloneDX CBOM is one format for recording it.

Fix it without waiting for upstream

Post-quantum migration happens mostly through dependency upgrades: new versions of TLS libraries, SSH implementations, crypto packages and base images, each of which also carries ordinary vulnerabilities on its own schedule. The section below covers that dependency side; it does not change which algorithms your services negotiate, which remains inventory and configuration work.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

To try it on your own machine, download Safeguard from https://safeguard.sh/download and see the CLI documentation at https://docs.safeguard.sh/docs/cli .

See how Safeguard would help

The first demo sets up Safeguard's local runner on your own machine, approves it with a device code, and runs a scan from the terminal. Pointed at a service repository or a base image, the same flow lists the TLS and crypto library versions it ships, which is the dependency half of step 6 above; it does not show which algorithms the service negotiates.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session: asked to fix a lodash CVE, it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. Moving a project to a crypto library release with post-quantum support follows the same pattern of a reviewed dependency bump, tested before anything is pushed.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. With that connection you can ask which projects carry a particular TLS or crypto library version while keeping control of what the assistant can touch.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Peter W. Shor, Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer, arXiv quant-ph/9508027
• Lov K. Grover, A fast quantum mechanical algorithm for database search, arXiv quant-ph/9605043
• NIST IR 8105: Report on Post-Quantum Cryptography, April 2016 (PDF)
• NIST: NIST Releases First 3 Finalized Post-Quantum Encryption Standards, 13 August 2024
• NIST CSRC: FIPS 203, ML-KEM and full text (PDF)
• NIST CSRC: FIPS 204, ML-DSA and full text (PDF)
• NIST CSRC: FIPS 205, SLH-DSA and full text (PDF)
• NIST: NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption, 11 March 2025
• NIST CSRC: IR 8547 initial public draft and full text (PDF)
• NSA: Announcing the Commercial National Security Algorithm Suite 2.0, advisory PP-22-1338 (PDF)
• NSA: CNSA Suite 2.0 and Quantum Computing FAQ, version 2.2, October 2026 (PDF)
• CISA, NSA and NIST: Quantum-Readiness: Migration to Post-Quantum Cryptography, 21 August 2023 and factsheet (PDF)
• UK NCSC: Timelines for migration to post-quantum cryptography, 20 March 2025
• UK NCSC: Quantum security technologies white paper, 5 August 2025
• IETF: RFC 9954, Hybrid Key Exchange in TLS 1.3
• IETF: RFC 10024, Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3
• CycloneDX: Cryptography Bill of Materials (CBOM)
• CycloneDX: bom-1.6 JSON schema

Last reviewed: 23 October 2026.