Post-Quantum Cryptography Migration in 2026: A Small-Team Roadmap

Post-quantum cryptography can sound like a problem for large banks and research labs. It is also a planning task for small teams that store sensitive data or run old systems. This guide shows how to start without a costly rebuild. You will learn what to list, which risks to rank, what to ask vendors, and how to test one change.

A simple way to picture the change

Think of an old lock that may not hold up against a new kind of tool. You do not need to replace every lock at once. First, list the doors that matter most. Next, test a new lock on one door. Keep a way to open it if the test fails. Post-quantum planning works much the same way. Start with the data and systems that must stay safe for years.

Why plan now

A business does not need a quantum computer to start this work. The real task is to find where it uses encryption and digital signatures, then work out what it can change safely. Some systems keep data for many years. If that data is captured today and decrypted in the future, the loss may come long after the original breach. This risk matters most for long-lived secrets, legal files, health data, research, and key business records. It does not mean all current encryption is broken. It means teams should plan for a change before they face a rushed deadline.

A practical example

For example, a small logistics firm may keep shipping records for seven years. Its team might use a cloud storage service, a supplier portal, and an old VPN. The best first step is to list those systems and ask how they protect data in transit and at rest. Do not buy a new tool until you understand the answers.

What changed in 2026

The National Institute of Standards and Technology released its first three main post-quantum standards in 2024. They include ML-KEM for key establishment and ML-DSA and SLH-DSA for digital signatures. In October 2026, NIST published IR 8547 with guidance for moving away from quantum-vulnerable algorithms. Its transition plan points to 2035 for the broad removal of vulnerable methods from NIST standards, with higher-risk systems expected to move sooner. That date is a planning signal, not permission to wait until the last year.

A useful check

These standards do not replace every security control. Teams still need patching, access limits, key protection, logging, and recovery plans. A weak password or exposed admin token remains a problem even when an app uses new cryptography.

Build a cryptography inventory

Start with a simple sheet. Record the service owner, application name, data type, current protocol, certificate provider, key store, outside vendor, and expected replacement date. Some teams will have full answers in a day. Others will need help from vendors. Both outcomes are useful. A blank entry is a gap to investigate, not a reason to guess.

A practical example

Ask the network team about TLS termination, VPNs, and device links. Ask developers about libraries and code signing. Ask procurement about managed services and contract renewals. Ask the records team how long sensitive data must stay private. This mix of people catches far more systems than an automated scan alone.

Rank the systems that matter most

A simple priority score can help a small team. Give more weight to long-lived sensitive data, systems open to the internet, software that is hard to update, and vendors with no public migration plan. Put high-risk items first, even if they are not the largest systems. A payroll archive may need more care than a public product page.

A useful check

Use three bands. The first band includes data that must stay private for many years or services that protect critical actions. The second includes routine business applications with managed updates. The third includes low-risk systems that can move during a normal refresh. Review the bands with the people who own the data.

Ask vendors the right questions

Do not ask only whether a vendor is quantum safe. Ask which standards it supports, which products and regions are covered, when the feature is available, and whether old clients can still connect. Ask how it handles certificate changes, key rotation, and rollback. Request a public document or a written answer that names the algorithms. A marketing label alone is not proof.

A practical example

Suppose your cloud provider supports a hybrid key exchange for one managed endpoint but not for every database connection. Your plan must reflect that difference. Write the answer next to each service. It will help you avoid a false sense of progress.

Test before a broad switch

Create a small test environment that mirrors one real workflow. Measure connection setup time, request latency, certificate handling, CPU use, and error rates. Check mobile clients, old browsers, appliances, and partner integrations. New algorithms can change message and signature sizes. The impact depends on the protocol and implementation. So measure your own system.

A useful check

Keep a safe rollback path during the pilot. Record the old and new configuration, the person who approved the change, and the test results. If a partner connection fails, revert the specific test while the team investigates. Do not weaken security across the full network just to make one legacy client work.

Keep keys and certificates under control

Cryptographic migration is also a key-management project. Find out where keys are made, stored, rotated, and retired. Check whether hardware modules, secrets managers, and certificate services support the algorithms you plan to use. A standards-compliant library is not enough if another part of the system cannot store its keys or sign a release.

A practical example

Treat old private keys as sensitive until they are properly retired. Rotate affected credentials under an approved plan. Log changes and limit access to the people who need it. The migration should improve security operations rather than create an unmanaged collection of new keys.

Handle old devices and code

Some systems cannot adopt new algorithms through a simple software update. Network gear, industrial devices, embedded products, and custom business apps may need vendor firmware or hardware replacement. Find these early. A device that is still under contract can still be a migration risk if its maker has no support plan.

A useful check

For old code, start with dependency ownership. Find the cryptography calls, the library version, and the release process. Prefer maintained libraries with clear test records. Avoid writing your own cryptographic routines. Use a staged release so users and partners can report failures before a full rollout.

Plan a practical 90-day pilot

During the first 30 days, map systems and data retention needs. In the next 30 days, contact vendors and pick a low-risk test path. During the last 30 days, run the pilot, record metrics, and build a plan for the next quarter. This is a sample pace, not a standard timeline. Large or regulated systems may need more review.

A practical example

Name one accountable owner and one backup. Hold a short review each month. Track how many critical systems have a known algorithm, a vendor response, a tested migration path, and a target date. Those measures show progress better than a claim that the organization is quantum ready.

Common mistakes to avoid

The first mistake is replacing working systems before mapping their dependencies. The second is trusting a product label without checking the protocol or algorithm. The third is ignoring old certificates and client compatibility. The fourth is treating post-quantum work as a one-time purchase. Systems, vendors, and standards will continue to change.

A useful check

Another mistake is assuming every dataset has the same risk. Public marketing copy and records that must remain secret for decades deserve different levels of effort. Set priorities based on harm, retention, and exposure. That keeps the work useful even when budgets are tight.

What to do next

If you have only one hour this week, list the ten services that hold your most sensitive data. Find their owners. Note which ones use outside vendors and which ones have old clients or devices. Then choose one system for a vendor question and one for a safe test. That is a concrete start.

A practical example

Read the NIST transition report and the NIST post-quantum project guidance. Use them to check terminology and timing. For any product-specific choice, verify the latest documentation from its maker before you change a live system.

Quick migration checklist

• Inventory applications, keys, certificates, and vendor services.
• Rank systems by sensitivity, retention, and exposure.
• Ask providers for standards, scope, and deployment dates.
• Test one low-risk workflow before wide rollout.
• Keep rollback records and a named owner.

Sources and scope

The technical timeline and standard names above come from the official NIST October 2026 announcement and its final report. The priority scores and 90-day schedule are suggested planning methods, not NIST requirements. This is general security guidance; sensitive systems need a qualified review.