Two Regulations, One Problem
Financial services organizations face a unique convergence in 2026: two major regulations — the EU's Digital Operational Resilience Act (DORA) and PCI DSS 4.0 — are both fully enforced, and both have direct implications for how you manage TLS certificates.
DORA, which went live in January 2025, focuses on ICT risk management and operational resilience across the EU financial sector. PCI DSS 4.0, fully enforced since March 2025, raised the bar for payment card data protection with stricter TLS and cryptographic requirements.
Most financial institutions have addressed the headline requirements of both regulations. But certificate lifecycle management — the intersection of cryptographic hygiene, operational resilience, and continuous monitoring — remains a gap that auditors are increasingly catching.
DORA: Certificate Requirements You're Probably Missing
Article 6: ICT Risk Management Framework
DORA requires financial entities to establish a comprehensive ICT risk management framework. Certificates are explicitly within scope because they are ICT assets that, when mismanaged, cause service disruptions.
What auditors look for:
- A complete inventory of all TLS/SSL certificates across the organization
- Risk classification of certificates based on the services they protect
- Documented procedures for certificate renewal, revocation, and emergency replacement
- Evidence that certificate management is integrated into the overall ICT risk framework — not handled ad hoc
Common finding: Organizations have a certificate inventory, but it's a spreadsheet that's updated quarterly. DORA expects a continuously accurate inventory, which requires automated discovery.
Article 9: Protection and Prevention
Article 9 requires financial entities to implement mechanisms to detect anomalous activities and protect ICT systems. For certificates, this means:
dora_article_9_certificate_requirements: detection: - Monitor for certificates nearing expiry (30, 14, 7 day alerts) - Detect unauthorized certificate issuance - Identify certificates using deprecated algorithms (SHA-1, RSA-1024) - Alert on certificate revocations that affect production services prevention: - Enforce minimum key sizes (RSA 2048+, ECDSA P-256+) - Require Certificate Transparency logging - Block certificates from unauthorized CAs - Prevent deployment of self-signed certificates in production
Common finding: Organizations monitor certificate expiry but don't detect unauthorized issuance. An attacker or misconfigured system that issues a rogue certificate for your domain goes unnoticed.
Article 11: Response and Recovery
DORA requires documented and tested response plans for ICT incidents, including:
- Certificate compromise response: Can you revoke and replace a compromised certificate within hours, not days?
- Mass revocation scenarios: If your CA is compromised, can you reissue all affected certificates?
- Business continuity: If your primary CA becomes unavailable, do you have a backup CA and the automation to switch?
Common finding: Incident response plans mention "revoke compromised certificates" as a bullet point, but there's no tested procedure. The actual process involves SSH-ing into servers, manually generating CSRs, and uploading certificates one at a time.
Article 15: ICT Third-Party Risk
If you use external Certificate Authorities (and you do), DORA treats them as critical ICT third-party service providers. This means:
- Due diligence on CA security practices and compliance certifications
- Contractual requirements for incident notification (what if your CA is breached?)
- Exit strategies — can you migrate to a different CA without operational disruption?
- Regular assessment of CA risk and performance
Common finding: Organizations rely on a single CA with no documented exit strategy. When that CA has an outage or policy change, they discover their entire certificate infrastructure is vendor-locked.
PCI DSS 4.0: The TLS Requirements That Tightened
Requirement 4: Protect Cardholder Data in Transit
PCI DSS 4.0 Requirement 4 is where certificate management gets specific:
| PCI DSS 4.0 Sub-Requirement | Certificate Impact |
|---|---|
| 4.2.1: Strong cryptography for transmission | TLS 1.2+ required; certificates must use approved algorithms |
| 4.2.1.1: Certificate inventory | Maintain inventory of all trusted certificates and keys |
| 4.2.1.2: Certificate validity verification | Verify certificates are valid and not expired before trust |
| 4.2.2: PAN secured with strong cryptography | Certificates protecting PAN data must meet stricter standards |
What changed from PCI DSS 3.2.1: The certificate inventory requirement (4.2.1.1) is new. Previously, PCI DSS required strong cryptography but didn't explicitly require knowing where your certificates are. Now you need a documented, maintained inventory.
Requirement 6: Develop and Maintain Secure Systems
Requirement 6 affects certificate management through:
- 6.2.4: Software development practices must include certificate and key management for custom applications
- 6.3.1: Security vulnerabilities are identified and managed — expired or weak certificates are vulnerabilities
- 6.4.1: Public-facing web applications must be protected — which includes properly configured TLS certificates
Requirement 10: Log and Monitor All Access
Requirement 10 now requires logging of certificate-related events:
pci_dss_4_logging_requirements: certificate_events_to_log: - Certificate installation and replacement - Certificate revocation - Certificate expiry warnings - Changes to certificate configurations - Access to private keys - CA trust store modifications log_retention: "12 months minimum, 3 months immediately accessible" review_frequency: "Daily automated review, quarterly manual audit"
Common finding: Organizations log certificate installations in change management tickets but don't log certificate-related events in their SIEM. An expired certificate that causes an outage has no trail showing when the expiry was first detected and why it wasn't renewed.
Requirement 12: Security Policies
Requirement 12.3.1 now requires a targeted risk analysis for any requirement where the organization has flexibility in how it meets the standard. For certificates:
- Document your risk analysis for certificate lifetime choices
- Justify why you're using 398-day certificates (or why you've moved to shorter lifetimes)
- Document your risk acceptance for any self-signed certificates in the cardholder data environment
- Include certificate management in your annual security policy review
The Compliance Mapping: CLM Capabilities to Regulation Requirements
| Capability | DORA Article | PCI DSS 4.0 Req | Why It Matters |
|---|---|---|---|
| Automated discovery | Art. 6 (inventory) | 4.2.1.1 (cert inventory) | You can't manage what you can't find |
| Continuous monitoring | Art. 9 (detection) | 10.4.1 (audit logs) | Detect issues before they become incidents |
| Automated renewal | Art. 11 (recovery) | 4.2.1 (valid certs) | Eliminate expiry-related outages |
| Multi-CA support | Art. 15 (third-party risk) | 4.2.1 (strong crypto) | No vendor lock-in, CA exit strategy |
| Policy enforcement | Art. 9 (prevention) | 6.3.1 (vuln management) | Block weak algorithms and unauthorized CAs |
| Audit logging | Art. 6 (risk framework) | 10.2.1 (log events) | Complete trail for every certificate action |
| Incident response | Art. 11 (response) | 12.10.1 (IR plan) | Rapid revocation and replacement |
| Compliance reporting | Art. 6 (governance) | 12.3.1 (risk analysis) | Evidence for auditors on demand |
Common Audit Findings in Financial Services
Based on industry patterns, these are the certificate-related findings that auditors most frequently flag:
Finding 1: Incomplete Certificate Inventory
What auditors see: An Excel spreadsheet with 200 certificates, but network scanning reveals 800+ certificates in the environment.
Why it fails: Both DORA (Art. 6) and PCI DSS 4.0 (4.2.1.1) require a complete inventory. Manual inventory methods consistently miss:
- Certificates on development and staging servers
- Certificates embedded in applications and containers
- Certificates on network equipment (load balancers, firewalls)
- Cloud-provider managed certificates (ACM, Azure Key Vault)
Finding 2: No Expiry Monitoring for Non-Production Certificates
What auditors see: Production certificates are monitored, but staging and development certificates expire without detection — causing delayed deployments and testing failures.
Why it matters under DORA: Article 9 requires detection of anomalous activities across all ICT systems, not just production. An expired certificate in staging that blocks a critical hotfix deployment is an operational resilience failure.
Finding 3: Manual Renewal Processes
What auditors see: Certificate renewal involves creating a Jira ticket, manually generating a CSR, emailing it to the CA, downloading the certificate, and SSH-ing into the server to install it. Average time from request to deployment: 3-5 business days.
Why it fails under DORA: Article 11 requires the ability to recover from ICT incidents rapidly. A 3-5 day certificate replacement process is incompatible with a 4-hour incident response target.
Why it fails under PCI DSS: Requirement 4.2.1.2 requires verification that certificates are valid before trust. Manual processes can't guarantee this check happens consistently.
Finding 4: Single CA Dependency
What auditors see: All certificates issued by a single CA, with no documented alternative or migration plan.
Why it fails under DORA: Article 15 requires ICT third-party risk management, including exit strategies. A CA outage that prevents certificate issuance or renewal is a third-party concentration risk.
Finding 5: No Certificate Event Logging
What auditors see: Certificate installations are tracked in change management, but there's no centralized log of certificate lifecycle events (issuance, renewal, revocation, expiry).
Why it fails under PCI DSS: Requirement 10 explicitly requires logging and monitoring of security-relevant events. Certificate lifecycle events are security-relevant.
Financial Services Certificate Compliance Checklist
Use this checklist to assess your current compliance posture:
certificate_compliance_checklist: inventory_and_discovery: - [ ] Automated discovery of all certificates (network, cloud, container) - [ ] Certificate inventory updated in real-time, not periodically - [ ] Risk classification of certificates by service criticality - [ ] Coverage of non-production environments monitoring_and_alerting: - [ ] Expiry alerts at 90, 60, 30, 14, and 7 days - [ ] Unauthorized issuance detection (CT log monitoring) - [ ] Weak algorithm detection (SHA-1, small key sizes) - [ ] Revocation status monitoring automation: - [ ] Automated certificate renewal for all certificate types - [ ] Automated deployment to servers, load balancers, CDNs - [ ] Renewal success verification and rollback capability - [ ] Sub-4-hour emergency certificate replacement governance: - [ ] Multi-CA support with documented exit strategy - [ ] Certificate policy enforcement (algorithms, lifetimes, CAs) - [ ] RBAC for certificate management operations - [ ] Segregation of duties for certificate approval audit_and_reporting: - [ ] Centralized logging of all certificate lifecycle events - [ ] SIEM integration for certificate event correlation - [ ] Compliance dashboard for DORA and PCI DSS mapping - [ ] Quarterly compliance report generation incident_response: - [ ] Documented certificate compromise response procedure - [ ] Tested mass revocation and reissuance capability - [ ] Backup CA configured and tested - [ ] Communication plan for certificate-related incidents
The 47-Day Multiplier
The upcoming 47-day certificate lifetime requirement (SC-081, March 2029) makes every gap in this checklist worse:
- Incomplete inventory: More renewals mean more chances for an unknown certificate to expire and cause an outage
- Manual processes: Renewing every 30 days instead of every 12 months increases labor costs 12x
- Single CA dependency: More frequent CA interactions means more exposure to CA outages
- Missing logs: 8x more certificate lifecycle events to track per year
Financial institutions that delay certificate automation will face a compliance cliff when 47-day lifetimes arrive. The regulations don't care whether your certificate expired because you forgot or because you couldn't keep up with the renewal cadence.
How TigerTrust Addresses Financial Services Compliance
TigerTrust is purpose-built for the regulatory requirements that financial institutions face:
- Continuous discovery: Agent-based and agentless scanning finds every certificate across your infrastructure, satisfying DORA Article 6 and PCI DSS 4.2.1.1
- Policy enforcement: Define certificate policies that map directly to your regulatory requirements — algorithm minimums, lifetime limits, approved CAs, and CT logging requirements
- Automated lifecycle management: End-to-end certificate renewal and deployment with sub-hour emergency replacement capability, meeting DORA Article 11 response requirements
- Multi-CA architecture: Support for multiple public and private CAs with automated failover, addressing DORA Article 15 third-party risk requirements
- Audit-ready reporting: Pre-built compliance reports mapped to DORA articles and PCI DSS requirements, with full certificate lifecycle audit logs for Requirement 10 compliance
- SIEM integration: Stream certificate events to your existing SIEM for correlation with other security events
Financial regulators are paying attention to certificate management. Make sure your CLM platform gives you the answers they're looking for. See how TigerTrust maps to your compliance requirements at tigertrust.io.