Products Cryptographic assurance

PQC

Post-quantum cryptography migration

Find every key a quantum computer would break and replace them in order.

FIPS 203, 204 and 205 standardise ML-KEM, ML-DSA and SLH-DSA. GraphAtlas inventories where an organisation relies on quantum-vulnerable cryptography, orders the migration by dependency, prices the size cost of the new keys and signatures, and tests implementations against the known-answer vectors.

Try the calculation Request a walkthrough

Verification: 10 statements. 3 proved, 1 certified, 6 tested.

Regime: FIPS 203, 204 and 205, NIST IR 8547, and the EU and UK migration timelines
Set by: National Institute of Standards and Technology
European Commission and the European Supervisory Authorities
Built for: Security architecture
Platform and PKI teams
Compliance
Version: 1.4

Try it

Run it on sample data

Move the quantum date, or choose whose dates apply, and watch the order change. Open a row to change what a use protects, how long its move takes or what it moves to. Then check the sizes in the second figure against the tables of the standards.

Fig. 1 Order of migration for the keys and signatures of an illustrative insurer

Verifying receipt

The assumptions

Planning year

Years until a quantum computeryears

An assumption, not a forecast. Nobody knows this year, so move it and watch the order.

Whose dates apply

The EU roadmap, version 1.1. High risk uses by the end of 2030 and the rest by the end of 2035, with the risk level taken from the four rules of its section 5.

Uses already late

9 uses change. 3 are already late, 1 has to start in 2026 and 5 have time. 2 uses do not change, because their algorithms survive a quantum computer.

The uses that change, in the order they must start, with the year to start by and the year to finish by. Uses that do not change follow.
Use	Start byDates	Finish by	Bytes on the wire
RSA-2048 → ML-KEM-768	2012Late by 14 yearsLate by 14 yFinish by 2015quantum date	2015quantum date	256 B → 1,088 B
RSA-3072 → ML-KEM-768	2020Late by 6 yearsLate by 6 yFinish by 2024a later use	2024a later use	384 B → 1,088 B
RSA-3072 → ML-DSA-65	2025Late by 1 yearLate by 1 yFinish by 2028quantum date	2028quantum date	768 B → 5,261 B
ECDH P-256 → SecP256r1MLKEM768	2026Start nowStart nowFinish by 2028quantum date	2028quantum date	130 B → 2,402 B
ECDSA P-256 → ML-DSA-65	2028In 2 yearsIn 2 yFinish by 2030quantum date	2030quantum date	129 B → 5,261 B
ECDSA P-384 → ML-DSA-65	2030In 4 yearsIn 4 yFinish by 2032quantum date	2032quantum date	193 B → 5,261 B
X25519 → X25519MLKEM768	2031In 5 yearsIn 5 yFinish by 2032quantum date	2032quantum date	64 B → 2,336 B
ECDSA P-256 → ML-DSA-65	2034In 8 yearsIn 8 yFinish by 2035EU date	2035EU date	129 B → 5,261 B
Ed25519 → ML-DSA-65	2035In 9 yearsIn 9 yFinish by 2035EU date	2035EU date	96 B → 5,261 B
Audit log hash chainSHA-256, which a quantum computer does not break	No change		–
Database encryption at restAES-256, which a quantum computer does not break	No change		–

From the latest start to the latest finish Starts before 2026 A government date The quantum date, 2041

Each bar is drawn from 2026 on the left to 2041 on the right. Open a row to see how its dates were reached, and to change what it protects.

A second routine, which builds no order

It finds each date by pulling uses earlier until none moves, then compares them with the plan above, together with the exposure, the order and every sum of bytes. It does not read the plan to find the answer.

Fig. 2 Sizes of keys, ciphertexts and signatures, worked out from the formulas of the standards and set beside what they print

Verifying receipt

Family

FIPS 203. Takes the place of the key exchange of RSA and elliptic curves. A sender wraps a secret under the encapsulation key of the receiver, and the receiver opens the ciphertext with the decapsulation key.

Open a row to see the arithmetic with its own numbers, and where the standard prints the result.

Sizes worked out, and equal to the standard

48 of 48

Every size that the formulas give is the size that the standard prints. 33 are printed in a table and 15 in the sentence of the text that gives them.

FIPS 203: each size in bytes, worked out from the formulas of the standard
Set	Encapsulation key	Decapsulation key	Ciphertext	Shared secret
Security category 1	800 agrees with the standard	1,632 agrees with the standard	768 agrees with the standard	32 agrees with the standard
Security category 3	1,184 agrees with the standard	2,400 agrees with the standard	1,088 agrees with the standard	32 agrees with the standard
Security category 5	1,568 agrees with the standard	3,168 agrees with the standard	1,568 agrees with the standard	32 agrees with the standard

