IR 8547 is NIST's core transition document for federal agencies, industry and standards bodies, finalising the November 2024 draft. The headline schedule: quantum-vulnerable public-key algorithms used for key establishment (RSA, Diffie-Hellman, ECDH) and for signatures (RSA, ECDSA, EdDSA) become deprecated after 2030 and disallowed after 2035. "Deprecated" means still permitted if the data owner accepts the risk; "disallowed" means not permitted for that purpose. NIST repeats that earlier cryptographic transitions took 10 to 20 years and urges organisations to inventory, plan, buy post-quantum-capable products and retire systems that cannot be upgraded.

What changed from the draft, according to SITG Consulting's side-by-side comparison (not yet checked line by line against NIST's PDF): the 2030 deprecation now applies to all security strengths, where the draft deprecated only 112-bit keys such as RSA-2048; wording hardened from "NIST intends to" to "NIST will"; signature migration is described as urgent even without harvest-now exposure; ML-KEM-768 is named as the default for key establishment; and hybrid schemes can be FIPS-validated where at least one component is approved (see SP 800-227 and SP 800-56C). For federal high-value and high-impact systems, the report restates the Executive Order 14412 / OMB M-26-15 dates: key establishment by December 31, 2030, signatures by December 31, 2031, and TLS 1.3 support by January 2, 2030.

The NCSC now recommends hybrid (post-quantum plus classical) key exchange in TLS, which is what common libraries already ship, and also lists pure post-quantum options, noting their final RFC is still pending. TLS 1.3 is the only version that supports post-quantum cryptography and earlier versions will not be upgraded, so anything still on TLS 1.2 should move. High-priority migration should be finished by 2031, and post-quantum authentication recommendations for TLS will follow "in the coming months". Date note: this was published October 15, inside Edition #11's window, and is covered here for the first time.

Using OMB guidance, GAO checked three preparation practices at the 24 CFO Act agencies; none fully met them. Causes: too little cryptography expertise, weak processes for building cryptographic inventories and finding transition funding, and no plans for testing. The restricted version made 89 recommendations to 23 agencies; one agency disagreed with three of its four. GAO says most experts expect a cryptographically relevant quantum computer possibly in the 2030s, with wide uncertainty. If federal agencies with a mandate struggle with inventory, most organisations should assume theirs is incomplete too.

The service lets customers choose the regions where their TLS private keys can be decrypted on Cloudflare's network. Keys are wrapped with hybrid HPKE (RFC 9180) combining ML-KEM-768 and X25519, so a recording of key-distribution traffic is not useful to a future quantum computer. Edge servers must pass TPM 2.0 attestation and location checks before receiving regional keys, and requests fail closed rather than decrypting in the wrong country. The beta starts with Cloudflare One customers (Magic WAN, Tunnel, Gateway); CDN support comes before general availability. Cloudflare says it chose HPKE because no standardised post-quantum attribute-based encryption exists. Details here come from secondary reporting; Cloudflare's own post was not retrieved this week.

Coverage of OpenBSD 8.0 describes post-quantum SSH and TLS support enabled by default. We could not load the release notes to confirm which algorithms, so treat this as a pointer: if you run OpenBSD firewalls or gateways, check the 8.0 notes before upgrading and use the SSH checks from Edition #11 to confirm what your connections negotiate.

IR 8547 tells organisations to give long-lived confidential data earlier attention because it can be recorded now and decrypted later, and GAO lists decryption of "data stolen earlier and stored" as one of two main risks of a future quantum computer. Neither reports a new collection campaign, but both make HNDL a documented planning assumption that auditors can cite, rather than a vendor talking point.

NowSecure found no detectable post-quantum code in 96.9% of apps, and more than 3,100 still running legacy ciphers such as DES and RC4. Much of an app's cryptography arrives inside third-party SDKs (analytics, payments, advertising) that ordinary dependency scans miss. Caveats: absence in the binary is not proof of absence, presence is not proof of use, and NowSecure sells the assessment tooling. The useful point for HNDL planning is that apps handling logins and payments rely on the operating system and SDK vendors; if you build apps, ask your SDK suppliers the same questions you ask network vendors.