This is a free, public weekly briefing tracking the transition from classical to post-quantum cryptography — from government mandates to vendor deployments to the hardware progress that drives the urgency. Edition #2 is the first active edition: the August 6 baseline established the foundation; this week, Block 7 (Momentum Indicators) runs for the first time. Companion daily vulnerability and threat intelligence reports are available at deepfalcon1313.com.
BLOCK 1
NIST PQC Standards & Mandate Tracker — Contractor Compliance Deadline Added to EO 14412 Picture
Updated
No new NIST standards were finalized this week — the three published standards (FIPS 203, 204, 205) and the two in-development (FIPS 206, HQC) are unchanged from the baseline edition. The focus this week is on the full implications of EO 14412 (June 22, 2026), specifically the contractor compliance layer that was mentioned in the baseline but merits a more complete treatment given its direct reach into private-sector organizations.
| Standard / Directive | Status | Algorithms | Deadline / Scope |
|---|---|---|---|
| FIPS 203 (ML-KEM) | ✅ Finalized Aug 13, 2024 | Key encapsulation (replaces ECDH/RSA key exchange) | Published — available for adoption now |
| FIPS 204 (ML-DSA) | ✅ Finalized Aug 13, 2024 | Digital signatures (replaces ECDSA/RSA signatures) | Published — available for adoption now |
| FIPS 205 (SLH-DSA) | ✅ Finalized Aug 13, 2024 | Hash-based signatures (backup to ML-DSA) | Published — available for adoption now |
| FIPS 206 (FN-DSA / FALCON) | 🔄 Draft in development | FALCON-based signatures (bandwidth-constrained environments) | In draft — Q2 2026 status: draft |
| HQC (backup KEM) | 🔄 Standard in development | Code-based key encapsulation (backup if ML-KEM lattice math weaknesses found) | Selected March 2025 — standard in development |
| EO 14412 — Federal Civilian (Key Establishment) | ⚡ HARD DEADLINE | ML-KEM (FIPS 203) — all high-value assets and high-impact systems | December 31, 2030 |
| EO 14412 — Federal Civilian (Digital Signatures) | ⚡ HARD DEADLINE | ML-DSA (FIPS 204) — all high-value assets and high-impact systems | December 31, 2031 |
| EO 14412 — Federal Contractors | 📋 Regulation Incoming | All NIST FIPS PQC standards — federal contracting agencies must issue regulations requiring contractor compliance by end of 2030; contractors must also update vulnerability disclosure programs to cover "cryptographic vulnerabilities including testing for lack of encryption and use of non-FIPS approved algorithms" | Contractor regulations due by 2030 |
| EO 14412 — Critical Infrastructure | 📢 Directed Support | CISA and NSA directed to assist and encourage critical infrastructure operators — not a mandate, but a strong signal of where expectations are heading for utilities, financial services, and transportation | Ongoing — no fixed deadline |
| CNSA 2.0 (National Security Systems) | 🔄 Separate Track | ML-KEM, ML-DSA, SLH-DSA, LMS/XMSS for all NSS — follows separate, faster timeline than federal civilian systems | 2027–2033 tiered (see NSA CNSA 2.0) |
| FIPS 140-3 Procurement | ⚡ NEAR-TERM DEADLINE | Any cryptographic product procured for federal use must be FIPS 140-3 validated; this applies immediately to vendor procurement regardless of the 2030 migration deadline | September 21, 2026 (validated modules required for new federal procurement) |
The contractor reach of EO 14412 explained: Federal agencies that issue contracts are required to publish regulations mandating that their contractors comply with NIST's FIPS PQC standards by end of 2030. This extends the EO's practical scope well beyond the federal civilian agencies it directly covers. Additionally, contractors must update their vulnerability disclosure programs to explicitly address "cryptographic vulnerabilities, including testing for lack of encryption and the use of non-FIPS approved algorithms" — meaning cryptographic hygiene becomes a formal contractor compliance item, not just a best practice. If your organization sells to, or provides IT services to, the U.S. federal government, these deadlines apply to you even though EO 14412's text directly addresses federal agencies. The timeline went from 2035 (NSM-10, 2022) to 2030 — a pull-forward of four to five years.
BLOCK 2
Vendor Crypto-Agility Moves — The 2026 Asymmetry: Session Keys Are PQ-Protected, Server Certificates Are Not
Updated
The defining asymmetry of PQC deployment in 2026: When a Chrome user loads a website over X25519MLKEM768 — the hybrid TLS key exchange that is now the default in Chrome, Firefox, Edge, and Safari — the symmetric session key protecting that connection is post-quantum secure. But the server certificate that authenticated the handshake is still signed with classical ECDSA P-256 or RSA-2048. No ML-DSA roots exist in the Mozilla, Apple, Microsoft, or Chrome trust stores. The CA/Browser Forum's Server Certificate Working Group has a PQC ballot tracker but no merged baseline requirement permitting ML-DSA in publicly trusted certificates as of this edition. This means the connection is protected against a quantum adversary eavesdropping on the key exchange, but a sufficiently capable quantum adversary who can forge classical signatures could still impersonate a server to initiate an authenticated connection. Understanding this asymmetry is important for accurately characterizing your organization's PQC posture in 2026.
Cloudflare
ML-KEM hybrid TLS (X25519MLKEM768) default across entire edge network. Per Cloudflare's own Radar measurements: 54% of all human web requests now use post-quantum key agreement as of Q2 2026 — up from approximately 27% one year prior. Roadmap: post-quantum origin authentication (server certificate layer) targeting mid-2026; Merkle Tree Certificates mid-2027; full SASE-suite PQC coverage by early 2028; complete product portfolio (including authentication) by 2029.
Google / Chrome
Chrome enables X25519MLKEM768 by default on all platforms. March 2026: Google announced 2029 as the deadline for full PQC migration across Google infrastructure. Google Cloud has published PQC migration tooling for enterprise customers. Chromium is the primary driver for the 54%+ web traffic figure — any site reachable by Chrome gets hybrid PQC key exchange at no cost to the site operator.
Apple (NEW this edition — not in baseline)
iOS 26 and macOS Tahoe 26 (2026 releases) ship system-wide post-quantum cryptography support, bringing Safari fully into ML-KEM hybrid TLS. This is the final major browser/platform to complete the transition — Chrome, Firefox, Edge, and now Safari all negotiate hybrid PQC by default. For mobile traffic, this closes the remaining gap where iOS Safari sessions were using classical-only key exchange.
AWS
ML-KEM hybrid TLS deployed across AWS KMS, Amazon S3, CloudFront, Application Load Balancers, Network Load Balancers, AWS Payments Cryptography, ACM, and Secrets Manager. AWS Private CA supports ML-DSA for digital signatures. AWS Private CA is one of the few production ML-DSA deployments available outside of test environments. AWS has announced plans to complete ML-KEM deployment across all HTTPS endpoints in 2026.
Microsoft
ML-KEM and ML-DSA integrated into SymCrypt — Microsoft's primary cryptographic library underpinning Windows, Azure, Microsoft 365, and related platforms. PQC APIs became generally available across Microsoft's platform in 2025. Active Directory Certificate Services PQC general availability is targeted for early 2026 — this would be a significant milestone given ADCS is the internal PKI infrastructure for a large proportion of enterprise Windows environments.
Akamai
Hybrid ML-KEM + X25519 key exchange made default for all Akamai customers (February 2026, per roadmap). Applications behind Akamai's CDN and edge security products now receive PQC key exchange protection by default without requiring configuration changes from operators.
Certificate trust stores — the remaining gap: The IETF draft-ietf-tls-mldsa was in working group last call as of May 2026. No major browser negotiates ML-DSA for server certificate by default. No public CA has issued ML-DSA root certificates chaining into any major trust store. The industry's PQC migration for session keys is largely complete at the CDN/browser layer; the migration for certificates (authentication) is still in early design stages at the standards and trust-store level.
BLOCK 3
"Harvest Now, Decrypt Later" Risk Watch — EO 14412 Explicitly Names This as the Driver
Context
// Why the Deadline Has Already Passed for Some Data
EO 14412 (June 22, 2026) explicitly cites harvest now, decrypt later as the primary justification for pulling the federal PQC migration deadline forward from 2035 to 2030. The order states that adversaries can "collect encrypted U.S. data now and decrypt it later, once a large-scale quantum machine exists" — and that this risk is active today, before any cryptographically relevant quantum computer exists, because the data being stolen now may still need to be secret in 2035 or beyond.
The practical implication of HNDL for prioritization: a federal agency or contractor migrating to PQC by 2030 has already ceded the security of any sensitive data that was transmitted over a classically-encrypted channel and captured by an adversary since, approximately, 2020. The 2030 deadline addresses future data — it does not retroactively protect data already captured. This is the "wrong deadline" problem: organizations prioritizing PQC migration based on when a CRQC might arrive are optimizing for the wrong moment. The correct prioritization question is: when does the data I am protecting today need to stop being secret?
Sector-specific HNDL urgency signals this week: No new incident disclosures or sector-specific advisories tied specifically to HNDL surfaced in this edition's research window. The ongoing HNDL risk context is unchanged from the baseline — intelligence agencies, national security communications, long-lived financial records, medical records, and legal documents remain the highest-urgency categories given their multi-decade sensitivity lifetimes. The EO 14412's explicit HNDL language does give this risk assessment official U.S. government endorsement as an active, not theoretical, concern.
BLOCK 4
Quantum Computing Progress, Contextualized — 96 Logical Qubits Today; ~4,000 Needed; Gap Is Engineering, Not Physics
Updated
The gap in plain terms: Breaking RSA-2048 via Shor's algorithm requires approximately 4,000 error-corrected logical qubits running deep circuits. The largest demonstrated logical qubit count as of early 2026 is 96 (QuEra Computing, January 2026). The gap is not one of physics understanding — it is engineering scale. Multiple organizations have now demonstrated the key property needed for scaling (exponential error suppression as code distance increases, sometimes called "below-threshold" error correction), meaning the path to a cryptographically relevant quantum computer is now an engineering problem rather than a fundamental science problem. That distinction matters for timeline assessments.
QuEra Computing — Neutral Atom
96 logical qubits demonstrated, January 2026 — the current record for a single demonstration (per April 2026 analysis from entangledfuture.com, cross-referenced via quantagram.org mid-2026 state of quantum). This is specifically logical, error-corrected qubits — not physical (noisy) qubits. Physical qubit counts for neutral-atom systems are much higher; what matters for CRQC capability is the logical qubit count after error correction overhead.
Quantinuum + Microsoft H2 — Trapped Ion / Hybrid
94 error-protected logical qubits demonstrated at beyond-break-even computation (March 2026). Separately, a Microsoft + Quantinuum collaboration demonstrated 12 logical qubits at a logical error rate of approximately 2 per 1,000 — described as "reliable quantum computing" because the logical error rate is below the underlying physical error rate (the definition of successful error correction). These are different milestones: the 94-qubit result shows scale; the 2/1,000 error rate result shows fidelity. Both need to be true at the same scale to approach CRQC capability.
IBM — Superconducting
Kookaburra system: approximately 4,158 physical qubits (modular architecture), targeting a demonstration of quantum advantage on a useful workload by end of 2026. IBM's published roadmap targets "Starling" (~200 logical qubits) by 2029 — explicitly not CRQC-scale (which requires thousands of logical qubits), but described as the threshold for early fault-tolerant quantum advantage on specific computational tasks. The roadmap extends to much larger fault-tolerant systems by the early 2030s.
Google Quantum AI — Superconducting (Willow)
Progressed from 3x3 to 7x7 surface code demonstration in early 2026, with each step suppressing the logical error rate approximately 2x as predicted by surface-code theory. This is the scaling law that makes error-corrected quantum computing theoretically achievable: more physical qubits reduce logical error exponentially, rather than making it worse. Google targets approximately 1 million physical qubits for a fault-tolerant utility-scale machine — still many generations away, and described as a scientific utility milestone rather than a code-breaking one.
IonQ — Trapped Ion (Tempo System)
64 algorithmic qubits reached in Q1 2026. IonQ's trapped-ion architecture offers all-to-all qubit connectivity (an advantage over superconducting systems where connectivity is limited by chip topology). Algorithmic qubits are not the same as error-corrected logical qubits — this metric reflects the effective computational capability rather than fault tolerance level.
Timeline context (what independent analysts say): Global Risk Institute (May 2026) assessed approximately 17–22% probability of a cryptographically relevant quantum computer existing by 2031. Expert consensus across non-vendor sources places a CRQC in the mid-2030s to mid-2040s range. IBM's roadmap and PsiQuantum's photonic architecture plans represent the most specific public timelines from major players — both point to the early-to-mid 2030s for fault-tolerant systems capable of running Shor's algorithm at meaningful scale. The migration urgency comes from HNDL (data being captured now for future decryption) and procurement lead times, not from the imminent arrival of a CRQC.
BLOCK 5
Practical Readiness — This Week's Focus: Certificate Lifecycle and CA Readiness
Actionable
Edition #1 (August 6) covered: starting a cryptographic inventory — mapping all systems using RSA, ECDH, ECDSA, or Diffie-Hellman. This week's focus: certificate lifecycle and CA readiness — the layer where the PQC transition is furthest behind deployment of hybrid TLS key exchange.
// This Week's Readiness Step: Certificate Lifecycle & CA Readiness
- Understand the asymmetry before acting: Your TLS session key may already be PQ-protected if you are behind Cloudflare, Akamai, or AWS CloudFront — but the server certificate that authenticated that handshake is almost certainly still classical ECDSA or RSA. The certificate layer is where the migration gap currently sits. Understanding which part of your TLS stack is protected and which part is not is the prerequisite for the steps below.
- Identify your internal Certificate Authority (CA) infrastructure: Determine whether your organization runs its own PKI (e.g., Active Directory Certificate Services, an internal EJBCA, HashiCorp Vault CA, AWS Private CA, or similar). These are the systems that will need to issue ML-DSA certificates for your internal infrastructure when the migration begins — and they need to support ML-DSA before any ML-DSA certificates can be issued. AWS Private CA already supports ML-DSA. Microsoft ADCS PQC support is targeting early 2026 GA. Check your CA vendor's specific PQC roadmap now.
- Understand public trust store timeline: For externally-facing systems (public websites, customer APIs), your server certificate must chain to a root CA in the browser and OS trust stores (Mozilla, Apple, Microsoft, Chrome). No ML-DSA roots exist in any major trust store yet. The CA/Browser Forum is working on requirements, but no timeline is committed. For your publicly-trusted certificates, you will be on a classical-certificate trust model until the trust stores update — plan accordingly and do not confuse hybrid TLS key exchange (already deployed) with ML-DSA certificate trust (not yet deployed).
- Check your certificate validity periods and renewal cadence: Shorter certificate lifetimes (one year or less, as required by most CA/B Forum policies) mean you will have natural rotation opportunities to issue ML-DSA certificates once the trust infrastructure matures. Multi-year certificates that won't renew until 2027 or later are an asset here — you won't be stuck on a certificate issued before PQC certificates were available. Map your certificate renewal schedule now so you can time the transition.
- Evaluate HSM support for ML-KEM and ML-DSA: If you use hardware security modules to protect private keys (as is required for many regulated environments), verify that your HSM supports ML-DSA key operations. Not all HSMs currently support PQC algorithms natively. SEALSQ and other HSM vendors have been targeting 2025–2026 for NIST-approved PQC algorithm integration. Check your HSM vendor's current support and roadmap before assuming your key management infrastructure can issue PQC certificates.
- Prepare a vendor PQC certificate readiness matrix: List every vendor whose certificate-issuing or certificate-consuming product sits in your environment. For each: does it support ML-DSA signature verification? Can it issue ML-DSA certificates? Can it handle the larger certificate sizes that lattice-based algorithms require? A vendor that says "PQC supported" in a roadmap slide but has not shipped it yet is not ready. This matrix identifies the longest lead-time dependencies in your certificate migration path.
BLOCK 6
This Week's Log — August 12, 2026
Log
2026-08-12 — Edition #2 / First Real Edition
Standards: No new NIST standards published this week. FIPS 206 and HQC standard remain in development — no draft updates found in this week's research window. Block 1 focused this week on the contractor compliance implications of EO 14412 (June 22, 2026), which extends PQC requirements to federal contractors and their vulnerability disclosure programs by 2030.
2026-08-12 — Vendor Moves
Block 2 new item: Apple iOS 26 and macOS Tahoe 26 (2026) confirmed as shipping system-wide PQC support, bringing Safari into hybrid ML-KEM TLS — the last major browser/platform to complete this transition. Cloudflare Q2 2026 measurement confirmed: 54% of all human web traffic now uses PQ key agreement. The 2026 asymmetry (PQ session keys, classical certificates) documented for the first time in this service's briefings.
2026-08-12 — Quantum Hardware
Block 4: No new hardware milestones from the past 7 days specifically — this edition's Block 4 covers the H1 2026 milestone landscape as reported through mid-2026 sources. Key number to track: 96 logical qubits demonstrated (QuEra, January 2026) vs. ~4,000 needed for RSA-2048. Engineering scale-up is now the constraint, not fundamental physics.
2026-08-12 — Block 7 First Run
Momentum Indicators dashboard running for the first time this edition. Eight signals assessed — see Block 7 below. The self-referential indicator (frequency in this service's daily threat/vuln reports) returned 1 result for the past 7 days: the August 6 baseline edition of this quantum briefing itself. No quantum or PQC mentions in the daily vulnerability or threat intelligence reports for August 7–12.
2026-08-12 — Corrections
No corrections to the August 6 baseline edition. The FIPS 140-3 September 21, 2026 procurement deadline stated in the baseline is confirmed accurate — it applies to new federal procurement of cryptographic products starting that date.
BLOCK 7
Momentum Indicators — First Run (NEW v1.2) — 8-Signal Maturity Dashboard
🆕 First Run
A weekly maturity-signal dashboard tracking eight indicators of how post-quantum cryptography is progressing from research topic to operational reality. All items must connect specifically to the cryptographic/security implication of quantum computing — general quantum computing news that doesn't affect when classical cryptography breaks or how ready organizations are for that event is excluded. First run establishes the baseline signal reading for each indicator.
| # | Indicator | Signal | This Week's Reading |
|---|---|---|---|
| 1 | Research Publication GrowthCryptanalysis, PQC algorithm design, or quantum algorithms with direct cryptographic relevance | Moderate | No single landmark cryptanalysis paper or algorithm breakthrough found in this week's specific window. Background publication rate for lattice-based cryptography, HNDL-related research, and PQC migration methodology remains strong as a category — multiple surveys and implementation analyses are publishing on a rolling basis (tracked at IACR ePrint). The volume is consistent with an established, active research field rather than a discovery-phase acceleration. Will elevate this signal if a notable cryptanalytic result or algorithm update (such as an improved attack on ML-KEM or a new factoring breakthrough relevant to Shor's timeline) surfaces. |
| 2 | Patent FilingsPQC algorithms, quantum-resistant hardware, or crypto-agility tooling | Moderate | No specific new PQC patent filings confirmed within this week's research window. Major cloud providers (Amazon, Google, Microsoft) and HSM vendors continue to accumulate PQC-related IP — this is a background rate rather than a spike. PQC patent activity in crypto-agility tooling and hybrid TLS implementation has been consistently elevated through 2025-2026 per patent tracking services, but this indicator requires a specific newly-filed or granted patent to report as Active. No meaningful new filing this specific week to report. |
| 3 | Startup FundingPQC migration tooling, quantum-safe products, or crypto-agility platforms specifically | Moderate | No new PQC-specific startup funding rounds confirmed in this week's research window. Background context: PsiQuantum has raised over $2.3 billion toward a photonic fault-tolerant quantum computer — relevant to this indicator only to the extent its architecture is on the path to a CRQC. Crypto-agility platform startups (CryptoNext Security, PQShield, SandboxAQ in its PQC advisory capacity) have been active in the market but no new round was confirmed for this specific window. This indicator requires a newly-closed or announced funding event to report as Active. |
| 4 | Product ReleasesNew product categories or vendors new to PQC space — not incremental updates from Block 2 vendors | Active | Apple iOS 26 / macOS Tahoe 26 (2026 release) — system-wide PQC integration shipping to hundreds of millions of devices, bringing Safari into hybrid TLS and making Apple the last major platform to complete this transition. This is the completion of a platform-layer rollout that has been building since Chrome 116 (2023). The practical effect: the browser ecosystem for PQC key exchange is now complete across Chrome, Firefox, Edge, and Safari on all major platforms. |
| 5 | Standards ProgressStandards bodies OTHER than NIST/NSA (ETSI, ISO, IETF, industry consortia) | Active | IETF draft-ietf-tls-mldsa was in working group last call as of May 2026 — this is the standard that will define how ML-DSA (FIPS 204) is negotiated in TLS, enabling quantum-resistant server certificates in addition to the quantum-resistant key exchange already deployed. Last call is a late-stage milestone; the draft moving through to RFC status will unlock the certificate trust-store layer of PQC deployment currently blocked. CA/Browser Forum PQC ballot tracker remains active — the technical work is proceeding even though no merged baseline requirement has been published. These two tracks together define the path to the missing certificate layer. |
| 6 | Enterprise AdoptionOrganizations publicly confirming PQC migration steps — demand side, not vendor-side | Active | EO 14412's contractor compliance requirements are activating enterprise demand. Federal contractors across defense, technology, and critical infrastructure are beginning cryptographic inventories and migration planning in response to the June 22 executive order — the hardest endpoint of the demand signal, since contractor compliance regulations must be issued by 2030. Multiple financial institutions have begun PQC migration pilots citing both EO 14412 and CNSA 2.0 scope. Public confirmations from named enterprises are still relatively sparse in this week's specific research window, but the regulatory trigger is unambiguous and the demand signal is real. |
| 7 | Regulatory ReferencesQuantum/PQC in regulatory guidance BEYOND NIST/CNSA — financial regulators, insurance, sector-specific compliance, non-US jurisdictions | Moderate | PCI DSS references to PQC readiness have appeared in compliance documentation for financial institutions (PCI DSS 4.0 and its guidance on future-proofing cryptographic controls). UK NCSC has published PQC migration guidance for UK financial services. EU's ENISA (European Union Agency for Cybersecurity) has incorporated PQC into its cryptographic recommendations. No specific new regulatory guidance from a financial, insurance, or non-US jurisdiction was published in this specific 7-day window — the signal here is sustained background activity rather than a new issuance. |
| 8★ | Frequency in Service's Daily ReportsSelf-referential: quantum/PQC mentions in this service's own threat/vuln archives, past 7 days | 1 Reference | 1 result for "quantum," "pqc," or "post-quantum" in the service's threat/vulnerability reports for August 6–12, 2026: the August 6 baseline edition of this quantum briefing itself (indexed in search-index.json, report_type: quantum). Zero quantum/PQC references in the daily vulnerability reports or daily threat intelligence reports for August 7–12. This is expected — no quantum-relevant CVE or threat actor using PQC-specific techniques was reported this week. The August 11-12 Patch Tuesday reports covered classical cryptography vulnerabilities (CVE-2026-68820 WinSock EoP, DNS RCE, Exchange auth bypass) with no post-quantum dimension. This indicator will rise when quantum readiness themes begin appearing in non-quantum pillar reports — a meaningful signal of cross-pillar relevance. |
Signal states: Active = specific qualifying event confirmed this week · Moderate = ongoing background activity, no new discrete event · Quiet = no qualifying activity found. An explicit "no meaningful signal this week" is more informative than padding.