DORA Compliance
DORA Certificate Register
Which certificates and certificate-storing devices belong in the register, and how do you keep it up to date? We explain the legal basis, scope and ongoing maintenance and show the implementation with Blackfort Certificate Intelligence.
DORA certificate: what it means
Searches for a “DORA certificate” usually mean one of two things: the digital certificates in the ICT infrastructure that financial entities must keep in a register, or some kind of certification that confirms DORA compliance.
There is no official DORA certification. DORA is an EU regulation. Whether a financial entity complies is assessed by the competent supervisory authorities, in Germany BaFin and the ECB for significant banks. Training records, vendor attestations and audit reports evidence individual measures; they are not an official compliance certificate.
Digital certificates, on the other hand, are regulated specifically. The register obligation covers at least all certificates and certificate-storing devices of the ICT assets that support critical or important functions. These can include TLS, client, code signing, S/MIME and CA certificates. That is what this page is about.
What is the DORA certificate register?
Legal basis and wording
“Financial entities shall create and maintain a register for all certificates and certificate-storing devices for at least ICT assets supporting critical or important functions. Financial entities shall keep that register up to date.”
“Financial entities shall ensure the prompt renewal of certificates in advance of their expiration.”
DORA has applied since 17 January 2025. Delegated Regulation (EU) 2024/1774 specifies the ICT risk management requirements as regulatory technical standards (RTS). Art. 7 covers cryptographic key management; paragraphs 4 and 5 concern certificates. Art. 8 DORA generally requires ICT assets to be identified and documented; the explicit certificate register obligation is in the Delegated Regulation.
Who the obligation applies to
It applies to financial entities within the scope of DORA that use the general ICT risk management framework. Entities under the simplified framework of Art. 16 DORA are not covered by Art. 7(4). Small and medium-sized insurance intermediaries are exempt from DORA.
The minimum scope follows the critical or important functions: the certificates and certificate-storing devices of the ICT assets supporting them must be recorded. The register must also be kept up to date, so a one-off export does not meet the obligation.
Which certificates and certificate-storing devices must be recorded?
TLS and server certificates
TLS certificates, often still called SSL certificates, for web applications, APIs, load balancers, reverse proxies and internal services.
Client and machine certificates
Devices, services and interfaces that authenticate to other systems, for example via mTLS or 802.1X.
Code signing and S/MIME
Signed software and scripts, signed and encrypted email.
CA certificates
Root and intermediate certificates of your own PKI and of the trust chains that critical services rely on.
Certificate-storing devices and locations
Besides the certificate itself, the regulation explicitly names certificate-storing devices: hardware security modules, cloud vaults such as Azure Key Vault, AWS Certificate Manager or Google Certificate Manager, Windows certificate stores, Java keystores, Kubernetes secrets and appliances. The same certificate can be deployed in several places, for example a wildcard certificate on several load balancers.
Certificates in cloud environments, at ICT third-party providers and in isolated network segments are included as far as they support critical or important functions. Private keys do not belong in the register; it holds only the public certificate and the details about it.
Building a DORA-compliant certificate register
Art. 7(4) does not prescribe specific register software, and whether a register meets the requirements is decided in the individual review. The following steps are our recommendations for practical implementation from PKI projects in regulated environments.
1. Define scope and responsibilities
Start from the critical or important functions and the ICT assets that support them. From there follow the sources: which CAs, cloud vaults, clusters, endpoints and isolated segments are included, and who is responsible for them. Areas not yet clarified are kept visible as open instead of being silently left out.
2. Useful register fields
| Area | Fields (recommendation) |
|---|---|
| Technical | Fingerprint, serial number, issuer, subject and SANs, validity, key type and length, signature algorithm |
| Origin and storage | Source (CA, cloud vault, network scan, import), certificate-storing device or location, related ICT asset, first and last seen |
| Governance | Supported function or process, classification as critical or important, responsible owner |
| Status and evidence | Expiry, revocation status, open findings, handling status, change history |
3. Organise currency and timely renewal
Changes must be reflected in the register promptly. Regular source imports and documented update times support ongoing maintenance. Upcoming expiries are escalated by criticality and assigned to a responsible owner. Renewal itself is done with the existing CA or CLM processes. Updated source data and a re-check loop help to follow it through; whether the new certificate is actually in use is verified at the respective location.
4. Embed it in existing processes
New systems, supplier changes and infrastructure changes should trigger a review of the affected certificates. Findings belong where work already happens: as a ticket in the ITSM system, as an alert in monitoring, as a daily summary in the team channel.
Practice
Typical challenges with the certificate register
The requirement is short. In grown environments, often built around a Microsoft CA that has been running for years, implementation fails at these five points.
Scattered sources
Certificates come from several CAs, cloud vaults, Kubernetes clusters and public orders. Each source only knows its own slice; a shared inventory is missing.
Missing owners
Certificates are renewed for years without a documented responsible owner. When renewal fails, operations is the first to notice.
Unclear currency
Excel lists and exports go stale unnoticed. During an audit you cannot show when the inventory was last fully captured.
Findings left lying
Upcoming expiries, revoked certificates still in use and weak cryptography are reported but not followed up.
Costly evidence
An audit request for all certificates of critical functions cannot be answered from one consistent source.
Positioning
CA, monitoring, CLM and Certificate Intelligence
Several tools contribute to the register, each with a different job.
CA and PKI
Issues and revokes certificates and knows its own inventory. It has no view across several CAs, cloud vaults and public certificates.
Monitoring
Monitors connected services and certificates. A complete register additionally needs all relevant sources plus functions and owners.
CLM platform
Supports inventory and lifecycle processes up to issuance, renewal and deployment. Required privileges and integration effort depend on the scope.
Certificate Intelligence
Consolidates certificates from connected sources in one register, adds functions and owners and provides findings and evidence. Issuance and renewal stay with existing systems.
Implementation
Blackfort Certificate Intelligence for running the register
A reliable register links certificate data to the ICT assets, functions and owners that depend on it. For operations and evidence we recommend documenting data currency, expiries and the handling of findings in a traceable way. That is what we built Certificate Intelligence for: a read-only certificate register that runs in your environment as containers, including isolated networks, and never sees private keys.
Consolidate the inventory
Read-only connectors at CAs and cloud vaults, a built-in TLS scanner, Certificate Transparency logs and file import for isolated segments. Each certificate held once, with source, location and first and last seen.
Maintain functions and owners
Critical or important classification, supported function, responsible owner and custom columns on each certificate. New imports never overwrite them. Certificates without an owner are visible at a glance.
Work through findings
Expiry staggered by criticality, revocation status via CRL and OCSP including “revoked but still in use”, weak cryptography, key reuse and orphans. Findings can become Jira tickets with a due date, and the register keeps checking until they are resolved.
Deliver evidence
Append-only audit trail of all changes and a complete Excel and CSV export for internal and external auditors, without an account. Plus 13 monitoring integrations and a daily summary in Microsoft Teams.
Sources
Validated against real CA software in the Blackfort PKI test lab: Microsoft ADCS, EJBCA, HashiCorp Vault PKI, smallstep step-ca.
Tested in the lab against a real cluster: Kubernetes with cert-manager.
Cloud vaults: Azure Key Vault, AWS Certificate Manager, Google Certificate Manager.
Plus: TLS scanner, Certificate Transparency logs, file import for isolated segments. OT and IoT systems in scope can be included via file import or scan.
Source and location (CA, cloud vault, Kubernetes secret, endpoint) document the origin and observed use of a certificate. Certificate-storing devices are currently not held as separate register objects; devices not covered that way need to be documented in addition. Issuance and renewal are not part of the product, and responsibility for scope and renewal remains with the financial entity. As of October 2026.
Pilot and licence
- 30-day pilot free of charge, up to 500 certificates
- Annual licence from €2,490 net
- Self-install in your environment
Screenshots with synthetic demo data (example domains such as example.com / demo.internal); the product interface is in German.
Guided
Start with an assessment
If you want the inventory reviewed first: in the assessment we capture your PKI and certificate inventory read-only, assess risks and governance and deliver a prioritised action plan with a management summary. No templates are changed on the Microsoft CA and no certificates are issued or revoked.
Fixed prices after scoping from €4,900 net; the tiers are listed on the product page.
Request an assessmentExperience in regulated PKI environments
- Long-standing project experience with internal and outsourced PKI in financial services, public administration and healthcare
- PKI development for the German health telematics infrastructure (eGK CAs and OCSP responders)
- Thales nShield Certified Systems Engineer
- DigiCert partner for public certificates
- Advisory on DORA, NIS2 and ISO 27001
Frequently asked questions about the DORA certificate register
Is there an official DORA certificate?
No. DORA has no certification scheme like ISO 27001 in which accredited bodies issue a certificate. Whether a financial entity complies is assessed by the competent supervisory authorities, in Germany BaFin and the ECB for significant banks. Training records, vendor attestations or audit reports evidence individual measures, but they are not an official DORA compliance certificate.
What does DORA mean by certificates?
Digital certificates in the ICT infrastructure: TLS and server certificates, client and machine certificates, code signing and S/MIME certificates and CA certificates. The explicit obligation to keep a certificate register is in Art. 7(4) of Delegated Regulation (EU) 2024/1774. Art. 8 DORA generally requires ICT assets to be identified and documented.
Who must keep a certificate register?
Financial entities within the scope of DORA that are subject to the ICT risk management rules of Delegated Regulation (EU) 2024/1774. Entities applying the simplified ICT risk management framework are not covered by Art. 7(4). Small and medium-sized insurance intermediaries are exempt from DORA. Which obligations apply to you depends on your classification.
Which certificates and certificate-storing devices must be recorded?
At least all certificates and certificate-storing devices of the ICT assets that support critical or important functions. Recording beyond that minimum can make sense when function mappings change or the boundary is not yet clear.
Which details should the register contain?
Art. 7(4) does not list specific fields for the certificate register. Proven fields are technical details (fingerprint, issuer, validity, key type and length), source and storage location, the supported function and its classification, the responsible owner, and status, findings and change history.
Do certificates have to be renewed automatically?
Art. 7(5) requires the prompt renewal of certificates in advance of their expiration. The regulation does not prescribe a specific technique. What matters is that upcoming expiries are detected, assigned and demonstrably handled in time.
Can a certificate register be kept in Excel?
The regulation does not require specific software. The register must however be complete and kept up to date. In small environments a maintained spreadsheet may be enough. With several CAs, cloud vaults and short lifetimes it becomes hard to prove currency and completeness by hand.
How does the certificate register differ from the DORA register of information?
The register of information under Art. 28(3) DORA records contractual arrangements on the use of ICT services provided by third parties. The certificate register records certificates and certificate-storing devices of the ICT assets in the defined scope, including relevant outsourced environments. They are separate obligations; certificates at service providers can be mapped in the certificate register via source and owner.
What are the consequences of an incomplete register?
In supervisory reviews an incomplete or outdated register can be identified as a weakness in ICT risk management, leading to findings and remediation requirements. Independently, an expiring certificate that nobody notices is an operational risk for the services that depend on it.
What does Blackfort Certificate Intelligence do?
It consolidates certificates from your sources in one register, adds functions and owners, shows findings, follows them until resolved and provides an audit trail and a complete export for auditors. It works read-only in your environment and never sees private keys. Issuance and renewal stay with your CA or CLM; responsibility for scope and renewal remains with the financial entity.
Will the Microsoft CA be modified?
No. The export runs as an openly readable PowerShell script on or next to the CA. No templates are changed, no certificates are issued or revoked and no settings are modified. Private keys are never read.
Is our monitoring not sufficient?
Whether your monitoring is sufficient depends on the connected sources and the register data you maintain. Check in particular the coverage of certificate-storing devices, functions, owners and data currency. Certificate Intelligence adds the cross-source register to your existing monitoring and feeds its values into 13 monitoring tools.
Kontakt aufnehmen
Build your DORA certificate register
Try Certificate Intelligence free for 30 days in your environment, or have your inventory captured in an assessment.