Sixteen weeks from now a date lands that does not ask you to replace a single algorithm.
31 December 2026 is the EU's first post-quantum checkpoint. Read what it actually asks for and the surprising part is how little of it is cryptography.
It asks whether you can produce a record. Who owns this. What runs on what. Which systems would still cause real damage if the traffic protecting them were decrypted a decade from now.
Most organisations cannot produce that record today. The algorithm gap is downstream of it.
What does the roadmap mean by a "minimum level of readiness" in all Member States by the end of 2026?
The Coordinated Implementation Roadmap is the first deliverable of the NIS Cooperation Group work stream on post-quantum cryptography. It states its own purpose plainly: it is aimed at "facilitating a swift transition to PQC across the EU and ensure a minimum level of readiness in all Member States by the end of 2026."
Readiness, not migration. That distinction is the whole document.
Milestone 1 is dated 31.12.2026 and carries two parts. Eight First Steps, and two main achievements: PQC transition planning and pilots for high- and medium-risk use cases have been initiated, and initial national PQC transition roadmaps have been established by all Member States.
"Initiated." "Established." Nothing in Milestone 1 requires a completed post-quantum cryptography transition anywhere.
What it requires is that the transition has a documented shape. A stakeholder list. An inventory. A dependency map. A risk analysis. A plan with a timeline attached. Those are artifacts, and artifacts get read back to you by someone else.
Does Milestone 1 bind Member States, your organisation, or both?
Be precise here, because a lot of vendor commentary is not.
The document is a high-level concept paper aimed at the Member States. It creates no directly binding duty on your entity, and anyone telling you 31 December 2026 is your compliance deadline is selling something.
But it does two things that matter to you.
It names you. The roadmap says it "will also be useful for government organisations and other entities including the ones that have to comply to the NIS2 Directive," and that public administration entities and other critical infrastructures, notably those in scope of the NIS2 Directive, "should refer to this document and its further releases."
And it tells you where your duty already lives. It calls these First Steps "no-regret" moves that support "the compliance with cybersecurity regulations like the NIS2 Directive." Its executive summary is blunter: NIS2 and DORA require entities in scope to adopt cybersecurity risk-management measures, including on the use of state-of-the-art cryptography, and provide that the entities' management bodies can be held liable for failing to comply.
So the chain runs: no new obligation from this document, an existing obligation under NIS2 and DORA, and now a published European reference for what adequate looks like.
That is a worse position than a deadline, not a better one. A deadline you plan against. A published benchmark gets applied backwards, to every risk decision you have already made.
Which of the eight First Steps produce a record someone else can read back?
The eight First Steps, as listed in the Milestone 1 box:
→ Identify and involve stakeholders → Support mature cryptographic asset management → Create dependency maps → Perform quantum risk analysis → Include the supply chain → Create a national awareness and communication program → Share knowledge and get involved with the NIS CG work stream on PQC → Develop a timeline and an implementation plan
Two of those belong to the Member State: the awareness programme and the work stream participation. The other six land on entities, and five of them terminate in a document.
Cryptographic asset management is defined tightly. The roadmap asks for current inventories of assets that perform cryptographic operations and of assets that have cryptographic operations performed on them. Both halves. It recommends a standardised format, naming CBOM, the Cryptographic Bill of Materials, as an extension of the SBOM standard.
Quantum risk analysis has a stated destination. Member States should encourage public administrations and other critical infrastructures, notably entities in scope of the NIS2 Directive, to include the quantum threat to cryptography in their top-level risk management, which the roadmap says "ensures that the threat and risk is being discussed and evaluated at the board level."
Supply chain inclusion has a verb attached. Every organisation needs to start the dialogue with product and service suppliers, "because the transition depends on them."
Stakeholder identification names functions: CTO, CISO and CIO from ministries, large government organisations and other critical entities, plus supervisory bodies for NIS2 and eIDAS.
The implementation plan gets a structure: prepare, plan, act, which the roadmap is careful to say are not consecutive phases but three timelines running differently per use case.
The list, it adds, "should not be seen as exhaustive." The eight are a floor.
How do the three quantum risk levels decide what you pilot first, and what the 2030 and 2035 dates actually cut off?
The roadmap defines three quantum risk levels: low, medium, high. Three factors influence the level of a use case.
→ The quantum weakness of the cryptography used → The expected impact of that cryptography being broken → The estimated time and effort required to migrate to PQC
The third factor is the one people skip, and it is the one that reorders your list. A system taking more than eight years to migrate carries a medium or high level before you argue about impact at all. If that effort is high and the impact is high too, for example securing software updates, the level is high.
The confidentiality rule is the sharpest test. If confidentiality needs to be protected for at least ten years, and an attack after ten years or more would still have significant impact, the level is high.
Apply that literally. It is a question about your retention periods and your contractual confidentiality terms, not about your TLS configuration.
The forward dates then do specific work. For high-risk use cases, quantum-vulnerable public-key mechanisms shall not be used stand-alone after the end of 2030. For medium-risk use cases, after the end of 2035. Note "stand-alone": the recommended replacement is a standardised hybrid combination including PQC, where feasible and suitable.
Both dates are ahead of us. So is Milestone 1. Nothing here has expired. What has already started is the clock on complex systems. The roadmap flags them directly: systems with a long life-cycle, or complex ones such as PKIs, take a lot of time, so detailed transition plans for them should be developed as soon as possible, with pilots and testing to ensure business continuity.
Why are dependency maps and supply chain reach, not algorithm choices, the constraint on your 2027 plan?
One sentence in the First Steps is load-bearing and easy to read past. On dependency mapping, across applications, products, platforms and operations, covering both internal dependencies and third party dependencies, the roadmap says: "Essential information for prioritisation and planning can only be provided after this step."
Can only be provided after this step.
An inventory alone does not produce a plan. You can hold a complete cryptographic bill of materials and still be unable to sequence one migration, because you do not know what breaks when a certificate authority, a message broker or an embedded device changes its key exchange.
The roadmap goes further. The dependency mapping "will eventually be driven by supply chain dependencies." Your migration order is not yours to set. It is set by the roadmap of every supplier whose product sits in the path, which is why the supply chain is its own First Step and why the transition "depends on them."
So the sequencing for the next sixteen weeks is not "hybrid or pure PQC." It is: inventory both halves of the crypto estate, map internal and third party dependencies on top of it, then let the risk levels order the pilots.
Algorithm selection is a decision you make once the constraint graph is visible. Third-party reach is the constraint graph. Same discipline you already run on third-party risk, pointed at cryptography.
What should your own agents do inside your perimeter, and what has to stay deterministic?
Look at what the First Steps actually cost.
Discovering assets that perform cryptographic operations. Discovering the assets that have cryptographic operations performed on them. Mapping what depends on what. Pulling evidence out of internal systems. Reporting status upward so the board conversation the roadmap asks for can happen at all.
That is labour, not judgment. Repetitive, deep inside your estate, and exactly the work a compliance team of four never finishes. It is also the work now being handed to agents.
Which raises the question the current wave of "agentic GRC" answers badly: whose trust boundary is the agent running in.
The prevailing model gives a vendor's agents standing access across your systems so their platform can go find your assets. Read that against what this quarter asks of you. Inventory your cryptographic assets. Map your third party dependencies. Open a supply chain dialogue because the transition depends on your suppliers. Granting a new third party persistent access to the estate you are trying to inventory is a strange way to begin.
We build it the other way round.
The engine is deterministic. Every obligation, risk and control traces to verbatim regulation text, grounded in source law rather than generated from a model's memory. That is what makes it compliance AI you can put in front of an auditor.
Because the record is deterministic, the labour can be delegated safely. The platform is open over MCP and API, so your own agents run the discovery, the evidence gathering, the control status and the posture reporting inside your perimeter, under your IAM, your logging and your DLP. Bring your own agent, Claude Code or any MCP client. We never receive a credential. Only attested signal comes back, and it lands on a source-cited record.
Your agents do the work. Our engine keeps it honest.
Automation without exposure.
The inversion matters more here than in most compliance work. The artifact Milestone 1 asks for is a map of precisely the assets you would least like a third party to hold standing access to.
Which Next Steps should already be running before the Milestone 1 date passes?
The Next Steps are not a 2027 problem. The roadmap says they should be considered "as soon as possible and not wait for completion of the First Steps or the end of the year 2026," and that waiting for the completion of Milestone 1 "cannot be afforded."
Four have hooks worth acting on now.
Cryptographic agility. Support for it should be considered first when new products are developed, and from December 2027 it "would need to be systematically implemented according to the CRA." The roadmap also suggests including cryptographic agility in evaluation of NIS2 conformity.
Quantum-safe upgrade paths. Even where a product is not fully transitioned, software and firmware upgrade routines should use quantum-safe signatures, so it can be upgraded safely later. Securing software updates is the roadmap's own example of a high quantum risk level.
Resource allocation. Budget and personnel, estimated and secured at all levels, with organisations encouraged to make budget reservations in their life-cycle management. Your 2027 budget cycle closes before Milestone 1 does.
Certification. Schemes should account for the quantum threat, and the European Cybersecurity Certification Group's Agreed Cryptographic Mechanisms document, which applies to the EUCC scheme, already carries PQC algorithm recommendations in version 2.
None of these wait for a completed inventory.
What this actually asks of you
Milestone 1 is not a cryptography deadline. It is a readiness record with a date on it, pointed straight at the NIS2 and DORA risk-management duty you already carry.
The record has a shape: inventory, dependency map, quantum risk analysis inside top-level risk management, supplier dialogue, plan with a timeline.
Build it once and it holds for more than PQC. The roadmap calls cryptographic asset management a no-regret move for a reason. The same inventory serves incident and vulnerability management, CRA readiness and your NIS2 file.
Answer once. Assess everything.
A posture you can defend in front of a regulator, a board, or a plaintiff.
FAQ: EU PQC roadmap Milestone 1 and the 31 December 2026 date
Is 31 December 2026 a legal deadline for my organisation? No. The Coordinated Implementation Roadmap is a recommendation aimed at Member States. Milestone 1 dates the First Steps and the initial national PQC transition roadmaps to 31.12.2026. Your binding duty stays with NIS2 and DORA risk management, which the roadmap says these steps support.
What counts as a high quantum risk use case? Three factors set the level: the quantum weakness of the cryptography used, the expected impact of it being broken, and the estimated time and effort to migrate. If confidentiality must hold for at least ten years and an attack after ten years or more would still have significant impact, the level is high. It is also high where migration effort exceeds eight years and impact is high, such as securing software updates.
What is a CBOM and does the roadmap require one? A Cryptographic Bill of Materials, described as an extension of the SBOM standard. The roadmap recommends it as a standardised format for the cryptographic inventory rather than mandating it.
Do I have to stop using quantum-vulnerable public-key cryptography in 2030? For high-risk use cases, the roadmap states quantum-vulnerable public-key mechanisms shall not be used stand-alone after the end of 2030, and after the end of 2035 for medium-risk use cases. Standardised hybrid combinations including PQC are the recommended replacement where feasible and suitable.
See the PQC and NIS2 obligations that actually apply to your profile, each traced to the source text, at agrc.ai. The quantum threat then sits in the same register as everything else you already track under risk management.
Inside 60 minutes you'll see your exposure mapped to the obligations that actually apply to you. No call required.
