Risk and Data Classification — Quantum-Safe: Readiness Assessment

A cryptographic inventory tells you where encryption, signatures, keys, certificates, and protocols live. It does not tell you what to fix first. Risk and data classification is the step that turns that inventory into an ordered plan. The central question is simple: which systems protect information or trust relationships that will still matter when a cryptographically relevant quantum computer exists?

The problem is not discovery; it is order

After cryptographic discovery, many organizations find hundreds or thousands of entries in a Cryptographic Bill of Materials, or CBOM. A CBOM is a structured inventory of where cryptography is used, including algorithms, keys, certificates, protocols, libraries, systems, owners, and dependencies. That inventory is necessary, but by itself it is not a migration plan.

Trying to remediate everything at once usually fails. Teams spend energy on systems that are easy to change while harder and more dangerous exposures remain untouched. The better approach is to classify the data and trust relationships each system protects, then rank the work by risk.

For post-quantum migration, the first and most useful ranking lens is time. Some data stops mattering quickly. Some data must remain secret for decades. The second lens is what can go wrong: can an attacker read something later, or forge something later? The third lens is how long the system will take to change. Together, those lenses turn a long inventory into a sequence of defensible choices.

📌

Inventory is only the start. A CBOM finds the cryptography; risk classification decides the order in which you should act.

Data shelf life is the master lens

Data shelf life means the length of time information must remain confidential. A one-hour session token has a short shelf life. A password that will be rotated next month may have a shelf life measured in weeks. A health record, tax record, merger document, intelligence file, product design, or cryptographic root key may need protection for ten, twenty, thirty, or fifty years.

This matters because of harvest now, decrypt later. In that attack pattern, an adversary records encrypted traffic or steals encrypted files today, even though they cannot decrypt them today. If a future quantum computer can break the public-key cryptography that protected the session keys or wrapped the data, the attacker may be able to read the old material later.

Long-shelf-life data is therefore not a future-only concern. If it is being captured now and must remain secret beyond the arrival of a capable quantum computer, it is already exposed in a practical risk sense. Classification starts by asking a plain question for every system: what is the longest-lived secret this system protects?

Mosca’s inequality makes the deadline visible

Michele Mosca’s framing is often written as X plus Y is greater than Z. X is the time the data must remain secret. Y is the time needed to migrate the vulnerable system to quantum-safe protection. Z is the time until a cryptographically relevant quantum computer exists. If X plus Y is greater than Z, the organization is already in the danger zone.

The inequality is not meant to predict the exact date of a quantum computer. Its value is that it joins two things that organizations can estimate now: how long the data must remain protected, and how long the organization will need to change the system. A long X means the information has a long confidentiality requirement. A long Y means the technology, vendor dependency, hardware footprint, protocol design, or operational process will be slow to change.

This is why hard-to-change systems can become urgent even when they do not look urgent on a calendar. A modern web service that can switch cryptographic libraries in a controlled release may have a small Y. A twenty-year-old embedded device, a payment terminal, an operational technology device, a medical device, a customer-installed appliance, or a vendor product with no clear upgrade path may have a very large Y.

⚠️

Do not rank by ease. If a system is slow to change, that difficulty increases Y and can make the work more urgent, not less.

If secrecy plus migration time exceeds time-to-quantum, the system is already exposed.

Classify the kind of exposure

Post-quantum risk is not only about confidentiality. Confidentiality exposure means an attacker may read harvested encrypted data later. This is the classic harvest-now-decrypt-later problem, and it is most serious for information with a long shelf life.

Authenticity exposure is different. It concerns whether an attacker could forge something that others trust. Examples include a root Certificate Authority, or CA, that issues certificates; a code-signing key used to authenticate software; a firmware-signing key used to authorize updates; or a long-lived device identity that a fleet depends on. If the underlying public-key algorithm is broken and the trust anchor is still accepted, the attacker may be able to create signatures or identities that appear valid.

Long-lived trust anchors deserve extra weight because failure is systemic. A leaked customer file is serious, but a forged firmware-signing root can affect an entire device fleet. A forged CA can undermine many certificates below it. These anchors are also painful to replace because they are embedded in devices, operating systems, applications, supply chains, build pipelines, recovery procedures, and customer environments.

Confidentiality risk lets attackers read later; authenticity risk lets them forge trust.

Use a simple score that people can defend

A risk score does not need false precision. It needs to produce a clear ordering that a security team, system owner, auditor, and executive can understand. One practical model uses four inputs: sensitivity, shelf life, anchor weight, and difficulty to change.

Put sensitivity on a 1 to 5 scale, where 1 means public or low-impact information and 5 means regulated, highly confidential, mission-critical, or breach-catastrophic information. Put shelf life on a 1 to 5 scale, where 1 means less than a year and 5 means ten years or more. Put difficulty on a 1 to 5 scale, where 1 means a configuration or library change and 5 means vendor dependency, hardware replacement, field upgrade, protocol redesign, or uncertain ownership.

