The post-quantum cryptography transition won't begin the day a regulator publishes a specific obligation. For many European enterprises it has already begun — quietly, in technology contracts, renewal cycles, long-lived data, critical vendors and architectures that aren't always ready to swap cryptography without friction.
2026 is not the year of the post-quantum big bang. For mature organisations it will be the year that separates those who turn a still-abstract threat into an executable programme from those who keep waiting for a magic start date. The second group is already late.
Post-quantum cryptography is no longer a futuristic conversation about algorithms. NIST published its first final post-quantum standards — ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) — in August 2024, a meaningful milestone for the technical transition. In parallel, the European Commission has recommended that member states move towards a coordinated roadmap for post-quantum cryptography adoption.
So the question is no longer just whether there will be business impact. The useful question is when, where and at what cost it will affect each organisation.
From a B2B perspective the core idea is clear: post-quantum readiness is a problem of risk management, enterprise architecture, third-party governance and operational resilience — not just an algorithm change. If it is treated as "swap a library at the last minute", the usual result is technical debt, vendor lock-in, budget pressure and prolonged exposure of critical assets.
This article lays out a realistic roadmap for European enterprises between 2026 and 2028 around three priorities:
- Business-focused cryptographic inventory.
- Prioritisation by risk and feasibility.
- Executable actions that build traction without blocking operations.
1. From technical narrative to business risk
The most common error in management committees is treating post-quantum cryptography as a technical fashion. It is not. It must be integrated into the corporate risk map alongside business continuity, digital resilience, third-party governance and regulatory compliance.
The right question is not just "when will the algorithms be ready?". The useful question for leadership is: what information are we protecting today that will still be sensitive in 5, 7 or 10 years?
That reframing transforms the conversation. It's no longer just about cryptography — it's about future exposure, operational risk and adaptive capacity. Any CEO, CISO, CIO or compliance lead should be asking:
- Which protected data today will retain strategic value years from now?
- Which processes depend on signatures, certificates or key-exchange mechanisms with long lifecycles?
- Which critical systems cannot be easily updated?
- Which suppliers constrain our real migration capability?
- Which technology contracts signed today could become crypto debt tomorrow?
This is where the "harvest now, decrypt later" scenario comes in: capturing encrypted information today to attempt decryption in the future, when sufficiently capable quantum systems exist. Not every organisation is equally exposed, but the risk is particularly relevant in sectors with long-lived or strategically valuable data: healthcare, defence, energy, finance, industry, research, intellectual property, public administrations and technology providers.
In Europe, the regulatory context further pushes towards a reinforced due-diligence posture. NIS2 and DORA are not post-quantum-specific regulations, but they raise the bar on risk management, continuity, resilience, critical suppliers and control evidence.
For that reason, post-quantum readiness must connect with existing NIS2, DORA, ISO 27001 programmes — not create a separate technical silo. If the organisation is already working on cyber resilience, business continuity and disaster recovery, the post-quantum transition should hang from that same frame. That is the first intelligent move.
2. Cryptographic inventory: no map, no transition
You can't migrate what you can't see. And most companies overestimate their cryptographic visibility.
When we talk about a post-quantum inventory, it is not enough to list public TLS certificates or review load balancers, firewalls and VPNs. That's only part of the problem. A useful inventory has to identify where, how and why cryptography is used in critical business processes.
What a useful cryptographic inventory must include
A baseline inventory should cover at minimum:
- Assets and services: applications, APIs, cloud platforms, on-premise systems, OT/IoT, endpoints, backups and exposed services.
- Cryptographic use: encryption in transit, encryption at rest, digital signature, key exchange, certificates, time-stamping and secret management.
- Technical dependencies: libraries, HSMs, PKI, protocol versions, security modules, firmware and embedded components.
- External dependencies: SaaS providers, MSPs, manufacturers, integrators, gateways, cloud platforms and B2B integrations.
- Lifecycle: certificate validity, support horizons, change windows, operational criticality and update constraints.
- Data context: sensitivity, retention, legal impact, regulatory impact, competitive value and persistence over time.
The goal isn't to build a perfect inventory on day one. The goal is to obtain visibility good enough to make decisions. An inventory that is valid for an audit may not be sufficient for a post-quantum transition. The key is that it answers executive questions: what asset is critical, what data does it protect, how long will that data remain sensitive, which cryptography does it use, who owns it, what does it cost to change, which vendor or contract is blocking the transition?
When the inventory connects with real exposure, architecture and supply chain, prioritisation improves significantly. It pays to integrate it with cybersecurity audit exercises, infrastructure and network audit and continuous attack surface management.
Common inventory mistakes
The most frequent ones we see:
- Reducing the analysis to visible infrastructure and ignoring applications, APIs and signing processes.
- Not including suppliers — exactly where the least controllable part usually lives.
- Not mapping long-lived data.
- Not assigning a business owner per asset or process.
- Not connecting the inventory to a CMDB, architecture repository or change management model.
- Not updating it after technology renewals, new SaaS adoption or cloud changes.
The result is usually an incomplete, technical map that's not useful for leadership. To avoid that, the inventory must have a clear owner, a review cadence and a direct link to procurement, architecture, compliance and operations.
3. Initial classification: from inventory to decision
An organisation can get stuck if it tries to classify everything in too much detail from the start. To move forward, use a simple model. An initial four-tier classification is usually enough:
Tier A — Critical and high persistence. Highly sensitive data with long shelf life and high impact if compromised in the future. Industrial secrets, healthcare data, intellectual property, regulated information, sensitive financial data, strategic information.
Tier B — Critical and low persistence. Operationally critical processes but with shorter-lived data. They require protection, but the deferred risk may be lower.
Tier C — Important or moderate. Assets relevant to operations but with lower strategic impact or shorter data persistence.
Tier D — Non-critical or replaceable. Low-impact systems, low-sensitivity data or assets that can be replaced quickly.
This model lets you move from a technical inventory to a portfolio prioritised for leadership. Post-quantum readiness should not compete for attention as an isolated project — it must be integrated into the same language already used for risk assessment, residual risk and security posture.
4. Prioritisation 2026-2028: risk × feasibility
Once minimum visibility exists, the next common mistake is to try moving everything at once. The result is predictable: organisational fatigue, blocked projects, unresolved dependencies and loss of credibility with leadership.
Effective prioritisation combines two axes:
- Accumulated risk: impact, likelihood, data sensitivity and time horizon.
- Execution feasibility: technical complexity, cost, third-party dependency, operational window and internal maturity.
Executive decision matrix
A simple 2×2 matrix mapping risk (low/high) against feasibility (low/high) is usually enough to start. High-risk + high-feasibility goes first. High-risk + low-feasibility requires medium-term planning with vendor engagement. Low-risk + high-feasibility can be opportunistic (refresh cycles). Low-risk + low-feasibility waits — but is tracked, not forgotten. This avoids endless debate and helps justify decisions to the risk committee, audit, regulator and CFO.
Factors that should weigh more than usual
Between 2026 and 2028, three factors should be over-weighted in prioritisation.
First, information lifetime. The longer a piece of data must remain confidential, the higher the deferred-risk exposure.
Second, contractual rigidity with suppliers. Many changes won't depend on the internal team alone — they'll depend on manufacturers, SaaS providers, integrators, MSPs, HSMs, managed PKI or cloud platforms.
Third, identity and trust dependencies: PKI, certificates, digital signatures, authentication, time-stamping, APIs and service accounts. This last point connects directly with IAM and cloud posture management, Zero Trust and non-human identities — much of the cryptographic risk lives in trust mechanisms that aren't always well inventoried.
What not to prioritise at the beginning
Not everything belongs in the first wave. Avoid:
- Complex migrations without a clear owner.
- Low-impact systems with high technical effort.
- Cosmetic initiatives done to "tick a box".
- Migrations that block ongoing major projects.
- Unilateral changes on systems shared with third parties without coordination.
5. Executable actions for 2026
Strategy is worth nothing if it doesn't translate into specific actions. These are the six high-leverage actions that should be on the table during 2026.
5.1 Stand up a cryptographic governance group
Post-quantum readiness can't be a project of just the security team. It needs a working group that brings together security, architecture, operations, procurement, legal and compliance. The mandate should be explicit: own the cryptographic inventory, prioritise migrations, validate new technology purchases against post-quantum criteria and report progress to the risk committee. Without that cross-functional accountability, the programme stalls at the first vendor renewal.
5.2 Update the technology procurement policy
Every new SaaS, infrastructure or service contract signed in 2026 should include explicit clauses on cryptographic agility — the vendor's roadmap towards post-quantum algorithms, willingness to support hybrid cryptography during transition, key rotation capabilities and migration support. Contracts signed today without these clauses become crypto debt tomorrow. This is exactly the kind of strategic consultation our cybersecurity consulting practice supports.
5.3 Build a baseline of critical assets
Even if a full inventory takes 6-12 months, identify the top 20-30 critical assets in scope of post-quantum readiness within 60 days. For each: criticality, data sensitivity, lifetime, current cryptography, owner, vendor dependency, migration complexity. That baseline is what enables the prioritisation matrix and the first executive conversation.
5.4 Launch controlled pilots
Where possible, run small pilots on hybrid cryptography (classical + post-quantum) on non-critical systems. The objective is not yet migration — it's learning operational reality: latency, library compatibility, hardware support, monitoring impact. Pilots reduce uncertainty for later stages when migrations need to happen quickly. Consider including pilots in your research and development roadmap.
5.5 Define risk-oriented KPIs
Avoid vanity metrics. Useful KPIs include: percentage of critical assets with cryptographic inventory complete, percentage of new contracts with crypto-agility clauses, percentage of HSMs with vendor roadmap to post-quantum, number of identified vendor-dependent migrations and their owner, and time elapsed since last review of cryptographic posture. These are the metrics that turn the programme into accountable progress.
5.6 Prepare audit and board
Audit and the board will start asking about post-quantum readiness in 2026-2027. Get ahead: prepare a short narrative explaining the current state, the active roadmap and the risk appetite. Connect it to existing programmes (NIS2, DORA, ISO 27001, business continuity). This is the work that turns a technical topic into a defensible governance conversation.
6. Roadmap 2026-2028
Phase 1 — 2026: visibility and governance
First wave: inventory of critical assets, cryptographic governance group, updated procurement policy, definition of KPIs and first executive report. Pilots on hybrid cryptography in low-risk environments. By end of 2026 the organisation should be able to answer: where do we use cryptography, what's at stake and what's our roadmap?
Phase 2 — 2027: directed execution and contractual reinforcement
Begin actual migrations on top-tier high-feasibility assets. Renegotiate critical contracts with explicit crypto-agility clauses. Scale pilots to controlled production scenarios. Activate continuous vendor monitoring through vulnerability management and threat intelligence feeds focused on supply-chain crypto changes. Integrate findings into the regular SOC cycle.
Phase 3 — 2028: scaling and normalisation
By 2028 the post-quantum migration should be a standard part of the technology change cycle, not a separate programme. Crypto-agility becomes a default architecture principle. Vendor selection routinely tests post-quantum compatibility. The risk committee gets quarterly visibility on residual exposure. The organisation has moved from "thinking about post-quantum" to "operating in a post-quantum-aware architecture".
7. Risks of not acting
Deferring action carries its own categories of risk.
Financial risk
Last-minute migrations always cost more — emergency vendor consulting, expedited hardware refreshes, parallel system runs to avoid downtime, opportunity cost of locked-in critical projects. Organisations that wait until 2028-2029 will be doing in 12 months what others spread across three years, at multiples of the cost.
Operational risk
Forced migrations under regulatory or vendor pressure tend to introduce instability. Cryptography touches identity, signatures, sessions, integrations — getting it wrong creates outages, broken integrations and incident response burden that wasn't on anyone's roadmap. A controlled programme over three years avoids that.
Regulatory risk
NIS2 and DORA already require demonstrable risk management on critical technology. ENISA and national CSIRTs are publishing increasingly specific post-quantum guidance. Inspectors asking "what's your post-quantum readiness plan?" in 2027 won't accept "we're waiting for the algorithms to be ready" — the algorithms are ready. A documented programme is the audit answer.
Strategic risk
Enterprise customers, especially in regulated sectors, are starting to include post-quantum readiness in due diligence questionnaires. Suppliers without an answer lose deals. Suppliers with a credible roadmap differentiate. This is reputational and commercial, beyond pure cybersecurity.
8. What a CEO or CISO can ask for in the next 30-45 days
If the leadership team wants to start without disruption, here is a 30-45-day action set that any mid-size or large organisation can run.
- Designate an owner for the cryptographic inventory and governance group, with explicit cross-functional mandate.
- Define the minimum scope of the initial inventory — start with TLS, PKI, HSM, identity, signature and the 20 most critical applications.
- Identify the top 5 vendor contracts whose renewal in 2026-2027 should include crypto-agility clauses.
- Connect the post-quantum work with NIS2, DORA, ISO 27001 and business-continuity programmes to avoid duplication and silos. Our business continuity and disaster recovery practice and compliance & GRC pillar are natural integration points.
- Draft a one-page executive brief for the next risk committee summarising the current state, the proposed roadmap and the resources required.
- Schedule a follow-up review at 90 days to verify that the inventory and governance group are operational.
9. How to connect post-quantum readiness with the existing cybersecurity programme
Post-quantum readiness should not become a separate silo. It must hang from the existing cybersecurity programme:
- From ISO 27001: cryptographic key management (A.8.24), use of cryptography (A.8.24), classification and handling of information (A.5.12, A.5.13).
- From NIS2: risk management, supply chain and continuity (Article 21).
- From DORA: ICT risk management and third-party risk (Articles 5-10, 28).
- From cloud security and IAM posture: certificate, secret and key-rotation management in cloud platforms.
- From incident response: prepared playbooks for crypto-related incidents (key exposure, certificate compromise, ransomware impacting signing).
- From red team / adversary simulation: validation of identity and signature controls under realistic attack scenarios.
Hanging post-quantum readiness from existing frames accelerates adoption and reduces resistance from teams that are already saturated with parallel programmes.
10. Conclusion: 2026-2028 is a preparation window, not a waiting window
Post-quantum transition is not a single event. It's a multi-year process that already requires concrete decisions in 2026. Organisations that turn it into a structured programme — inventory, governance, prioritisation, executable actions, KPIs, governance reporting — will move with control between now and 2028.
Those that wait will face the same migration, but compressed, costly, with vendor friction and audit pressure. The technical work is the same. The strategic position is opposite.
The window for preparation is now.
Want to assess your organisation's post-quantum readiness?
Hard2bit helps European enterprises connect post-quantum readiness with their existing security and compliance programme — without creating new silos and without forcing premature migrations.
We can run a cryptographic inventory aligned with critical business processes, propose a prioritisation matrix adapted to your regulatory context, and integrate the work with your existing NIS2, DORA or ISO 27001 roadmaps. Talk to a Hard2bit specialist and we'll scope a focused first phase.
Recommended sources
- NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), August 2024.
- NIST Post-Quantum Cryptography Standardization project documentation.
- European Commission Recommendation on a Coordinated Implementation Roadmap for the transition to post-quantum cryptography.
- ENISA "Post-Quantum Cryptography — Integration study" and follow-up advisories.
- CCN-CERT TEC-009 "Recommendations for the transition to post-quantum cryptography" (Spain).
- BSI "Migration to Post Quantum Cryptography" recommendations (Germany).
- ANSSI "Position paper on post-quantum cryptography" (France).
Disclaimer: This article is informational and reflects the state of post-quantum cryptography standards and EU regulatory guidance as of mid-2026. Specific organisational decisions require formal risk assessment and may benefit from specialised legal and technical consultation. It does not replace a technical audit, a configuration review or a formal compliance assessment.