The post-quantum conversation has settled into a familiar rhythm: inventory RSA and elliptic-curve cryptography, identify long-lived secrets, test ML-KEM and post-quantum signatures, and build a migration roadmap. That work is necessary. It is also incomplete.
The underexamined problem is trust.
Enterprises do not merely encrypt information. They constantly make assertions about what is legitimate: this server is trusted, this device belongs to us, this software update is authentic, this employee certificate is valid, this API endpoint is the right endpoint, this route authorization is genuine, and this firmware image was approved by the manufacturer.
Those assertions are carried by public-key infrastructure, digital signatures, certificates, code-signing systems, machine identities, trust stores, certificate authorities, and routing-security mechanisms. If quantum-resistant migration treats those components as a secondary detail behind “encryption,” an organization can become quantum-ready on paper while leaving its decision fabric exposed.
01 / The encryption story is too small
“PQC migration” is often interpreted as replacing vulnerable public-key encryption and key-establishment mechanisms. NIST's current migration guidance is broader: a cryptographic inventory should include algorithms, protocols, keys, certificates, systems, components, and the data protected by cryptography. NIST also explicitly identifies certificates and certificate chains as inventory objects. NIST NCCoE's June 2026 FAQ makes that scope explicit.
That distinction matters because a certificate is not merely an encrypted file. It is a signed statement about identity and authorization. A digital signature is not merely a privacy control. It is an integrity and authenticity control.
When the underlying public-key assumptions fail, the question becomes much larger than “Can someone decrypt this database?” It becomes:
- Can an attacker manufacture a credential that looks legitimate?
- Can software signing chains still distinguish authorized releases from forged releases?
- Can devices validate one another without trusting an obsolete signature scheme?
- Can network infrastructure distinguish a legitimate routing authorization from a counterfeit one?
- Can an organization rotate trust anchors without breaking millions of dependent systems?
02 / The certificate is becoming a security boundary
Modern enterprises have quietly transformed certificates into infrastructure. TLS certificates protect web traffic. Mutual TLS certificates authenticate services. Device certificates identify machines. Code-signing certificates establish software provenance. Enterprise PKI supports smart cards, VPNs, Wi-Fi authentication, workload identity, privileged administration, and internal service meshes.
That means the certificate lifecycle is part of the attack surface.
Current IETF work is already grappling with the mechanics of post-quantum authentication, including composite certificates, dual certificates, and PQC-only certificates. A 2025 IETF Internet-Draft on PQC signature migration frames the problem as a transition in PKI-based protocols rather than simply a replacement of one encryption algorithm. The document is work in progress—not a final standard—but its existence is a useful signal: the trust layer is becoming a migration problem of its own.
There is another complication. A certificate ecosystem is a dependency graph. A root CA signs an intermediate. The intermediate signs certificates. Applications trust stores. Devices contain firmware and embedded roots. Service meshes rotate identities. Vendors build certificate automation into products. A change at the top can create failure at the bottom.
That is why a successful PQC pilot can be almost meaningless if the organization has not mapped the trust relationships around it.
03 / The machine-identity problem nobody wants on the board agenda
Human identities are comparatively visible. Machine identities are not.
A large enterprise can have certificates and cryptographic identities attached to servers, containers, APIs, IoT devices, industrial controllers, workloads, build systems, code-signing pipelines, network appliances, databases, HSMs, mobile devices, and third-party integrations. Many are created and rotated automatically. Others are embedded in firmware or vendor-managed systems.
Quantum migration therefore collides with a problem that cybersecurity teams already struggle to solve: knowing what exists.
Certificates and keys may exist outside the CMDB, IAM platform, or security tooling that leadership assumes is authoritative.
Roots, signing keys, algorithms, and validation logic can be buried inside firmware, appliances, libraries, and vendor software.
A post-quantum credential is useless if dependent clients cannot parse it, validate its chain, or complete the handshake.
An enterprise may be ready while a critical supplier's PKI, code-signing infrastructure, or device fleet is not.
The board-level risk is not simply cryptographic weakness. It is loss of reliable identity at scale.
04 / The overlooked attack: trust inversion
Consider a future in which a cryptographically relevant quantum computer exists and a vulnerable signing algorithm is still accepted somewhere in an enterprise's trust chain.
The obvious scenario is decryption. The less discussed scenario is trust inversion: an adversary uses a broken public-key assumption to create something that a system recognizes as authentic.
The impact depends on the role of the compromised key. A forged web certificate may enable interception. A forged device credential may provide network access. A compromised code-signing key can turn a software distribution channel into a delivery mechanism. A compromised trust anchor can invalidate the entire meaning of downstream identity assertions.
This is why post-quantum digital signatures deserve board-level attention equal to key establishment. NIST's current PQC program identifies ML-DSA and SLH-DSA as foundational signature standards, while continuing to evaluate additional signature schemes. In May 2026, NIST advanced nine additional candidates to a third round of evaluation. The standards landscape is therefore active, and enterprises should build for agility rather than assume today's PQC choice will be the last cryptographic change they ever make.
05 / Routing is part of the quantum trust fabric
One of the clearest examples of this broader problem is the Resource Public Key Infrastructure, or RPKI, which helps authenticate Internet number resource holdings and routing authorizations.
In July 2026, an IETF Internet-Draft proposed a post-quantum authentication layer for RPKI, explicitly noting that current RPKI relies on classical RSA signatures and that replacing signatures at global scale creates repository-size and validation-cost problems. Another June 2026 draft proposed an initial PQC signature profile for RPKI.
That is an important clue about the future of cybersecurity: quantum migration is becoming a systems-engineering problem at the infrastructure level. It is not confined to databases, browsers, VPNs, or encrypted archives.
The trust fabric includes the systems that decide which networks, software, machines, services, and identities deserve belief.
06 / What “quantum ready” should mean in 2026
A more useful executive definition is:
It is not enough to know where RSA and ECC exist. The organization must know which identities depend on them, which trust anchors validate them, which vendors control them, and how those relationships will be rotated without operational collapse.
07 / The board question should be different
Most executives will eventually hear some version of: “What is our PQC migration plan?” That is a reasonable question. It is not the most revealing one.
The better question is:
That question forces a company to connect cryptography to operational resilience. It pulls PKI, IAM, endpoint engineering, software supply chain, network security, procurement, OT, cloud architecture, incident response, and third-party risk into one conversation.
It also changes the economics of the migration. Instead of buying “quantum-safe” products, the organization begins building a replaceable trust architecture.
Conclusion / The real race is not to decrypt
The post-quantum era will not arrive as a single switch being flipped. It will arrive as a long period in which classical and post-quantum mechanisms coexist, vendors move at different speeds, standards evolve, and enterprises discover dependencies they did not know they had.
NIST's latest migration work emphasizes cryptographic discovery, interoperability, inventory, and crypto agility. That direction is correct. But executive programs should extend the same discipline to the trust relationships those cryptographic mechanisms support.
The organization that wins the transition will not simply be the one that replaces the most RSA keys first.
It will be the one that can change its cryptographic assumptions without losing its ability to tell the difference between legitimate and illegitimate.
That is the quantum trust problem. And unlike the quantum computer itself, the enterprise does not have to wait for it to become real before the risk becomes measurable.
Selected Sources & Further Reading
- NIST, Frequently Asked Questions about Post-Quantum Cryptography, updated June 30, 2026.
- NIST, Post-Quantum Cryptography, current project and standards guidance.
- NIST, CSWP 39upd1: Considerations for Achieving Crypto Agility, updated June 29, 2026.
- NIST, Nine Candidates Advance to the Third Round of the Additional Digital Signatures for the PQC Standardization Process, May 14, 2026.
- IETF, Guidance for Migration to Composite, Dual, or PQC Authentication, Internet-Draft, October 2025. Work in progress.
- IETF, Post-Quantum Authentication for the Resource Public Key Infrastructure, Internet-Draft, July 2026. Work in progress.
- IETF, Root CA Certificate Rekeying in the Scenario of Post Quantum Migration, Internet-Draft, May 2026. Work in progress.