The decision to migrate to post-quantum cryptography is not the hard part. What stops most organisations from making meaningful progress is the sequencing problem: PQC migration cannot happen across all systems simultaneously, resources are finite, and the wrong migration order leaves your highest-risk assets exposed for longest while consuming budget on lower-priority work. The Cryptographic Asset Prioritisation Matrix solves the sequencing problem by applying a consistent, weighted scoring framework across every cryptographic asset in scope and producing a ranked migration order. Score your cryptographic assets
What the Cryptographic Asset Prioritisation Matrix Does
The matrix accepts five inputs per asset category and calculates a weighted priority score for each:
Asset type: TLS endpoints, code signing infrastructure, data-at-rest encryption, PKI, authentication systems, and key management systems. The taxonomy covers the full range of enterprise cryptographic assets. For OT and ICS assets, the dedicated OT Cryptographic Asset Prioritisation Matrix provides a specialised assessment with different asset types and migration constraints.
Data sensitivity classification: public, internal, confidential, restricted, or classified. Sensitivity is a primary driver of the priority score because it determines how consequential a breach would be.
Data longevity requirement: how long does the data protected by this asset need to remain confidential? This is the HNDL variable, assets protecting data with longevity requirements of 10 years or more are at retrospective decryption risk now, not just at Q-Day.
Current algorithm: RSA, ECDSA, AES-128, AES-256, DH, or others. The algorithm determines the nature of the quantum vulnerability. RSA and ECDSA are completely broken by Shor's algorithm on a sufficiently large CRQC. AES-128 is weakened by Grover's algorithm. AES-256 retains adequate security. An asset running RSA-1024, already a legacy algorithm considered insecure under classical computing, and one that survives in real-world authentication infrastructure far longer than it should, compounds classical vulnerability with the quantum threat in a way that may make it the highest-priority item in your entire estate.
Exposure surface: internet-facing, internal network, OT/air-gapped. Exposure surface contributes to the score but does not dominate it. This is where the matrix produces counterintuitive results that gut feel and project convenience would miss.
A concrete example of why the weighting matters: an internet-facing TLS endpoint running RSA-2048 with two-year data longevity may score lower than an internal authentication system running RSA-1024 protecting 15-year HR records. The internet-facing endpoint has higher visibility, but the internal authentication system has higher sensitivity, longer longevity, and a worse algorithm, and the combination of those factors outweighs the exposure surface advantage. Migration projects sequenced by convenience (or by what is technically easiest) routinely migrate the wrong things first, leaving their highest-risk assets exposed longest.
The output is a ranked list of asset categories ordered by migration priority, with a rationale score for each position in the ranking. A cryptographic inventory is the prerequisite, the matrix cannot score assets that have not been identified.
Why Sequencing Your PQC Migration Matters
Most migration plans are sequenced by technical convenience rather than risk priority. That is how the most critical assets end up migrated last.
NIST published FIPS 203, FIPS 204, and FIPS 205 on 13 August 2024. These are the finalised PQC standards, the migration path is defined. NSA CNSA 2.0 sets compliance windows for National Security Systems that are now active. For commercial and public-sector organisations outside NSS scope, NIS2 (enforcement from October 2024) and DORA (applicable from January 2025) provide the equivalent regulatory pressure to begin structured migration programmes.
Migration resources are finite. A security team with a two-year migration window and a limited budget cannot migrate everything simultaneously. A prioritised order concentrates early resource on the assets where failure would cause the most damage. not the assets where migration is easiest.
The cost of wrong sequencing is not just rework. It is also regulatory exposure. If a high-sensitivity, long-longevity asset remains on a quantum-vulnerable algorithm while lower-priority assets have been migrated, and a regulatory examination asks why, the answer "we migrated the easier things first" does not hold up.
HNDL risk applies differentially across your asset estate. Assets protecting data with long longevity requirements are at retrospective decryption risk now. The matrix accounts for this: assets with high longevity scores rank higher regardless of their exposure surface, because the threat is current rather than future.
Our tools are designed as directional tools only. Advice and standards are changing rapidly and although we update tools as new information is periodically released they are not designed as a replacement for expert advice. If your organisation results show high-priority exposure the next step is to contact our team or speak to a qualified expert member.
How to Use the Cryptographic Asset Prioritisation Matrix
Step 1. Compile your asset list. The matrix requires at least a partial cryptographic inventory. If you have not yet completed one, work through the asset taxonomy the tool provides and identify which categories apply to your organisation. A full inventory is the ideal input; an estimated inventory is still useful, the output will flag confidence levels.
Step 2. For each asset category, select the asset type. The tool presents a structured taxonomy covering enterprise IT cryptographic asset types. Select the category that most closely matches each asset.
Step 3. Set data sensitivity. Select the sensitivity classification that accurately reflects the data protected by this asset: public, internal, confidential, restricted, or classified. Resist the urge to classify everything as "confidential", differentiated inputs produce more useful outputs.
Step 4. Set data longevity. Enter the longevity requirement for data protected by this asset, in years. Default to the longer requirement if you are uncertain, conservative inputs generate more useful priority rankings.
Step 5. Set current algorithm. Select the algorithm(s) in use for this asset category.
Step 6. Set exposure surface. Select internet-facing, internal network, or OT/air-gapped.
Step 7. Submit and receive the ranked output. The matrix processes your inputs and returns a ranked list of asset categories ordered by migration priority, with a score breakdown for each.
For organisations with large and complex asset estates, working at the asset class level is more practical than entering every individual endpoint. The matrix is designed for class-level analysis, enter "internet-facing TLS endpoints" as a class rather than logging 400 individual certificates.
How to Interpret Your Prioritisation Results
The output divides your asset categories into priority tiers:
Tier 1: migrate within the first 6 to 12 months of your programme. These are the assets where the combination of algorithm vulnerability, data sensitivity, and longevity requirement is highest. Delaying these is not a resourcing decision, it is a risk acceptance decision that should be explicit and documented.
Tier 2: include in your primary migration programme window. These assets carry material risk but not the same combination of critical factors as Tier 1.
Tier 3: schedule in the second phase. Lower sensitivity, shorter longevity, or less vulnerable algorithms mean these assets can follow the first two tiers without unacceptable risk accumulation.
Assets flagged as technically complex within a tier, embedded systems, legacy code signing infrastructure, custom PKI implementations, require a human sequencing decision within the tier. The matrix provides the priority order; your technical leads determine the feasible order within each tier based on implementation constraints.
If OT assets appear in your matrix results, use the OT Cryptographic Asset Prioritisation Matrix for deeper analysis. Enterprise IT migration and OT migration require different approaches: an OT controller running a quantum-vulnerable algorithm in a safety-critical environment cannot be migrated through the same process as an enterprise web server.
Update the matrix as your migration programme progresses. Assets that have moved to quantum-safe algorithms should be removed from the active priority list; changes to data classification or longevity requirements should trigger a re-score.
Discuss your results with a QSECDEF expert member. A directional assessment is the starting point, not the programme. If your results show high-priority exposure, the next step is a discussion about a structured migration programme with defined milestones. Request a consultation with our team or find a qualified expert member.