All sizes are in bytes. A tick means the number worked out from the formula is the number the standard prints.

Inputs and outputs

What goes in. What comes out

The plate runs a slice of the engine. This is the whole shape of it.

What goes in

Inventory: Each place a key or a signature is used. For each one, the algorithm, what it is for, how many years what it protects must stay secret and how many years the move takes.
What waits for what: The uses that must be finished before another can start, such as a root authority before the authorities that it signs.
Years until a quantum computer: An assumption of yours. Nobody can supply it, so the plan is drawn for the value you give it.
Whose dates apply: None, the US federal dates, the EU roadmap or the UK timeline. The plan keeps the earlier of the date of the rule and the date that the quantum assumption allows.

What comes out

Order of migration: Every use that changes, with the year it must start, the year it must finish and what set each date.
Late, now and planned: How many uses are already behind, must start in the planning year or have time.
Reasons: For each use, the rules and the waiting that fixed its dates, each in a sentence.
Bytes on the wire: What a replacement adds to a key exchange, a wrapped key or a signature, from the sizes that the standards give.
Receipt: A hash of the dates, the sizes, the inventory and the plan. Anyone can recompute it.

What the plate covers

In the plate above

An inventory of eleven uses, with the order of migration under each of the four calendars.
The size of every key, ciphertext and signature that the plan moves to, beside the table that prints it.
A second routine that checks the plan without building an order, and a button that breaks the plan to show that it refuses.

In the licensed engine, not the plate

Finding the keys. The plan starts from an inventory that you have already made.
Testing an implementation against the known-answer vectors of the standards. The product does this and the plate does not.
Whether a replacement is approved for your hardware, your certificates or your protocol. The vendors and the standards bodies say that, and they change.
The dates of other countries, and the rules of a sector that sit on top of those of a government.
The cost and the effort of a move, which the plan takes as the years you give it.

Clause map

Every rule has an address

Each row names the clause, the function that carries it and the statements that check it. A test opens each file and confirms the function exists.

Rules of the regulation, the code that carries each one and the statements that check it
Reference	Rule	Carried by	Checked by
FIPS 203, Tables 2 and 3	An ML-KEM encapsulation key is 384k + 32 bytes, a decapsulation key 768k + 96 and a ciphertext 32(du × k + dv), where k, du and dv belong to the parameter set.	`mlKemSizes` src/kernel/pqc.ts	Tested PQ-05
FIPS 204, Tables 1 and 2	The size of an ML-DSA key and signature follows from the parameters k, l, eta, d, lambda, gamma1 and omega, with the lengths of the bit strings that Algorithms 22, 24 and 26 write.	`mlDsaSizes` src/kernel/pqc.ts	Tested PQ-05
FIPS 205, Equations 5.1 to 5.4	A WOTS+ signature is len chains of n bytes, and len is the sum of two lengths worked out in whole numbers.	`wotsLength` src/kernel/pqc.ts	Tested PQ-05
FIPS 205, Section 3.1, Algorithm 20 and Table 2	An SLH-DSA public key is 2n bytes and a private key 4n. A signature is n bytes for the randomizer, k(1 + a) for the FORS part, h for the tree and d × len for the chains.	`slhDsaSizes` src/kernel/pqc.ts	Tested PQ-05
RFC 10024, Sections 4.1 to 4.3	A hybrid key share is the elliptic curve share and the ML-KEM key or ciphertext, side by side, so each side of a TLS 1.3 exchange sends both.	`hybridSizes` src/kernel/pqc.ts	Tested PQ-05 Tested PQ-09
NIST IR 8547, Section 3	A use is exposed when the years to keep it secure plus the years to migrate exceed the years until a quantum computer. It must start no later than the year that leaves room for both.	`plan` src/kernel/pqc.ts	Proved PQ-01 Tested PQ-07
NIST IR 8547, Section 4, Tables 2 and 4	Quantum-vulnerable public-key algorithms are deprecated after 2030 and disallowed after 2035. Key establishment, signatures and the most sensitive systems have earlier dates.	`dueDate` src/kernel/pqc.ts	Tested PQ-06
EU roadmap, Section 5	A use is at least medium risk when it protects confidentiality or takes more than eight years to migrate. It is high risk when its impact is high and it keeps confidentiality for ten years or more or takes more than eight years to migrate.	`euRisk` src/kernel/pqc.ts	Proved PQ-02 Tested PQ-06
EU roadmap, Sections 4.1 and 4.2	High-risk uses migrate by the end of 2030 and the rest by the end of 2035.	`dueDate` src/kernel/pqc.ts	Tested PQ-06
NCSC timeline, the key milestones	The highest-priority migration is done by 2031, and everything by 2035.	`RULES` src/kernel/pqc.ts	Tested PQ-06
Planning rule of this product, latest finish	A use that others wait for must finish before the earliest of them can start, so a late use makes every use it waits for late too.	`plan` src/kernel/pqc.ts	Proved PQ-03
Planning rule of this product, order	The uses that change are listed once, by latest start, with key establishment before signatures when two tie and never before a use that must be done first.	`plan` src/kernel/pqc.ts	Tested PQ-08
FIPS 203 Table 3, FIPS 204 Table 2 and RFC 10024	What a replacement adds on the wire is the sum of the sizes the standards give, and a use whose algorithm survives a quantum computer adds nothing.	`wireBefore` src/kernel/pqc.ts	Tested PQ-09
Receipt of a plan	A second routine takes the date of each use on its own, lets each use pull the ones it waits for earlier until nothing moves, and confirms every date, the order and every sum of bytes.	`checkPlan` src/kernel/pqc.ts	Certified PQ-04
Receipt of a plan, what it covers	The receipt covers the dates, the thresholds, the sizes, the inventory and the plan. It does not change with a name or with the order of the inventory.	`pqcReceiptPayload` src/kernel/pqc.ts	Tested PQ-10

