Stop treating quantum computing as a problem for the 2030s.

Regulators in the U.S., the U.K., and the European Union have now published migration deadlines running from 2028 through 2035. The first milestone in every one of them isn't a technology upgrade. It's knowing what cryptography you run and where, and that's what most organizations can't do today.

The technical foundation for this transition is already settled. NIST published its first three post-quantum encryption standards on August 13, 2024, covering key encapsulation and digital signatures. The algorithms are no longer an open question. What organizations are missing isn't mathematics. It's the map.

In our compliance and assessment work, we see the same pattern across sectors. Most teams grasp the quantum threat in the abstract. They've read the coverage, and many have briefed their boards on it. Then we ask a simple question: which systems in your environment rely on public-key cryptography, and which of your suppliers protect your data with their own? The answers come back partial, manually assembled, and months out of date. That gap determines whether you hit the deadlines. Not the arrival of quantum hardware.

Harvest now, decrypt later isn't a future risk.

The attack that matters has already started. Cybercriminals are harvesting encrypted data today, waiting for computing power to catch up. They don't need to decrypt anything now. They need the information to remain valuable when they can, and much of it will.

This framing has moved from security conferences into law. Executive Order 14412, signed June 22, 2026, opens by identifying this exact risk: adversaries collecting information now and decrypting it later, once large-scale quantum computers are operational. When that language appears in the opening section of a presidential order, the debate on whether the risk is real is over.

The practical consequence is that your exposure is determined by the lifespan of your data, not by the technology's date of arrival. If you are encrypting something in 2026 that must stay confidential in 2036, you have to assume an adversary who copies it today will eventually read it. That covers a lot of ground: health records, government files, legal papers, trade secrets, personal data under privacy law, and any long-lived credentials.

What the regulators have asked for.

The published timelines converge on the same decade, but they ask for different things at different points, and that detail is where planning succeeds or fails.

The U.K.'s National Cyber Security Centre has set three milestones:

• Identifythe cryptographic services that need upgrading and build a migration plan by2028.
• Executethe highest-priority upgrades between 2028 and 2031.
• Finish by 2035.

In the U.S., NIST's draft transition report, IR 8547, proposes deprecating today's vulnerable public-key algorithms after 2030, then disallowing them after 2035. Executive Order 14412 went further, setting firm dates for federal systems. High-value assets and high-impact systems move to post-quantum key establishment by December 31, 2030, and to post-quantum digital signatures by December 31, 2031. EU Member States, supported by the Commission, issued their own coordinated roadmap in June 2025.

Read the earliest milestone in each, and the pattern is clear. It is a discovery milestone. The National Cyber Security Centre (NCSC) asks for a full understanding of where cryptography lives in your business by 2028, not a completed migration. Everything downstream depends on that work, and it is the one task nobody can outsource to a vendor roadmap.

There's a second pressure point that private-sector leaders routinely miss. Executive Order 14412 also directs the Federal Acquisition Regulatory Council to propose a rule requiring federal contractors to meet NIST's standards, including post-quantum algorithms, by December 31, 2030. Procurement is how government timelines become supplier timelines. If you sell to the government or to anyone who does, that date applies to you through your contracts, regardless of where you are based.

The hard part isn't the cryptography; it's the inventory.

The most common misconception we encounter is that this is a cryptography project, best handled by a specialist team. In practice, it's an asset management and governance challenge that happens to be about cryptography.

Choosing and implementing algorithms is well understood, and standards exist for that work. The difficult part is knowing your business, owning the dependencies, sequencing the investment, and holding suppliers to a schedule. Those are governance disciplines, not cryptographic ones, which is why organizations that already run structured, visibility-led security programs start this from a far better position than their cryptographic expertise alone would suggest.

Cryptography accumulates quietly over decades. It hides in apps, certificates, firmware, embedded modules, and external services. Almost nobody has ever audited the entire set as a single category. Ask a large organization for a complete inventory of its cryptographic dependencies, and you will usually receive a partial answer. You can't plan a migration or scope the budget from that.

The exposure also extends well past your own perimeter. Your data isn't only protected by your cryptography. It is protected by your providers' cryptography, too. If a payment processor, a cloud platform, or a managed service you depend on hasn't started this work, its timeline silently becomes your exposure, and you tend to discover it late.

Policy is moving the same way. Executive Order 14412 directs CISA and NIST to define the minimum requirements for a cryptographic bill of materials. The aim is to let software and hardware specify which encryption they use so that a machine can check it rather than doing it manually. Read that as a signal: before long, your customers and your suppliers will ask you to prove this.

Why the runway is shorter than the deadlines suggest.

Discovery is only the first stage of a queue, and the stages behind it run in sequence rather than in parallel. Take systems that depend heavily on encryption, with payment infrastructure the clearest case. Providers and manufacturers may need a couple of years just to implement new algorithms in their products. Then come the compliance cycle, the investment decisions, the retirement of hardware and solutions already in service, and the rollout across every location. Very little of that sequence sits under your direct control.

Work backward from 2030 or 2031 through that chain, and the planning window is now, not 2028. For a deeper treatment of why payment environments are particularly difficult here, my colleague Fayyaz Makhani has written on quantum computing and the future of secure payment systems, including the effect of long hardware replacement cycles.

How AI is shortening the timeline.

Artificial Intelligence (AI) and quantum computing are often framed as rivals. That misses what's happening. AI is accelerating research that brings capable quantum machines closer, cutting out steps along the way.

