A Banker's Guide to Quantum Safe Cryptography
Part 3: Roadmap to PQC Migration for Financial Institutions
PHASE 1: PREPARATION AND ASSESSMENT (MONTHS 0–6)
CRYPTO INVENTORY & GOVERNANCE SETUP
Launch a project to perform a comprehensive cryptographic inventory. Catalog all applications and systems that use cryptography, noting algorithm types, key lengths, and where keys are stored. Simultaneously, establish a governance structure – form a PQC migration task force or steering committee, and develop a high-level crypto migration policy (aligned with DORA Article 6 requirements and NIS2 Article 21) to set direction.
Identify “ crypto owners ” across different business units. Begin engaging vendors to understand the support for PQC in current products. Start raising awareness at the executive level that a quantum transition project is underway (this helps secure budget and attention).
If not already done, update your encryption and key management policy documents to reflect that new algorithms will be introduced and how decisions will be made (e.g. following NIST/ENISA guidance).
OUTCOME
A clear view of the cryptographic estate and a documented game plan approved by risk management.
Deliverables: Crypto inventory report, risk assessment highlighting critical vulnerabilities (e.g. use of legacy algorithms or stored data vulnerable to long-term quantum risk), and an initial PQC roadmap document.
PHASE 2: FOUNDATIONAL CAPABILITIES (MONTHS 3-12)
IMPLEMENT CENTRALIZED CRYPTO MANAGEMENT
Based on the inventory findings, decide on a centralized key management solution to adopt. This could involve deploying a new enterprise key management system (like a KMS/HSM orchestration platform) or upgrading an existing one. Begin migrating keys from disparate stores into the centralized solution or, if full migration is not feasible yet, integrate them virtually (ensure the central system at least has visibility via APIs to external KMS).
This phase often includes rolling out a unified key inventory dashboard and enabling rolebased controls so that the crypto team can manage keys enterprise-wide. Important: design the central solution with crypto agility in mind – e.g. ensure it can accommodate custom object attributes for PQC keys, larger key sizes, etc. In parallel, start piloting crypto-agile development practices: for instance, have one or two apps refactor their crypto module to use a centralized API or library (abstracting the algorithm). This is a test run for agility. management.
TRAINING & QUICK WINS
Train the core cryptography team and application security architects on PQC basics (perhaps via workshops with experts or training courses). Pursue some “ quick win ” upgrades on the classical crypto side: for example, if any applications still use deprecated algorithms (SHA-1, 1024-bit RSA, 3DES), replace those with modern algorithms now – this reduces your overall technical debt and demonstrates progress to auditors. Begin a project to replace hard-coded crypto in one legacy system with calls to the new centralized service (this not only fixes that system but serves as a template for others). By the end of Phase 2, the organization should have a centralized, well-controlled cryptography environment in place as the backbone for further changes.
DELIVERABLES
Central key management platform in production, updated architectural standards for crypto, and a progress report to regulators/auditors if needed showing steps taken (this can help fulfill interim compliance obligations for DORA/PCI by showing a plan in action).
PHASE 3: PILOT POST-QUANTUM IMPLEMENTATIONS (MONTHS 9-18)
HYBRID CRYPTOGRAPHY PILOT
Identify a suitable use-case to introduce hybrid classical-PQC encryption as a pilot. A good candidate might be an internal VPN or inter-datacenter link, or a new feature of a mobile banking app that encrypts certain data. Work with a vendor or open-source library to implement a solution where data is encrypted with both a conventional algorithm and a PQC algorithm. Monitor the performance and reliability. Alternatively (or additionally), set up a test Public Key Infrastructure (PKI) that issues dual-certificates (containing RSA and PQC public keys) and use it for some internal services like code signing or document signing, to gain experience with PQC signatures.
UPGRADE INFRASTRUCTURE FOR PQC
Concurrently, ensure your underlying crypto infrastructure is ready: upgrade HSM firmware or modules that support PQC algorithms (some HSMs already support Dilithium or Kyber in firmware updates). If hardware does not yet support PQC, plan for it (coordinate with HSM vendors on timelines, perhaps budget for new HSM models by a certain year). Also update cryptographic libraries in your development stack to versions that include PQC (for example, OpenSSL 3.0+ with OQS integration for PQC algorithms, or similar for Java BouncyCastle which has PQC implementations). This ensures that when developers need to use a PQC algorithm, they have the tools available.
TESTING AND VALIDATION
Rigorously test the PQC implementations under realistic conditions. Pay attention to performance impacts – e.g. PQC algorithms like Dilithium have larger signatures, and Kyber has larger ciphertexts; ensure your systems (bandwidth, storage, processing) can handle this. Test failover scenarios: if one half of a hybrid algorithm pair fails, does the system still secure the data? Also test your monitoring and incident response – ensure that new algorithm identifiers are recognized in your logging/alerting (so that, for instance, your SOC isn ’t confused by seeing “KYBER512” in network traffic). This phase might also involve third-party security evaluations, e.g. having an external team cryptanalyze your implementation or validate that keys are protected in transit between software and HSM.
OUTCOME
By the end of Phase 3, you should have confidence in deploying PQC tech on a small scale and have ironed out major issues.
PHASE 4: BROAD DEPLOYMENT AND MIGRATION (MONTHS 18-36)
PHASED ROLLOUT BY PRIORITY
With lessons learned from pilots, begin the phased rollout of PQC across the enterprise. Prioritize systems identified as high-risk in the initial assessment (e.g. systems protecting sensitive long-term data or critical infrastructure connections). For each system or application, follow a defined migration plan: deploy updates that enable hybrid or PQC modes, run them in parallel with classical modes for a period (if possible), then eventually disable the weaker algorithms once confidence is high. Use your centralized key management to distribute new PQC keys and certificates – for example, your central KMS can generate a Kyber key pair for an application and deliver it just as it used to for an RSA key, ensuring consistent handling. Continue in waves – for instance, migrate internal systems first (which you control end-to-end), then tackle external-facing ones or those that depend on partner compatibility (since you might need to coordinate with others for, say, enabling PQC cipher suites on a client-facing website – browsers and client OS need to support it too).
PARALLEL COMPLIANCE TRACKING
As you progress, maintain close alignment with compliance requirements. Update your documentation for auditors to show that new algorithms meet required “ strength” (regulators may ask, for example, what is the equivalent security of Kyber vs RSA – be prepared with references to NIST security strength comparisons). If you ’ re under PCI DSS, verify that the use of hybrid or new algorithms doesn ’t violate any requirement (PCI might eventually issue supplemental guidance on PQC – stay tuned to the PCI Council bulletins). It’ s also important to get sign-off from risk committees and possibly regulators at key points – for instance, if you are a large bank, your regulator might appreciate being informed that you are pioneering a quantum-resistant encryption for SWIFT transactions, etc. This builds trust and could even influence industry norms.
OUTCOME
By the end of Phase 4, the majority of your critical data flows and storage should be protected with PQC or hybrid crypto, and all supporting infrastructure (key management, monitoring, etc.) is running in production with these new algorithms. Classical algorithms may still be around (for backward compatibility or noncritical systems), but they would ideally be isolated to low-risk areas.
PHASE 5: DECOMMISSION LEGACY CRYPTO AND CONTINUOUS IMPROVEMENT (MONTHS 36 AND BEYOND)
SUNSET WEAK ALGORITHMS
Once quantum-resistant solutions are broadly deployed, plan the retirement of legacy cryptography. This means eventually disabling RSA, ECC, and other algorithms in your environments (perhaps keeping them only in read-only historical systems if necessary). This step might align with future regulatory phases – for instance, the EU roadmap ’ s 2035 goal for complete transition. You should set an internal target (maybe earlier than regulators) to turn off non-compliant crypto. Maintain a crypto exception register for any straggling use of old algorithms and actively work them down to zero.
MONITOR, AUDIT AND ADAPT
Finally, treat cryptographic security as an ongoing program, not a one-time project. Put in place continuous monitoring to ensure no new shadow usage of non-approved algorithms emerges (for example, integrate checks into CI/CD pipelines that flag any use of disallowed crypto libraries). Keep an eye on developments: new PQC algorithms may be standardized (NIST will introduce more algorithms as backups), and some might be deprecated if issues are found. With your crypto-agile setup, adapt to these changes – e.g. if in 2028 NIST says “Algorithm X is no longer recommended, use Algorithm Y” , your organization can smoothly implement that. Continue engaging in industry forums, share lessons with peers (many banks collaborate via ISACs or industry working groups on PQC).
From a compliance view, ensure your documentation and evidence remain up-to-date – presumably, by 2030, auditors might require proof that “all critical systems use PQC encryption” which you should be able to furnish easily thanks to your inventory and centralized management. Also, by this time, key management operations should be largely automated and policy-driven, reducing human error and effort.
CONCLUSION
Throughout all phases, communication is key – keep the board and executives informed of progress and any roadblocks (this is a high-profile risk area now). Also, ensure clients and partners are informed appropriately, especially if changes affect them (for instance, if you require clients to use updated software to connect securely with PQC, provide ample notice and support).
This phased roadmap aligns with regulatory expectations: by 2025 you have a plan and foundational improvements (meeting the immediate PCI 4.0 and DORA requirements), by 2026–2028 you have pilots and some PQC in place (showing supervisory authorities progress on the EU roadmap ’ s early milestones), and by 2030 you have completed the critical migrations (meeting the EU’ s 2030 objective for critical systems and well on track to full transition by 2035). It also leverages the principles of crypto agility and centralized control at every stage, ensuring the effort is efficient and adaptive.
Admittedly, this is a large undertaking – but as experts have warned, the transition to PQC is likely to consume several years of hard work, so starting now is non-negotiable. The cost of inaction (or late action) could be severe: whether it’ s a compliance penalty or, worse, a security breach where encrypted financial data is suddenly cracked by a quantum adversary, the stakes are too high to delay.
Fortunately, by following a structured roadmap and utilizing modern solutions (like an integrated key management system with PQC support), financial institutions can navigate this journey in a risk-managed way.