Verification

What we claim, and how it is checked

Every statement is registered, and each says which level of assurance it has earned. The ladder is explained on the verification page.

Proved

True for every input.

PQ-01

When only the quantum computer sets the date, the latest start is the years until it arrives less the years to keep the data secure and the years to migrate. Nothing later keeps the data safe, and the use is late exactly when those two add up to more than the years until it arrives.

3 checks, decided by Z3 5.3.3.0 (WebAssembly) and rerun from the emitted file by Z3 5.3.3 (native) and cvc5 1.4.2 (native, nl-cov). 4 broken variants are refuted. proofs/smt2/PQ-01.smt2
PQ-02

A use is at least medium risk under the EU roadmap exactly when it protects confidentiality or takes more than eight years to migrate. It is high risk exactly when it has a high impact and either protects confidentiality for ten years or more or takes more than eight years to migrate.

3 checks, decided by Z3 5.3.3.0 (WebAssembly) and rerun from the emitted file by Z3 5.3.3 (native) and cvc5 1.4.2 (native, nl-cov). 6 broken variants are refuted. proofs/smt2/PQ-02.smt2
PQ-03

A use that others wait for finishes no later than it would alone and no later than any of them can start, and no later finish does both. It starts strictly earlier than each of them, so a use that is late makes every use it waits for late too.

8 checks, decided by Z3 5.3.3.0 (WebAssembly) and rerun from the emitted file by Z3 5.3.3 (native) and cvc5 1.4.2 (native, nl-cov). 4 broken variants are refuted. proofs/smt2/PQ-03.smt2

Certified

True for the case in hand, with evidence anyone can recheck.

PQ-04

A migration plan is accepted by a second method that builds no order. It starts from the date each use has on its own, lets every use pull the ones it waits for earlier until no date moves, and then confirms every date, the exposure, the order and every sum of bytes. A plan with one figure changed, two uses swapped or a use placed before one it waits for is refused.

tests/kernel/pqc.test.tssrc/kernel/pqc.ts

Tested

True on every input we tried.

PQ-05

Every key, ciphertext and signature size of ML-KEM, ML-DSA and SLH-DSA is derived from the formulas of FIPS 203, 204 and 205 and equals the size that the standard prints, in a table or in the sentence that gives it. That covers the three ML-KEM sets, the three ML-DSA sets and the six rows of Table 2 of FIPS 205. The hybrid key shares of TLS 1.3 are derived from RFC 10024 and equal the sizes it writes.

tests/kernel/pqc.test.ts
PQ-06

The dates are those of NIST IR 8547, the EU roadmap and the NCSC timeline, at every boundary they set, and the EU risk level follows the four rules of its section 5, including the difference between nine years of confidentiality and ten and between a migration of eight years and nine.

tests/kernel/pqc.test.ts
PQ-07

A use is exposed exactly when the years to keep it secure plus the years to migrate exceed the years until a quantum computer. It is late when its latest start is before the planning year, and a quantum computer that is further away never makes a use start earlier.

