A Banker's Guide to Quantum Safe Cryptography

An essential first step is to discover and catalog all cryptographic assets in the organization. This means identifying where and how encryption is used – certificates, TLS connections, VPNs, application-layer encryption, databases, HSM-stored keys, etc. along with the algorithms and key lengths in use. Many institutions are now performing “ crypto discovery ” scans and creating centralized crypto inventories as part of their DORA/NIS2 compliance and PQC readiness.

Alongside inventory, perform a risk assessment: classify which systems and data are most sensitive or at risk from quantum threats. For example, any data with long confidentiality requirements (customer PII, longterm secrets, PKI keys) should be prioritized for early migration to PQC because it could be intercepted now and decrypted later.

This inventory and risk map will guide a phased migration – it’ s the groundwork that both regulators and internal stakeholders will expect. In practice, firms are using tools to automate crypto discovery (scanning code and network endpoints for instances of cryptography). The outcome should be a catalogue of CBOMs (cryptographic bill of materials) that gives a clear visibility of your “ crypto estate ” – which then informs all other strategic steps. Prioritize long-lived confidentiality data for early PQC or hybrid protections due to HNDL risk.

Crypto agility is the ability to change cryptographic algorithms and implementations with minimal disruption. This needs to be embraced as a core architectural principle going forward. Practically, this means designing systems and applications such that algorithms are pluggable or configurable, rather than hard-coded. Wherever possible, use standardized APIs and protocols that support algorithm negotiation or swapping. For instance, use PKI libraries that will support new PQC certificate types, or use an abstraction layer for encryption in applications so that you can redirect from an RSA implementation to a PQC implementation easily.

At the enterprise level, consider establishing a Cryptography Center of Excellence or similar governance group that defines coding guidelines and ensures new projects use approved crypto libraries (facilitating future updates). The payoff is significant: crypto-agile organizations can respond rapidly to new standards or threats (e.g. if a weakness is found in an algorithm, they can “hot-swap ” it out).

Regulators and boards are increasingly demanding this agility – vendor-independent, agile cryptographic architectures that avoid lock-in and allow quick algorithm swaps are seen as winners. A concrete example is implementing TLS 1.3 with support for hybrid key exchanges (classical + PQC) so that when browsers and servers agree on a PQC algorithm, your systems can participate with a config change, not a full redesign. Crypto agility also means maintaining multiple algorithms in parallel during a transition (e.g. supporting both RSA and MLDSA in a key infrastructure) which requires careful planning.

Organizations should update their cryptography policy (as required by DORA/NIS2) to explicitly include agility – e.g. a policy clause that new solutions must support approved PQC algorithms by a certain date, and that systems should be designed to facilitate crypto updates. Embracing crypto agility now is an investment that will reduce technical debt and compliance risk in the coming years.

Tackling the fragmentation of crypto systems is paramount. Financial institutions should move toward a centralized key management strategy, often enabled by a unified key management system or platform. The goal is to consolidate the management of keys from on-prem HSMs, cloud KMS services, and software key stores into a single pane of glass or coordinated control plane. By doing so, institutions can enforce uniform key policies (e.g. rotation intervals, strength requirements), get a global view of key usage, and dramatically streamline audit reporting. For example, Barclays integrated its multiple HSM clusters and cloud accounts under one central Cryptomathic ’ s CrystalKey360 solution; the result was a 65% reduction in operating, hardware and licensing costs and much improved auditability.

A unified key manager also enables automated key rotation and lifecycle management – rather than adhoc manual rotations, keys can be rotated on schedule across environments, with logs automatically recorded for compliance. Crucially, centralization is an enabler for crypto agility: when you need to introduce a new PQC key type, you can do it in one central system and propagate across all uses, instead of updating dozens of separate systems.

Many institutions are evaluating vendor-agnostic key orchestration solutions (including bring your own key (BYOK) services for cloud) to achieve this central control.

