Chapter 2 — Quantum and post-quantum security: current practice
Lesson map
Lesson 02 published. Map, example, EX006.
flowchart TD
N0["Learning outcomes"]
N1["2.1 Standards"]
N2["2.2 Transition guidance"]
N3["2.3 Deployment"]
N4["2.4 Worked case"]
N5["2.5 Practice task"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX006"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["2.1 Standards"]
N2["2.2 Transition guidance"]
N3["2.3 Deployment"]
N4["2.4 Worked case"]
N5["2.5 Practice task"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX006"]
[Learning outcomes]
|
v
[2.1 Standards]
|
v
[2.2 Transition guidance]
|
v
[2.3 Deployment]
|
v
[2.4 Worked case]
|
v
[2.5 Practice task]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX006]
Learning outcomes
You will (1) summarise the state of standards, guidance and deployment as of the source date; (2) distinguish final, draft and in-development documents; (3) describe how hybrid key exchange reached large-scale deployment; (4) evaluate national and sector guidance for applicability; and (5) maintain a living "state of practice" brief for an organization.
2.1 Standards
NIST's final standards are FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), published in August 2024, together with SP 800-208 for the stateful hash-based signatures LMS and XMSS. SP 800-227 gives recommendations for KEMs, including their composition. FN-DSA (FIPS 206, derived from Falcon) and a KEM standard based on HQC, selected in 2025 as a code-based backup to ML-KEM, were in development on the source date. Specialists should keep a dated register of each document's status, because procurement and audit language often cites drafts as if they were final.
2.2 Transition guidance
NIST's IR 8547 initial public draft (November 2024) proposes deprecating quantum-vulnerable public-key algorithms at 112-bit security after 2030 and disallowing quantum-vulnerable algorithms after 2035. CSWP 39 discusses crypto-agility considerations. The NCCoE's Migration to Post-Quantum Cryptography project publishes practice guides developed with industry. National agencies elsewhere publish their own roadmaps; their dates and algorithm preferences differ in detail. A specialist summarises the convergent message — inventory now, prioritise long-lived confidentiality, adopt hybrids during transition, plan signatures and PKI — and flags divergences relevant to the organization's jurisdictions.
2.3 Deployment
Hybrid key exchange in TLS moved from experiment to default in a few years. Chrome announced hybrid Kyber in 2023 (Chromium Blog); the standardised X25519MLKEM768 group (RFC 10024) followed in major browsers, CDNs and TLS libraries. Post-quantum authentication lags: ML-DSA certificates require CA, browser and policy changes, and their size (Chapter 5) is a real engineering cost. IKEv2 supports additional key exchanges via RFC 9370, and vendor support varies. Terminology for hybrids is set by RFC 9794.
2.4 Worked case
NRHT's state-of-practice brief, one page, dated: final standards (FIPS 203/204/205, SP 800-208); drafts (IR 8547 dates); in development (FN-DSA, HQC); deployment (hybrid TLS widely available in browsers and CDNs; NRHT's PACS cloud reader already negotiates X25519MLKEM768; VPN appliances: vendor A supports RFC 9370 in current firmware, vendor B "roadmap 2027"); gaps (no public CA issuing ML-DSA certificates for the web PKI at scale; medical-device vendors mostly silent). The brief is reviewed quarterly and every claim has a link.
Assign an owner to each line of the brief and a date for its next check. When a status changes, such as a draft being finalised, update the line and keep the previous version so readers can see what changed. The brief then becomes evidence in its own right for auditors.
2.5 Practice task
Write your organization's (or NRHT's) state-of-practice brief. Mark each item final, draft, in development or vendor claim.
Keep the brief to one page with a date at the top and a link beside every claim. Include at least one item from each category, and add a column for what each item means for the organization. Ask a colleague to check that no draft is described as final and that every vendor claim is labelled as a claim. Set a date for the next quarterly review before you file it.
2.6 Common errors and limits
- Citing draft dates as mandates.
- Assuming web deployment status applies to VPNs, devices or PKI.
- Briefs without dates, which age silently.
Each error has a guard in NRHT's brief: a status label on every document, separate lines for web, VPN, PKI and devices, and a date at the top with a quarterly review. When citing IR 8547, quote its draft status in the same sentence as its dates. Treat any vendor statement as a claim until it is observed in operation.
Exercises
- EX006 — Status register. Classify FIPS 203, IR 8547, FIPS 206, SP 800-227 and RFC 10024 by status on 12 October 2026. Rubric: 3 = five correct with sources.
- EX007 — Convergent message. Summarise in four bullets the advice on which major guidance converges. Rubric: 3 = inventory, prioritisation, hybrids, PKI planning.
- EX008 — Lag analysis. Explain why post-quantum authentication lags key exchange in TLS deployment. Rubric: 3 = HNDL urgency asymmetry, ecosystem coordination, size.
- EX009 — Vendor claim. NRHT's vendor B says "PQC-ready". Write three questions that turn this into checkable claims. Rubric: 3 = algorithm/parameter, protocol/standard, date/version.
- EX010 — Jurisdiction. NRHT operates under two national authorities whose roadmaps differ by three years for deprecation. How should the programme set its internal date? Rubric: 3 = earliest binding requirement, documented rationale, review.
Synthesis
Current practice combines final standards, draft transition guidance and uneven deployment. Specialists maintain dated, sourced briefs that separate what is required, proposed, available and merely claimed.
Continue studying — chapter 02 of 12
← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →