Keep transactions confidential for as long as the record matters.
Inventory the cryptography on the wire, move payments and core banking to post-quantum TLS without touching the applications, and give PCI DSS, NYDFS and DORA the evidence they ask for.
Q-day is uncertain. The requirements for financial services are not.
Nobody knows when a cryptographically relevant quantum computer will arrive (Q-day), but your cryptography requirements do not depend on that date. Four reasons to start now:
AI is already finding weaknesses in algorithms
Anthropic’s Claude Mythos preview found serious weaknesses in candidate algorithms without a quantum computer. Cryptography can fail before Q-day arrives.
Adversaries are harvesting encrypted data now
They are collecting payment and account data which stay sensitive for decades, to decrypt when Q-day arrives: harvest now, decrypt later.
Regulators already require PQC migration
For a bank that means the cryptographic inventory PCI DSS 12.3.3 requires, the transition plan DORA asks for, and the encryption in transit NYDFS Part 500 expects.
Estimates for Q-day keep shrinking
Google has set 2029 as the target for its own migration. If yours is not finished in time, the foundation of modern financial infrastructure is at risk.
Google’s 2029 target and resource estimates: QuSecure, April 2026. NIST IR 8547, initial public draft, November 2024. Anthropic, Claude Mythos preview, 2026.
Why use QuProtect?
Cryptography belongs in a layer you control and configure, not in application code.
No rewrite, no rip-and-replace
QuProtect moves critical and legacy systems to PQC in a fraction of the time and cost.
Discovery and remediation in one platform
Many PQC solutions stop at discovery and leave the fix to you.
Built for large, complex organizations with highly sensitive traffic
Developed with the U.S. Army and U.S. Air Force.
Nothing is re-coded
A bank cannot afford application downtime to re-code its systems, so QuProtect does not ask for it.
The next migration is a configuration change
It is made from an Orchestrator you control, not run as another program.
Proven in production
Banco Sabadell validated post-quantum TLS in four months.
Use case in action
Your network, from the cryptography it runs today to the policy change that keeps it current. Move through the five steps, or click a number on the drawing.
-
Branches and field
- ATMs and branch hardware cannot be upgraded
- POS estates cannot be upgraded
-
Data centre
- Payment switch cannot be upgraded
- Core banking (mainframe) cannot be upgraded
- Trading and market data
-
Counterparties (not yours to change)
- SWIFT and interbank gateway
- Card networks
- Cloud services
Legacy cryptography, and what Q-day does to it
The branch estate reaches the payment switch on TLS 1.0, and the switch, the mainframe and the market-data feeds reach SWIFT, the card networks and the cloud on TLS 1.2 with RSA key exchange. Traffic recorded today can be stored until a quantum computer running Shor’s algorithm recovers those keys, and payment records stay sensitive for decades.
Sensors find the legacy negotiations and rank the violations
Reconnaissance sensors read what is on the wire and record the cipher suites, protocols, certificates and keys in use, without touching a system. Each policy violation is ranked by severity: TLS 1.0 on the branch hops first, RSA key exchange on the interbank links next.
Encryptors remediate at the network layer
A gateway in front of the branch estate and sidecars beside the switch, the mainframe and the market-data feeds carry each hop over TLS 1.3 with NIST post-quantum key exchange, X25519MLKEM768. No code changes, and the systems behind them are untouched.
Data in transit is secured, and the CBOM proves it
Traffic recorded from now on is not readable by a future quantum computer. The CBOM lists each connection’s protocol, algorithm and certificate with no open violations, in the form PCI DSS 12.3.3 and DORA ask an examiner to see.
Crypto-agility: the next algorithm is a policy change
When a standard moves, the Orchestrator pushes the new policy to each encryptor and the connections renegotiate, here from ML-KEM-768 to ML-KEM-1024, while traffic keeps flowing. The program does not start again.
Other use cases
Cryptographic inventory for PCI DSS 12.3.3 and DORA
Sensors watch live traffic and produce the CBOM of cipher suites, protocols, certificates and keys in use, on the annual review cadence the requirement sets.
Post-quantum key exchange on interbank links
SWIFT, card-network and cloud connections carry post-quantum TLS to the bank’s edge, and end to end where the counterparty negotiates ML-KEM, so traffic recorded today is not readable later.
Certificates at 47-day lifetimes
Automated provisioning and rotation from the Orchestrator, ML-DSA where the peer can verify it and classical fallback where it cannot.
Evidence for the examiner
Handshakes, identities and rotations are logged, and the CBOM carries owner and risk context into the GRC workflow.
TLS 1.3 uplift on systems that cannot be upgraded
Payment switches, core banking on the mainframe and market-data appliances stuck on TLS 1.0 to 1.2 are carried over TLS 1.3 at the network layer.
Branch and field hardware protected in place
ATMs, POS estates and end-of-life HSMs that will never take post-quantum firmware sit behind a gateway encryptor rather than being replaced.
Mutual TLS identity per application
Each workload gets its own identity and pairs over post-quantum mTLS: the segmentation between payment, trading and back-office systems examiners look for.
Algorithm change by policy
When the standard moves again, the change is a policy push across everything the Orchestrator governs, not a repeat of the program.
Financial services case study
Cipher rotation across 4,000 services while traffic kept flowing.
Banco Sabadell validated post-quantum TLS on customer-facing infrastructure in four months, and the SEC cited the pilot as an industry benchmark.