Then add a special anchor weight. Use 0 for ordinary entries. Add 5 for long-lived trust anchors such as a root CA, code-signing root, firmware-signing root, or other key whose forgery would create broad trust failure. A usable formula is: risk equals sensitivity times shelf life, plus anchor weight, plus difficulty.

For example, a firmware-signing root might score sensitivity 5, shelf life 5, difficulty 5, and anchor weight 5. Its score is 5 times 5, plus 5, plus 5, for a total of 35. A one-hour session token behind a configuration flag might score sensitivity 2, shelf life 1, difficulty 1, and anchor weight 0. Its score is 2 times 1, plus 0, plus 1, for a total of 3. The numbers are not universal truth; the ordering is the useful result.

✅

The score is a sorting tool. Use the score to justify priority, not to pretend that risk can be measured with mathematical perfection.

A defensible score combines sensitivity, shelf life, anchor weight, and difficulty.

Turn classification into bands

Classification bands make the scoring model easier to use at scale. They also help non-specialists see why two systems that both use vulnerable cryptography may not deserve the same priority. The bands should be simple enough that system owners can apply them consistently, and strict enough that every high-risk exception has to be explained.

A common starting point is to classify shelf life into four bands. Critical means ten years or more, such as health records, financial records, state secrets, root CA keys, and firmware-signing roots. High means three to ten years, such as contracts, intellectual property, long-term customer data, and strategic plans. Moderate means one to three years, such as many operational records and ordinary business data. Low means less than one year, such as ephemeral sessions and short-lived tokens.

These bands are not a replacement for legal, regulatory, privacy, or records-management classifications. They are a post-quantum planning layer. In practice, you should map them to existing data governance categories where possible, so teams do not have to maintain two unrelated languages for the same information.

First wave: long shelf life and hard to change, because both X and Y are large.
Do soon: long shelf life and easy to change, because the risk is real and the fix is accessible.
Plan early: short shelf life but hard to change, because the work may take years even if the data risk is lower.
Can wait: short shelf life and easy to change, because neither the secrecy window nor the migration effort is large.

Four bands rank data from decades of secrecy down to ephemeral tokens.

The real decision is a migration register

The output of risk and data classification should be a risk register: a ranked list of cryptographic exposures with owners, systems, affected data, vulnerable algorithms, exposure type, score, decision, target date, and dependency notes. This is where the CBOM becomes an accountable migration plan.

For practitioners, the register answers operational questions. Which libraries need replacement? Which Transport Layer Security, or TLS, endpoints need new configurations or hybrid key exchange? Which Public Key Infrastructure, or PKI, components need new certificate profiles, issuance processes, or trust stores? Which signing keys need a renewal strategy, timestamping policy, or firmware update path? Which vendor products need contractual pressure or replacement planning?

For leaders, the register answers governance questions. Which risks are already inside the Mosca danger zone? Which business services depend on long-lived trust anchors? Which changes need budget because they involve hardware, suppliers, field devices, certification, or customer coordination? Which risks can be accepted temporarily, and who has authority to accept them?

Good prioritization often feels uncomfortable because the first wave may not be the easiest wave. That is the point. If a low-risk web setting can be fixed in an afternoon, fix it when convenient. But do not let convenient work hide a root key, embedded device fleet, legacy protocol, or vendor-controlled platform that will take years to move.

Key takeaways

Start prioritization with data shelf life: information that must stay secret for decades may already be exposed to harvest-now-decrypt-later risk.
Use Mosca’s inequality, X plus Y greater than Z, to connect secrecy lifetime, migration time, and the uncertain arrival of a capable quantum computer.
Classify both confidentiality exposure and authenticity exposure; long-lived trust anchors need special attention because forgery can create systemic failure.
A simple score using sensitivity, shelf life, anchor weight, and difficulty to change is often enough to produce a defensible order of work.
Do not fix only what is easy; hard-to-change systems increase migration time and may need to enter the first wave.
The practical output is a risk register with owners, scores, decisions, deadlines, and dependencies.

Glossary

Cryptographic Bill of Materials: A structured inventory of the cryptography used across systems, including algorithms, keys, certificates, protocols, libraries, owners, and dependencies.
Data shelf life: The length of time information must remain confidential.
Harvest now, decrypt later: An attack pattern in which an adversary captures encrypted data today and waits for future capability to decrypt it.
Mosca’s inequality: The rule of thumb that if the secrecy lifetime of data plus the migration time is greater than the time until a capable quantum computer, the system is already exposed.
Trust anchor: A root key, certificate, or authority that other systems rely on as a starting point for trust.
Certificate Authority: An entity that issues digital certificates used to bind identities to public keys.
Public Key Infrastructure: The policies, systems, certificates, keys, and authorities used to manage public-key trust.
Transport Layer Security: A widely used protocol that protects network connections by providing encryption, integrity, and authentication.
Risk register: A ranked list of identified risks with owners, evidence, decisions, target dates, and follow-up actions.