Financial institutions operating in the EU have faced a significantly tightened regulatory environment since January 2025: the Digital Operational Resilience Act (DORA) is now in force and overlaps with the NIS2 Directive on several key points. Both frameworks impose requirements on TLS certificates and PKI — but from slightly different angles.
Here is what CISOs and compliance officers at banks, insurers, and investment firms need to have in place.
DORA and certificates: what the regulation requires
DORA (Regulation EU 2022/2554) entered into force on 17 January 2025 and applies to financial entities including banks, insurers, investment firms, payment institutions, and a broad range of other actors.
DORA's primary focus is operational resilience — the ability to withstand, respond to, and recover from ICT disruptions. Certificates and TLS are in scope in several ways:
Article 8 — ICT asset management. Financial entities must identify and document all ICT assets — including the certificates that secure communications and systems. A complete certificate register is a direct consequence of this requirement.
Article 9 — Protection and prevention. DORA explicitly requires strong encryption measures and secure configuration. For TLS this means: protocol versions (TLS 1.2 minimum, TLS 1.3 preferred), cipher suites (no RC4, no 3DES), and key lengths (RSA 2048+ or ECDSA 256+). These are the parameters regulators and supervisory authorities check during inspections.
Article 17 — ICT-related incidents. DORA introduces detailed requirements for classifying, reporting, and managing incidents. A certificate expiry that disrupts payment services or customer access is potentially a notifiable incident under the regulation.
Articles 28–30 — Third-party risk. DORA imposes particularly stringent requirements for managing ICT vendors. The certificates and TLS configuration of critical third-party providers are in scope — financial entities are expected to monitor that vendors maintain secure connections.
NIS2 and the financial sector
Banks and financial institutions are classified as "essential entities" under NIS2 — the highest-scrutiny category. This means:
- Proactive supervisory powers for regulators
- Fines of up to €10 million or 2% of global annual turnover
- The same risk management and incident reporting requirements as other NIS2 entities
For certificates, the same requirements apply as set out in NIS2 Article 21 — but financial sector entities are subject to a stricter supervisory framework.
Overlap and synergy
DORA and NIS2 are not designed to duplicate each other — DORA is sector-specific lex specialis for financial entities, while NIS2 is the general framework. For financial institutions, DORA takes precedence as the primary framework where the two overlap, but NIS2 requirements can complement it in areas DORA does not cover.
In practice, there is substantial overlap on certificate management:
- Both require a complete asset register that includes certificates
- Both require risk assessment of TLS configuration and certificate lifecycle
- Both require procedures for incident handling and reporting
- Both require monitoring of third-party security posture
A certificate management programme built for DORA Articles 8 and 9 will satisfy the overlapping NIS2 Article 21 requirements. The only area requiring additional work is DORA's stricter third-party contractual requirements under Articles 28–30.
| Requirement | DORA | NIS2 |
|---|---|---|
| Scope | Financial entities (banks, insurers, investment firms, payment institutions) | Essential and important entities across 18 sectors |
| Asset register | Article 8 — ICT asset management (mandatory) | Article 21(2)(h)/(i) — asset management as part of security measures |
| TLS/certificate requirements | Article 9 — strong encryption, cipher suites, key lengths | Article 21(2)(h) — cryptography and encryption policies |
| Initial incident notification | 4 hours (major incidents, from classification) | 24 hours (early warning, significant incidents) |
| Third-party obligations | Articles 28–30 — detailed ICT vendor requirements, contractual obligations | Article 21(2)(d) + Article 22 — supply chain security |
| Primary supervisory authority (Denmark) | Finanstilsynet (Danish FSA) | Finanstilsynet (financial sector) |
| Maximum fine | Sanctions applied by national supervisory authorities | €10 million or 2% of global annual turnover (essential entities) |
What is specific to the financial sector
Encryption standard requirements. Financial regulators (EBA and national supervisory authorities) impose stricter requirements on TLS configuration than the general market. TLS 1.0 and 1.1 are unacceptable, and weak cipher suites are a red flag during inspections.
The vendor chain runs deep. DORA's third-party requirements are more detailed than those in NIS2. Financial entities are expected to have contractual requirements governing critical ICT vendors' certificate management — and documentation that those requirements are being met.
Tight reporting deadlines. DORA introduces even shorter timelines for classifying incidents than NIS2: 4 hours for the initial notification to authorities for major incidents. Without a complete certificate register, it is simply not possible to assess the scope of a certificate-related outage within that window.
Note on technical standards: DORA Article 9 requirements are further elaborated in the Joint Committee RTS on ICT risk management (JC 2023 86), published January 2024 and applicable from January 2025. This RTS specifies encryption and PKI requirements in operational terms — including requirements for key management and certificate validity that align directly with what CertControl monitors and reports on.
Three priorities for financial institutions
For financial institutions looking to address both frameworks efficiently, there are three key priorities:
Consolidate your ICT asset register. A complete, automatically maintained certificate register satisfies the asset management requirement under both regulations. Build it once and use it for both compliance objectives.
Monitor critical ICT vendors continuously. Identify critical ICT vendors and set up automated monitoring of their certificates. A certificate expiry at a critical payment infrastructure provider is your DORA incident — with a reporting obligation within 4 hours of classification.
Maintain a continuous, timestamped audit log. A continuous log of certificate events, changes, and alerts — with timestamps — is one of the most effective forms of compliance evidence during DORA and NIS2 inspections. It cannot be reconstructed after the fact and is difficult to dispute.
What CertControl delivers for DORA and NIS2
The three priorities for financial institutions — one register for two purposes, vendor monitoring as a default, audit log as compliance evidence — are precisely what CertControl is built to deliver:
- One automatically maintained certificate register covering both regulations. CertControl combines CT log enumeration for externally visible certificates with an on-premise agent for internal systems. The register is updated continuously — not manually ahead of an inspection. It satisfies the asset register requirement under DORA Article 8 and NIS2 Article 21(2)(h) from a single data source.
- Vendor certificate monitoring without manual tracking. CertControl can monitor TLS certificates on critical ICT vendors' endpoints directly — payment infrastructure, settlement systems, data feeds. A certificate expiry at a critical vendor is visible 30–90 days in advance, not when the connection breaks.
- Meeting DORA's 4-hour classification window requires a complete register. DORA's requirement for initial notification within 4 hours of a major incident assumes that the scope of a certificate-related outage can be determined quickly. With CertControl, you know immediately which systems are affected by a given certificate — because the certificate-to-system mapping is in the register.
- A continuous audit log that cannot be reconstructed after the fact. CertControl logs all certificate events, alert triggers, and changes with timestamps. This history is credible precisely because it was not created for the occasion — making it the strongest form of compliance evidence during DORA and NIS2 inspections.