Walt Schagen
Jul 28, 2026
14 min read
Most security roadmaps still treat post-quantum cryptography (PQC) as a 2030+ problem. That framing is increasingly wrong, and it has changed sharply in the last twelve months.
There are two clocks running at once. The legal clock: in January 2026, the European Commission proposed writing PQC migration planning directly into NIS2 as a named obligation for every Member State. Once that lands, it is no longer a best practice, it is law.
The threat clock: the qubit budget needed to break standard encryption has collapsed faster than anyone expected. In May 2025, Google researcher Craig Gidney showed that 2048-bit RSA could be cracked in under a week with fewer than one million qubits, a 20-fold reduction from his own 2019 estimate. A follow-up Google paper in March 2026 made similar gains against elliptic-curve cryptography, prompting one of its authors to state publicly that he now puts the probability of a quantum computer breaking a widely-used key type by 2032 at "at least 10%." That is no longer a long-tail risk; it is a number that fits into a risk model.
Google's own planning has moved accordingly. Their VP of Security Engineering has publicly placed the company's internal planning horizon at 2029 and described harvest-now-decrypt-later, adversaries capturing encrypted traffic today to decrypt it once quantum hardware matures, as the dominant risk right now, not a future one.
This is the part most enterprise plans have not caught up to.
A lot of commentary points to Microsoft's quantum-safe programme, early adoption by 2029, full transition by 2033, as the reference path. Microsoft has made real progress: post-quantum algorithms integrated into their core cryptographic libraries, new APIs available in Windows Server and .NET, hybrid TLS 1.3 key exchange rolling into the stack.
But the timeline itself is not aggressive. A plan that finishes in 2033 is a plan that implicitly bets Q-Day arrives after 2033. Given the algorithmic breakthroughs above, that bet is tighter than it looks.
The right way to read Microsoft's programme is as a floor, not a ceiling. It proves that even the world's largest cloud provider treats this as a multi-year structural transformation rather than a patch cycle. The shape is right, inventory first, foundational libraries second, identity and key management third, the long tail last. The pace is what anyone starting today should be willing to beat.
The Dutch public sector is one of the more organised early movers in Europe. Their central programme, Quantumveilige Cryptografie Rijk (QvC Rijk), exists specifically to help government bodies through PQC migration, backed by a practical handbook developed by the national intelligence service (AIVD), TNO, and the national mathematics institute (CWI). The handbook and the free PQChoiceAssistant tool are publicly available from digitaleoverheid.nl.
The Dutch Court of Audit published a sobering review in early 2026: despite roughly €615M invested in quantum opportunity, preparedness on the threat side remains uneven. The government's own response described PQC migration as "not optional, but necessary."
Within that landscape, RDW, the Dutch vehicle authority, is a compelling early-mover case. Their cryptographic estate is genuinely complex: vehicle credentials, cross-border data exchanges, identity infrastructure tied to EU-wide regulations, and a deep supplier base including embedded hardware vendors. The lesson is not any single technical choice they made. It is the discipline of the approach: a named programme, a working inventory, and active pressure on suppliers to follow.
Most boards still read NIS2 as a procedural exercise: policies, incident reports, risk registers. That reading underestimates the directive considerably.
NIS2 does not tell you which algorithms to use. It does something harder: it requires you to prove you can change them. The practical obligations come down to four things:
The broader EU picture is moving in the same direction. The revised European cybersecurity certification framework is being positioned as a route for organisations to demonstrate compliance, and ENISA's guidance already recommends quantum-resistant algorithms for systems that hold data with long-term confidentiality requirements.
The signal from all of it is consistent: "we use TLS" is no longer a sufficient answer to a cryptography question. "Here is our cryptographic inventory, here are our migration milestones, here is our agility benchmark" is.
You do not need to be a cryptographer to navigate PQC, but a few facts change how you frame the problem internally.
TLS 1.3 is the last version of TLS that matters. There is no TLS 1.4 in the works. The industry's strategy is to evolve TLS 1.3 itself, layering post-quantum key exchange on top of the existing protocol rather than replacing it. If a system is still running an older version, getting to TLS 1.3 is the first concrete step. Without it, none of the quantum-safe improvements rolling out from CDNs, browsers, and major cloud providers will actually apply.
PQC is primarily about asymmetric cryptography. The algorithms broken by quantum computing are the ones used to set up a secure connection; the handshake, the key exchange, the digital signature. The bulk encryption that follows is much less exposed. Symmetric encryption such as AES-256 is considered quantum-safe under current analysis. The urgent work is migrating TLS handshakes, certificate issuance, code-signing pipelines, and identity systems.
Your suppliers are not ready yet, but you are not stuck. Most embedded-system vendors, enterprise software providers, and SaaS platforms are nowhere near PQC-compliant. The right move is asymmetric upgrade: deploy TLS 1.3 with post-quantum hybrid key exchange on the servers you control, while staying compatible with clients and suppliers still on older versions. TLS 1.3 handles this automatically, a modern server speaks the new protocol with clients that support it and falls back gracefully for those that do not. You improve your security posture continuously without waiting for every supplier to catch up.
PQC migration does not exist in isolation. It sits inside a broader acceleration in how quickly vulnerabilities are discovered, exposed, and exploited, and that acceleration is being driven by AI in ways that change the security calculus for every organisation.
The clearest illustration came in April 2026, when Anthropic launched Project Glasswing, a defensive initiative using a frontier AI model to find previously unknown vulnerabilities in widely-used open-source software. The model found:
Most of the vulnerabilities found had been sitting undetected in production code for a decade or more.
The implication runs in two directions. On the defensive side, AI can now find vulnerabilities at a scale and depth previously impossible. On the offensive side, those same capabilities are available to adversaries and you no longer need to be a security expert to use them. The XZ Utils incident from 2024 showed what a patient actor could do with a two-year supply-chain infiltration conducted through social engineering in an open-source project. AI-assisted attackers can compress that kind of operation dramatically.
This is the point at which "AI protects against AI" stops being a slogan and becomes a structural requirement. The same AI capability that surfaces vulnerabilities at scale is exactly what a compliance platform needs to continuously monitor a cryptographic estate, detect emerging weaknesses, and prioritise remediation before an adversary gets there first.
Knowing what to do is straightforward enough. Doing it across thousands of services, repositories, firmware images, third-party libraries, and supplier contracts — and keeping it current as standards, threats, and AI models themselves evolve — is where most programmes stall.
This is the genuine opportunity for AI tooling: a modular compliance platform with a swappable LLM at its core that produces and maintains a live Cryptographic Bill of Materials (CBOM), a structured, auditable record of every cryptographic dependency in the organisation. PQC is the first use case. The next compliance wave is the second. Ongoing vulnerability monitoring is the third.
There are existing tools that scan code and infrastructure for known cryptographic patterns. They are good at what they know, and blind outside it. They struggle with custom-wrapped crypto, with infrastructure-as-code, with older codebases in less common languages, and with anything that requires reasoning across documents.
The opportunity is not to run those tools alongside an LLM assistant. It is to absorb them. A well-designed platform calls the deterministic scanners as tools inside itself, using them for the patterns they handle well, and then adds a reasoning layer on top: catching the long tail, synthesising findings across the estate, mapping everything to the relevant compliance obligations, and generating the readable, audit-ready narrative that a security team can hand to an auditor. From an operator's point of view, there is one platform.
For a platform ingesting source code, certificates, infrastructure configs, and vendor contracts, data sovereignty is not optional. Two sensible architectures:
Because the platform operates on potentially sensitive code and configuration, selective scoping must be a first-class feature. Teams decide repository by repository, and service by service, what is exposed to the LLM, at what tier of processing, and under what retention rules. Highly sensitive codebases stay air-gapped or out of scope entirely. The access logs from those decisions become compliance evidence in their own right.
The LLM, the knowledge store, and the retrieval logic should all sit behind clean internal interfaces so they can be replaced independently. The most important reason is not vendor risk or regulatory flexibility, it is the pace of model improvement.
LLMs get substantially better roughly every six to twelve months. A platform locked to the model that was best in 2026 is locked to 2026-level capability for the duration of a five-year compliance programme. A modular platform absorbs each new generation as an upgrade, not a rebuild. Over that timeframe, the quality difference compounds significantly.
The way AI systems retrieve and reason over stored knowledge is itself changing fast. The most immediate dimension is efficiency: newer retrieval approaches are finding ways to reach higher-quality answers while consuming significantly fewer input tokens, lower operating costs and faster response times at scale.
The deeper shift is from treating knowledge as a bag of documents to treating it as a structured graph of relationships. For a cryptographic inventory, this is particularly powerful: the interesting questions are not "does this document mention RSA?" but "which business-critical service depends on which library, which uses which algorithm, which is now vulnerable?" That is a graph traversal, not a keyword search, and graph-based retrieval handles it far better.
Three retrieval strategies in brief:
A well-designed platform routes questions to the right tier by complexity.
The important design implication: separate what you know from how you retrieve it. A platform that stores knowledge in a well-structured, model-agnostic format can swap retrieval strategies, and LLMs, as the field improves, without rebuilding the accumulated inventory.
For TLS certificates: yes. The ACME protocol, which underpins automated certificate issuance at scale, is well-suited to agent-driven workflows. The platform can request, validate, renew, and revoke certificates automatically across the estate. As post-quantum certificate standards roll out, it can manage those lifecycles too. This is exactly the operational crypto-agility that NIS2 is looking for.
For formal compliance certifications: the platform does not apply on an organisation's behalf, those are awarded by accredited audit bodies. What it can do is generate the documentation, control mappings, inventory exports, and evidence packages that make those audits tractable. For most organisations, producing that evidence on demand is the bottleneck, not the audit itself.
One of the structural questions in building this kind of platform is how the LLM connects to the rest of the organisation's tooling, scanners, certificate stores, asset management systems, CI/CD pipelines, supplier portals.
Model Context Protocol (MCP) is the answer that is emerging as the industry standard. Originally developed by Anthropic, donated to the Linux Foundation in December 2025 under the Agentic AI Foundation, and now co-governed by Anthropic, OpenAI, Google, Microsoft, AWS, Cloudflare, and others — it defines a universal, plug-and-play interface for AI agents to connect to external tools and data sources. Build an MCP server once, and any MCP-compatible AI client can use it.
By March 2026, MCP had reached 97 million monthly SDK downloads — the kind of adoption curve that signals infrastructure, not a trend. Building on it rather than around it is the architectural decision that ages well, in the same way that REST APIs became the assumption for web services a decade ago.
At the core is a live CBOM; an auditable, machine-readable record of every cryptographic dependency across the estate: algorithms, certificates, protocols, libraries, hardware modules, and the chains of dependency between them.
Built around that, the platform:
The operational benchmark that matters is time to algorithm switchover, how quickly the organisation can replace a compromised or deprecated algorithm across its estate. The platform's job is to make that number trend toward days rather than months.
PQC is a multi-year migration. But the capability it forces organisations to build live cryptographic visibility, AI-assisted compliance analysis, continuous vulnerability monitoring, a modular platform that improves with each model generation is exactly the capability needed for every compliance wave that follows, and for every AI-accelerated threat that emerges alongside it.
The organisations that treat PQC as a one-off project will be starting over in three years. The ones that treat it as the reason to build the platform will be ahead for the next decade.
