A patient opens a hospital portal and downloads her genetic test results. The record is encrypted. It may remain sensitive for the rest of her life, long after the application, database, and vendor that handled it have been replaced.

That is the timeline I want in every post-quantum cryptography conversation.

The first number I ask for is not how many certificates an organization has. It is how long its most sensitive data must stay confidential. A cryptographic inventory tells us where crypto lives. The data tells us where to move first.

NIST has finalized its first three post-quantum standards. The work has moved from choosing algorithms to finding every place we depend on vulnerable public-key cryptography and planning a controlled transition.

But an inventory without a priority order becomes another spreadsheet. We already know how that ends.

Start with the data, not the hardware list.

I want a CISO and a data owner to ask four questions about each high-value information flow:

  1. How long does this information need to stay confidential?
  2. Where does it travel and where are copies retained?
  3. Which public-key algorithms protect the connection, signature, or stored key?
  4. How long will it take to change every system and supplier in that path?

The answer changes the sequence. A customer service log with a short retention period is different from a research archive containing genetic data. A system can be low criticality on an uptime chart and still hold information that must stay private for decades.

That difference matters because adversaries can collect encrypted traffic today and retain it. If future quantum capability makes some current public-key cryptography vulnerable, the old ciphertext could become readable. The risk depends on the value and useful life of the data, not on how reassuring a vendor questionnaire looks.

Then map the full path.

Include the application, the certificate authority, the key management service, the hardware security module, the backup copy, the API gateway, and the vendor that terminates the connection. Include devices already deployed in the field. Include signed software and firmware that may still be trusted years from now.

This is where programs get uncomfortable. The cloud team knows its TLS endpoints. The identity team knows its certificate lifecycle. Procurement knows the vendor contract. The CISO has to connect those records into one decision. A key nobody can name is a migration dependency nobody can schedule.

One more thing: an algorithm change does not erase an old copy. If an attacker has retained ciphertext, replacing a certificate next quarter does not recall that data. Retention rules, key destruction, and the handling of long-lived archives belong in the plan alongside protocol upgrades.

Build the roadmap around three measures.

Confidentiality horizon. How long would exposure still harm a real person or the business? Name the owner who can answer.

Migration lead time. Which systems need a hardware refresh, a supplier release, a protocol change, or a regulatory review? Put the longest dependency at the top.

Evidence of control. Can the team show that an identified workload has an owner, a supported transition path, a test plan, and a date to retire the old method?

That is a board conversation. Not a count of scanned endpoints. Not a promise that a vendor will “support PQC soon.” A risk-ranked plan with named owners and decisions the board can fund.

On Monday morning, choose one flow that carries data with a long confidentiality horizon. Trace it from the user to every system and supplier. Ask each owner what has to change, what can be tested now, and what could block migration. You will learn more from that exercise than from another hundred pages of questionnaire responses.

The deadline is not one date on a regulatory calendar. Every data set has its own clock. Find the longest one first.

Here's what I'm watching this quarter: which organizations can explain their migration order in terms of the people and records they must keep safe, rather than the number of cryptographic assets they have found. Fellow CISOs, how are you deciding what moves first?

Lekshmy Sankar, PhD