Banks treat cryptographic migration as a future project until a regulator names a date. In 2026, regulators are naming dates. FINMA expects Swiss financial institutions to have board-approved post-quantum cryptography roadmaps by mid-2027. The CNSA 2.0 timeline requires new National Security System acquisitions to comply from January 2027.
SWIFT's mandatory Release 8.0 arrives in July 2027. For banking security leaders evaluating post-quantum cryptography (PQC) platforms, the question is no longer whether to migrate. It is how to evaluate the platforms that will carry your institution through the next decade of cryptographic change.
This guide maps the evaluation criteria that matter for regulated financial institutions: source-code transparency, customer-managed key control, algorithm agility, and sovereign deployment. ExeQuantum delivers a connected platform covering discovery, migration, and monitoring under one data model.
Key Takeaways: Evaluating PQC Platforms for Banks in 2026
- Source-code transparency and formal verification allow your security team to audit cryptographic implementations independently, which regulators increasingly expect.
- Customer-managed key control (Bring Your Own Key) eliminates vendor custody risk and keeps cryptographic material under your jurisdiction.
- Algorithm agility as architecture means swapping cryptographic primitives through configuration changes, not rebuilding systems when standards evolve.
- Sovereign deployment models that support air-gapped and on-premises operation satisfy data residency mandates across APRA, FINMA, DORA, and PCI DSS.
- ExeQuantum's STAC framework aligns platform evaluation directly with Sovereignty, Transparency, Agility, and Compliance requirements for banks.
Why Banks Face Unique PQC Migration Challenges
Banking infrastructure carries characteristics that make PQC migration harder than in most sectors. Transaction data, customer records, and interbank messaging must remain confidential for decades. Adversaries collecting encrypted financial traffic today will be able to decrypt it when cryptographically relevant quantum computers arrive.
This harvest-now-decrypt-later exposure creates an urgent need that banks in particular cannot defer. According to a September 2026 analysis by CSIS, only about 1 in 10 of the roughly 400 U.S. banks filing SEC annual reports mentions quantum risk at all.
Regulatory timelines compound the pressure. A FINMA survey of 60 Swiss financial institutions (July 2026) found that only 8% had a PQC roadmap. Europol, ENISA, and the European Central Bank issued a joint report naming cryptographic inventory as the foundational first step for financial services migration.
What Is Source-Code Transparency in PQC Platforms?
Source-code transparency means your organisation can inspect, audit, and verify the cryptographic implementation running in production. For banks, this is a regulatory and operational requirement, not a philosophical preference.
Closed cryptographic libraries create a specific risk. Your security team cannot verify that the code executes in constant time, handles secret material correctly, or resists timing side-channels introduced by compiler optimisations like branch prediction and instruction reordering.
Why Formal Verification Matters for Banking Cryptography
Formal verification produces mathematical proof that the compiled binary behaves exactly as specified. For banking applications where a single timing side-channel could expose private keys, this level of assurance is a design requirement.
ExeQuantum's CipherForge uses a Jasmin/C hybrid architecture. Every subroutine handling secret values is written in Jasmin, enforcing constant-time execution and formal verification at the assembly level. The ML-DSA signing implementation runs at 115% to 137% of the standard C reference throughput.
How to Evaluate Source-Code Access During Platform Selection
Request specifics when evaluating a PQC platform's source-code posture. Ask whether the implementation source code is available for independent audit. Confirm whether formal verification covers the routines that handle key material and signing operations.
Check if the vendor can demonstrate constant-time execution at the assembly level. Platforms offering source-code handover for air-gapped deployments give your organisation the ability to verify cryptographic behaviour independently.
Assess the verification scope. Formal verification that covers only one algorithm family, while leaving other supported primitives unverified, signals an incomplete assurance posture.
What Is Customer-Managed Key Control and Why Do Banks Need It?
Customer-managed key control means your organisation retains full custody of encryption keys, entropy generation, and algorithm governance. The vendor never stores, accesses, or transmits your keys. For banks operating under APRA CPS 230, DORA, or PCI DSS, this is a compliance prerequisite.
Vendor-held keys introduce two risks. A breach of the vendor's infrastructure exposes your cryptographic material. And keys stored in a foreign data centre may be subject to foreign government access requests, regardless of your own regulatory obligations.
Bring Your Own Key (BYOK) Across Deployment Models
Full BYOK means key custody remains with your organisation across every deployment scenario: cloud, on-premises, hybrid, and air-gapped. Some platforms offer BYOK only in their enterprise tier or only for specific key types.
ExeQuantum supports full Bring Your Own Key across all deployment models. The platform's BYOD (Bring Your Own Database) architecture stores all scan data and CBOM outputs in your own provisioned database. ExeQuantum never holds or has persistent access to client data.
Evaluating Key Custody and Data Residency Claims
Ask whether key custody is a policy or an architectural constraint. A vendor policy can be revised. An architecture that never handles your keys cannot. Confirm where discovery data and scan results are stored.
For banks with data residency obligations, verify that the platform runs entirely on-premises or in air-gapped mode. On-premises deployment should not require callback connections to the vendor's cloud for licensing or telemetry.
Validate the claim with a technical demonstration. Request a network traffic capture during a scan cycle to confirm that no data leaves your infrastructure boundary during operation.
How to Assess Algorithm Agility in a PQC Platform
Algorithm agility is the ability to swap cryptographic primitives through configuration changes rather than re-engineering systems. The HAWK withdrawal in July 2026 demonstrated that the window between algorithm proposal and algorithm failure is compressing.
A platform built on a single algorithm creates a single point of failure. If that algorithm is weakened or withdrawn, your organisation faces an emergency migration project on top of production workloads.
What Algorithm Agility Looks Like in Practice
A platform with genuine agility supports NIST-standardised algorithms: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). It also supports additional candidates like HQC and FN-DSA (Falcon), plus hybrid TLS and pre-shared key modes for backward compatibility.
ExeQuantum's CipherForge supports ML-KEM and ML-DSA alongside HQC and FN-DSA, enabling algorithm rotation as standards evolve. Hybrid TLS and pre-shared key modes extend agility into constrained environments like payment terminals and IoT-connected banking infrastructure.
Questions to Ask Vendors About Algorithm Support
Determine which NIST-standardised and candidate algorithms the platform supports. Confirm whether algorithm updates are delivered as configuration changes or require software re-deployment.
Ask how the platform handles hybrid classical/post-quantum modes during the migration period, and whether these modes are available across TLS, API, and certificate operations.
Why Sovereign Deployment Models Matter for Banks
Sovereign deployment means your PQC platform operates entirely inside your infrastructure boundary, under your jurisdiction, with no data flowing to the vendor. For banks subject to APRA CPS 230, FINMA Guidance 05/2026, DORA, or NIS2, this is the clearest path to satisfying data residency mandates.
Cloud-native PQC offerings from hyperscale providers operate at the boundary of their own infrastructure. They are incentivised to confirm their environment is safe, not to surface cryptographic exposure in your on-premises or multi-cloud estate.
Air-Gapped and On-Premises Deployment Requirements
Banks operating classified or restricted networks require PQC platforms that function without internet connectivity. The platform binary should be verifiable at install time using post-quantum signatures.
ExeQuantum's full platform runs on-premises or in air-gapped environments. The on-premises bundle is verified at install with ML-DSA-65 and minisign. Sovereign deployment keeps keys and data inside your infrastructure boundary, eliminating foreign vendor dependencies.
A vendor-neutral platform that scans your actual estate, regardless of where it sits, removes the conflict of interest inherent in hyperscaler-provided PQC tools that only cover their own boundary.
How to Build a Cryptographic Inventory Before Migrating
The conversation about post-quantum readiness often jumps straight to algorithm selection. That question matters, but it is premature for any organisation that has not first answered: what cryptographic assets do we have, where are they, and which ones are already vulnerable?
A cryptographic inventory catalogues every key, certificate, protocol, and algorithm in use across your estate. It identifies where RSA, ECDSA, Diffie-Hellman, and other quantum-vulnerable primitives sit in production.
What a Standards-Compliant CBOM Delivers
A Cryptographic Bill of Materials (CBOM) in CycloneDX format gives your security and compliance teams a machine-readable map of cryptographic exposure. It documents which algorithms protect which assets, their key sizes, certificate expiry dates, and protocol versions.
ExeQuantum's CipherScout discovers cryptographic assets across 10 attack surfaces and produces a standards-compliant CBOM. Every finding carries a NIST control reference. The same scan data feeds into CipherForge for remediation and CipherWatch for monitoring.
Why Manual Cryptographic Inventories Fall Short
Point-in-time audits and spreadsheet-based registers capture a snapshot that begins decaying the moment the audit completes. New certificates are issued, APIs are updated, and shadow cryptography accumulates in development environments.
An automated discovery engine that runs recurring scans and tracks changes over time is the only approach that keeps a cryptographic inventory current and audit-ready.
Third-party connections add another layer of exposure. Vendor-supplied cryptographic dependencies may change without notice, requiring a discovery engine that monitors external as well as internal cryptographic surfaces.
A Step-by-Step Framework for Evaluating PQC Platforms
Structured evaluation prevents the selection process from collapsing into a feature-comparison exercise. The STAC framework (Sovereignty, Transparency, Agility, Compliance) offers a systematic method for scoring PQC platforms against the criteria that matter for regulated financial institutions.
Step 1: Assess Sovereignty Controls
Map the platform's deployment options against your jurisdiction's data residency requirements. Verify that key custody, scan data, and CBOM outputs remain inside your infrastructure boundary. Confirm air-gapped deployment is supported without licensing callbacks.
Evaluate whether the platform supports source-code handover for no-external-dependency environments. This capability is relevant for banks operating under national security classifications.
Step 2: Evaluate Transparency and Auditability
Request documentation of formal verification, including the scope of verified routines and the proof artefacts available for review. Confirm whether the platform produces standards-compliant CBOMs and that every finding carries a reference to the applicable regulatory control.
Step 3: Test Algorithm Agility
Verify the list of supported NIST-standardised and candidate algorithms. Confirm that algorithm rotation happens through configuration changes. Request a demonstration of a live algorithm swap in a test environment.
Step 4: Validate Compliance Alignment
Map the platform's compliance reporting against your regulatory obligations: APRA CPS 230, FINMA Guidance 05/2026, DORA, NIS2, PCI DSS, and ISO 27001. Confirm that the platform produces audit-ready evidence, not only dashboards.
Ask for sample compliance reports. Evidence-based compliance requires that every cryptographic finding links directly to the regulatory control it affects, enabling precise audit conversations.
Step 5: Run a Scoped Proof of Concept
A scoped POC delivers tangible output: a cryptographic inventory of a defined network segment, a risk report, and a migration priority ranking. ExeQuantum offers a fixed-fee POC programme with defined deliverables, timelines, and success criteria.
What Compliance Frameworks Require from PQC Platforms in Banking
Multiple regulatory frameworks now intersect at post-quantum cryptography, each with different timelines and specificity. Understanding how they overlap helps your organisation build a single migration plan that satisfies several mandates simultaneously.
CNSA 2.0 and NIST Standards
The CNSA 2.0 timeline requires new National Security System acquisitions to use quantum-resistant algorithms from January 2027, with a full mandate by December 2031. NIST has finalised FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) as the core post-quantum standards.
APRA CPS 230 and Operational Resilience
Australia's APRA CPS 230 requires regulated entities to manage operational risks from critical operations, including technology supply chains and third-party dependencies. A PQC platform's sovereign deployment, customer-managed key control, and vendor-neutral discovery directly address CPS 230's operational resilience requirements.
DORA, NIS2, and European Mandates
DORA and NIS2 impose ICT risk management and incident reporting obligations on financial entities operating in the EU. A PQC migration programme with audit-ready evidence of cryptographic posture satisfies the intent of these frameworks ahead of any quantum-specific amendment.
How PQC Platform Architecture Differs from Point Solutions
Splitting cryptographic discovery, implementation, and monitoring across multiple vendors creates gaps at every handoff. Inconsistent data models and competing priorities mean that discovery findings do not automatically flow into remediation workflows.
ExeQuantum's EQCore operates as a Cryptographic Control Plane: CipherScout discovers, CipherForge migrates, CipherWatch monitors. All three share a common data model, with a single CBOM that travels from inventory through remediation to ongoing posture management.
Why a Single Data Model Reduces Migration Risk
When discovery findings and remediation actions share the same data format, there is no translation loss between stages. An RSA-2048 certificate identified by CipherScout carries the same metadata through CipherForge's ML-KEM replacement and into CipherWatch's monitoring scope.
This eliminates the risk of items falling through gaps between separate tools with incompatible data structures. One chain of accountability from discovery to remediation to ongoing monitoring is how banks achieve audit-ready migration evidence.
In Conclusion: How to Evaluate PQC Platforms for Your Bank
The organisations best positioned for the post-quantum migration are those that start with discovery, build toward agility, and treat cryptography as a governed risk system. For banks, the evaluation criteria are specific: source-code transparency with formal verification, customer-managed key control, algorithm agility as architecture, and sovereign deployment.
The regulatory clock is running. FINMA, CNSA 2.0, SWIFT, and APRA are converging on timelines that require cryptographic readiness between 2027 and 2031. Starting with a cryptographic inventory is the lowest-risk path to an auditable migration roadmap.
To assess your organisation's cryptographic posture, request a Quantum Readiness Assessment or contact us at info@exequantum.com.
FAQs About Evaluating PQC Platforms for Banks
What is post-quantum cryptography and why do banks need it?
Post-quantum cryptography (PQC) is a class of encryption algorithms designed to resist attacks from both classical and quantum computers. Banks need PQC because financial data must remain confidential for decades, and harvest-now-decrypt-later attacks put current encrypted traffic at risk.
What is a Cryptographic Bill of Materials (CBOM)?
A CBOM is a machine-readable inventory of every cryptographic asset in your environment: keys, certificates, algorithms, and protocols. ExeQuantum's CipherScout produces CycloneDX-format CBOMs that map exposure to NIST control references, giving your team a prioritised migration roadmap.
How does customer-managed key control differ from vendor-managed keys?
Customer-managed key control means your organisation holds, generates, and governs all encryption keys. The vendor never has access to your key material.
ExeQuantum enforces this through its BYOD architecture, where all cryptographic data stays in your own database under your own access controls.
What is algorithm agility and why is it a design requirement?
Algorithm agility is the ability to swap cryptographic primitives through configuration changes, not code rewrites. ExeQuantum's CipherForge supports NIST-standardised algorithms alongside emerging candidates, enabling algorithm rotation as standards evolve.
How should a bank start its PQC platform evaluation?
Start with a cryptographic inventory. Before selecting algorithms or platforms, you need visibility into what cryptographic assets your organisation runs and where quantum-vulnerable primitives sit in production.
ExeQuantum's POC programme delivers a scoped inventory with a risk report and migration priorities.
What regulatory frameworks require PQC migration for banks?
CNSA 2.0 mandates quantum-resistant algorithms for National Security Systems from January 2027. FINMA Guidance 05/2026 expects PQC roadmaps by mid-2027. APRA CPS 230, DORA, and NIS2 impose operational resilience obligations that PQC migration directly addresses.
