Cyber Strategy
Cyber Secure
Cyber Operations
Cyber Response
Cyber ResilienceThe Reframe: Prioritize by Data Lifetime, Not System Criticality
Most post-quantum migration discussions start with a familiar instinct: identify the most critical systems first. A logical move for confidentiality risk, it can point organizations in the wrong direction. The better question to ask rather than the importance of the system is to ask:
If an attacker captures this encrypted data today, will it still be valuable by the time they can decrypt it later?
That is the logic behind Harvest Now, Decrypt Later (HNDL). An attacker does not need to break the encryption today. They can collect encrypted traffic, files, archives, or backups now and wait for future quantum capabilities to make today’s public-key cryptography breakable.
This changes the prioritization model.
Consider two encrypted data flows.
The first is a short-lived session token, API token exchange, or routine operational transaction. The data may be sensitive at the moment it is transmitted, but its useful confidentiality lifetime is short. If it is decrypted years later, the token has expired, the transaction has closed, and the business impact is likely limited.
Now compare that with encrypted M&A records, government tender documents, legal case files, product designs, medical records, or board-level strategy. These are different. Their confidentiality value can survive for years or decades. If an attacker records that data today and decrypts it later, the damage can still be material.
The cryptography may be identical, but the urgency is not.
That is the key point: in post-quantum migration, the data decides the priority. A highly critical system protecting short-lived data may not be the first migration target. A less visible system protecting long-lived confidential data may be far more urgent.
System criticality still matters, but for Harvest Now, Decrypt Later risk, it should not be the first sorting mechanism. Data lifetime and collection exposure should be.
Mosca’s X + Y > Z
NIST’s post-quantum migration guidance, particularly draft NIST IR 8547 and the practice guide SP 1800-38, treats PQC migration as a risk-management exercise. The focus is on what the cryptography protects, how long that data must remain protected, and whether it can be captured now for future decryption. The HNDL threat matters most for long-lived confidential data, because the risk begins at capture, not at the future date when quantum decryption becomes practical.
SP 1800-38B makes the prioritization method explicit. In its discussion of risk methodologies, it identifies Mosca’s Theorem as a commonly referenced starting point for organizations beginning post-quantum migration.
The model is simple:
X + Y > Z
Where:
- X is the confidentiality lifetime of the data: how long the data needs to remain secret.
- Y is the migration time: how long it will take to move the relevant systems, protocols, vendors, certificates, libraries, and operational processes to quantum-safe cryptography.
- Z is the threat timeline: the time until quantum capabilities can realistically break today’s vulnerable public-key cryptography.
If the data must remain confidential for longer than the time available to migrate before the quantum threat arrives, then the organization is already exposed. For example, if a dataset must remain confidential for 15 years, and the migration effort is expected to take 5 years, then the organization needs a threat timeline longer than 20 years to remain comfortable. If the realistic threat timeline is shorter than that, waiting is not neutral. It means data captured today may still be valuable when decryption becomes possible.
This is why post-quantum migration cannot be treated as a generic “upgrade later” project. Long-lived data and slow migration timelines create risk before quantum computers are actually available.
The model does not mandate the migration immediately. Rather, it helps identify where the confidentiality lifetime and migration timeline exceed the time available. Some data flows may be low priority because their value expires quickly whereas others may be high priority even if the systems protecting them are not the most visible or business-critical assets in the estate.
Separating Confidentiality Risk from Signature Risk
Before organizations start scoring assets for post-quantum migration, they need to be clear about what type of quantum risk they are measuring. HNDL is primarily a confidentiality problem. The attacker captures encrypted data today because that data may still be valuable when future quantum capabilities make today’s public-key cryptography breakable. That logic applies naturally to encryption and key establishment.
It does not apply the same way to digital signatures.
An attacker cannot usually “harvest now, forge later” in the same sense. A forged signature becomes useful only once the attacker has the capability to create it. That makes signatures a separate migration track with a different clock. They still matter, but their urgency is not usually driven by captured historical traffic.
One especially urgent signature case is software and firmware signing for devices whose trust anchors cannot be updated later. If a device is expected to remain in the field for many years, and its root of trust is tied to a quantum-vulnerable signature algorithm, the migration window may close before the device can be practically fixed. In that case, signature migration can become urgent before quantum capabilities arrive.
The second distinction is between bulk encryption and key establishment.
In most HNDL scenarios, issue is how the encryption keys were established. If a session key was protected using RSA, finite-field Diffie-Hellman, or elliptic-curve Diffie-Hellman, then a future quantum attacker may be able to recover that key exchange and decrypt the recorded session. That means the practical scoring question is not only, “What algorithm is used?” It is also:
What does this cryptography protect, and does it rely on quantum-vulnerable public-key mechanisms to establish or protect keys?
If the answer is yes, and the protected data has a long confidentiality lifetime, then the asset is exposed to HNDL risk.
Turning Crypto Discovery into a Migration Plan
Once the organization understands what kind of post-quantum risk it is measuring, the next step is to turn that risk into a migration plan.
The starting point is cryptographic discovery. For most organizations, discovery is the hardest part of the program. Cryptography is rarely stored in one clean register. It is spread across protocols, certificates, keys, libraries, APIs, SaaS platforms, HSMs, KMS services, embedded devices, vendor products, backups, and undocumented data flows.
That is why inventory should be treated as the input to prioritization, not the final deliverable. An organization cannot prioritize what it cannot see. A useful inventory should answer five practical questions:
- Which protocols and algorithms are in use?
- Where are RSA, Diffie-Hellman, ECDH, ECDSA, or other quantum-vulnerable mechanisms used?
- Which certificates, keys, libraries, and cryptographic modules are involved?
- Which systems, owners, vendors, and third parties depend on them?
- What data does each cryptographic asset actually protect?
The last question is the most crucial. A cryptographic asset should not be scored in isolation; it should be mapped to the data it protects. From there, the organization can assign a confidentiality lifetime (Mosca’s X).
The point is not to invent fake precision. Nobody needs to pretend they can distinguish between “11.5 years” and “12.2 years” of confidentiality. Use bands instead:
- 0-30 days
- 1 year
- 3 years
- 7 years
- 15 years
- Permanent
Where possible, these bands should come from existing data-classification rules, regulatory retention schedules, contractual obligations, and business policy.
Next, estimate collection exposure. A system protecting long-lived data is more urgent if adversaries can realistically collect that data today. Collection exposure may come from:
- Internet-facing services
- External APIs
- Third-party file transfers
- Replicated backups
- Shared archives
- High-value network paths
- Compromised service accounts
- Long attacker dwell time
- Insider access
Internal systems should not automatically be treated as safe. Stolen backups, third-party access, compromised identities, and persistent attackers can all create collection opportunities.
Collection exposure works best as a modifier on confidentiality lifetime, not a separate number added beside it. HNDL risk needs both conditions at once: the data must be long-lived and reachable. A fifteen-year secret with an internet-facing path is far more urgent than the same secret with no realistic way to collect it today, so exposure should scale the urgency that lifetime contributes. Keep a floor rather than zeroing exposure out, though, because exposure is the most uncertain variable in the model: air gaps leak, backups are stolen, and internal networks get breached. Low exposure should lower HNDL urgency, but long-lived data still has to be migrated before the threat timeline closes, even if it does not belong in the first wave.
Then estimate migration effort, Mosca’s Y, how long it will take to migrate. Migration effort should include more than technical implementation. It should cover:
- Application changes
- Protocol support
- Certificate replacement
- Library upgrades
- Vendor readiness
- HSM or KMS compatibility
- Testing requirements
- Operational downtime
- Crypto-agility
The key question is not only whether a given system can be migrated, but whether that environment can swap cryptographic algorithms at all without a full rebuild. Crypto-agility plays two roles here: it is a property to assess, because an agile system is cheaper to migrate and lowers Y, and it is a goal to build toward, because the standards will keep changing and you do not want to repeat this exercise from scratch. At this point, the common mistake is to add everything into one priority score. Post-quantum prioritization works better as a two-axis model:
- Urgency: sensitivity, confidentiality lifetime, collection exposure, and threat interest.
- Effort: technical difficulty, vendor dependency, operational complexity, and crypto-agility.
Keeping these separate matters because high effort does not make an asset less important. In Mosca’s model, high effort can make an asset more urgent. A long migration timeline is exactly what increases the risk that X + Y will exceed the time available.
Once urgency and effort are separated, the migration plan becomes clearer:
- Wave 1: High urgency, low effort. These are quick wins that reduce real exposure early.
- Wave 2: High urgency, high effort. These are start-now programs precisely because the migration timeline is long.
- Wave 3: Low urgency. These should be monitored, kept crypto-agile where possible, and revisited when something changes the inputs. A Wave 3 asset moves up when the threat timeline (Z) shortens, when a regulatory or policy deadline approaches, when a vendor ships post-quantum support and drops the effort (Y), when the data is reclassified or its retention extended (X), or when an architecture change increases its collection exposure. Wave 3 is a watch list with defined promotion triggers, not a backlog that is quietly ignored.
Signature migration should be tracked separately. That does not mean it is minor. In many organizations, PKI, certificate lifecycle management, device identity, code signing, and firmware signing may be larger and harder than key-establishment migration. The point is that signature risk runs on a different clock from HNDL confidentiality risk, so it should not be forced into the same scoring model.
The Reframe: Prioritize by Data Lifetime, Not System Criticality
Most post-quantum migration discussions start with a familiar instinct: identify the most critical systems first. A logical move for confidentiality risk, it can point organizations in the wrong direction. The better question to ask rather than the importance of the system is to ask:
If an attacker captures this encrypted data today, will it still be valuable by the time they can decrypt it later?
That is the logic behind Harvest Now, Decrypt Later (HNDL). An attacker does not need to break the encryption today. They can collect encrypted traffic, files, archives, or backups now and wait for future quantum capabilities to make today’s public-key cryptography breakable.
This changes the prioritization model.
Consider two encrypted data flows.
The first is a short-lived session token, API token exchange, or routine operational transaction. The data may be sensitive at the moment it is transmitted, but its useful confidentiality lifetime is short. If it is decrypted years later, the token has expired, the transaction has closed, and the business impact is likely limited.
Now compare that with encrypted M&A records, government tender documents, legal case files, product designs, medical records, or board-level strategy. These are different. Their confidentiality value can survive for years or decades. If an attacker records that data today and decrypts it later, the damage can still be material.
The cryptography may be identical, but the urgency is not.
That is the key point: in post-quantum migration, the data decides the priority. A highly critical system protecting short-lived data may not be the first migration target. A less visible system protecting long-lived confidential data may be far more urgent.
System criticality still matters, but for Harvest Now, Decrypt Later risk, it should not be the first sorting mechanism. Data lifetime and collection exposure should be.
Mosca’s X + Y > Z
NIST’s post-quantum migration guidance, particularly draft NIST IR 8547 and the practice guide SP 1800-38, treats PQC migration as a risk-management exercise. The focus is on what the cryptography protects, how long that data must remain protected, and whether it can be captured now for future decryption. The HNDL threat matters most for long-lived confidential data, because the risk begins at capture, not at the future date when quantum decryption becomes practical.
SP 1800-38B makes the prioritization method explicit. In its discussion of risk methodologies, it identifies Mosca’s Theorem as a commonly referenced starting point for organizations beginning post-quantum migration.
The model is simple:
X + Y > Z
Where:
- X is the confidentiality lifetime of the data: how long the data needs to remain secret.
- Y is the migration time: how long it will take to move the relevant systems, protocols, vendors, certificates, libraries, and operational processes to quantum-safe cryptography.
- Z is the threat timeline: the time until quantum capabilities can realistically break today’s vulnerable public-key cryptography.
If the data must remain confidential for longer than the time available to migrate before the quantum threat arrives, then the organization is already exposed. For example, if a dataset must remain confidential for 15 years, and the migration effort is expected to take 5 years, then the organization needs a threat timeline longer than 20 years to remain comfortable. If the realistic threat timeline is shorter than that, waiting is not neutral. It means data captured today may still be valuable when decryption becomes possible.
This is why post-quantum migration cannot be treated as a generic “upgrade later” project. Long-lived data and slow migration timelines create risk before quantum computers are actually available.
The model does not mandate the migration immediately. Rather, it helps identify where the confidentiality lifetime and migration timeline exceed the time available. Some data flows may be low priority because their value expires quickly whereas others may be high priority even if the systems protecting them are not the most visible or business-critical assets in the estate.
Separating Confidentiality Risk from Signature Risk
Before organizations start scoring assets for post-quantum migration, they need to be clear about what type of quantum risk they are measuring. HNDL is primarily a confidentiality problem. The attacker captures encrypted data today because that data may still be valuable when future quantum capabilities make today’s public-key cryptography breakable. That logic applies naturally to encryption and key establishment.
It does not apply the same way to digital signatures.
An attacker cannot usually “harvest now, forge later” in the same sense. A forged signature becomes useful only once the attacker has the capability to create it. That makes signatures a separate migration track with a different clock. They still matter, but their urgency is not usually driven by captured historical traffic.
One especially urgent signature case is software and firmware signing for devices whose trust anchors cannot be updated later. If a device is expected to remain in the field for many years, and its root of trust is tied to a quantum-vulnerable signature algorithm, the migration window may close before the device can be practically fixed. In that case, signature migration can become urgent before quantum capabilities arrive.
The second distinction is between bulk encryption and key establishment.
In most HNDL scenarios, issue is how the encryption keys were established. If a session key was protected using RSA, finite-field Diffie-Hellman, or elliptic-curve Diffie-Hellman, then a future quantum attacker may be able to recover that key exchange and decrypt the recorded session. That means the practical scoring question is not only, “What algorithm is used?” It is also:
What does this cryptography protect, and does it rely on quantum-vulnerable public-key mechanisms to establish or protect keys?
If the answer is yes, and the protected data has a long confidentiality lifetime, then the asset is exposed to HNDL risk.
Turning Crypto Discovery into a Migration Plan
Once the organization understands what kind of post-quantum risk it is measuring, the next step is to turn that risk into a migration plan.
The starting point is cryptographic discovery. For most organizations, discovery is the hardest part of the program. Cryptography is rarely stored in one clean register. It is spread across protocols, certificates, keys, libraries, APIs, SaaS platforms, HSMs, KMS services, embedded devices, vendor products, backups, and undocumented data flows.
That is why inventory should be treated as the input to prioritization, not the final deliverable. An organization cannot prioritize what it cannot see. A useful inventory should answer five practical questions:
- Which protocols and algorithms are in use?
- Where are RSA, Diffie-Hellman, ECDH, ECDSA, or other quantum-vulnerable mechanisms used?
- Which certificates, keys, libraries, and cryptographic modules are involved?
- Which systems, owners, vendors, and third parties depend on them?
- What data does each cryptographic asset actually protect?
The last question is the most crucial. A cryptographic asset should not be scored in isolation; it should be mapped to the data it protects. From there, the organization can assign a confidentiality lifetime (Mosca’s X).
The point is not to invent fake precision. Nobody needs to pretend they can distinguish between “11.5 years” and “12.2 years” of confidentiality. Use bands instead:
- 0-30 days
- 1 year
- 3 years
- 7 years
- 15 years
- Permanent
Where possible, these bands should come from existing data-classification rules, regulatory retention schedules, contractual obligations, and business policy.
Next, estimate collection exposure. A system protecting long-lived data is more urgent if adversaries can realistically collect that data today. Collection exposure may come from:
- Internet-facing services
- External APIs
- Third-party file transfers
- Replicated backups
- Shared archives
- High-value network paths
- Compromised service accounts
- Long attacker dwell time
- Insider access
Internal systems should not automatically be treated as safe. Stolen backups, third-party access, compromised identities, and persistent attackers can all create collection opportunities.
Collection exposure works best as a modifier on confidentiality lifetime, not a separate number added beside it. HNDL risk needs both conditions at once: the data must be long-lived and reachable. A fifteen-year secret with an internet-facing path is far more urgent than the same secret with no realistic way to collect it today, so exposure should scale the urgency that lifetime contributes. Keep a floor rather than zeroing exposure out, though, because exposure is the most uncertain variable in the model: air gaps leak, backups are stolen, and internal networks get breached. Low exposure should lower HNDL urgency, but long-lived data still has to be migrated before the threat timeline closes, even if it does not belong in the first wave.
Then estimate migration effort, Mosca’s Y, how long it will take to migrate. Migration effort should include more than technical implementation. It should cover:
- Application changes
- Protocol support
- Certificate replacement
- Library upgrades
- Vendor readiness
- HSM or KMS compatibility
- Testing requirements
- Operational downtime
- Crypto-agility
The key question is not only whether a given system can be migrated, but whether that environment can swap cryptographic algorithms at all without a full rebuild. Crypto-agility plays two roles here: it is a property to assess, because an agile system is cheaper to migrate and lowers Y, and it is a goal to build toward, because the standards will keep changing and you do not want to repeat this exercise from scratch. At this point, the common mistake is to add everything into one priority score. Post-quantum prioritization works better as a two-axis model:
- Urgency: sensitivity, confidentiality lifetime, collection exposure, and threat interest.
- Effort: technical difficulty, vendor dependency, operational complexity, and crypto-agility.
Keeping these separate matters because high effort does not make an asset less important. In Mosca’s model, high effort can make an asset more urgent. A long migration timeline is exactly what increases the risk that X + Y will exceed the time available.
Once urgency and effort are separated, the migration plan becomes clearer:
- Wave 1: High urgency, low effort. These are quick wins that reduce real exposure early.
- Wave 2: High urgency, high effort. These are start-now programs precisely because the migration timeline is long.
- Wave 3: Low urgency. These should be monitored, kept crypto-agile where possible, and revisited when something changes the inputs. A Wave 3 asset moves up when the threat timeline (Z) shortens, when a regulatory or policy deadline approaches, when a vendor ships post-quantum support and drops the effort (Y), when the data is reclassified or its retention extended (X), or when an architecture change increases its collection exposure. Wave 3 is a watch list with defined promotion triggers, not a backlog that is quietly ignored.
Signature migration should be tracked separately. That does not mean it is minor. In many organizations, PKI, certificate lifecycle management, device identity, code signing, and firmware signing may be larger and harder than key-establishment migration. The point is that signature risk runs on a different clock from HNDL confidentiality risk, so it should not be forced into the same scoring model.
Moving Toward a Quantum-Safe Cryptographic Stack
Prioritization tells you the order, but it does not tell you what you are migrating to. Once the waves are set, the target state has to be defined, and this is where the global standards and the local rulebook both come into play.
On the algorithms themselves, there is broad agreement. The post-quantum schemes that matter are NIST’s: ML-KEM for key establishment, and ML-DSA and SLH-DSA for signatures (FIPS 203, 204, and 205). These are the algorithms most regulators now point to, and they are the destination for the asymmetric cryptography that HNDL actually threatens.
Where opinion still divides is on how to get there: whether to deploy post-quantum algorithms on their own or alongside the classical ones. The European approach, in the EUCC Agreed Cryptographic Mechanisms April 2026 Working Draft, treats hybrid deployment as mandatory, combining a post-quantum scheme with a classical one so that both must be broken for the protection to fail. The American approach, in NIST IR 8547, treats hybrid as optional and temporary, a hedge on the way to pure post-quantum cryptography, and leaves the choice to each application. Same algorithms, different posture on standalone use.
For organizations in the UAE, that debate is largely settled, because the answer is already written into regulation.
Federal Decree-Law No. 8 of 2023 on Cryptography, its Executive Regulation No. 71 of 2024, and the 2025 Government Cryptographic Migration Guide together make post-quantum migration a compliance obligation rather than a planning exercise. Government entities are sorted into two categories.
- Category 1, the most critical, must use post-quantum cryptography at the highest security level (NIST Category 5, 256-bit), alongside national cryptographic algorithms, and must achieve cryptographic agility as an explicit requirement under Article 9.
- Category 2 entities must meet at least 128-bit security, with post-quantum cryptography recommended. The approved post-quantum set is the same NIST family—ML-KEM, ML-DSA, and SLH-DSA—while legacy algorithms such as SHA-1, MD5, DES, 3DES, and RC4 are prohibited outright.
The framework is just as prescriptive about how migration happens. It defines a phased process that begins, as this article has argued it must, with a cryptographic inventory and a migration analysis, then moves through a formal migration plan, review, execution, and audit, ending in a Migration Compliance Certificate.
The plan carries a clock: it must be submitted within 180 days of the Center’s first communication. After migration, entities file an annual compliance plan to stay aligned as the standards change.
That last detail is the one to hold onto. The framework does not treat the move to post-quantum cryptography as a single event with an end date. It treats it as something to be maintained—inventory, migrate, prove it, and keep doing so as algorithms are added and retired. That is the same conclusion the prioritization model reaches from the other direction. The deliverable was never a one-time swap to a particular algorithm, because the lists will change and today’s recommended scheme can be tomorrow’s deprecated one. The deliverable is crypto-agility, the ability to change cryptographic algorithms as standards, threats, and regulations move, without rebuilding the system underneath.
And the reason to begin now has not changed since the first section. Data captured today is already exposed if it must stay secret long enough to outlast the migration. Prioritize by how long the data must live and how easily it can be collected, define the destination clearly, and build for change rather than for a single migration. In the UAE, that is no longer a matter of foresight but of compliance; a 180-day plan and a certificate at the end of it. Elsewhere, it is the same quiet arithmetic, X plus Y, measured against a Z that is only moving closer.
Moving Toward a Quantum-Safe Cryptographic Stack
Prioritization tells you the order, but it does not tell you what you are migrating to. Once the waves are set, the target state has to be defined, and this is where the global standards and the local rulebook both come into play.
On the algorithms themselves, there is broad agreement. The post-quantum schemes that matter are NIST’s: ML-KEM for key establishment, and ML-DSA and SLH-DSA for signatures (FIPS 203, 204, and 205). These are the algorithms most regulators now point to, and they are the destination for the asymmetric cryptography that HNDL actually threatens.
Where opinion still divides is on how to get there: whether to deploy post-quantum algorithms on their own or alongside the classical ones. The European approach, in the EUCC Agreed Cryptographic Mechanisms April 2026 Working Draft, treats hybrid deployment as mandatory, combining a post-quantum scheme with a classical one so that both must be broken for the protection to fail. The American approach, in NIST IR 8547, treats hybrid as optional and temporary, a hedge on the way to pure post-quantum cryptography, and leaves the choice to each application. Same algorithms, different posture on standalone use.
For organizations in the UAE, that debate is largely settled, because the answer is already written into regulation.
Federal Decree-Law No. 8 of 2023 on Cryptography, its Executive Regulation No. 71 of 2024, and the 2025 Government Cryptographic Migration Guide together make post-quantum migration a compliance obligation rather than a planning exercise. Government entities are sorted into two categories.
- Category 1, the most critical, must use post-quantum cryptography at the highest security level (NIST Category 5, 256-bit), alongside national cryptographic algorithms, and must achieve cryptographic agility as an explicit requirement under Article 9.
- Category 2 entities must meet at least 128-bit security, with post-quantum cryptography recommended. The approved post-quantum set is the same NIST family—ML-KEM, ML-DSA, and SLH-DSA—while legacy algorithms such as SHA-1, MD5, DES, 3DES, and RC4 are prohibited outright.
The framework is just as prescriptive about how migration happens. It defines a phased process that begins, as this article has argued it must, with a cryptographic inventory and a migration analysis, then moves through a formal migration plan, review, execution, and audit, ending in a Migration Compliance Certificate.
The plan carries a clock: it must be submitted within 180 days of the Center’s first communication. After migration, entities file an annual compliance plan to stay aligned as the standards change.
That last detail is the one to hold onto. The framework does not treat the move to post-quantum cryptography as a single event with an end date. It treats it as something to be maintained—inventory, migrate, prove it, and keep doing so as algorithms are added and retired. That is the same conclusion the prioritization model reaches from the other direction. The deliverable was never a one-time swap to a particular algorithm, because the lists will change and today’s recommended scheme can be tomorrow’s deprecated one. The deliverable is crypto-agility, the ability to change cryptographic algorithms as standards, threats, and regulations move, without rebuilding the system underneath.
And the reason to begin now has not changed since the first section. Data captured today is already exposed if it must stay secret long enough to outlast the migration. Prioritize by how long the data must live and how easily it can be collected, define the destination clearly, and build for change rather than for a single migration. In the UAE, that is no longer a matter of foresight but of compliance; a 180-day plan and a certificate at the end of it. Elsewhere, it is the same quiet arithmetic, X plus Y, measured against a Z that is only moving closer.
Dubai