DORA Article 7: key management and the certificate register

Article 7 of Commission Delegated Regulation (EU) 2024/1774, the DORA regulatory technical standards (RTS) on ICT risk management, requires two things: cryptographic key management across the whole key lifecycle, and a register of certificates for ICT assets that support critical or important functions. The register is a compliance artefact, but it is also the operational list you will need the day you migrate key exchange and signatures to post-quantum algorithms. This guide sets out the fields to record, the read-only commands that discover certificates, and how the register connects to the wider cryptographic inventory required by DORA Article 6. It is information, not legal advice.

What Article 7 literally asks for

The RTS text is short and specific. Financial entities must have policies and procedures for cryptographic key management covering generation, renewal, storage, backup, archival, retrieval, transmission, retirement, revocation and destruction of keys. Separately, they must keep a register of the certificates and certificate-storing devices for ICT assets supporting critical or important functions, and manage certificate renewal so that expiry does not interrupt those functions. The authoritative text is on EUR-Lex: Commission Delegated Regulation (EU) 2024/1774.

Three consequences follow directly from that wording, before any interpretation.

• Scope is function-driven, not infrastructure-driven. The trigger is support for a critical or important function, so the register follows your own classification of functions, not a network boundary.
• Devices are in scope, not only files. Certificate-storing devices means hardware security modules (HSMs), smartcards, trusted platform modules and appliance keystores, so inventory the holder as well as the credential.
• Renewal is an availability control. An expired certificate on a payment gateway is an ICT incident, which is why Article 7 pairs the register with renewal management.

What Article 7 does not say is equally important. It does not name post-quantum algorithms, it does not set a migration date, and it does not require a specific file format. Article 6 is the article that requires provisions for updating or changing cryptographic technology as cryptanalysis develops, which is the crypto-agility hook. Our reading, labelled as interpretation: a register that records the algorithm and key size of every certificate turns Article 6 from a written intention into something you can execute, because you can list in minutes every asset still relying on RSA or ECDSA signatures.

Fields to record for each certificate

Keep the register machine-readable (one row per certificate, exported from your sources rather than typed by hand). The columns below cover the Article 7 duties and carry the data a post-quantum migration needs.

Two fields repay the effort of adding them even though no text demands them: the deployment surface (which load balancer, ingress, broker or mutual TLS peer presents the certificate) and a post-quantum readiness flag per asset, set from measurement rather than intention.

Key lifecycle: what to write down for keys, not certificates

A certificate is a public object with an expiry date. The key lifecycle duty covers material you must never export, so the register records facts about the key rather than the key itself. For each key, or for each class of keys where you have thousands, record: generation method and entropy source, approved algorithm and parameters, storage boundary (software, HSM, cloud keystore with its protection level), who holds administrative and recovery rights, backup and escrow arrangements, archival duration for keys that must still verify old signatures, retirement criteria, destruction procedure and evidence, and the compromise playbook with its decision owner.

Separate three categories, because their migration paths differ. Key agreement keys protect confidentiality in transit, and recorded traffic can be decrypted later if the key agreement is broken, which is why harvest now, decrypt later makes key exchange the first thing to migrate. Signature keys authenticate, and a signature forged in 2035 cannot retroactively break a session from today, so certificates can migrate after key exchange. Long-lived signing keys are the exception: firmware and software signing keys that must remain trustworthy for a decade deserve attention now, and NIST standardized stateful hash-based signatures for exactly that case in SP 800-208 (LMS and XMSS, see SP 800-208).

Discovery: how to populate the register

No single source holds every certificate. Combine at least four, and treat each as partial.

1. Ask the certification authorities

Internal CA databases and your public CA accounts list everything they issued. Public issuance is also visible in Certificate Transparency logs, which is the fastest way to find certificates issued for your domains by teams you did not know existed.

2. Scan what is actually listening

Read-only checks against a host show the certificate in production, which is sometimes not the certificate you think you deployed. Test in a non-production environment first, and confirm your scanning authorisation.

# Inspect the presented chain and the key algorithm
openssl s_client -connect host.example.com:443 -servername host.example.com -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -serial -fingerprint -sha256 -text \
  | grep -E "Subject:|Issuer:|Not (Before|After)|Public Key Algorithm|Public-Key|Signature Algorithm|DNS:"

# Which key agreement group was negotiated (OpenSSL 3.5 or later for the ML-KEM groups)
openssl s_client -connect host.example.com:443 -servername host.example.com \
  -groups X25519MLKEM768:X25519 </dev/null 2>/dev/null | grep -E "Negotiated|Protocol"

3. Sweep the filesystems and keystores

# Certificates and keys on disk, with expiry, for one host
find /etc /opt /srv -type f \( -name "*.pem" -o -name "*.crt" -o -name "*.cer" \) 2>/dev/null \
  | while read -r f; do
      printf '%s\t' "$f"
      openssl x509 -in "$f" -noout -subject -enddate 2>/dev/null || echo "not a certificate"
    done

# Java keystore contents (read-only listing)
keytool -list -v -keystore /path/to/keystore.jks | grep -E "Alias name|Valid from|Signature algorithm"

4. Query the platforms that manage certificates for you

Kubernetes secrets and cert-manager resources, cloud certificate managers, cloud key vaults and HSM partitions, service meshes issuing short-lived mutual TLS certificates, API gateways, message brokers, database TLS configuration, VPN concentrators and code-signing services. Short-lived mesh certificates are usually better recorded as a policy row (issuer, algorithm, lifetime, rotation mechanism) than as millions of individual rows; say so explicitly in the register so a reviewer sees the choice was deliberate.

# cert-manager inventory across a cluster (read-only)
kubectl get certificates -A \
  -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,ISSUER:.spec.issuerRef.name,SECRET:.spec.secretName,RENEWAL:.status.renewalTime,EXPIRY:.status.notAfter

Automation matters more than completeness on day one. The US federal instructions under OMB M-26-15 call for an automated, continuously updated cryptographic inventory, and that principle travels well: a register refreshed by a scheduled job survives, a spreadsheet refreshed by goodwill does not.

Tying the register to the cryptographic inventory

The certificate register is one layer of a larger inventory. Keep them linked rather than merged: the certificate register answers which credentials exist and when they expire, while the cryptographic inventory answers which algorithms your software and protocols actually use, including key agreement, symmetric encryption at rest, hashing and libraries. A cryptography bill of materials (CBOM) is one practical way to express the software layer, as described in what a CBOM is; that is our interpretation of good practice, not a DORA requirement.

The same artefacts serve several frameworks, which is the argument for building them once.

On dates, keep the distinctions precise. PCI DSS v4.0.1 requirement 12.3.3 has been mandatory since 31 March 2025. The EU Coordinated Implementation Roadmap v1.1, published on 23 June 2025, is coordinated guidance for Member States and not a regulation binding companies: it places cryptographic inventories and national roadmaps by the end of 2026, high-risk use cases migrated by the end of 2030 and medium-risk by the end of 2035. NIST IR 8547 remains an initial public draft; it proposes deprecating quantum-vulnerable algorithms at 112-bit security after 2030 and disallowing quantum-vulnerable public-key algorithms after 2035, and it should be cited as a draft. The full set of dated milestones is on our regulations hub.

Common pitfalls

• Recording only public web certificates. Mutual TLS between internal services, database clients, message brokers, code signing and device identity usually outnumber the public ones.
• Omitting the private key location. Without it you cannot answer the only question that matters during a compromise: where is the key and who can reach it.
• Treating expiry as the only lifecycle event. Revocation that has never been exercised is an untested control.
• Letting scope drift silently. When a function is reclassified as critical or important, its certificates enter scope. Re-run the scope rule on a schedule and keep the dated output.
• Confusing certificate migration with key exchange migration. Hybrid key agreement protects traffic recorded today and is already deployable; post-quantum certificates depend on CA and client support. Start with the key exchange, as explained in crypto-agility.
• Carrying obsolete pre-standard algorithms. The Kyber draft TLS groups are superseded by the standardized ML-KEM groups; the hybrid group to look for is X25519MLKEM768.

Next step: measure before you document

A register built from intentions ages badly, so fill the algorithm and readiness columns from measurement. For every externally reachable asset supporting a critical or important function, scan your domain with PQC Status to read the negotiated TLS versions, the key agreement groups offered, the cipher suites and the certificate chain, then paste those values straight into the register. The scan describes the externally visible TLS configuration only: it is not a certification and not a compliance attestation, and our methodology page sets out exactly what it does and does not prove. Once the external surface is recorded, repeat the discovery commands above on internal listeners, assign an owner to every row, and schedule the export so the register refreshes itself.