A new financial platform may be expected to serve the business for years. Some of the information it protects must remain confidential for much longer. Security planning therefore needs to consider not only current threats, but also whether the architecture can adapt when its cryptographic assumptions change.
In August 2024, NIST published its first three principal post-quantum cryptography standards: ML-KEM for key establishment, and ML-DSA and SLH-DSA for digital signatures. These are concrete standards for implementation work, not a reason to assume that every system labeled “quantum-ready” already protects every relevant component. 1
Identify what the business is actually protecting
Start with an inventory of where cryptography is used: communications, identity certificates, software updates, signing services, stored records and external interfaces. Record the owner of each dependency and whether the enterprise can change it directly or needs a supplier to act.
NIST’s migration program identifies cryptographic discovery and interoperability testing as distinct workstreams. That distinction is useful: finding an affected component is not the same as proving that its replacement works with the rest of the environment. 2
Prioritize by information lifetime and operational impact
Some confidentiality risks precede a future attack. NIST explains the “harvest now, decrypt later” concern: an adversary may collect encrypted information today in the hope of reading it with more capable technology later. Long-lived sensitive information therefore deserves attention even when the timing of a cryptographically relevant quantum computer remains uncertain. 3
For an enterprise program, a practical prioritization exercise would consider how long the information must remain protected, the consequence of exposure, and the time needed to change the affected systems. The result should be a sequence of work with named owners, rather than a single target date attached to the entire estate.
Ask for boundaries, evidence and a change plan
Supplier conversations should identify the precise algorithms, protocols and components in scope. Ask which implementations have been tested, which remain planned, and how interoperability, performance and recovery will be assessed. A component-level improvement should not be presented as proof that every connected system has completed migration.
Ovryde’s public communications identify quantum resilience as an architectural theme. For any proposed Hybrid Chain deployment, that theme should become a specific technical review with documented coverage and remaining dependencies, not an unqualified claim that the whole environment is immune to future attacks. 4
The strongest starting point is modest and actionable: know what must change, who can change it, and how the business will verify the result.