Security Teams · Free Tool
Select the cryptographic asset categories your organisation manages. Answer three questions per asset. The tool produces a ranked migration sequence with a phase timeline and per-asset guidance. No account required. Nothing is transmitted.
Post-quantum cryptography migration is not a single event. Organisations responsible for protecting data or operating secure communications infrastructure must replace quantum-vulnerable public-key algorithms across a heterogeneous estate of systems, each with different key lifetimes, different replacement lead times, and different data sensitivity profiles. NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. Those publications established the first formal quantum-resistant standards for public-key cryptography. Many organisations now face a migration obligation across multiple asset categories simultaneously and need a principled method for deciding where to start.
This tool produces a ranked migration sequence. It is a prioritisation instrument, not a risk assessment. It does not calculate your organisation's aggregate exposure to quantum threats, assess compliance status, or enumerate vulnerabilities. What it does is take the cryptographic asset categories you have declared, score each one across three factors, and return them in the order in which migration effort should be directed.
The three factors are asset lifetime, replacement lead time, and data sensitivity. They are weighted 30%, 35%, and 35% respectively. Replacement lead time and data sensitivity receive the highest weights because one determines when migration must begin and the other determines the consequence of delay. Asset lifetime contributes to the harvest-now-decrypt-later (HNDL) exposure window: long-lived keys remain active for extended periods and accumulate interception risk across their entire active life. The data sensitivity scoring scale uses the values 1, 2, 4, and 5. There is no value of 3. The gap is deliberate. The qualitative difference between moderate and high data sensitivity is consequential in the PQC threat context and the scale reflects this.
Assets are scored and ranked highest-first. Four priority bands group the output: Immediate, High, Standard, and Low. A phase timeline groups the same assets by recommended programme sequence. For each asset, an expandable detail row shows the three sub-scores, identifies the primary score driver, and gives a practical first step.
The scoring model draws on NIST SP 1800-38 series (Migration to Post-Quantum Cryptography), NSA CNSA 2.0 transition guidance, and NCSC quantum security migration planning guidance. Reference replacement lead times for each asset category are drawn from current vendor roadmaps and implementation experience across a range of organisation sizes and infrastructure types.
Quantum Security and Defence does not collect, associate, or retain your name or your company name when you use these tools. All information is stored only for the duration of the browser session.
We collect only country, industry, and results data. This information is anonymised and cannot be associated with you or your company. Such anonymised data may be used for industry-level reporting, shared with members, incorporated into our research, and provided to government departments to support lobbying activity and the communication of industry readiness.
By using this tool, you consent to the provision of results data on a strictly anonymised basis. No personal name, email address, or company name is stored.
Country is recorded anonymously for industry-level reporting only.
Required to calculate your score, recorded anonymously.
If your industry includes Defence, Space, Intelligence, or Government departments, select 'Defence' or 'Public administration'. These industries face earlier compliance deadlines under frameworks such as CNSA 2.0.
Industry selection is required and recorded anonymously. It does not affect the priority score.
Not recorded. Only used to create your PDF report in the browser session.
Not recorded. Only used to create your PDF report in the browser session.
Name and company are used only within your browser session. They are not stored or transmitted.
Select every category that applies. The tool will ask three questions about each one. If you are uncertain whether a category applies to your organisation, include it. You can revise your answers before viewing results.
Nothing is transmitted from your browser.
Answer three questions about this asset category. Base your answers on your organisation's current practice, not theoretical limits.
How long do keys or certificates for TLS certificates typically remain active before they are rotated or replaced?
Consider your current rotation policy for this asset category. If practice varies across instances, select the category that covers the majority. Assets with short rotation cycles present lower exposure because a compromised key expires quickly. Long-lived keys accumulate HNDL risk across their full active lifetime: an adversary capturing encrypted data today can hold it against the day a CRQC makes decryption feasible.
Shorter-lived assets are lower priority because compromised keys expire quickly. Long-lived keys accumulate exposure over their lifetime.
How long would it take your organisation to replace or upgrade the cryptography for TLS certificates?
Include the full end-to-end timeline: planning, procurement, vendor coordination, infrastructure preparation, testing, and deployment. The technical installation step is typically a small fraction of the total. An organisation that has not completed a hardware compatibility assessment, vendor PQC roadmap review, and internal change management process cannot reliably estimate lead time without this groundwork.
Reference lead time: Weeks to 2 months. Most major CAs and ACME providers are preparing PQC support.
How sensitive is the data or communications protected by TLS certificates?
Consider the most sensitive data that this asset category protects. For assets that protect other keys, such as HSM master keys or PKI root CAs, assess the sensitivity of the entire hierarchy that depends on them. In the PQC context, sensitivity is not only a question of current value: data with long-term confidentiality requirements carries heightened risk even if the data itself is not actionable for years. Consider what an adversary retaining ciphertext today could do with the plaintext in ten years.
There is no score of 3 for data sensitivity. The gap is deliberate. The distinction between moderate and high sensitivity is qualitatively significant in the PQC threat context.
For long-lived secrets, consider the data's sensitivity over its full retention period, not its immediate value.
Nothing is transmitted from your browser.
Answer three questions about this asset category. Base your answers on your organisation's current practice, not theoretical limits.
How long do keys or certificates for code-signing keys typically remain active before they are rotated or replaced?
Consider your current rotation policy for this asset category. If practice varies across instances, select the category that covers the majority. Assets with short rotation cycles present lower exposure because a compromised key expires quickly. Long-lived keys accumulate HNDL risk across their full active lifetime: an adversary capturing encrypted data today can hold it against the day a CRQC makes decryption feasible.
Shorter-lived assets are lower priority because compromised keys expire quickly. Long-lived keys accumulate exposure over their lifetime.
How long would it take your organisation to replace or upgrade the cryptography for code-signing keys?
Include the full end-to-end timeline: planning, procurement, vendor coordination, infrastructure preparation, testing, and deployment. The technical installation step is typically a small fraction of the total. An organisation that has not completed a hardware compatibility assessment, vendor PQC roadmap review, and internal change management process cannot reliably estimate lead time without this groundwork.
Reference lead time: 3 to 12 months. Requires HSM support, build pipeline updates, and subscriber trust updates.
How sensitive is the data or communications protected by code-signing keys?
Consider the most sensitive data that this asset category protects. For assets that protect other keys, such as HSM master keys or PKI root CAs, assess the sensitivity of the entire hierarchy that depends on them. In the PQC context, sensitivity is not only a question of current value: data with long-term confidentiality requirements carries heightened risk even if the data itself is not actionable for years. Consider what an adversary retaining ciphertext today could do with the plaintext in ten years.
There is no score of 3 for data sensitivity. The gap is deliberate. The distinction between moderate and high sensitivity is qualitatively significant in the PQC threat context.
For long-lived secrets, consider the data's sensitivity over its full retention period, not its immediate value.
Nothing is transmitted from your browser.
Answer three questions about this asset category. Base your answers on your organisation's current practice, not theoretical limits.
How long do keys or certificates for data-at-rest encryption keys typically remain active before they are rotated or replaced?
Consider your current rotation policy for this asset category. If practice varies across instances, select the category that covers the majority. Assets with short rotation cycles present lower exposure because a compromised key expires quickly. Long-lived keys accumulate HNDL risk across their full active lifetime: an adversary capturing encrypted data today can hold it against the day a CRQC makes decryption feasible.
Shorter-lived assets are lower priority because compromised keys expire quickly. Long-lived keys accumulate exposure over their lifetime.
How long would it take your organisation to replace or upgrade the cryptography for data-at-rest encryption keys?
Include the full end-to-end timeline: planning, procurement, vendor coordination, infrastructure preparation, testing, and deployment. The technical installation step is typically a small fraction of the total. An organisation that has not completed a hardware compatibility assessment, vendor PQC roadmap review, and internal change management process cannot reliably estimate lead time without this groundwork.
Reference lead time: 6 months to 3 years. Depends on data volume, key hierarchy depth, and whether re-encryption is required.
How sensitive is the data or communications protected by data-at-rest encryption keys?
Consider the most sensitive data that this asset category protects. For assets that protect other keys, such as HSM master keys or PKI root CAs, assess the sensitivity of the entire hierarchy that depends on them. In the PQC context, sensitivity is not only a question of current value: data with long-term confidentiality requirements carries heightened risk even if the data itself is not actionable for years. Consider what an adversary retaining ciphertext today could do with the plaintext in ten years.
There is no score of 3 for data sensitivity. The gap is deliberate. The distinction between moderate and high sensitivity is qualitatively significant in the PQC threat context.
For long-lived secrets, consider the data's sensitivity over its full retention period, not its immediate value.
Nothing is transmitted from your browser.
Answer three questions about this asset category. Base your answers on your organisation's current practice, not theoretical limits.
How long do keys or certificates for VPN credentials typically remain active before they are rotated or replaced?
Consider your current rotation policy for this asset category. If practice varies across instances, select the category that covers the majority. Assets with short rotation cycles present lower exposure because a compromised key expires quickly. Long-lived keys accumulate HNDL risk across their full active lifetime: an adversary capturing encrypted data today can hold it against the day a CRQC makes decryption feasible.
Shorter-lived assets are lower priority because compromised keys expire quickly. Long-lived keys accumulate exposure over their lifetime.
How long would it take your organisation to replace or upgrade the cryptography for VPN credentials?
Include the full end-to-end timeline: planning, procurement, vendor coordination, infrastructure preparation, testing, and deployment. The technical installation step is typically a small fraction of the total. An organisation that has not completed a hardware compatibility assessment, vendor PQC roadmap review, and internal change management process cannot reliably estimate lead time without this groundwork.
Reference lead time: 3 to 18 months. IKEv2 hybrid PQC (RFC 9370) is available; vendor firmware drives the timeline.
How sensitive is the data or communications protected by VPN credentials?
Consider the most sensitive data that this asset category protects. For assets that protect other keys, such as HSM master keys or PKI root CAs, assess the sensitivity of the entire hierarchy that depends on them. In the PQC context, sensitivity is not only a question of current value: data with long-term confidentiality requirements carries heightened risk even if the data itself is not actionable for years. Consider what an adversary retaining ciphertext today could do with the plaintext in ten years.
There is no score of 3 for data sensitivity. The gap is deliberate. The distinction between moderate and high sensitivity is qualitatively significant in the PQC threat context.
For long-lived secrets, consider the data's sensitivity over its full retention period, not its immediate value.
Nothing is transmitted from your browser.
Answer three questions about this asset category. Base your answers on your organisation's current practice, not theoretical limits.
How long do keys or certificates for email encryption typically remain active before they are rotated or replaced?
Consider your current rotation policy for this asset category. If practice varies across instances, select the category that covers the majority. Assets with short rotation cycles present lower exposure because a compromised key expires quickly. Long-lived keys accumulate HNDL risk across their full active lifetime: an adversary capturing encrypted data today can hold it against the day a CRQC makes decryption feasible.
Shorter-lived assets are lower priority because compromised keys expire quickly. Long-lived keys accumulate exposure over their lifetime.
How long would it take your organisation to replace or upgrade the cryptography for email encryption?
Include the full end-to-end timeline: planning, procurement, vendor coordination, infrastructure preparation, testing, and deployment. The technical installation step is typically a small fraction of the total. An organisation that has not completed a hardware compatibility assessment, vendor PQC roadmap review, and internal change management process cannot reliably estimate lead time without this groundwork.
Reference lead time: 6 to 24 months. Requires client software updates and external correspondent readiness for S/MIME.
How sensitive is the data or communications protected by email encryption?
Consider the most sensitive data that this asset category protects. For assets that protect other keys, such as HSM master keys or PKI root CAs, assess the sensitivity of the entire hierarchy that depends on them. In the PQC context, sensitivity is not only a question of current value: data with long-term confidentiality requirements carries heightened risk even if the data itself is not actionable for years. Consider what an adversary retaining ciphertext today could do with the plaintext in ten years.
There is no score of 3 for data sensitivity. The gap is deliberate. The distinction between moderate and high sensitivity is qualitatively significant in the PQC threat context.
For long-lived secrets, consider the data's sensitivity over its full retention period, not its immediate value.
Nothing is transmitted from your browser.
Answer three questions about this asset category. Base your answers on your organisation's current practice, not theoretical limits.
How long do keys or certificates for PKI root and intermediate CAs typically remain active before they are rotated or replaced?
Consider your current rotation policy for this asset category. If practice varies across instances, select the category that covers the majority. Assets with short rotation cycles present lower exposure because a compromised key expires quickly. Long-lived keys accumulate HNDL risk across their full active lifetime: an adversary capturing encrypted data today can hold it against the day a CRQC makes decryption feasible.
Shorter-lived assets are lower priority because compromised keys expire quickly. Long-lived keys accumulate exposure over their lifetime.
How long would it take your organisation to replace or upgrade the cryptography for PKI root and intermediate CAs?
Include the full end-to-end timeline: planning, procurement, vendor coordination, infrastructure preparation, testing, and deployment. The technical installation step is typically a small fraction of the total. An organisation that has not completed a hardware compatibility assessment, vendor PQC roadmap review, and internal change management process cannot reliably estimate lead time without this groundwork.
Reference lead time: 3 to 7 years. Root CA replacement involves offline key ceremony and trust distribution across all relying parties.
How sensitive is the data or communications protected by PKI root and intermediate CAs?
Consider the most sensitive data that this asset category protects. For assets that protect other keys, such as HSM master keys or PKI root CAs, assess the sensitivity of the entire hierarchy that depends on them. In the PQC context, sensitivity is not only a question of current value: data with long-term confidentiality requirements carries heightened risk even if the data itself is not actionable for years. Consider what an adversary retaining ciphertext today could do with the plaintext in ten years.
There is no score of 3 for data sensitivity. The gap is deliberate. The distinction between moderate and high sensitivity is qualitatively significant in the PQC threat context.
For long-lived secrets, consider the data's sensitivity over its full retention period, not its immediate value.
Nothing is transmitted from your browser.
Answer three questions about this asset category. Base your answers on your organisation's current practice, not theoretical limits.
How long do keys or certificates for Hardware Security Module keys typically remain active before they are rotated or replaced?
Consider your current rotation policy for this asset category. If practice varies across instances, select the category that covers the majority. Assets with short rotation cycles present lower exposure because a compromised key expires quickly. Long-lived keys accumulate HNDL risk across their full active lifetime: an adversary capturing encrypted data today can hold it against the day a CRQC makes decryption feasible.
Shorter-lived assets are lower priority because compromised keys expire quickly. Long-lived keys accumulate exposure over their lifetime.
How long would it take your organisation to replace or upgrade the cryptography for Hardware Security Module keys?
Include the full end-to-end timeline: planning, procurement, vendor coordination, infrastructure preparation, testing, and deployment. The technical installation step is typically a small fraction of the total. An organisation that has not completed a hardware compatibility assessment, vendor PQC roadmap review, and internal change management process cannot reliably estimate lead time without this groundwork.
Reference lead time: 2 to 5 years. Not all current-generation HSMs support FIPS 203/204/205 via firmware update.
How sensitive is the data or communications protected by Hardware Security Module keys?
Consider the most sensitive data that this asset category protects. For assets that protect other keys, such as HSM master keys or PKI root CAs, assess the sensitivity of the entire hierarchy that depends on them. In the PQC context, sensitivity is not only a question of current value: data with long-term confidentiality requirements carries heightened risk even if the data itself is not actionable for years. Consider what an adversary retaining ciphertext today could do with the plaintext in ten years.
There is no score of 3 for data sensitivity. The gap is deliberate. The distinction between moderate and high sensitivity is qualitatively significant in the PQC threat context.
For long-lived secrets, consider the data's sensitivity over its full retention period, not its immediate value.
Nothing is transmitted from your browser.
Answer three questions about this asset category. Base your answers on your organisation's current practice, not theoretical limits.
How long do keys or certificates for IoT and device identity keys typically remain active before they are rotated or replaced?
Consider your current rotation policy for this asset category. If practice varies across instances, select the category that covers the majority. Assets with short rotation cycles present lower exposure because a compromised key expires quickly. Long-lived keys accumulate HNDL risk across their full active lifetime: an adversary capturing encrypted data today can hold it against the day a CRQC makes decryption feasible.
Shorter-lived assets are lower priority because compromised keys expire quickly. Long-lived keys accumulate exposure over their lifetime.
How long would it take your organisation to replace or upgrade the cryptography for IoT and device identity keys?
Include the full end-to-end timeline: planning, procurement, vendor coordination, infrastructure preparation, testing, and deployment. The technical installation step is typically a small fraction of the total. An organisation that has not completed a hardware compatibility assessment, vendor PQC roadmap review, and internal change management process cannot reliably estimate lead time without this groundwork.
Reference lead time: 3 to 10 years. Devices that cannot receive remote updates may require physical replacement.
How sensitive is the data or communications protected by IoT and device identity keys?
Consider the most sensitive data that this asset category protects. For assets that protect other keys, such as HSM master keys or PKI root CAs, assess the sensitivity of the entire hierarchy that depends on them. In the PQC context, sensitivity is not only a question of current value: data with long-term confidentiality requirements carries heightened risk even if the data itself is not actionable for years. Consider what an adversary retaining ciphertext today could do with the plaintext in ten years.
There is no score of 3 for data sensitivity. The gap is deliberate. The distinction between moderate and high sensitivity is qualitatively significant in the PQC threat context.
For long-lived secrets, consider the data's sensitivity over its full retention period, not its immediate value.
Nothing is transmitted from your browser.
Answer three questions about this asset category. Base your answers on your organisation's current practice, not theoretical limits.
How long do keys or certificates for API authentication tokens typically remain active before they are rotated or replaced?
Consider your current rotation policy for this asset category. If practice varies across instances, select the category that covers the majority. Assets with short rotation cycles present lower exposure because a compromised key expires quickly. Long-lived keys accumulate HNDL risk across their full active lifetime: an adversary capturing encrypted data today can hold it against the day a CRQC makes decryption feasible.
Shorter-lived assets are lower priority because compromised keys expire quickly. Long-lived keys accumulate exposure over their lifetime.
How long would it take your organisation to replace or upgrade the cryptography for API authentication tokens?
Include the full end-to-end timeline: planning, procurement, vendor coordination, infrastructure preparation, testing, and deployment. The technical installation step is typically a small fraction of the total. An organisation that has not completed a hardware compatibility assessment, vendor PQC roadmap review, and internal change management process cannot reliably estimate lead time without this groundwork.
Reference lead time: 1 to 6 months. OAuth signing key rotation and JWT algorithm updates; timeline depends on integrations.
How sensitive is the data or communications protected by API authentication tokens?
Consider the most sensitive data that this asset category protects. For assets that protect other keys, such as HSM master keys or PKI root CAs, assess the sensitivity of the entire hierarchy that depends on them. In the PQC context, sensitivity is not only a question of current value: data with long-term confidentiality requirements carries heightened risk even if the data itself is not actionable for years. Consider what an adversary retaining ciphertext today could do with the plaintext in ten years.
There is no score of 3 for data sensitivity. The gap is deliberate. The distinction between moderate and high sensitivity is qualitatively significant in the PQC threat context.
For long-lived secrets, consider the data's sensitivity over its full retention period, not its immediate value.
Nothing is transmitted from your browser.
Answer three questions about this asset category. Base your answers on your organisation's current practice, not theoretical limits.
How long do keys or certificates for database connection encryption typically remain active before they are rotated or replaced?
Consider your current rotation policy for this asset category. If practice varies across instances, select the category that covers the majority. Assets with short rotation cycles present lower exposure because a compromised key expires quickly. Long-lived keys accumulate HNDL risk across their full active lifetime: an adversary capturing encrypted data today can hold it against the day a CRQC makes decryption feasible.
Shorter-lived assets are lower priority because compromised keys expire quickly. Long-lived keys accumulate exposure over their lifetime.
How long would it take your organisation to replace or upgrade the cryptography for database connection encryption?
Include the full end-to-end timeline: planning, procurement, vendor coordination, infrastructure preparation, testing, and deployment. The technical installation step is typically a small fraction of the total. An organisation that has not completed a hardware compatibility assessment, vendor PQC roadmap review, and internal change management process cannot reliably estimate lead time without this groundwork.
Reference lead time: 1 to 3 months. TLS configuration update at both application and database tiers.
How sensitive is the data or communications protected by database connection encryption?
Consider the most sensitive data that this asset category protects. For assets that protect other keys, such as HSM master keys or PKI root CAs, assess the sensitivity of the entire hierarchy that depends on them. In the PQC context, sensitivity is not only a question of current value: data with long-term confidentiality requirements carries heightened risk even if the data itself is not actionable for years. Consider what an adversary retaining ciphertext today could do with the plaintext in ten years.
There is no score of 3 for data sensitivity. The gap is deliberate. The distinction between moderate and high sensitivity is qualitatively significant in the PQC threat context.
For long-lived secrets, consider the data's sensitivity over its full retention period, not its immediate value.
Nothing is transmitted from your browser.
Post-Quantum Cryptography Advisory
Quantum Security Defence advises security teams and boards on post-quantum cryptography readiness. From initial asset inventory through to migration programme governance, CNSA 2.0 compliance, and NIST FIPS 203/204/205 implementation.
Speak to the team