ICT risk management
Record where RSA, ECDSA, ECDH and other quantum-vulnerable public-key cryptography protect financial data, administration, customer channels and critical operations.
DORA guide
DORA and Post-Quantum Cryptography
DORA does not name a specific post-quantum algorithm, but it does make ICT risk, third-party dependency, testing and operational resilience evidence central for EU financial entities. Quantum-vulnerable cryptography belongs in that evidence trail.
Updated: 19 June 2026|12 min read
ICT third-party risk
Ask cloud, payment, identity, CDN, HSM, signing and managed-service providers for PQC roadmaps, evidence and configuration responsibility.
Resilience testing evidence
Use external scans, configuration snapshots and supplier attestations as evidence that cryptographic risk is being measured and tracked.
Migration governance
Assign owners, dates, blockers and remediation actions so PQC work becomes part of the same risk governance used for other digital resilience work.
Why DORA Teams Should Track PQC
Financial entities depend on cryptography in customer portals, payment APIs, market data systems, identity platforms, certificates, token signing, supplier integrations, backup channels and administration interfaces.
Post-quantum migration is not just an algorithm decision. It is a dependency management problem: which assets use vulnerable public-key cryptography, what data is protected, how long that data stays sensitive and which ICT supplier controls the migration path.
A practical DORA-aligned approach starts with measurable public endpoints, then expands into inventory, supplier evidence, exception management and migration governance. The output should be a backlog that risk, security, technology and procurement teams can actually maintain.
DORA PQC Evidence Roadmap
1. Baseline visible endpoints
- -Scan public websites, customer portals, investor portals, API hostnames, payment callback URLs and remote access entry points.
- -Save TLS 1.3, certificate, security-header and visible PQC evidence in a free account.
- -Identify which endpoints are controlled by a CDN, cloud load balancer, WAF, API gateway or managed provider.
2. Build a DORA-aligned crypto inventory
- -Map TLS, mTLS, VPN, SSO, certificate, signing, token, HSM and key-management dependencies.
- -Tag systems by critical operation, data lifetime, supplier owner, regulator exposure and customer impact.
- -Separate public transport security from signing workflows, stored-data protection and internal service-to-service cryptography.
3. Collect supplier PQC evidence
- -Request support dates for NIST FIPS 203, 204 and 205 algorithms from ICT providers.
- -Record whether hybrid ML-KEM support is available, enabled, optional, roadmap-only or blocked by legacy clients.
- -Add PQC questions to supplier due diligence, renewal reviews and technology procurement.
4. Prioritise pilots and exceptions
- -Pilot hybrid ML-KEM TLS where compatibility can be measured and rollback is controlled.
- -Create exception records for suppliers, legacy clients, HSM limitations and signature chains that cannot migrate immediately.
- -Report progress using inventory coverage, supplier evidence, pilot status and blocker age.
What to Ask ICT Suppliers
| Supplier area | PQC evidence question | Decision record |
|---|---|---|
| CDN / WAF | Which hostnames support hybrid ML-KEM TLS, and is it enabled? | Enabled, planned, blocked or not supported |
| Cloud / load balancer | Does the managed TLS layer expose PQC configuration and logs? | Owner, region and compatibility status |
| Identity provider | Which signing algorithms protect tokens, assertions and certificates? | Signature migration owner and dates |
| HSM / key manager | What NIST PQC algorithm support is available or on the roadmap? | Vendor roadmap and exception notes |
| Payment/API gateway | How are mTLS, partner clients and callback signatures migrated? | Partner testing and rollback plan |
Primary References
DORA and PQC FAQ
Does DORA explicitly require post-quantum cryptography?
DORA does not mandate a named PQC algorithm. The practical connection is ICT risk: financial entities need to manage risks to network and information systems, critical operations and ICT third-party dependencies. Quantum-vulnerable cryptography should be tracked in that risk model.
What should a DORA programme scan first?
Start with public websites, login portals, API hostnames, payment callback endpoints and remote access surfaces. Those assets are visible, measurable and often controlled by suppliers whose PQC readiness must be evidenced.
How does PQC evidence fit supplier registers?
Treat PQC readiness as supplier evidence: which provider owns the cryptographic layer, what algorithms are supported, when hybrid options are available, who enables them and what client compatibility blockers remain.
Is a public scanner enough for DORA evidence?
No. A public scanner is a starting signal. DORA-aligned evidence also needs cryptographic inventory, supplier responses, governance records, testing evidence and documented migration decisions.
Start With One Evidence Item
Scan a public financial-services endpoint, save the result in a free account and use it as the first item in a DORA-aligned cryptographic evidence record.
Free readiness account
Keep This Guide Connected to a Real Website Scan
A PQC guide is more useful when it is attached to current evidence. Create a free account, add a public domain now or later, and keep a repeatable baseline for TLS, security headers and visible post-quantum readiness.
No cardStart the free evidence path without a paid plan.
Saved scanKeep the public endpoint result after the browser session.
Rescan laterRerun after TLS, header or provider changes.
Prefer to scan first? Open the free quantum security scanner.