My concern is that most migration plans were built around an assumed arrival date, and that assumption will only ever move in one direction. Organizations are budgeting against a timeline that may not hold, while the value of the data being harvested today stays the same. Anyone planning to the outer edge of published deadlines leaves itself no margin if the timeline shortens.

Building a quantum readiness program: a practical sequence.

1. Run a real cryptographic discovery.

Scope it wider than feels comfortable and include the crypto libraries buried in systems nobody has opened in years. You want a complete picture, not a sample. This is the work the 2028 milestone is asking for.

2. Extend discovery to your suppliers.

Ask your critical providers for their migration timelines in writing. Their answers will constrain what you can realistically commit to; the gaps will tell you where to concentrate. If you already run a structured third-party risk management program, fold this into it. Rank by how long the data must stay private.

Here's where the usual risk ranking misleads people. Harvest now, decrypt later flips the logic. The first systems to fix aren't always the ones the business relies on the most. They're the ones holding data that must stay private the longest, because that's what an attacker gains most from taking today. A quiet archive can carry more quantum risk than a busy payment system.

3. Build crypto agility into everything you procure.

Anything you buy or design from this point should allow cryptographic algorithms to be replaced without redesigning the system around them. Make it a procurement requirement and an architectural standard now, so the next algorithm change is a configuration exercise rather than a capital project.

4. Anchor the plan to the obligations that bind you.

The applicable deadlines depend on your jurisdiction, sector, and whom you sell to. If your organization already operates a recognized framework such as ISO 27001, use it as the governance chassis for this work rather than standing up a parallel program that duplicates effort and creates contradictory policies.

Readiness is a risk management problem.

The published deadlines have settled whether to migrate. What remains is a more uncomfortable question: can you answer the first item on the list?

Organizations that can produce a credible cryptographic inventory have a planning problem, and planning problems respond to budget and sequencing. Organizations that can't are facing a discovery problem sitting in front of their planning problem, and only one of the two can be solved with a purchase order.

The work is unglamorous, and most of it isn't about quantum computing at all. It's about knowing what you run, who you depend on, and how long your suppliers will take. That work can start today, and it becomes more expensive with every month the queue behind it grows. The organizations that come out of this well won't be the ones with the deepest cryptographic expertise. They will be the ones that already know their own business.

Frequently asked questions.

What is the biggest problem with quantum computing?

For most organizations, the biggest problem isn't what quantum computers will eventually break. It's that most organizations can't say which systems rely on vulnerable encryption in the first place. Migration deadlines assume you can answer that question, and most can't. Discovery is the bottleneck, not mathematics.

What is harvest now, decrypt later?

Harvest now, decrypt later describes attackers stealing encrypted data today and storing it until quantum computers can decrypt it. The data doesn't need to be readable now; it only needs to be valuable later. It means your exposure depends on how long your data stays sensitive, not on when quantum hardware arrives.

What is post-quantum cryptography?

Post-quantum cryptography refers to encryption algorithms designed to resist attacks from both classical and quantum computers. NIST published the first three standards in August 2024. They replace the public-key algorithms, such as RSA and elliptic-curve cryptography, that quantum computers are expected to break.

Will AI replace quantum computing?

Neither replaces the other, and treating them as rivals misreads the relationship. They solve different problems. The connection that matters for security teams is that AI is accelerating quantum research, which may push the threat timeline forward and shorten the runway you have to migrate.

When does my organization need to be quantum-ready?

That depends on your jurisdiction and sector. The U.K. expects a cryptographic discovery and migration plan by 2028, with full migration by 2035. U.S. federal high-value assets face deadlines in December 2030 and December 2031, and a proposed rule would extend the 2030 deadline to federal contractors. Working backward through supplier lead times, planning starts now.

How can VikingCloud help?

VikingCloud has more Qualified Security Consultants than any other company, 100+ across 16 countries, supported by an in-house Compliance Council. That scale shows our consultants how cryptographic dependencies build up in practice, especially across sites that rely on lean local IT support.

Our compliance and risk advisors can help you:

• Run a full discovery across your apps, certificates, firmware, and embedded systems, then turn it into an inventory you can defend.
• Check your supplier exposure, including the providers whose encryption guards your data.
• Rank the work by how long your data must stay private, not by system size alone.
• Build a migration roadmap that matches the rules and dates your sector must meet.

The same discipline applies to your AI.

Quantum readiness and AI governance are different problems, but they fail the same way. Both start with an inventory nobody has.

AI is compressing the quantum timeline from the outside. Inside your business, AI adoption creates its own exposure. Teams sign up for tools nobody approved, and vendors embed AI into products you already bought. Only 4% of organizations require corporate security review before an individual location adopts an AI tool.

Organizations can't protect themselves when they don't know what AI tools are running across their systems. The risk is real—and growing.

The VikingCloud AI Readiness Assessment answers the question most businesses currently can't: can you prove your AI is under control? You get one readiness score from 0 to 100 and a rating across 15 risk areas so that you can show the board progress instead of intent. Every gap is ranked by risk and tied to what the standard actually requires, measured against ISO/IEC 42001, ISO/IEC 42005, the NIST AI Risk Management Framework, and the EU AI Act, plus AIUC-1, the emerging assurance standard for AI agents.

You share your evidence with us securely through the Asgard Platform®, our assessors do the work, and you receive your report at the end. Act on the findings now, and the same baseline gives you a head start when you certify under ISO/IEC 42001 later.  

Ready to start on either front? Schedule a free 30-minute meeting with a VikingCloud expert advisor. We'll walk through the risk areas that apply to you and what it takes to get started.