Your Data Has a Longer Life Than Your Encryption

A practical quantum-readiness roadmap for privacy, security and technology teams.

A customer can change a password tomorrow. They cannot change their medical history, their date of birth or the information in an identity document that has already been exposed.

That is why quantum readiness belongs on the privacy agenda today.

Some information collected now will still be sensitive many years from now. The systems protecting it may need substantial changes during that time. Understanding the gap between those two lifetimes is a useful starting point for post-quantum planning.

The immediate task is concrete: identify the data that matters, understand how it is protected and establish who will change that protection when necessary.

What quantum computing changes

A sufficiently capable quantum computer could break widely used public-key cryptography, including RSA and elliptic-curve schemes. That would threaten key establishment, authentication and digital signatures. The timing of that capability remains uncertain. [1, 2]

One concern is harvest now, decrypt later: an attacker collects encrypted information today and retains it in the hope of decrypting it in the future. Data that must remain confidential for many years deserves particular attention. [1]

Digital trust also needs consideration. Organisations depend on certificates and signatures to identify systems, authorise software updates and verify documents. Migration planning must cover those functions alongside confidentiality. [1, 2]

Post-quantum cryptography, or PQC, uses algorithms designed to resist quantum attacks while running on conventional computers. Organisations do not need to buy a quantum computer to adopt it. [1, 2]

What a real migration roadmap looks like

The Central Bank of Jordan's Sectoral Quantum-Resistant Cryptography (QRC) Migration Roadmap, version 1.0, December 2025, offers a useful example of organised preparation. It sets out three phases for financial institutions regulated by the bank. [1]

These are the milestones in that sectoral roadmap, not universal deadlines for every organisation. The December 2025 document develops Phase 1 in detail and says further guidance for Phases 2 and 3 will follow. [1]

For a global audience, the transferable lesson is the sequence: establish accountability, discover dependencies, prioritise risk, test changes and maintain evidence of progress.

1. Give the programme an owner

Quantum migration crosses organisational boundaries. Security teams may understand the cryptographic risk, while application owners control the systems, procurement controls supplier commitments and privacy teams understand the consequences of exposure.

The CBJ roadmap calls for an accountable migration lead or team and defined responsibilities. [1] A practical implementation is to bring these roles together:

• An executive sponsor who can approve priorities and funding.
• A technical lead who coordinates architecture, discovery and testing.
• Privacy and data owners who assess sensitivity and required confidentiality.
• Procurement and supplier managers who obtain product-specific commitments.
• Application owners who plan changes, recovery and service continuity.

For a smaller organisation, one person may cover several roles. Every important dependency should still have an owner who can make a decision.

2. Connect sensitive data to the cryptography protecting it

Start with two connected views of the environment.

The data view explains what information exists, where it is stored, who uses it and how long it must remain protected. Include production systems, exports, shared folders, mailboxes, backups and third-party processing.

The cryptography view explains how systems protect that information: algorithms, protocols, certificates, key-management services, software libraries, hardware security modules and supplier dependencies.

The roadmap explicitly links cryptographic assets with the sensitive data they protect. It also warns about blind spots such as offline keys and assets that automated discovery cannot reach. [1] NIST's NCCoE similarly treats cryptographic discovery and interoperability testing as distinct migration workstreams. [3]

For an initial register, PrivacyBuilt recommends these fields:

Keep raw private keys, passwords and other secret values out of the register. Record controlled references and metadata instead.

Where secrets discovery fits

Finding a cryptographic key or certificate file provides a lead for investigation. The next questions are whether it is active, what it protects, which service depends on it and who owns that service.

A discovery label alone does not establish the security of an entire application. Equally, a scan returning no findings does not establish that an environment has no cryptographic dependencies.

PrivacyBuilt's existing quantum-safe secrets discovery course featuring Ground Labs provides a learning path for connecting discovery findings with application, certificate, key-management and supplier evidence. Its stated scope also makes clear that discovery alone cannot certify a service as quantum safe. [5]

3. Prioritise by consequence and migration difficulty

An internet-facing service is not automatically the only priority. An internal archive may contain information that remains sensitive for decades. A difficult-to-replace device may require planning well before a modern application.

The CBJ roadmap identifies data sensitivity, confidentiality lifetime, network exposure, dependencies and vendor readiness as prioritisation factors. [1]

Use those factors to ask:

• Would disclosure still cause harm several years from now?
• Could an attacker capture protected traffic or obtain encrypted copies?
• Does this component establish trust for many other systems?
• How long would replacement, integration and testing take?
• Is there a supported migration route, or a supplier dependency that could delay it?

