The organisation that has accepted the quantum threat and decided to act immediately faces a second, less discussed problem: where do you actually start? PQC migration is not a bounded project with a clear entry point, it is a programme that cuts across every layer of infrastructure, with interdependencies between authentication, encryption, PKI, and communications that mean the wrong starting point generates rework, scope conflicts, and wasted budget. The PQC Migration Decision Tree gives you a structured, question-based recommendation for which workload or asset category your migration should begin with. Find your starting point
What the PQC Migration Decision Tree Does
The decision tree works through a guided sequence of questions about your organisation's profile and maps your answers to a structured migration starting-point recommendation. It is not a full migration programme plan, it produces a defensible, structured starting point. From there, the Cryptographic Asset Prioritisation Matrix and the PQC Readiness Checklist take the programme forward.
The question categories cover six dimensions:
Organisation type and sector: enterprise, government, financial services, healthcare, critical infrastructure, or other. The sector determines which regulatory frameworks apply and what the typical cryptographic asset profile looks like.
Regulatory framework: which of the applicable frameworks governs your organisation? NIST guidance (FIPS 203, 204, and 205) applies broadly across US federal agencies and serves as global best practice. NSA CNSA 2.0 applies specifically to National Security Systems. not to commercial organisations, unless they have NSS obligations. NIS2 governs EU organisations in scope for critical infrastructure and digital service provider requirements. DORA governs EU financial entities. These are distinct frameworks with different scopes and enforcement mechanisms; the tool asks which applies to you, not asks you to comply with all simultaneously.
Infrastructure composition: cloud-native, on-premises, hybrid, or multi-cloud. Infrastructure composition determines which migration paths are technically feasible and how long they are likely to take.
Data sensitivity profile: what proportion of your organisation's data is long-lived and sensitive? An organisation where most data has short longevity requirements faces a different starting-point recommendation from one holding decades of classified records.
Cryptographic awareness level: has your organisation completed a cryptographic inventory? The answer to this question, yes, partial, or no, has a significant effect on the recommendation. Starting a migration without an inventory is the route to discovering mid-programme that you have missed major asset categories.
Migration resource availability: dedicated migration team, shared resource with other security programmes, or planning-only stage. Resource level affects the scope of a realistic first tranche.
The output is a recommendation identifying which workload type or asset class should be the first tranche of migration, with the rationale derived from your inputs. It is a recommendation, not an instruction, your infrastructure knowledge supplements the tree's framework logic.
Why Starting Point Matters in a PQC Migration
PQC migration differs from most security programmes because there is no natural entry point. A standard penetration testing programme starts at the perimeter. A zero-trust programme starts at identity. PQC migration has no equivalent, it applies everywhere cryptographic algorithms are used, which means everything.
The wrong starting point is often the technically easiest one. Migrating front-end TLS infrastructure is tractable, well-understood, and produces visible progress. The problem is that it may not be where your highest risk sits. An organisation that migrates every external HTTPS endpoint while leaving its authentication infrastructure, data-at-rest encryption, and PKI on quantum-vulnerable algorithms has improved its visible security posture without addressing its actual exposure profile. The highest-risk assets, internal authentication systems protecting long-lived records, root certificate authorities, hardware security modules, are typically the most complex to migrate, so they tend to get pushed to later tranches. Where they often remain.
The regulatory pressure creates a starting-point requirement. NIST's finalisation of FIPS 203, 204, and 205 on 13 August 2024 defined the endpoint of migration: these are the approved PQC standards organisations should be migrating towards. NSA CNSA 2.0 gives NSS operators defined compliance windows by system type. An organisation that has not identified a starting point cannot commit to a compliant programme timeline.
Resource reality reinforces this. PQC migration budgets are not unlimited. A structured starting point concentrates early resource on the migration items with the highest risk-adjusted priority, which may or may not be the same as the items your delivery team would prefer to tackle first.
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 PQC Migration Decision Tree
Step 1. Open the tool. No account or registration required.
Step 2. Select your organisation type. Choose from enterprise, government, financial services, healthcare, critical infrastructure, or other. This selection shapes which regulatory frameworks are presented in the next question and calibrates the recommendation against your sector's typical cryptographic asset profile.
Step 3. Identify your primary regulatory framework. Select the framework(s) that govern your organisation. If you are a US federal agency: NIST standards apply. If you operate National Security Systems: CNSA 2.0 applies in addition. If you are an EU-based organisation in a NIS2-covered sector: NIS2 applies. If you are an EU financial entity under DORA: DORA applies. Select only the frameworks that genuinely apply, the recommendation will be calibrated accordingly.
Step 4. Describe your infrastructure composition. Select cloud-native, on-premises, hybrid, or multi-cloud. If your environment is hybrid, select the mode that best describes your most sensitive systems, the recommendation will account for the migration constraints typical of that environment.
Step 5. Assess your data sensitivity profile. The tool asks what proportion of your data is long-lived (longevity requirement of 10 years or more) and sensitivity-classified (confidential or above). Provide your best estimate, this question is about the proportion of your estate, not individual records.
Step 6. Rate your current cryptographic awareness. Has your organisation completed a cryptographic inventory of its assets? Select yes, partial, or no. If the answer is no or partial, expect the recommendation to identify completing the inventory as a prerequisite for the starting tranche.
Step 7. Indicate migration resource availability. Select the option that best describes your current resourcing state.
Step 8. Review the recommendation. The tool presents the starting-point recommendation, identifying which workload or asset class should be the first migration tranche and explaining why given your inputs.
How to Interpret Your Migration Starting-Point Recommendation
The output is a structured recommendation grounded in your specific answers, not a generic starting guide. It tells you which asset class or workload your migration should address first and why that combination of sector, regulatory framework, infrastructure, and resource level points to that starting point.
Validate the recommendation against your own knowledge. The tree provides structure from a framework perspective; your technical leads provide context about what is feasible within your specific environment. If the recommendation identifies external TLS endpoints as the starting point and you know those endpoints are managed by a vendor with a 6-month update cycle, that constraint affects your sequencing even if the priority ranking is correct.
From here, three steps follow. The Cryptographic Asset Prioritisation Matrix helps you rank specific assets within your recommended starting category, knowing that authentication infrastructure should come first does not tell you which authentication systems to move first. The PQC Readiness Checklist identifies gaps in your organisational preparedness for the migration, vendor contracts, policy documentation, and inventory completeness, that may affect your delivery timeline. And if your infrastructure profile or resource level changes significantly, re-run the decision tree to confirm the starting point still holds.
The organisations that make genuine progress on PQC migration in the first 90 days tend to share one characteristic: they accepted a "good enough" starting point and began rather than continuing to optimise the plan. The decision tree gives you a defensible starting point. The programme then depends on delivery.
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.