CrystalKey360 is an example of such a platform; it unifies on-prem HSM and multi-cloud key management under one roof and automates compliance reporting for standards like PCI DSS 4.0 and DORA. By deploying a centralized crypto management solution, a CISO can alleviate “key sprawl” and ensure that audit evidence (key inventories, rotation logs, encryption coverage) can be generated in clicks rather than via months of spreadsheet work. Centralization also brings role-based access control and strong segregation of duties (e.g. separation of who can generate keys vs. who can approve usage), which is important for compliance (PCI requires strict access controls for keys). In summary, a robust Enterprise Key Management (EKM) program – like CrystalKey360 – is foundational for crypto agility and governance. It creates a single source of truth for all cryptographic assets and significantly reduces the operational burden.

Adopting a hybrid approach allows organizations to get started with PQC without fully replacing existing cryptography overnight. In practice, “hybrid” means using classical and post-quantum algorithms in parallel so that each compensates for the other ’ s uncertainties. For example, one can implement TLS handshakes that perform two key exchanges: one using a traditional algorithm like ECDH and one using a PQC algorithm like CRYSTALS-Kyber, combining the shared secrets – this way, even if one algorithm is broken, the session remains secure as long as the other is safe. Similarly, one could issue digital certificates that contain two public keys (RSA and ML-DSA), or sign code with both an ECC signature and a PQC signature.

Hybrid modes are being exercised at Internet scale in browsers and CDNs and are progressing through IETF drafts; treated as a pragmatic near-term measure, not yet a universal standard. It offers a pragmatic path: you retain the assurance of well-trusted classical crypto while adding quantum-resistant protection as an overlay. 

Many financial firms are testing such approaches in non-production environments – for instance, pilot projects to transact between two offices with a VPN that has dual encryption (AES-256 and a PQC algorithm).

The advantage of hybrid is that it buys time to vet the new algorithms ’ performance and reliability, and it mitigates the risk in case early PQC algorithms later exhibit weaknesses (you ’d still have classical security as a backstop). Regulators also view hybrid positively; it demonstrates proactive risk mitigation (“defense in depth” for cryptography). Therefore, a key part of the strategy is to deploy hybrid crypto solutions wherever feasible in the next few years – particularly for protecting high-value data. This could be as simple as using libraries that implement composite certificates, or using a HSM’ s capability to generate dual signatures. As standards solidify (e.g. the IETF is standardizing hybrid key exchange in TLS 1.3), organizations that have experimented with hybrid will be ahead of the curve in rolling out full PQC. One must, however, manage the complexity (two algorithms mean extra computational load and complexity in key handling), so planning and testing are important.

Given the lack of internal expertise, organizations should consider partnerships and training as strategic investments. Use NCCoE migration materials and ENISA guidance to structure staff enablement and pilots. This can mean hiring external consultants for the migration project’ s duration. Analyst firms and big consultancies are developing quantum readiness assessment services – these can provide an outside perspective and help in drafting the roadmap. In parallel, invest in training your existing security architects and developers: send them to cryptography courses, workshops, or have them participate in open-source PQC projects for hands-on exposure.

Another emerging practice is establishing a cross-functional crypto working group that brings together the PKI team, network security, app development leads, and compliance officers. This group can collectively hammer out the migration steps and ensure nothing is overlooked (for instance, updating an internal CA to issue PQC certificates touches many stakeholders).

Also, involve internal audit and risk management in this journey – their buy-in will ensure that once solutions are in place, they tick the right boxes for compliance. 

By building at least some in-house competence, you ’ll be better positioned to operate and maintain the new cryptographic environment once the consultants leave.

Many banks are finding that the PQC migration is an opportunity to rejuvenate their cryptography practice overall – to clear out legacy algorithms (3DES, old RSA keys), to update documentation, and to instill a culture of crypto-agility among developers.

Each of these strategic initiatives reinforces the others. For example, having a strong centralized key platform makes it easier to implement hybrid solutions (you can generate classical and PQC keys from one place and distribute them). Adopting crypto-agile design means when you do your inventory you can tag which systems are upgradable vs. which need replacement. All strategies ultimately serve the goal of reducing risk – risk of non-compliance, risk of cryptographic failure, and operational risk during the transition.