In an interview with TechRadar, OpenSSL Corporation President Tim Hudson argues that post-quantum authentication is the hard half of the transition. That assessment is independently echoed by the Internet Architecture Board, which is holding a Prague workshop alongside the OpenSSL Conference in October specifically to address post-quantum authentication deployment. The IAB says post-quantum key establishment is now broadly deployed, while authentication lags because the signatures and public keys are measured in kilobytes rather than the few dozen bytes common with elliptic-curve systems.
That division changes the immediate priority. Browser-to-server traffic may already receive quantum-resistant protection during key establishment without an end user noticing. But enterprise certificate authorities, code-signing systems, device identities, VPN gateways, hardware security modules, and firmware-update chains have to carry the larger signatures and certificate material that come with post-quantum authentication.
ML-DSA certificate sizes turn PKI into a performance issue
The size gap is real, not marketing. NIST’s ML-DSA-44 standard defines a 1,312-byte public key and a 2,420-byte signature. An ECDSA P-256 signature, widely used in current Web PKI deployments, is typically 64 bytes. The calculation becomes uncomfortable when a TLS handshake includes a leaf certificate, one or more intermediate certificates, associated signatures, and Certificate Transparency data.
Hudson told TechRadar that a straightforward replacement can add roughly 7KB to 10KB to a fresh connection. The exact number will vary by certificate profile, chain depth, and implementation, but the operational conclusion holds: the concern is not an enterprise suddenly running out of internet transit capacity. It is the chance that a handshake exceeds the amount of data a transport can send before waiting for acknowledgment, forcing another round trip.
That penalty will not land evenly. A desktop on a low-latency corporate LAN may never expose it. A Windows laptop on congested hotel Wi-Fi, a field device using satellite backhaul, or a mobile client reaching an externally hosted application can. The result is a worse tail-latency experience: the slowest connections become slower, even if median response time looks acceptable in a data-center benchmark.
This is why the OpenSSL president’s “architectural” description deserves more attention than the bandwidth framing. If the Web PKI moves to post-quantum authentication at scale, certificate-chain design, trust-anchor distribution, and handshake behavior become performance engineering concerns. The proposed responses discussed in the broader standards community include reducing transmitted intermediates, negotiating trust anchors, and using Merkle-tree-based certificate approaches rather than treating a larger certificate as a drop-in replacement for a smaller one.
For administrators, that means PQC readiness testing cannot stop with “the TLS handshake succeeded.” Test fresh connections, resumed connections, chains of the actual length your services use, and links with packet loss and elevated round-trip time. A certificate that works in a lab may impose a visible cost when it meets real-world QUIC anti-amplification limits and a lossy cellular network.
The immediate risk is stored confidentiality, not yesterday’s signatures
The popular “Q-Day” shorthand has muddled two different risks. A sufficiently capable quantum computer would threaten RSA, Diffie-Hellman, ECDH, and ECDSA because Shor’s algorithm attacks the mathematical problems on which those public-key systems rely. Australia’s Signals Directorate makes that distinction directly in its cryptography guidance, while noting that symmetric primitives such as AES and SHA face a different, less immediate planning path.
The problem that exists today is often called “harvest now, decrypt later.” An attacker can collect encrypted traffic or archives now and wait for future computing capability to make decryption practical. Data with a long confidentiality life—government material, intellectual property, legal files, health records, merger plans, source-code escrow, credentials, and operational telemetry—therefore deserves earlier attention than data whose sensitivity expires in months.
This is also where the submitted interview needs a correction in tone. The Enigma comparison is a useful illustration of why advances in computation can collapse once-daunting tasks, but it is not a timetable. No cryptographically relevant quantum computer capable of breaking modern deployment-scale public-key cryptography has been publicly demonstrated. NIST’s standards and government transition dates are a response to the time required to migrate global infrastructure, not evidence that such a machine is imminent.
Authentication is a different scheduling problem. A certificate signature verified in 2026 does not become forged retroactively merely because a stronger computer exists in the future. But future code-signing, firmware-signing, device onboarding, and identity systems do require a replacement path before their current trust anchors and hardware roots become a trap.
That distinction should drive triage:
- Long-lived confidential data and externally exposed encrypted traffic should be assessed now for capture-and-decrypt-later exposure.
- Firmware, bootloaders, code-signing keys, HSM-held keys, and private certificate authority roots need priority because replacing them can require hardware, vendor certification, downtime, or physical access.
- Ordinary application cryptography should be made agile, then migrated on an evidence-based schedule rather than through a rushed, isolated algorithm swap.
A cryptographic bill of materials is becoming the starting point
Hudson’s recommendation to inventory before procurement is more than sound advice. The White House’s Executive Order 14412, issued June 22, 2026, directs the U.S. federal government’s move toward NIST-approved post-quantum standards. Two days later, the Office of Management and Budget issued Memorandum M-26-15 on executing that migration. The new federal direction places the cryptographic bill of materials, or CBOM, squarely in the planning conversation.
A CBOM is not merely a spreadsheet of algorithms. The Australian Signals Directorate describes a mature CBOM as an inventory that records the products, libraries, algorithms, protocols, parameters, versions, and configurations on which a system relies. In Windows-heavy environments, that should include Active Directory Certificate Services, internal and external PKI, IIS and reverse proxies, RDP and VPN infrastructure, signed PowerShell modules, Windows Update and third-party patching paths, disk encryption dependencies, smart-card and certificate-based authentication, backup systems, and embedded devices managed from the network.
The unpleasant finding will often be that nobody owns the full list. Application teams may know their TLS library but not which hardware appliance terminates sessions. Security teams may know a corporate root CA but not which operational technology systems have a pinned intermediate certificate or a decade-old firmware signer. Procurement may know a device’s expected service life but not whether its root of trust can accept a new signature scheme.
The inventory is the migration. Selecting ML-KEM or ML-DSA does not solve an estate whose products hard-code algorithms, expose no supported update mechanism, or require replacement certificates to be issued through a vendor-controlled process.
Australia’s ASD offers a useful, concrete schedule: refine a PQC transition plan by the end of 2026, begin transitioning critical systems by the end of 2028, and complete the transition by the end of 2030. Its guidance also says new equipment, applications, and libraries intended for use beyond 2030 should support approved post-quantum algorithms. Those dates are Australian guidance, not a universal legal requirement for private U.S. companies, but they are a credible planning baseline for products that must interoperate globally or operate over long lifetimes.
Hybrid TLS helps now, but it does not end the work
The practical transition technique is hybrid cryptography: combining a classical mechanism with a post-quantum one, so the connection retains protection if either component remains secure. This permits current endpoints to negotiate stronger key establishment while retaining interoperability with endpoints that do not yet support it.
That is useful for TLS 1.3 deployments, and OpenSSL’s provider architecture is designed to let applications use replaceable cryptographic implementations instead of permanently embedding algorithm choices in application logic. For developers with large C or C++ codebases, or products that depend on OpenSSL indirectly, that abstraction can reduce the cost of future changes.
It is not a reason to declare victory. ASD explicitly says it does not recommend hybrid schemes as the destination, although it does not prohibit them. Once a cryptographically relevant quantum computer exists, the classical portion supplies no quantum resistance; organizations should expect to move to purely post-quantum algorithms later. Hudson’s warning that hybrid deployment needs a budgeted second migration is therefore consistent with government guidance.
Windows and enterprise IT teams should ask vendors more specific questions than “Are you quantum-safe?” The productive questions are whether the product supports standardized PQC algorithms, which versions add support, whether that support is available in validated cryptographic modules, whether certificate and key-management tooling can manage the new key types, and whether the vendor has published a supported migration and rollback process.
The validation point is especially important for regulated environments. A standard can be published and supported in open-source code well before a FIPS-validated build or a Common Criteria-certified product is available. Hudson identifies validation lag as a central unresolved bottleneck, and that can leave federal contractors, financial institutions, and critical-infrastructure operators with a gap between a policy deadline and the availability of acceptable certified software.
The practical action is to find the assets that cannot be patched later
The post-quantum transition will be mostly invisible to consumers, as Hudson told TechRadar: browser and operating-system updates can change key establishment without requiring a new purchase or a new user workflow. The disruption falls on the organizations that operate long-lived infrastructure and the vendors whose devices cannot absorb a cryptographic change after shipment.
For IT leaders, the next budget conversation should focus on discovery, testing capacity, and replacement exposure. Identify systems with data that must remain confidential into the 2040s; locate roots of trust with long certificate validity; test how existing HSMs and PKI systems handle post-quantum keys; and put crypto-agility requirements into every procurement that will live past 2030.
The visible internet may change only through a few slower first connections and more device updates. Behind it, the organizations that succeed will be the ones that find their cryptography before regulators, customers, or an unpatchable device force the issue.