PKI Today 2026: Congratulations, Your Cert Renewal Is Now a Recurring Calendar Invite
398 days to 47 reads like a number change. Means nothing to management right? It's a workflow change. The cert(s) we touch once a year becomes the cert we touch every six weeks, multiplied by the entire inventory just built. The schedule is fixed, it is public, and it's not a rumor. The CA/Browser Forum passed Ballot SC-081v3 in April 2025, and it steps the maximum lifetime of a publicly trusted TLS certificate down: from 398 days, 200 days as of March 15, 2026, 100 days as of March 15, 2027, and 47 days as of March 15, 2029 [1]. Each step roughly halves the one before it. Certificates already issued keep their original lifetime, so nothing breaks overnight; the squeeze arrives at renewal, which is where most of your inventory meets the new rules whether it's ready or not. The math is the part that reframes it from policy to operations. An organization running a thousand public certificates handles on the order of a thousand renewals a year today. At a 47-day lifetime, those same thousand certificates generate nearly eight thousand renewal events a year, because each one now turns over roughly eight times instead of once [2]. That is the eight-fold figure sitting behind the opening line, and it's why "we'll add headcount" isn't an answer. You don't staff your way out of an eight-fold increase in a recurring administrative operation that requires a modicum of due diligence. You automate it, or you start having outages. This isn't hypothetical. Missed renewals already take down major infrastructures more than we sometimes want to admit: Microsoft Teams, February 2020: an expired authentication certificate locked users out of Teams globally for roughly three hours after the company reported that users may be unable to access Microsoft Teams and later confirmed the outage was due to an expired certificate (TechCrunch) Ericsson SGSN-MME, December 2018: an expired software certificate in Ericsson's core network software shut down affected equipment, knocking out mobile data and voice for roughly 32 million O2 customers in the UK and tens of millions of SoftBank customers in Japan (Softpedia) Logitech certificate, January 2026: an expired code-signing certificate broke Logitech's macOS apps system-wide, a fresh reminder that renewal failures aren't a 2018-2020 relic (MacRumors) Three different failure modes, one common thread: none of these companies lacked the engineering talent to prevent an expiration date from arriving unnoticed. They lacked the automation, or monitoring, or inventory, or any combination of the three. The 2027 Cliff Here is the part the headlines seem to miss: the cliff is 2027, not 2029. The 200-day phase that arrived in 2026 still survives a semi-manual process, because renewing twice a year is annoying but livable. The 100-day phase in March 2027 is where it breaks for most organizations, because quarterly-plus renewal across a production inventory is past the point where people clicking buttons can keep pace. By the time 47 days lands in 2029, any team that is going to make it has already automated. If 2029 is the coup de grâce, then 2027 is the wound, and "it's just a flesh wound" is not a migration strategy. Plan for the 2027 date and the 2029 one mostly takes care of itself. Validity, meanwhile, is only the number everyone watches. The one that actually reshapes your tooling is domain control validation reuse, which steps down on its own track: 398 days, now 200, soon 100, and finally 10 days in the last phase [1]. At a 47-day certificate with a 10-day reuse window, you are re-proving control of each domain something like three dozen times a year. Email-based validation and a human dropping a file on a server are finished at that cadence; they were never meant to run weekly. Worse, validation is getting more rigorous at the same time as it gets more frequent: the Forum now requires corroborating domain validation from multiple network perspectives, and DNSSEC validation where present is effective alongside the first phase in March 2026 [3]. The operation you now run thirty-odd times a year is also harder to run each time. There is no shortcut hiding in the effort. The Escape Hatch There is, however, an escape hatch. In October 2025 the Forum added a new domain control validation method, section 3.2.2.4.22, "DNS TXT Record with Persistent Value," informally the DNS-PERSIST-01 method [4], with a matching ACME challenge moving through the IETF as dns-persist-01 [5]. The idea is a set-once and reap the benefits over time: we place a single persistent TXT record naming the CA and our account, and the CA reuses it across issuances instead of making us rewrite DNS on every renewal. Read the fine print, though, because it's easy to oversell. The persistent record doesn't exempt you from the 10-day reuse cap; the CA still re-checks the record at each issuance and still may only rely on it for those ten days. What it removes is the per-renewal DNS write, not the re-validation. For shops with strict DNS change-management, for multi-tenant and edge platforms, and for IoT fleets that can't coordinate real-time DNS updates, it can be the difference between feasible and ITIL change control revolt; it's a workflow simplification, not a loophole. Add it up and the conclusion isn't so subtle. At this cadence automation stops being a nice-to-have and becomes the only way to stay out of an asylum. But "just automate it" quietly assumes one thing that falls apart fast: that a single CA can issue everything you need. And that's what we discuss next. References [1] CA/Browser Forum. Ballot SC-081v3, "Introduce Schedule of Reducing Validity and Data Reuse Periods" (passed April 2025). Maximum TLS validity 398 to 200 (15 Mar 2026), 100 (15 Mar 2027), 47 (15 Mar 2029); DCV reuse 398 to 200, 100, then 10 days; Subject Identity Information reuse 825 to 398 days as of 15 Mar 2026. [2] DigiCert. "TLS Certificate Lifetimes Will Officially Reduce to 47 Days" (2025 [3] CA/Browser Forum. Ballot SC-067v3 (Multi-Perspective Issuance Corroboration) and Ballot SC-085v2 (Require Validation of DNSSEC when present for CAA and DCV lookups) [4] CA/Browser Forum. Ballot SC-088v3, "DNS TXT Record with Persistent Value DCV Method [5] IETF draft-ietf-acme-dns-persist, ACME challenge "dns-persist-01" for persistent DNS TXT record validation (working-group draft, rev -01, 2026).Hands-On Quantum-Safe PKI: A Practical Post-Quantum Cryptography Implementation Guide
Update (April 2026): The CNSA 2.0 section of this article originally listed both ML-DSA-65/87 and ML-KEM-768/1024 as approved. That's incorrect — CNSA 2.0 requires ML-DSA-87 and ML-KEM-1024 exclusively per draft-jenkins-cnsa2-pkix-profile §4. FIPS 204/203 standardize additional parameter sets but CNSA 2.0 only adopts Category 5. Is your Public Key Infrastructure quantum-ready? Remember way back when we built the PQC CNSA 2.0 Implementation guide in October 2025? So long ago! Due to popular request, we've expanded the lab to now include THREE distinct learning paths: NIST FIPS standards, NSA CNSA 2.0 compliance, AND alternative post-quantum algorithms for those wanting diversity or international compliance options.. The GitHub lab guide walks you through building quantum-resistant certificate authorities using OpenSSL with hands-on exercises. Why learn and implement post-quantum cryptography (PQC) now? While quantum computing is a fascinating area of science, all technological advancements can be misused. Nefarious people and nation-states are extracting encrypted data to decrypt at a later date when quantum computers become available, a practice you better know by now called "harvest now, decrypt later." Close your post-quantum cryptographic knowledge gap so you can get secured sooner and reduce the impact(s) that may not surface until after it's too late. Ignorance is not bliss when it comes to cryptography and regulatory fines, so let's get started. The GitHub lab provides step-by-step instructions to create: Quantum-resistant Root CA using ML-DSA-87 (FIPS and CNSA 2.0) Algorithm flexibility based on your compliance needs Quantum-safe server and client certificates OCSP and CRL revocation for quantum-resistant certificates TLS 1.3 key exchange testing with ML-KEM and hybrid modes Alternative algorithm exploration (FrodoKEM, BIKE, HQC) for TLS/KEM usage Access the Complete Lab Guide on GitHub → At A Glance: OpenSSL Quantum-Resistant CA Learning Paths Select the path that aligns with your requirements: FIPS 203/204/205 CNSA 2.0 Alt. Algorithms Target Audience Commercial organizations Government contractors, classified systems Researchers, international compliance, defense-in-depth Compliance Standard NIST FIPS standards NSA CNSA 2.0 Non-NIST algorithms, international standards Algorithm Coverage ML-DSA, ML-KEM, SLH-DSA, Hybrid ML-DSA-87, ML-KEM-/1024 FrodoKEM, BIKE, HQC Use Case General quantum-resistant infrastructure National security systems Algorithm diversity, conservative security 📚 Learning Path 1: NIST FIPS 203/204/205 For commercial organizations implementing quantum-resistant cryptography using NIST standards. This path uses OpenSSL 3.5.x's native post-quantum cryptography support—no external quantum library providers required. So nice, so easy. Modules Module Description 00 - Introduction Overview of FIPS 203/204/205, prerequisites, and lab objectives 01 - Environment Setup Verifying OpenSSL with PQC support 02 - Root CA Building a Root CA with ML-DSA-87 03 - Intermediate CA Creating an Intermediate CA with ML-DSA-65 04 - Certificates Issuing end-entity certificates for servers and users 05 - Revocation Implementing OCSP and CRL certificate revocation 06 - Hybrid Methods IETF hybrid PQC methods (X25519MLKEM768, composite signatures) Algorithms Covered ML-DSA-44/65/87 (FIPS 204) - Lattice-based signatures ML-KEM-512/768/1024 (FIPS 203) - Lattice-based key encapsulation X25519MLKEM768 - Hybrid TLS 1.3 key exchange 📚 Learning Path 2: NSA CNSA 2.0 For government contractors and organizations requiring CNSA 2.0 compliance. This path uses OpenSSL 3.2+ with Open Quantum Safe (OQS) providers for strict CNSA 2.0 algorithm compliance. Modules Module Description 01 - Introduction Overview of CNSA 2.0 requirements and compliance deadlines 02 - Root CA Building a Root CA with ML-DSA-87 03 - Intermediate CA Creating an Intermediate CA with ML-DSA-87 04 - Certificates Issuing CNSA 2.0 compliant certificates 05 - Revocation Implementing OCSP and CRL certificate revocation CNSA 2.0 Approved Algorithms Algorithm Type Approved Algorithms NIST Designation Digital Signatures ML-DSA-87 FIPS 204 Key Establishment ML-KEM-1024 FIPS 203 Hash Functions SHA-384, SHA-512 FIPS 180-4 Note: CNSA 2.0 requires ML-DSA-87 and ML-KEM-1024 exclusively — no other parameter sets are approved. ML-DSA-44, ML-DSA-65, ML-KEM-512, ML-KEM-768, SLH-DSA, and Falcon are NOT part of CNSA 2.0, even though several are FIPS-approved. See draft-jenkins-cnsa2-pkix-profile §4. 📚 Learning Path 3: Alternative PQC Algorithms (NEW!) For researchers, organizations requiring algorithm diversity, and those interested in international PQC implementations. This path explores post-quantum algorithms outside the primary NIST standards, providing options for defense-in-depth strategies and understanding of the broader PQC landscape. Perfect for organizations wanting to hedge against potential future vulnerabilities in current adopted standards. Modules Module Description 00 - Introduction Overview of non-NIST algorithms, international standards, use cases 01 - Environment Setup OpenSSL and modifying OQS provider configuration 02 - FrodoKEM Conservative unstructured lattice KEM (European recommended: BSI, ANSSI) 03 - BIKE and HQC Code-based KEMs (HQC is NIST-selected backup to ML-KEM) 04 - International PQC EU, South Korean, and Chinese algorithm standards 05 - Performance Analysis Comparing algorithms, latency impacts, use cases, nerd stats Algorithms Covered Algorithm Type Mathematical Basis Key Characteristic FrodoKEM KEM Unstructured lattice (LWE) Conservative security, European endorsed (BSI, ANSSI) BIKE KEM Code-based (QC-MDPC) NIST Round 4 candidate, smaller keys than HQC HQC KEM Code-based (Quasi-cyclic) NIST-selected backup to ML-KEM (standard expected 2027) Why Alternative Algorithms Matter Algorithm Diversity: If a vulnerability is found in lattice-based cryptography (ML-KEM), code-based alternatives provide a backup International Compliance: European agencies (BSI, ANSSI) specifically recommend FrodoKEM for conservative security Future-Proofing: HQC will become a FIPS standard in 2027 as NIST's official backup to ML-KEM Research & Testing: Understand the broader PQC landscape for informed decision-making What This Lab Guide Achieves Complete PKI Hierarchy Implementation The lab walks through building an internal PKI infrastructure from scratch, including: Root Certificate Authority: Using ML-DSA-87 providing the highest quantum-ready NIST security level Intermediate Certificate Authority: Intermediate Certificate Authority: ML-DSA-65 in the FIPS path, ML-DSA-87 in the CNSA 2.0 path for hierarchy-wide compliance. End-Entity Certificates: Server and user certificates with comprehensive Subject Alternative Names (SANs) for real-world applications Revocation Infrastructure: Both Certificate Revocation Lists (CRL) and Online Certificate Status Protocol (OCSP) implementation TLS 1.3 Key Exchange Testing: Hands-on testing with ML-KEM, hybrid modes, and alternative algorithms Security Best Practices: Restrictive Unix file permissions, secure key storage, and backup procedures throughout Key Takeaways After completing one or more of the labs, you will: Understand ML-DSA Cryptography: Gain hands-on experience with both ML-DSA-65 (Level 3 security) and ML-DSA-87 (Level 5 security) algorithms Explore Algorithm Diversity: Understand when and why to use alternative algorithms like FrodoKEM, BIKE, and HQC Configure Modern PKI Features: Implement SANs with DNS, IP, email, and URI entries, plus both CRL and OCSP revocation mechanisms Test TLS 1.3 Key Exchange: Hands-on experience with ML-KEM and hybrid key exchange in real TLS sessions Troubleshoot Effectively: Learn to diagnose and resolve common issues with opensl and oqsproviders for PQC compatibility Prepare for Migration: Start the practical steps needed to transition existing PKI infrastructure to quantum-resistant algorithms Access the Complete Lab Guide on GitHub → About This Guide We built the first guide for NSA Suite B in the distant past (2017) to learn ECC and modern cipher requirements. It was well received enough to built a new guide for CNSA 2.0 but it's quite specific for US federal audiences. That lead us to build a NIST FIPS PQC guide which should apply to more practical use cases. And now we've added alternative algorithms because things are only going to get a bit more complicated moving forward. In the spirit of Learn Python the Hard Way, it focuses on manual repetition, hands-on interactions and real-world scenarios. It provides the practical experiences needed to implement quantum-resistant PKI in production environments. By building it on GitHub, other PKI fans can help where we may have missed something; or simply to expand on it with additional modules or forks. Have at it! Frequently Asked Questions (FAQs) Q: What is CNSA 2.0? A: CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) is the NSA's updated cryptographic standard requiring quantum-resistant algorithms. Q: When do I need to implement quantum-resistant cryptography? A: The NSA and NIST mandate CNSA 2.0 and FIPS 203/204/205 implementation by 2030. Organizations should begin now due to "harvest now, decrypt later" attacks where adversaries collect encrypted data today for future quantum decryption. Q: What is ML-DSA (Dilithium)? A: ML-DSA (Module-Lattice Digital Signature Algorithm), formerly known as Dilithium, is a NIST-standardized quantum-resistant digital signature algorithm specified in FIPS 204. Q: What is ML-KEM (Kyber)? A: ML-KEM... ships in three parameter sets — ML-KEM-512 (~AES-128), ML-KEM-768 (~AES-192), and ML-KEM-1024 (~AES-256). ML-KEM-768 is the common enterprise default; CNSA 2.0 requires ML-KEM-1024. Q: What are the alternative algorithms and why should I care? A: FrodoKEM, BIKE, and HQC are non-NIST-primary algorithms that provide algorithm diversity. If a vulnerability is discovered in lattice-based cryptography (which ML-KEM and ML-DSA use), code-based alternatives like HQC could provide a backup. HQC is actually NIST's selected backup to ML-KEM and will become a FIPS standard in 2027. Q: What's the difference between BIKE and HQC? A: Both are code-based KEMs. BIKE has smaller key sizes but wasn't selected by NIST. HQC has larger keys and was selected as NIST's official backup to ML-KEM. Q: Why do European agencies recommend FrodoKEM? A: FrodoKEM uses unstructured lattices (standard LWE) rather than the structured lattices used in ML-KEM. This provides more conservative security assumptions at the cost of larger key sizes. Germany's BSI and France's ANSSI specifically recommend FrodoKEM for high-security applications. Q: Is this guide suitable for production use? A: NOPE. While the guide teaches production-ready techniques and compliance requirements, always use Hardware Security Modules (HSMs) and air-gapped systems for production Root CAs (cold storage too). The lab is great for internal environments or test harnesses where you may need to test against new quantum-resistant signatures. ALWAYS rely on trusted public PKI infrastructure for production cryptography. 🤓 Happy PKI'ing! Reference Links NIST Post-Quantum Cryptography Standards - Official NIST PQC project page FIPS 203: ML-KEM Standard - Module-Lattice Key Encapsulation Mechanism FIPS 204: ML-DSA Standard - Module-Lattice Digital Signature Algorithm FIPS 205: SLH-DSA Standard - Stateless Hash-Based Digital Signature Algorithm NSA CNSA 2.0 Algorithm Requirements - NSA's official CNSA 2.0 announcement Open Quantum Safe Project - Home of the OQS provider for alternative algorithms OQS Provider for OpenSSL 3 - GitHub repository for OQS provider HQC Specification - Official HQC algorithm documentation BIKE Specification - Official BIKE algorithm documentation OpenSSL 3.5 Documentation - Comprehensive OpenSSL documentationPKI Today 2026: Step One Is Always Inventory. You Haven't Done It.
Every PQC roadmap, every regulator, every agency opens with the same unglamorous instruction: inventory your cryptography first. There's a reason it's always step one, and it isn't bureaucratic throat-clearing. The reason is that all three of the pressures (horses) from the previous article, the cert validity compression, the post-quantum migration, and the FIPS sunset, share a single precondition. We can't shorten the renewal cycle on a certificate we don't know exists, we can't swap an algorithm we can't locate, and we can't prove a boundary is validated if we've never established where the boundary is. Discovery isn't the first task because someone enjoys paperwork. It's the first task because every other task lies undefined until it's done. The deadlines already have dates. Our cryptographic inventory does not yet exist. Start with what "cryptography" means here, because the word does more work than people expect. It's not your web TLS certificates alone: It's your TLS certificates AND The keys behind the code-signing pipeline The algorithms inside your VPN and SSH The cipher suites your load balancers negotiate, The crypto library static-linked across three dependencies deep into an application nobody's patched since 2019 The keys sitting in an HSM whose firmware you never audited (let's be honest, not many people have) The partner API's and Saas integrations you call, whose TLS and cert lifecycles you don't control but whose failure still breaks your pipeline anyway The machine-readable artifact for capturing all of that is the Cryptography Bill of Materials (CBOM), which extends a software Bill of Materials (SBOM) you may already produce [1] down into cryptographic specifics: which algorithm, which key length, which library, used where. The inventory itself is a federal requirement rather than a suggestion. NSM-10 and OMB M-23-02 direct agencies to maintain a prioritized inventory of cryptographic systems and to report on it, and NIST's transition guidance treats that inventory as the prerequisite for everything downstream [2][3]. The CBOM is the format that federal discovery work, including NIST's National Cybersecurity Center of Excellence (NCCoE) migration project, increasingly converges on [4], even where the binding mandate names the inventory rather than the file. Here is the trap, and it's quiet. Cryptographic inventories that are supposed to cover everything tend to collapse into TLS certificate inventories, because certs are the easiest thing to scan and count. Resist letting the scope collapse, but do let the sequencing reflect the urgency of the other deadlines: Certificates go to the front of the inventory & remediation queue, not because they matter more than code signing or VPN keys, but because they are where the first hard, externally imposed deadline lands. The 47-day impacted regime in the next piece has a date on it. Your code-signing migration, for now, does not. So you inventory everything and you triage certificates first, and those are two different statements that are dangerously easy to blur into one. The hard part of discovery is that it is never complete, and the entries that hurt you are the ones you didn't find. You will catch the certificates you provisioned on purpose. You will miss the self-signed cert an engineer stood up for a staging box in 2021, the key baked into a firmware image, the dependency that quietly pulls in its own TLS stack. No single method finds everything: Method Sees Misses Network scanning What answers on a port Anything not listening/exposed CT log mining What was publicly logged Internal/non-public certs, anything pre-CT-era Host agents What's installed on a managed endpoint Unmanaged hosts, shadow IT Source analysis What's compiled/linked in Runtime-only config, anything not in the repo you're scanning A realistic inventory process coordinates across all of them and still assumes it is incomplete, because the alternative is learning about the gap when a certificate you never knew about expires at two in the morning. Have I received that call? Yup. One discovery detail is worth singling out now, because it returns later in this article series with real consequences. When your inventory records that an appliance is "FIPS validated," that sentence isn't yet a fact, it's three possible facts. The validated boundary might be the software cryptographic module, the appliance as a whole, or an attached hardware security module, and on a platform like F5's BIG-IP those are genuinely different scopes with different validation status [5]. A CBOM entry that says "validated" without recording which boundary it means is an entry that will mislead you exactly when you can least afford it, during a migration whose whole premise is knowing what is actually certified. Record the boundary, not just the checkmark. None of this is glamorous, most of it is tedious, which is precisely why it gets deferred until a deadline drags it into the open. A finished inventory is the first time most teams see their real cert count. The second that number is on screen, the next problem introduces itself, because every one of those certs is about to need renewing far more often than it does today. Guess what topic we're teeing up for in the next article? References [1] CycloneDX (OWASP). Cryptography Bill of Materials (CBOM), an extension of the Software Bill of Materials that captures cryptographic assets (algorithms, key lengths, libraries, certificates) and their usage context. [2] National Security Memorandum 10 (NSM-10), May 2022, and Office of Management and Budget Memorandum M-23-02, "Migrating to Post-Quantum Cryptography," November 2022 [3] NIST IR 8547, Transition to Post-Quantum Cryptography Standards. [4] NIST National Cybersecurity Center of Excellence. SP 1800-38, Migration to Post-Quantum Cryptography [5] F5 BIG-IP FIPS 140-3 validationPKI Today 2026: Three Horses, Five Carts, Zero Slack
Everyone wants to tell you the post-quantum story as one horse, one cart, one tidy road to 2030. It isn't. There are three horses, they're all pulling at once, they're hitched to five different carts, and at least two of them are dragging the same cart in slightly different directions. That's why Public Key Infrastructure (PKI), from management to planning for future efforts feels heavier now even though nothing in your environment technically broke. The horses are our deadlines, and they don't coordinate. One is certificate validity collapsing from 398 days toward 47. One is Post-Quantum Cryptography (PQC) mandates, every major regulator setting its own pace around the year 2030. One is the FIPS-140-2 sunset, quietly invalidating cryptographic modules you're still running (I'm also going to lean in on this horse analogy way too much, you're welcome). Survivable, any one of them. But none of them checked the other two's calendar. Ballot: The 47-day Certificate Countdown The first horse is named Ballot, and it's the one already at a gallop. In April 2025 the CA/Browser Forum passed ballot SC-081v3, scheduling a reduction in maximum certificate lifetime from 398 days down to 47 by 2029 [1]. The schedule: 200 days as of March 15, 2026 (done) 100 days in 2027 47 days in 2029, with domain-validation reuse collapsing to 10 days That last step is the one that bites: a certificate you touched once a year becomes one you touch roughly eight times a year, multiplied by every public or regulated certificate in an inventory you haven't finished counting. Treat 2029 as the deadline and you've misread the schedule. The 2027 step to 100 days is where manual renewal breaks for most enterprises [2], and the market isn't waiting for the mandate either: Let's Encrypt has committed to a 45-day default by 2028, ahead of the industry timeline [3]. This is a now problem wearing a 2029 disguise. Reckoning: The Global Post-Quantum Cryptographic Timeline The second horse, called Reckoning, broke out running this year. US Executive Order 14412, signed June 22 2026, turned years of post-quantum draft guidance into enforceable federal deadlines [4]. High-value and high-impact systems must complete key-establishment migration to NIST-approved algorithms by the end of 2030, with digital-signature migration following by the end of 2031, and contractors are pulled to a 2030 line through the acquisition rules [4]. This isn't an American story alone. Every major regulatory bloc is running its own version of the same clock, non-exhaustively: EU: national roadmaps due end of 2026, high-risk systems migrated by 2030, full transition by 2035 [5] Australia: classical asymmetric cryptography retired entirely by end of 2030 [6] Canada: CCCS is running its own migration guidance on a parallel track, distinct from the NIST/CNSA baseline The mandates differ in mechanism and pace, but they converge on the same decade. Sunset: FIPS 140-2's Expiration Date The third horse is the quietest, which is exactly why it catches people. On September 21 2026, NIST's Cryptographic Module Validation Program (CMVP) moves FIPS 140-2 validations to its historical list, and a module on that list can no longer be procured to satisfy a federal cryptographic requirement [7]. Nothing about the module changes on that date. What changes is whether you are allowed to keep buying it. If your compliance story rests on a 140-2 certificate, that validation expires before either of the other two horses finishes its run. The replacement path runs through 140-3, and through providers that haven't finished validating their post-quantum primitives. We name this horse Sunset. The Pale Horse: CRQC's Unscheduled Arrival There is a fourth horse, and it's the reason the other three feel so urgent. Ballot's window collapse has the CA/Browser Forum cracking the whip; the Reckoning has regulators on different continents setting the pace; Sunset has a time window stamped on it by the CMVP. Somebody scheduled all three. Nobody scheduled the fourth. It rides last, and you already know the verse. And I looked, and behold a pale horse: and his name that sat on him was CRQC. Note: I'm pretty sure that's how the passage goes. The cryptographic relevant quantum computer (CRQC), it's the only thing on this page that never filed a transition timeline. You can't plan against its arrival date because it does not have one, which is exactly why the move is to start now instead of when it becomes obvious: by the time it is obvious, the broken thing is the math underneath everything you already shipped. Name the three and you have named the horses. The carts are the actual work efforts they tow behind them: Discovery: Finding the cryptography you can't currently see Automation: Issuance because manual renewal will be a death sentence Multi-CA: Running more than one certificate authority (CA) whether you wanted to or not PQC Deployment (including Hybrid): Deploying new quantum-resistant algorithms defined by your federal mandates PQC Cost: Surviving what those algorithms do to revocation and certificate size The trouble is that the horses don't line up one per cart. Ballot drags both discovery and automation. Reckoning is hitched to our PQC algorithm choices and our CA strategy and your deployment sequencing all at once. Sunset pulls on the same algorithm cart from the other side, because the modules you're forced onto are the ones still validating the new primitives. Pull hard on any one rein and you'll tighten three other traces you weren't watching. Note: A harness trace is what connects the horse to the cart. So this isn't a roadmap in the do-these-seven-things-in-order sense, because the work does not queue that cleanly. It's a map of which force is pulling which part of your estate, where they overlap, and what you can do about it, one dependency harness at a time. And every harness shares a single starting line. The horses do not agree on a deadline, and none of the work they demand is even possible until we know where our cryptography actually lives. Which is the part almost nobody has done. That's where this article series starts: not with algorithms or ballots, but with the unglamorous inventory every regulator quietly assumes you've already finished. From there we follow the path forward, one horse and one cart at a time. Analogy over. But we're just getting started with this article series. References [1] CA/Browser Forum. Ballot SC-081v3 (TLS certificate lifetime reduction), passed April 2025. Maximum validity 398 → 200 days (15 March 2026) → 100 days (2027) → 47 days (2029); DCV reuse window to 10 days. [2] Understanding the Risk Scale: 6-month SSL/TLS Validity Starts March 15, 2026. [3] Let's Encrypt. Decreasing Certificate Lifetimes to 45 Days. [4] Executive Order 14412, signed June 22, 2026. whitehouse.gov. Key-establishment migration end-2030, digital-signature migration end-2031; contractor pull-forward via acquisition rules. (FR Doc 2026-12909, Vol. 91 No. 121, 25 June 2026.) [5] EU NIS Cooperation Group. A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, June 2025. National plans end-2026, high-risk systems 2030, full transition 2035. [6] Australian Signals Directorate. Information Security Manual (ISM): ceasing traditional asymmetric cryptography targeted for end of 2030. [7] NIST Cryptographic Module Validation Program (CMVP). FIPS 140-2 validations moved to the historical list effective September 21, 2026.Breaking Down the Quantum Challenge: Why Post-Quantum Cryptography Can't Wait
The Quantum Challenge is Now Post-quantum cryptography represents the next steps of our digital security evolution. Sure, quantum systems capable of breaking current encryption may still be an a few years away, but those beginning their transition now will be well-positioned for when the crypto hits the fan. Nation-state adversaries and sophisticated private entities may be collecting data today hoping to decrypt it tomorrow so it's never to early to start solving the problem now. It's an excellent time to get ahead of the curve with quantum-resistant cryptography. What does this mean for your organization? Any sensitive data encrypted today using standard methods (RSA, ECDSA) could potentially become readable to future quantum-powered attackers. F5 Community Evangelist Chase Abbott discusses the real world implications of quantum computing, and how you can prepare and migrate to NIST-approved hybrid PQC standards. The transition to post-quantum cryptography represents a perfect opportunity to modernize enterprise PKI practices. Those of you that begin planning today have ample time to implement these changes thoughtfully and strategically, positioning yourselves as leaders in the next generation of cybersecurity; high fives all around. The Business Impact: Beyond Technical Considerations Regulatory and Compliance Pressure Government regulations across the globe are creating concrete deadlines for migration strategies: NSA CNSA 2.0 mandates quantum-resistant algorithms for classified systems by 2030 NIST has standardized post-quantum cryptography algorithms (FIPS 203, 204, 205) Industry regulations in finance, healthcare, and defense are beginning to incorporate quantum-safety requirements adhering to the update FIPS governance Your Quantum-Ready Roadmap: A Manageable Transition Phase 1: Assessment and Inventory Action items for leadership: Conduct cryptographic inventory across all systems and applications Identify critical data requiring long-term protection Assess vendor and third-party quantum readiness Establish quantum cryptography governance and budget allocation Phase 2: Pilot Implementation Strategic focus areas: Deploy quantum-resistant algorithms in non-critical environments Train IT and security teams on post-quantum cryptography Establish partnerships with quantum-ready technology vendors Begin updating security policies and procedures Phase 3: Production Migration Enterprise-wide deployment: Implement hybrid classical/quantum-resistant systems and software Migrate critical applications and PKI aggregation points to quantum-safe algorithms Update business continuity and disaster recovery plans Achieve full compliance with regulatory requirements as a priority over other systems Key Takeaways for Business Leaders Start planning now: The quantum threat timeline is uncertain, but the need for preparation is immediate Prioritize critical assets: Focus initial efforts on protecting your most sensitive and long-lived data Invest in capabilities: Quantum cryptography expertise will become as essential as any other IT security skill Engage stakeholders: Quantum security requires coordination across IT, compliance, procurement, and business units Monitor developments: Stay informed about quantum computing advances and regulatory updates Mahalo! Further Reading: Post Quantum Cryptography Coalition: PQC Migration Roadmap Post Quantum Cryptography Coalition: International PQC Requirements Post Quantum Cryptography Coalition: Inventory Workbook Essence of Linear Algebra Quantum Computing for the Very Curious Looking Glass Universe: Why I Left Quantum Computing Research US National Quantum Initiative
PKI Today 2026: Your ACME Client Is Going to Need Friends
The Protocol Dream The dream is one ACME client pointed at one free certificate authority (CA), renewing everything on a cron job until the heat death of the universe. It holds right up until you need a cert that CA structurally refuses to issue, and then the tidy picture shatters. Start with the part that does work, because it works well. The 47-day cadence, covered in our previous article, continues on schedule. The part that makes it survivable at scale is ARI, ACME Renewal Information [2], which lets the issuing CA tell the client when to renew rather than leaving every client to guess and stampede. ARI is also how a CA signals a mass-revocation event in advance, so the same mechanism that smooths ordinary renewal is the one that saves you when an issuer has to rotate a large batch of certificates on short notice. If your entire estate were public-facing domain-validated TLS, you could very nearly stop reading here. It isn't. Your estate has certificates that free public CAs cannot or will not issue, and the protocol layer is the part that will mislead us about that gap, because the protocol layer is actually converging. ACME began in the Web PKI, and it is steadily becoming the way internal issuance gets automated too. Enterprise CAs now speak ACME on private networks. The device-attest-01 challenge, now an IETF ACME working-group draft [3], folds hardware-attested device enrollment into ACME itself, replacing what mobile-device management used to hand to SCEP. The client proves the certificate key was generated inside a secure crypto-processor it can't be exported from, using a WebAuthn attestation statement, and external account binding lets the enterprise CA control exactly which devices may enroll. The legacy protocols aren't dead evenly: EST still owns a large installed base in the federal space CMP, with its Lightweight CMP Profile, is a shrinking niche outside a handful of telecom and industrial deployments SCEP lingers in network gear, mostly legacy installations [4] The direction of travel is unmistakable: one protocol, perimeter and internal, services and devices. Which is exactly what makes the dream feel reachable, and exactly why it is about to mislead you. Where Our Dream Breaks Because the dream turns to reality and diverges at the CA, not the protocol. Let's Encrypt is domain-validated (DV) by deliberate design and says so plainly: it does not issue, and has no plans to issue, organization-validated (OV) or extended-validation (EV) certificates. Human vetting those cannot be automated the way DV can [5]. That's not a gap in their roadmap, it is the roadmap. The moment a service needs an OV or EV certificate, which is to say the moment a compliance regime or a counter-party demands a verified legal identity rather than mere control of a domain, you're off Let's Encrypt and onto a commercial CA with its own enrollment, its own profiles, and its own automation story. That human-in-the-loop step doesn't go away just because everything around it got automated. Your ACME tooling needs to know which certificate profiles still require manual vetting, route those requests differently, and account for the fact that a human on the CA's side, working on business hours and business timelines, is now the slowest link in a pipeline built for six-week cadences. Automate the parts that can be automated and design process for the part that can't (INTERNS FTW). From there our divergence runs along three paths, each one independently forcing us off the single-CA road. Assurance level: DV from one source, OV and EV from another, because no single free-and-automated CA spans the range. Jurisdiction and scheme: A regulated European service can need two certificates for one endpoint at the same time. A qualified website authentication certificate satisfies eIDAS and the open-banking obligations under PSD2 [6], while a separate browser-trusted certificate comes from a CA in the root programs, because qualified status and browser trust are not the same trust and are not granted by the same body. You run both, on one service, sourced from two issuers, for reasons that have nothing to do with engineering convenience. Timing: As post-quantum issuance arrives, different CAs and different root programs will enable it on different schedules. The transition itself splits your portfolio between the CA that can issue what you need today and the one that can issue what you will need next. Three different reasons, same conclusion: pick one CA and something on this list eventually tels us no. Notice what's not on that list: the protocol. Even with ACME spreading across public and internal issuance alike, a shared protocol unifies the wire format, not the policy above it. Different CAs expose different validation methods, different profiles, different external-account-binding requirements, and different rate limits. "We use ACME everywhere" describes your transport and almost nothing about your actual operational burden. The burden has a resilience dimension the dream never accounts for. CAs do occasionally lose the trust of the root programs, and when an issuer is distrusted, the shops that can re-issue across a second CA in hours are in a very different position from the shops that built everything on one. Multi-CA stops looking like sprawl and starts looking like a preferred posture that survives a bad week. This is the point at which everyone reaches for a certificate-lifecycle-management platform, and they are not wrong to. A Certificate Lifecycle Management (CLM) platform can discover, administer, and automate over a lot of this, but the fragmentation isn't a tooling accident you can buy your way out of. It runs all the way down to the algorithms inside the certificate, and the reason it goes that deep is that the people writing the standards haven't agreed with each other either. Hey, that could be the next topic in this series! References [1] IETF RFC 8555. Automatic Certificate Management Environment (ACME) [2] IETF RFC 9773. ACME Renewal Information Extension (ARI) [3] IETF draft-ietf-acme-device-attest [4] Older internal-enrollment protocols ACME is now displacing: EST (RFC 7030), CMP (RFC 4210) with the Lightweight CMP Profile (RFC 9483), and legacy SCEP (RFC 8894) [5] Let's Encrypt. FAQ: issues domain-validated certificates only, no OV or EV, by design. [6] Regulation (EU) No 910/2014 (eIDAS), consolidated text as amended by Regulation (EU) 2024/1183. QWACs defined at Art. 3(38)–(39), requirements in Art. 45 and Annex IV; browser recognition obligation in Art. 45a.Even More Hands-On Quantum-Safe PKI: Building Enterprise PQC Certificate Authorities with EJBCA Community Edition
Your PQC CAs just graduated from the command line to the corner office. Back in December and again in January we published Hands-On Quantum-Safe PKI, a step-by-step lab for building quantum-resistant certificate authorities from scratch using OpenSSL. You learned ML-DSA algorithms, built a Root CA, chained an Intermediate CA, issued end-entity certificates, and stood up revocation infrastructure, all by hand, one command at a time. Billions of you went through it. Six of you even enjoyed it. But here's the thing about building a CA with OpenSSL: it works beautifully for learning and it works beautifully for testing. It does not work beautifully at 2 AM when someone asks you to revoke a certificate and your "management interface" is vim index.txt . Calgon, take me away! The lab has expanded. The Post-Quantum Cryptography Step-by-Step Lab now includes a complete EJBCA Community Edition deployment track, nine modules that take you from bare metal to enterprise-managed, quantum-resistant Certificate Authorities running inside a real PKI management platform. Same SassyCorp identity. Same ML-DSA-87 Root CA and ML-DSA-65 Intermediate CA. Now with a database, an application server, audit logs, and a web UI that doesn't require you to memorize openssl ca flags. But if you want to we won't stop you and we love you for that. 🔥🔥🔥 Access the Complete Lab on GitHub 🔥🔥🔥; The new lab walks through deploying Keyfactor's EJBCA Community Edition v9.3 on Ubuntu with WildFly 35, MariaDB, and OpenJDK 21. You configure a 3-port TLS architecture, HTTP on 8080, public HTTPS on 8442, and mutual TLS admin access on 8443 where your browser has to prove it's worth it is before EJBCA lets you touch anything. It's PKI with actual access control, which is a refreshing change from chmod 600 being your entire security model. The Evolution: Why This Matters Think of it as three stages of PQC readiness. The first lab (CNSA 2.0 with OpenSSL) taught you algorithm mechanics for federal use cases. The second lab (FIPS 203/204/205) broadened that to commercial compliance. This third expansion puts those same algorithms inside infrastructure that can actually manage certificates at scale — issuance, renewal, revocation, OCSP, CRL distribution, role-based access, and audit logging that doesn't live in a flat file. That progression is intentional. You can't meaningfully operate an enterprise PKI platform if you don't understand what's happening underneath it. And you can't stop at OpenSSL if your organization needs to manage more than a handful of certificates. The compliance clock is running - NIST is deprecating classical asymmetric algorithms by 2030, the NSA wants full CNSA 2.0 enforcement by 2033, and Australia is trying to eliminate classical public-key crypto entirely by 2030 (bless their ambitious hearts). Having people who can actually stand up and operate PQC certificate authorities isn't optional anymore. It's PKI Thunderdome! What You Can Do Next After completing the lab, you'll have a fully operational EJBCA instance with three CAs — the RSA ManagementCA for internal admin plumbing, plus your ML-DSA-87 Root and ML-DSA-65 Intermediate for quantum-resistant certificate operations. From here you can issue end-entity certificates through EJBCA's enrollment interface, configure CRL distribution points, set up OCSP responders, explore the REST API, and experiment with hybrid certificates that combine PQC and classical algorithms. You've got an enterprise PKI playground that happens to be quantum-resistant. The whole thing runs on a single VM if you want, that's what we did. No Docker, no scripts, no "just run this compose file and trust me." Every command is manual, every configuration file is edited by hand, and every step explains why. We remain faithful disciples of the "Learn Python the Hard Way" school of pedagogy, mostly because it works and partly because suffering builds character. The lab is open source, community-driven, and waiting for your pull requests. Go break something, then fix it. That's how you learn. Access the Complete Lab on GitHub → References Resource URL EJBCA Community Edition (Keyfactor) https://github.com/Keyfactor/ejbca-ce Keyfactor PQC Hybrid CA Tutorial https://docs.keyfactor.com/ejbca/latest/tutorial-create-pqc-hybrid-ca-chain Keyfactor EJBCA Installation Docs https://docs.keyfactor.com/ejbca-software/latest/installation WildFly 35 Documentation https://docs.wildfly.org/35/ PQC Coalition — International Requirements https://pqcc.org/international-pqc-requirements/PKI Today 2026: The Standards Aren't Converging. It's a Feature, Not a Bug
It's tempting to assume that once the National Institute of Standards and Technology (NIST) finalized its initial post-quantum standards in 2024 [1], the world inherited a shared rulebook (as we mostly had in the past). What the world actually has today is roughly a shared calendar and several competing rulebooks, and the gaps between them are precisely where multinational PKI runs into trouble. The Shared Calendar The shared calendar is real, it tightened this year. The United States moved last, but it moved hard. Executive Order 14412, signed June 22, 2026, converted what had been draft guidance into enforceable deadlines. Federal high-value and high-impact systems must complete key-establishment migration by the end of 2030 and digital-signature migration by the end of 2031. Contractors are pulled to a 2030 line through the acquisition rules [2]. The defense side keeps its own clock under CNSA 2.0, with a 2027 acquisition gate and ML-KEM-1024 and ML-DSA-87 as the only approved parameter sets against NIST's quantum-secure guidelines [3]. Europe's coordinated roadmap lands in the same window, with national plans due by end of 2026. High-risk systems must complete migration by 2030, and full transition by 2035. DORA and NIS2 are already making a cryptographic inventory and demonstrable crypto-agility binding obligations, rather than aspirations [4][5]. Canada's procurement clauses bite April 1, 2026 [6]. Australia's signals directorate is targeting end of 2030 for ceasing traditional asymmetric cryptography entirely [7]. Read down the list and the dates cluster around 2030 hard enough that you can almost plan against a single number. You can't, because the dates are where the agreement ends. The rulebooks diverge on two things that matter enormously the moment you operate across borders. Jurisdiction Key date(s) Hybrid stance Algorithm set US federal (EO 14412) Key est. 2030, sig 2031 Unspecified; follows NIST sequencing ML-KEM, ML-DSA, SLH-DSA US NSS (CNSA 2.0) 2027 acquisition gate, 2035 full Pure (no hybrid requirement) ML-KEM-1024, ML-DSA-87 only EU (roadmap + DORA/NIS2) Plans 2026, high-risk 2030, full 2035 Hybrid encouraged NIST set; floating EU-grown options Germany (BSI) Aligned ~2030 Hybrid mandated NIST + FrodoKEM + Classic McEliece France (ANSSI) Aligned ~2030 Hybrid required (KEM and signatures) NIST + conservative hedge Australia (ASD) Traditional gone by end-2030 Permitted, not mandated; pure end-state ML-KEM-1024, ML-DSA-87 (end state) South Korea (KpqC) Standardizing from Jan 2025 Not specified SMAUG-T, NTRU+, HAETAE, AIMer (homegrown) China (ICCS / SM) Separate track, ongoing Not specified SM suite + own PQC call Sources by row: US federal [2]; US NSS [3]; EU [4][5]; Germany [8]; France [9]; Australia [7]; South Korea [10]; China [11]. Japan sits closest to the NIST-plus-hybrid posture with a 2035 target [12], and Canada is NIST-aligned and procurement-driven [6]; both are in the prose rather than the table because neither is a divergence story. Divergence One: Hybrid or Pure PQC The first divergence is hybrid versus single PQC -only. Germany's BSI mandates hybrid key exchange and goes beyond NIST by recommending two conservative fall-backs alongside the lattice schemes: FrodoKEM, built on unstructured lattices Code-based Classic McEliece Both carried in TR-02102-1 since its 2020 edition and reaffirmed in the current v2026-01 [8]. France's ANSSI requires hybrid for both key exchange and signatures [9]. This isn't an outlier either. The EU-wide Agreed Cryptographic Mechanisms list, the ECCG document published through ENISA, now recommends FrodoKEM alongside ML-KEM [13]. FrodoKEM was standardized by ISO in 2026 after NIST declined to standardize it, so the conservative-hedge camp has a coordinated European bloc behind it even as NIST and CNSA 2.0 stay structured-lattice-only for now [14] (CNSA adds LMS/XMSS for firmware). Note: NIST did select a code-based backup, HQC, but it's not the same kind of hedge. HQC is still working through the standardization pipeline and is a long way from a usable FIPS algorithm, so it isn't yet an option BSI's or ANSSI's near-term guidance can point the way FrodoKEM already is. Australia takes the opposite posture: it pushes pure high-parameter post-quantum as the 2030 end state. It permits hybrid only as a transition mechanism under a specific control, ISM-1996, which requires that the post-quantum algorithm, the traditional algorithm, or both be ASD-approved [7]. These are all examples of sophisticated agencies, looking at the same algorithms, arriving at nearly opposite deployment doctrines. A system that satisfies ANSSI by mandating hybrid isn't automatically the system Australia wants you running by 2030. This is still a polarizing discussion within relevant IETF working groups, where you'll more often hear the term composite than hybrid, because IETF. Divergence Two: The Algorithm Set The second divergence is the algorithm set itself, and this is where fragmentation stops being a matter of configuration. South Korea ran its own competition and selected its own algorithms in January 2025 [10]: SMAUG-T and NTRU+ for key encapsulation HAETAE and AIMer for signatures China runs the SM family domestically and opened its own post-quantum call in early 2025, on a separate track from NIST by design [11]. Japan sits closer to the NIST-plus-hybrid posture with a 2035 target [12]. So in one region we have a NIST-aligned regime, a NIST-plus-conservative-hedge regime, a pure-PQC regime, a homegrown-algorithm regime, and a fully separate cryptographic universe, all at once. There is no single crypto policy that satisfies all of them. Neat. Divergence Three: The Protocol Layer That algorithm-set fragmentation has a second, quieter layer underneath it: not every national selection has a path into the protocols the rest of the world actually runs. CA/B Forum-governed webPKI and the TLS stacks that consume it depend on IETF-registered codepoints, PKIX algorithm OIDs, TLS registry entries, and JOSE identifiers, and right now that registration work tracks NIST's picks almost exclusively. ML-KEM has an active TLS working group draft moving toward IANA codepoints [15] FrodoKEM, despite losing the NIST round, still has a foothold through the BSI-and-ANSSI-adjacent authors pushing it into IETF IPsecMe and LAMPS working groups [16][17] Korea's KpqC algorithms have none of that: SMAUG-T, NTRU+, HAETAE, and AIMer exist as working OpenSSL integrations only through the research-grade Open Quantum Safe project, with no IANA registry entry or IETF draft to reference at this time [18] A KpqC-compliant Korean system and a CNSA-2.0-compliant American one aren't just running different policies. Outside a handful of purpose-built interop layers, they may not be able to negotiate a handshake with each other without proxy. This is the upstream cause of everything article four described. The reason our certificate portfolio fragments across CAs isn't just commercial, it's that the algorithms those certificates carry, and the deployment rules that govern them, are set by bodies that have not converged and show no sign of fully converging. The Qualified Website Authentication Certificate (QWAC) we juggle as an operational headache is downstream of a genuine policy disagreement about who gets to decide what a trustworthy certificate is. Which leaves the only question that actually matters once the inventory is built, the cadence is automated, and the regimes are mapped: out of all this, what do you actually deploy, and in what order? Yep, we're gonna cover that too. Mahalo! References [1] National Institute of Standards and Technology (NIST). FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) [2] Executive Order 14412, signed June 22, 2026 (Dates and provisions from the primary; key-establishment migration end-2030, digital-signature migration end-2031, contractor pull-forward via acquisition rules) [3] US National Security Agency (NSA). Announcing the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), 2022. ML-KEM-1024 and ML-DSA-87 as the only approved sets; 2027 acquisition gate, 2035 full. [4] EU NIS Cooperation Group. A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, June 2025. [5] Regulation (EU) 2022/2554 (DORA) and Directive (EU) 2022/2555 (NIS2). Binding cryptographic-inventory and crypto-agility obligations. [6] Government of Canada. Standard Procurement Information Notice (SPIN), PQC procurement clauses effective April 1, 2026; Canadian Centre for Cyber Security (CCCS), ITSM.40.001. cyber.gc.ca [7] Australian Signals Directorate. Information Security Manual (ISM), control ISM-1996 [8] Federal Office for Information Security (BSI). TR-02102-1, Cryptographic Mechanisms: Recommendations and Key Lengths, v2026-01 (23 January 2026), §2.4 (Quantum-Safe Asymmetric Mechanisms): FrodoKEM §2.4.1 (FrodoKEM-976, -1344), Classic McEliece §2.4.2 (mceliece460896/6688128/8192128 and f-variants), ML-KEM §2.4.3 (Cat 3/5 → ML-KEM-768, -1024). [9] Agence nationale de la sécurité des systèmes d'information (ANSSI). ANSSI vies on the Post-Quantum Cryptography transition (2023 follow up), Dec 21, 2023 [10] KpqC (Korean Post-Quantum Cryptography Competition). Final selections announced January 2025: SMAUG-T and NTRU+ (KEM), HAETAE and AIMer (signatures). [11] China: SM cryptographic suite (domestic) and national post-quantum standardization call opened early 2025. [12] CRYPTREC (Japan). NIST-plus-hybrid posture with a ~2035 target [13] European Cybersecurity Certification Group (ECCG), Sub-group on Cryptography. Agreed Cryptographic Mechanisms, Version 3 (working draft, April 2026; published through ENISA). §5.4 lists ML-KEM and FrodoKEM as Recommended key-establishment schemes (FrodoKEM-1344 / -976), adds hybrid (PQ/T) explicitly, and introduces an "Admissible" status replacing "Legacy" (greenfield systems must use Recommended, not Admissible). NOTE: first/working draft, still in consultation. [14] ISO/IEC 18033-2:2006/Amd 2:2026. FrodoKEM standardized as an approved mechanism (June 2026) [15] draft-ietf-tls-mlkem-08, "ML-KEM Post-Quantum Key Agreement for TLS 1.3." D. Connolly, SandboxAQ. IETF TLS Working Group. In WG Last Call as of 24 June 2026 (last call closed 8 July 2026). [16] draft-ietf-ipsecme-hybrid-kem-ikev2-frodo-00, "Post-quantum Hybrid Key Exchange in IKEv2 with FrodoKEM." G. Wang, L. Bruckert (BSI), V. Smyslov, M. Chen. IETF IPsecMe Working Group. Adopted 11 March 2026. [17] draft-smyslov-lamps-frodokem-certificates-01, "Internet X.509 Public Key Infrastructure: Algorithm Identifiers for FrodoKEM." IETF LAMPS Working Group, individual submission. [18] Integration and benchmarking of KpqC algorithms (HAETAE, AIMer, SMAUG-T, NTRU+) into OpenSSL via the Open Quantum Safe liboqs/oqs-provider framework; no corresponding IETF draft or IANA TLS registry entry identified as of this writing.
PQC: a blindspot (logging) on BIG-IP - RFE
On BIG-IP it's currently not possible to log information such as proposed and negotiated Key Exchange Algorithm. No available iRule commands for that. On the other hand, NGINX do offer the possible to log it ($ssl_curve/$ssl_curves variables). I've got a RFE created for the following: Provide new iRule commands in events CLIENTSSL_CLIENTHELLO and CLIENTSSL_HANDSHAKE that outputs the Key Exchange Algorithm: - list of proposed (by the SSL client) Key Exchange Algorithms in CLIENTSSL_CLIENTHELLO - negotiated Key Exchange Algorithms in CLIENTSSL_HANDSHAKE => RFE ID2347153 — "iRule command equivalent to NGINX's $ssl_curve for logging the negotiated KEM/DH group" Don't hesitate to open a support case to bind it to that RFE, the more we are the higher priority will be assigned to implement it (hopefully). 😀 Alexandre
