The Internet Engineering Task Force’s August 27 article, “Post-Quantum Authentication: Up Next,” draws an important distinction for migration programs: post-quantum key establishment is entering deployment, while post-quantum authentication still lacks enough evidence from production environments. The Internet Architecture Board is seeking that evidence for an October workshop, including measurements and experience involving certificate chains, hardware, firmware, offline verification, trust stores, and operational cost.
This is more than a standards-community request for papers. It is a warning against treating “PQC enabled” as a single system state. An organization can negotiate a hybrid post-quantum key exchange and still depend on quantum-vulnerable signatures across identities, software releases, devices, documents, and trust anchors. The two migrations have different urgency models, different dependencies, and very different failure modes.
Key establishment and authentication are separate inventories
Key establishment protects the creation of shared secrets used to encrypt sessions. Its immediate priority is strengthened by harvest-now-decrypt-later risk: traffic captured today could retain value when a capable quantum computer becomes available. Authentication answers a different question—whether a server, user, device, software package, or document is genuinely associated with the identity that signed it.
Those functions often appear together in a protocol, but they should not be collapsed into one inventory row. A TLS service may negotiate a post-quantum key-establishment group while presenting a certificate chain signed with a classical algorithm. A firmware image may never participate in TLS but can remain dependent on a signing key and a verifier burned into a device. A document may need to be validated years after its signer, certificate authority, or application has changed.
The practical inventory unit therefore needs context: algorithm, function, implementation, key location, certificate path, verifier population, protected data, owner, lifecycle, and replacement constraint. “Uses RSA” or “supports ML-DSA” is not enough to sequence work.
The slow part is coordinated acceptance
The IETF article explains why authentication can take longer even if an active quantum forgery threat is not yet present. A key-establishment rollout can often let clients and servers add support independently and negotiate the stronger option when both sides are ready. Authentication requires relying parties to know what they will accept. Certificate authorities, trust stores, cryptographic modules, applications, device firmware, package managers, and audit processes may all need compatible changes.
Some of those participants update quickly. Others are embedded systems, regulated modules, offline roots, or third-party services with long procurement cycles. The bottleneck may be firmware space, an HSM interface, certification, a parser limit, a trust-store release cadence, or a supplier roadmap. None of those constraints is visible in an algorithm-only checklist.
This creates a sequencing problem. Waiting for key-establishment migration to finish before starting authentication discovery may consume the lead time that authentication needs. Programs should track the two workstreams separately while coordinating shared dependencies such as libraries, HSMs, certificate services, testing, and policy.
Larger objects turn assumptions into failures
Post-quantum public keys and signatures can be much larger than familiar elliptic-curve objects. The IETF article uses concrete examples to show how certificate chains can collide with transport budgets, fragmentation behavior, round-trip limits, memory, storage, and signing capacity. Benchmarks for an isolated primitive do not predict whether a complete authentication flow will work at production scale.
Operators need measurements tied to real systems: handshake success, packet counts, latency distributions, retries, CPU, memory, bandwidth, issuance throughput, failure rates, and recovery behavior. They also need to know which component produced the measurement and under which configuration. A result from a browser-facing service may say little about EAP-TLS, secure boot, code signing, identity tokens, or archived signatures.
This is where cryptographic evidence should connect to architecture and operations. The relevant question is not simply whether an algorithm meets a security level. It is whether the full signing and verification path can adopt it without violating protocol, hardware, availability, or compliance constraints.
What organizations should do now
- Split the migration register by cryptographic function. Track key establishment, authentication, code signing, document signing, and other uses independently, even when they share an application.
- Map every verifier population. Identify browsers, services, devices, boot ROMs, trust stores, partners, and offline systems that must accept a new signature or credential.
- Record custody and certification constraints. Capture HSM, TPM, smartcard, secure-element, PKCS #11, backup, replication, and validation dependencies.
- Test complete paths. Measure real certificate chains, tokens, packages, firmware, and failure recovery—not only primitive operations.
- Preserve uncertainty as data. Unknown verifier coverage or an untested supplier path should remain an explicit gap, not become an assumption of compatibility.
How Vista Platform helps
Vista Platform is a self-hosted cryptographic system of record. Its operating loop is discovery, canonical inventory, evaluation, action, and proof. Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps.
For authentication migration, Vista can help teams connect discovered cryptographic evidence to governed inventory records, evaluate quantum exposure, assign and track remediation work, and preserve proof for review. It tracks and governs migration; it does not generate PQC keys or perform every migration step. Vista is not a vulnerability scanner, selected-asset Active Scan is not indiscriminate network scanning, and a discovery gap is not proof that a dependency is absent. Teams can explore the evaluation path on the Try Vista page.
Where uncertainty remains
The IETF workshop is explicitly seeking evidence because several production trade-offs remain unsettled. Different authentication approaches move cost among object size, computation, hardware support, protocol behavior, and ecosystem coordination. Organizations should avoid treating a proposed mechanism or a laboratory benchmark as a universal answer. The durable step today is to make dependencies, constraints, tests, owners, and evidence visible enough that the eventual decision can be made per system.
Sources
- Post-Quantum Authentication: Up Next, Internet Engineering Task Force, August 27, 2026.
- FIPS 204: Module-Lattice-Based Digital Signature Standard, NIST, August 13, 2024.
- RFC 9881: Internet X.509 Public Key Infrastructure—Algorithm Identifiers for ML-DSA, RFC Editor, May 2026.