tests/kernel/pqc.test.ts

Show the other 3 Show fewer

PQ-08

Every use that changes is listed once, in order of its latest start, key establishment first when two tie, and never before a use it waits for. A use never starts later than it could on its own, and the same inventory written in another order gives the same plan.

tests/kernel/pqc.test.ts
PQ-09

What a replacement adds on the wire is the sum of sizes that the standards give: both key shares for a hybrid exchange, the ciphertext for a wrapped key, and the signature with the public key for a signature. A use whose algorithm survives a quantum computer has nothing to send.

tests/kernel/pqc.test.ts
PQ-10

The receipt of a plan covers the dates, the thresholds, the sizes, the inventory and every figure of the plan. It changes when any input changes, and it does not change with a name or with the order in which the inventory is written.

tests/kernel/pqc.test.ts

Read the verification statement

Use it

The same call, anywhere

This sample is written from the input the plate starts with, so the code and the numbers cannot drift apart.

Call

import { plan, pqcReceiptPayload } from '@graphatlas/kernel/pqc';
import { receipt } from '@graphatlas/kernel/receipt';

// Each row is an id, an algorithm, a purpose, the years to keep it secure,
// the years to migrate, the impact, and the uses that must finish first.
const rows = [
  ['web-tls', 'x25519', 'key-establishment', 8, 2, 'other', []],
  ['partner-ssh', 'ecdh-p256', 'key-establishment', 12, 3, 'high', []],
  ['archive-keys', 'rsa-2048', 'key-establishment', 25, 4, 'high', []],
  ['hsm-kek', 'rsa-3072', 'key-establishment', 10, 5, 'high', []],
  ['ca-root', 'rsa-3072', 'signature', 12, 4, 'high', ['hsm-kek']],
  ['ca-issuing', 'ecdsa-p384', 'signature', 8, 3, 'other', ['ca-root']],
  ['mesh-mtls', 'ecdsa-p256', 'signature', 1, 2, 'other', ['ca-issuing']],
  ['app-signing', 'ecdsa-p256', 'signature', 10, 3, 'high', ['hsm-kek']],
  ['sso-tokens', 'ed25519', 'signature', 0, 1, 'other', []],
  ['db-at-rest', 'aes-256', 'encryption', 30, 1, 'other', []],
  ['audit-chain', 'sha-256', 'hash', 20, 1, 'other', []],
];

const uses = rows.map(
  ([id, algorithm, purpose, keepYears, migrateYears, impact, after]) => ({
    id, name: id, algorithm, purpose, keepYears, migrateYears, impact, after,
    replacement: null,
  }),
);
const input = { startYear: 2026, quantumYears: 15, framework: 'eu', uses };

const result = plan(input);
const hash = await receipt(pqcReceiptPayload(input, result));

Returns

const out = {
  quantumYear: 2041,
  late: 3,
  now: 1,
  planned: 5,
  unaffected: 2,
  order: [
    [1, 'archive-keys', 2012, 2015, 'late'],
    [2, 'hsm-kek', 2020, 2024, 'late'],
    [3, 'ca-root', 2025, 2028, 'late'],
    [4, 'partner-ssh', 2026, 2028, 'now'],
    [5, 'app-signing', 2028, 2030, 'planned'],
    [6, 'ca-issuing', 2030, 2032, 'planned'],
    [7, 'web-tls', 2031, 2032, 'planned'],
    [8, 'mesh-mtls', 2034, 2035, 'planned'],
    [9, 'sso-tokens', 2035, 2035, 'planned'],
  ],
  receipt: '275b51ecbf90735ecc07b07919b1bbf7c85f0c6b26a8fe072e6ea5d4960c41d2',
};

The call and the numbers come from the engine that built this page, run on the same input as the plate above. A replacement of null takes the default for the algorithm. Years are calendar years, and a start year before 2026 means that the use is already late.

Runs on

Browser
Edge
Node.js
Python
JVM
.NET
Excel
Command line
Container

Green surfaces are measured on every build of this site. Each must return the same receipt, bit for bit. The others are packaged targets that the build does not measure. How the platform works

Changes

When the rule moves, so does the engine

Publications that touch this regime, and the release that answered each.

27 Oct 2026

NIST Final text

Transition to post-quantum cryptography standards

Shipped as PQC 1.4, 3 days later

Open the full feed

PQC

What goes in

What comes out

What the plate covers

In the plate above

In the licensed engine, not the plate

Runs on

Transition to post-quantum cryptography standards

Bring us one book

Bring us
one book