- Post-quantum cryptography uses new methods designed to resist future quantum computers. The standards exist, but most teams should start with discovery, not a rushed product switch.
- List where public-key encryption and digital signatures protect data, software and access. Record the owner, vendor, algorithm, data life and upgrade path for each use.
- Rank long-lived sensitive data and critical services first. Ask suppliers for dates, tested options and fallback plans, then test changes away from production.
Quantum computers are not breaking normal business encryption today. Yet the move to new encryption will take years. That is why US and UK security agencies say planning should start now.
Post-quantum cryptography, or PQC, is a set of methods built to resist attacks from future quantum computers. NIST published its first three final PQC standards in 2024. The UK National Cyber Security Centre says organisations should finish discovery and an early plan by 2028.
The first useful step is not buying a product. It is finding where your company uses public-key encryption and digital signatures. This list is an encryption inventory. It turns a distant risk into work that a team can assign, rank and test.
Why the inventory comes first
Public-key encryption helps protect web sessions, remote access and data exchange. Digital signatures help prove that software, a document or a message came from the expected source. Today, many of these tasks use methods such as RSA or elliptic curve cryptography.
A strong quantum computer could one day weaken those methods. No one knows the exact date. NIST says organisations should still begin migration now. Its guidance also says high-risk systems should move earlier than the final 2035 target.
There is another reason to start early. An attacker can collect encrypted data now and try to read it later. This is often called “harvest now, decrypt later.” Data that must stay private for many years needs more attention than a public notice or a short-lived test file.
You cannot rank that risk if you do not know where encryption lives. It may sit inside a cloud service, a network device, a code-signing process or a vendor contract. The inventory makes those hidden links visible.
Set a small scope and name an owner
Start with one business service, not the whole company. Pick a service that handles valuable data or must stay available. Good examples include customer login, payroll, a software release process or a link to a key supplier.
Name one owner for the inventory. That person does not need to be a cryptographer. The job is to gather facts, involve the right teams and keep the list current. Security, IT, engineering, legal and purchasing may each hold part of the answer.
Write down the goal in plain language. For example: “By the end of this quarter, we will know which parts of customer login use public-key cryptography, who supplies them and how long the protected data stays sensitive.”
Record the facts that guide a decision
A spreadsheet can be enough for the first pass. Do not wait for a perfect discovery tool. Add one row for each clear use of public-key encryption or a digital signature.
| Field | What to record |
|---|---|
| System and owner | The service, device or process, plus the person or team responsible for it. |
| Purpose | Web encryption, remote access, code signing, identity, email, backup or another use. |
| Data and life | What the system protects and how long that data must remain private or trusted. |
| Current method | The known algorithm, key size, certificate type or library. Mark it unknown when you cannot confirm it. |
| Supplier and renewal | The vendor, product version, contract date, hardware life and support contact. |
| Change path | Available PQC support, test needs, dependencies, fallback and a likely migration window. |
Look at internet certificates, private certificate systems, VPNs, SSH access, software signing, device identity, secure email and encrypted links between services. Cloud platforms and managed software matter too, even when your team cannot see the keys.
Mark unknown facts instead of guessing. A useful inventory shows gaps. It does not hide them.
Rank the rows by business risk
Not every row needs the same deadline. Use a short scoring method that people can explain. Give more weight to data that must stay private for years, systems exposed to public networks and services that the business cannot run without.
Also look at how hard a change may be. Old hardware, fixed software, embedded devices and long vendor contracts can slow a move. A simple renewal may offer an easier point to add a PQC requirement.
The NCSC asks organisations to complete discovery and an initial migration plan by 2028, then finish the highest-priority work by 2031. Its wider target is 2035. These are planning points, not proof that every system can wait until the last date.
A practical first queue may have three groups:
- Act early: long-lived sensitive data, critical services and systems with a slow hardware or supplier change.
- Plan next: important systems with a clear vendor upgrade path and a normal renewal in the next few years.
- Watch: low-impact uses, short-lived data and products whose standards or support are still developing.
Ask vendors for evidence, not a label
A “quantum-safe” badge is not a migration plan. Ask the supplier which NIST standards it supports, which product versions include them and whether the support is ready for production. Ask how it handles keys, certificates, signatures and older clients during the change.
Fresh Australian government guidance gives buyers a useful structure. It says to locate dependencies, assess risk, rank systems, implement approved methods and keep talking with vendors. It also says PQC questions should enter purchasing, renewals and vendor reviews.
Ask for test results and limits. Larger keys or signatures can affect speed, message size and older devices. Ask what fails when PQC is turned on, how monitoring will show that failure and how the service can return to a safe state.
Put dates and duties in the contract when the service matters. Our software vendor evidence guide can help you frame that wider review. If a connected service uses an AI agent or bot, include it in the recurring access review too.
Test a narrow change away from production
Do not switch a critical service in one step. Choose a low-risk path and build a lab test. Check both ends of the connection. Measure response size, speed, device support, logs and failure behaviour.
Use standards and tested product support. NIST's first set includes ML-KEM for establishing shared secrets and ML-DSA and SLH-DSA for digital signatures. A normal team should not build these methods from scratch. Use trusted, supported implementations.
Some products may use a hybrid setup during the move. This combines a current method with a PQC method. Hybrid designs can reduce some transition risk, but they add parts to test. Follow the vendor and sector guidance that applies to your system.
Keep a rollback plan. Record the result in the inventory. A failed test is still useful when it shows which client, device or process needs an upgrade.
Make the inventory part of normal work
An inventory becomes stale if it is a one-time project. Add a PQC field to major software purchases and renewals. Ask about cryptography when a new service handles sensitive data. Update the list when a certificate system, network link or signing process changes.
Review the highest-risk rows at least twice a year. Track vendor dates and standards updates. Keep the owner and next action clear. This creates crypto agility, which means the ability to change encryption without rebuilding the whole service.
Start small this week. Pick one important service, list its encryption links and send three questions to its main vendor. That work is more useful than a broad promise to be “quantum ready.”
Sources and further reading
- NIST: Post-Quantum Cryptography standards and migration
- NIST NCCoE: Migration to Post-Quantum Cryptography
- UK NCSC: Timelines for migration to post-quantum cryptography
- Australian Cyber Security Centre: Post-quantum questions to ask vendors
- Meta Engineering: PQC migration framework and lessons
Frequently asked questions
Do small companies need a post-quantum plan now?
A small company does not need to replace every tool today. It should know which vendors and services protect long-lived sensitive data, and ask how those products will move to post-quantum standards.
What should an encryption inventory include?
Record the system, owner, purpose, data type, current public-key method, certificate or key location, vendor, renewal date, data lifetime and likely upgrade route.
Should a team install a post-quantum algorithm itself?
Usually not. Use tested support from trusted libraries, platforms and vendors. Start in a lab, check compatibility and keep a safe rollback path.