You run on webs of third-party APIs, and each connection carries data that has to stay protected far longer than the connection itself lasts. Know your customer (KYC) records, transaction history, and account data don’t expire in a year or two. And regulators on both sides of the Atlantic have noticed.
In the EU, the Digital Operational Resilience Act (DORA) requires financial entities to update their cryptography as cryptanalysis advances, and its technical standards name quantum as the threat they have in mind.
In the US, June’s Executive Order 14412 put federal systems on a 2030 clock for post-quantum key exchange. In August, the Treasury created a Quantum-Readiness Task Force for the financial sector with a workstream dedicated to vendor and third-party readiness. Add SWIFT’s post-quantum cryptography testing through Project Leap Phase 2 alongside New York Department of Financial Services (NYDFS) Part 500 and PCI DSS, and the real question isn’t whether to prepare. It’s where to start.
That’s a harder question for you than for a traditional bank. Your stack is rarely one system. It’s dozens of vendor APIs, cloud services, and microservices stitched together. Every one of those seams is a place where cryptography either holds or doesn’t. “Harvest now, decrypt later” (HNDL) doesn’t need your whole stack to fail. It only needs one long-lived connection captured today and decrypted once quantum computing catches up.
Where the Exposure Sits
Three places carry most of the risk. Third-party and API connections are the layer DORA names directly, and the layer the Treasury’s task force singled out for its primary workstream. Your security is only as strong as the weakest partner you connect to. Long-lived financial and identity data, KYC records, transaction history, and account records, sits exposed the moment it’s captured, regardless of when it’s eventually decrypted. And lastly, microservice-to-microservice identity, the handshakes happening constantly between your internal services, still runs on RSA and ECC.
Every one of these connections assumes encryption holds for as long as the data needs to stay private. But quantum computing breaks that assumption. NIST has already set the clock: RSA and ECC are deprecated after 2030 and disallowed after 2035. None of these three layers is optional to secure. You can’t protect your own core and leave the API layer exposed. The data moving across that layer is exactly what regulators and attackers both care about most.
Putting PQC on the Clock
If you’ve been treating PQC as a European compliance story, 2026 changed that. Executive Order 14412 requires federal agencies to move high-value systems to post-quantum key establishment by December 31, 2030, and to post-quantum digital signatures by December 31, 2031. That’s five years earlier than the old 2035 target. OMB’s M-26-15 turned the order into marching orders: inventory every cryptographic dependency, build PQC readiness and crypto-agility into vendor requirements, and submit a migration plan. A proposed Federal Acquisition Regulation (FAR) rule due this December would push FIPS compliance, including the PQC standards, onto federal contractors by 2030. And since September 21, NIST only accepts FIPS 140-3 validated modules for new federal procurement.
None of that binds a fintech directly. What binds you is what flows downstream from it. The Treasury is the Sector Risk Management Agency for financial services, which means the executive order tasks it with helping the sector build migration plans. It moved fast.
On August 24, it launched the aforementioned Quantum-Readiness Task Force, a public-private body with three workstreams: sector alignment and PQC transition, third-party and vendor readiness, and digital-asset risk. The vendor workstream exists because, as Moody’s put it, bank quantum readiness ends where third-party crypto opacity begins. If a bank or payments network is your customer or your counterparty, expect them to ask for your PQC roadmap, because they’re about to be asked for theirs. The Treasury also co-chairs the G7 Cyber Expert Group with the Bank of England, whose January 2026 roadmap points critical financial systems to 2030 and the full sector by 2035.
Banking and market regulators haven’t set a hard deadline, but they’ve made their expectations clear. The OCC flagged quantum risk in its Semiannual Risk Perspective as far back as 2022, and the Federal Reserve calls it a significant emerging risk. FINRA told securities firms in 2023 to inventory their cryptography and start planning their migration. The SEC’s cybersecurity disclosure rules don’t mention quantum, but they do require organizations to explain how they assess material cyber risk.
Meanwhile, a September 2026 CSIS review found that only about one in 10 SEC-reporting financial institutions even mentions quantum. That blind spot won’t go unnoticed by examiners. NYDFS Part 500 already requires encryption of nonpublic information in transit and at rest, along with an annual risk assessment. PCI DSS 4.0 expects you to track cryptographic weaknesses and maintain an inventory of keys and protocols. Neither explicitly calls for post-quantum security yet. But both give auditors a reason to question why your risk assessment overlooks an attack class the Treasury’s own task-force announcement describes as “a present-day risk control.”
What ZeroTier Quantum Adds
We built ZeroTier Quantum to embed hybrid PQC directly into the network layer. It runs through the ZeroTier Transport Protocol (ZTP), using the NIST-standardized ML-KEM-1024 algorithm (FIPS 203) for quantum-resistant key exchange and ML-DSA-87 (FIPS 204) for quantum-resistant digital signatures and identity authentication. Both algorithms align with the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), the world’s most stringent suite of cryptographic requirements.
ZeroTier Quantum also pairs ML-KEM-1024 with classical P-384 ECC cryptography for hybrid key exchange, adding a second layer of optional protection. Any eavesdropper must defeat both the P-384 and ML-KEM math. Cracking only one yields absolutely zero data.
It also brings cryptographic service identity in place of shared credentials, supporting the flexibility organizations need as PQC standards evolve.
Additionally, built-in continuous key rotation is what keeps this aligned with the ZTNA principles you’re likely already adopting. Instead of trusting a connection because it sits inside your perimeter, you verify identity and re-establish trust on a regular cadence. That’s also why ZeroTier Quantum fits naturally into a SASE architecture. Networking and security converge at the edge instead of routing everything back through a central VPN concentrator. You’re probably already moving toward ZTNA and SASE for exactly this reason, and post-quantum cryptography doesn’t require a separate architecture on top of that shift. It slots into the identity-first model already replacing your perimeter.
And ZeroTier Quantum’s continuous key rotation extends perfect forward secrecy into the post-quantum era. Even if a session’s keys were compromised, they can’t be used to decrypt sessions before or after it. That matters directly against HNDL, since captured traffic today stays unusable even once quantum decryption becomes viable. It also matters for the cryptographic bill of materials (CBOM) that CISA and NIST are due to define by March 2027: When the transport layer is PQC by default, every service connection running over it is one line you can already account for. The whole platform runs on infrastructure already aligned to SOC 2 Type II and the General Data Protection Regulation (GDPR).
Why ZeroTier Quantum Fits Fintech
Speed matters here in a way it doesn’t for every industry. Payments and trading can’t absorb the latency of routing everything through a VPN concentrator, and ZeroTier Quantum’s overlay model avoids that bottleneck entirely. It deploys the same way across jurisdictions, whether your workload sits in the cloud, on-prem, or inside a sovereign environment a regulator requires. That matters when you’re operating across the EU, UK, and US, each with its own regulatory requirements. The EU is calling for high-risk use cases to migrate by 2030, and the US federal deadline is now set for the same year.
And the real regulatory ask isn’t a one-time migration to a new algorithm. It’s also crypto-agility. The DORA technical standards require you to update cryptography as cryptanalysis moves. OMB M-26-15 tells federal buyers to write crypto-agility into vendor requirements. The G7 roadmap and the Treasury task force both name it as a goal. We built the platform to adapt as NIST, DORA, and the US frameworks keep evolving, instead of asking you to rebuild every time they do. Treat PQC as a checkbox to clear once, and you’ll be back here again in a few years. Build for crypto-agility, and you won’t.
PQC readiness is a “now problem” for regulators, not a 2030 one. The US just wrote the dates down, and the Treasury is already asking the sector’s vendors where they stand. Treat it as a future migration, and you’ll find that out during an audit, or a customer’s vendor review, instead of on your own timeline.
Your partners are preparing for a post-quantum future, and your platform needs to be ready. Contact sales to learn how ZeroTier Quantum brings post-quantum protection to your platform.