As an illustrative starting point, consider customer identity archives, healthcare records, confidential research transfers, certificate authorities and software-signing infrastructure. The order will depend on the organisation's actual data, architecture and threat assessment.

Privacy teams can contribute immediately by reviewing unnecessary retention and duplicate data. Removing information that no longer needs to be held reduces future exposure, provided applicable retention obligations and legal holds are respected. It does not undo an earlier interception or replace stronger protection for information that must be retained.

4. Ask suppliers for evidence that applies to your deployment

“PQC is on our roadmap” leaves too many questions unanswered.

The source roadmap includes a vendor-readiness survey and recommends aligning procurement and supplier commitments with migration plans. [1] A practical supplier discussion should establish:

1. Which deployed product versions and cryptographic functions are affected?
2. Which post-quantum capabilities are available, and which remain planned?
3. What algorithms, protocols and configurations will the supplier support?
4. Will adoption require licensing, hardware, firmware or integration changes?
5. What compatibility, performance and recovery evidence is available?
6. What fallback behaviour remains, and how can customers detect it?
7. What dates and support commitments apply to the customer's deployment?

Record the answers against specific services. A product announcement is useful evidence only when the supported feature, version and configuration match the environment being assessed.

5. Pilot changes against clear acceptance criteria

NIST finalised three initial PQC standards in August 2024: ML-KEM under FIPS 203 for key establishment, and ML-DSA and SLH-DSA under FIPS 204 and 205 for digital signatures. These perform different functions; selecting an algorithm is only part of a working deployment. [2]

The CBJ roadmap calls for staging, impact assessment and rollback planning. [1] The UK's NCSC also emphasises supplier coordination, continuity and cryptographic agility: the ability to change cryptographic mechanisms as requirements evolve. [4]

For a pilot, define the service boundary and the security property being improved. Then test normal operation, older clients, integration partners, failover, recovery and monitoring. Capture performance results against the existing baseline rather than assuming the impact will be negligible.

Document what happens when the preferred cryptographic option cannot be negotiated. A successful connection should not conceal a return to a configuration that fails the pilot's security objective.

Avoid building your own cryptographic implementation. Use appropriately supported libraries and products, with specialist review where the architecture requires it. [4]

Existing controls still have a role

The source roadmap identifies shorter certificate lifetimes, modern protocols, secure key management and defence in depth as interim measures. It explicitly says those measures do not replace migration to quantum-resistant solutions. [1]

Assess the complete cryptographic dependency. A TLS version label, certificate-renewal policy or hardware security module is not, by itself, evidence that the service has completed its quantum migration.

6. Measure completed changes and remaining exposure

PrivacyBuilt recommends reporting progress in terms that make the next decision clear:

• Critical services with verified cryptographic inventories, against the total in scope.
• Long-lived sensitive datasets mapped to their protection mechanisms.
• Critical suppliers with evidence-backed migration plans.
• Priority services that have passed their agreed migration tests.
• Unresolved dependencies and exceptions, each with an owner and review date.

Explain the scope behind every percentage. “80% complete” is difficult to assess if nobody knows whether the denominator is applications, certificates, connections or business services.

Keep discovery and review active after deployment. New systems, acquisitions and configuration changes can introduce dependencies that were absent from the original plan.

A practical first 90 days

This is a suggested PrivacyBuilt starter plan, not a regulator-mandated timetable. Adapt it to the organisation's size and existing maturity.

At the end of 90 days, the useful outcome is a defensible answer to three questions: What matters most? What protects it? What will we change first?

Start with one important service. Follow its data through storage, transfer, identity and recovery. Capture the dependencies you find, assign owners and turn the unknowns into work that can be scheduled.

For a guided introduction to discovery evidence, explore PrivacyBuilt's quantum-safe secrets discovery course.

Sources

1. Central Bank of Jordan, Sectoral Quantum-Resistant Cryptography (QRC) Migration Roadmap, version 1.0, December 2025. Relevant sections: Scope; Guiding Principles; Roadmap Phases; Phase 1; Annexes 1 and 2. This article provides independent educational commentary and original implementation suggestions; it is not an official CBJ roadmap or endorsement.
2. NIST, Announcing Approval of Three Federal Information Processing Standards for Post-Quantum Cryptography and Post-Quantum Cryptography project.
3. NIST NCCoE, Migration to Post-Quantum Cryptography.
4. UK NCSC, Timelines for migration to post-quantum cryptography.
5. PrivacyBuilt, Quantum-safe secrets discovery course featuring Ground Labs. Course positioning checked through its publicly indexed page; product coverage should be validated against current vendor documentation and the deployed version.