By NHI Mgmt Group Editorial TeamBased on eMudhra: “NIS2 and DORA Compliance: How PKI and CLM Help European Enterprises Stay Compliant” (May 28, 2026)

TL;DR: NIS2 and DORA now push certificate lifecycle management from infrastructure hygiene into regulatory control, because encrypted communications, mutual authentication, audit trails, and third-party trust all depend on governed PKI according to eMudhra. The compliance gap is not the presence of certificates but the inability to inventory, renew, and retire them continuously across hybrid and vendor ecosystems.


At a glance

What this is: This article argues that NIS2 and DORA push PKI from infrastructure hygiene into regulated governance, with certificate lifecycle control at the centre of compliance.

Why it matters: IAM, PAM, and NHI teams should treat certificates as governed identities, because expiry, orphaning, and third-party drift can become regulatory and operational failures.


Context

NIS2 and DORA make certificate lifecycle governance a compliance problem, not just an infrastructure task. In practice, the question is whether an organisation can inventory, issue, renew, and retire certificates quickly enough to prove control across critical services, financial systems, and external dependencies.

The article frames PKI as the control plane for encrypted communication, mutual TLS, code signing, and audit evidence. That matters for identity governance because certificates are machine credentials with a finite lifecycle, and unmanaged lifecycle drift becomes a trust and resilience issue rather than a simple operations issue.


Key questions

Q: What breaks when certificate lifecycle governance is missing under NIS2 and DORA?

A: Expiry, orphaning, and untracked renewals turn certificates from trusted machine credentials into operational liabilities. Systems can lose encrypted connectivity, mTLS authentication can fail, and auditors may be unable to prove that secure channels were continuously governed. Under NIS2 and DORA, that becomes a resilience and compliance problem, not just a technical outage.

Q: Why do certificates create regulatory risk in financial and critical infrastructure environments?

A: Because they are the identity and trust substrate for encrypted communications, code signing, and authenticated system-to-system access. If the lifecycle is poorly governed, the organisation cannot reliably prove continuity of trust, which is exactly what NIS2 and DORA expect for resilience, integrity, and oversight.

Q: How do teams know whether certificate governance is actually working?

A: Look for three signals: clean issuance records, consistent revocation propagation, and matching status across PKI, endpoint security, and operations. If a valid certificate is blocked or a revoked certificate remains trusted somewhere, governance is fragmented and the control model is failing.

Q: What role should third-party certificates play in supplier risk reviews?

A: They should be treated as part of the supplier’s operational trust posture, not as a narrow technical detail. If a vendor certificate can break a regulated service or interrupt authenticated traffic, its lifecycle belongs in supplier due diligence, renewal coordination, and resilience oversight.


Technical breakdown

Why certificate lifecycle now sits inside regulatory control

Certificate lifecycle management covers discovery, issuance, renewal, suspension, and retirement. In regulated environments, those steps are no longer operational conveniences, because expired or orphaned certificates can break service availability, weaken identity assurance, and undermine audit evidence. NIS2 and DORA both depend on the ability to prove that cryptographic trust is maintained continuously, not only at issuance time. That shifts PKI from a background service to a governed identity control with clear ownership, inventory, and monitoring expectations.

Practical implication: Practitioners should treat certificate lifecycle state as a governed control surface, not a passive infrastructure detail.

How mTLS and code signing depend on governed certificate trust

Mutual TLS uses certificates on both sides of a connection to verify identity before data exchange, while code signing binds software releases to an authenticated signer. Both mechanisms depend on trust chains that are only as reliable as certificate issuance, revocation, and renewal discipline. If certificate governance is weak, the control still exists technically, but the organisation cannot trust who is presenting or approving the identity. In NIS2 and DORA terms, that weakens both secure communications and software integrity assurance.

Practical implication: Practitioners should map certificate governance to the services and pipelines that rely on authenticated trust decisions.

Why third-party certificate drift becomes a compliance issue

DORA explicitly raises third-party ICT risk, and NIS2 extends concern into critical supply chains. That means a vendor’s certificate expiry, weak renewal process, or untracked CA trust chain can become the customer’s resilience problem. The technical failure is rarely the certificate alone. It is the absence of shared visibility into inventory, expiry windows, and responsibility for renewal across organisational boundaries. Once certificates cross vendor ecosystems, lifecycle governance becomes a dependency-management problem as much as a crypto problem.

Practical implication: Practitioners should include third-party certificate inventory and expiry ownership in supplier risk governance.


Threat narrative

Attacker objective: The objective is to exploit unmanaged certificate trust so that access, communications, or software integrity can fail without timely detection.

  1. Entry begins when a certificate is issued, discovered, or inherited without an authoritative inventory entry, leaving it outside normal governance.
  2. Escalation follows when that certificate is reused across encrypted channels, mTLS sessions, or signed releases without clear renewal or retirement oversight.
  3. Impact occurs when an expired, orphaned, or vendor-managed certificate disrupts service availability, weakens authentication, or creates audit failure during regulatory review.
  • Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
  • CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Certificate lifecycle governance is now a regulatory control, not an operational preference. NIS2 and DORA both force enterprises to prove that certificate trust is continuously managed across issuance, renewal, and retirement. That changes PKI from a back-office function into part of the regulated identity control set. The practitioner conclusion is straightforward: if certificates cannot be governed, the underlying compliance story is incomplete.

Identity hygiene does not scale when certificate estates span hybrid and third-party environments. The article’s core problem is not whether certificates exist, but whether anyone can reliably inventory them before expiry or orphaning creates exposure. This is the same failure pattern identity teams see in unmanaged non-human identity estates: visibility collapses before remediation can begin. The implication is that certificate governance must be treated as lifecycle control, not periodic clean-up.

Trust is distributed, so certificate accountability must be too. DORA’s third-party ICT focus means organisations cannot stop at internal PKI boundaries. If vendors, cloud providers, and service partners are part of the trust chain, certificate ownership has to extend into supplier oversight and evidence collection. The practitioner conclusion is that regulated resilience now depends on cross-boundary certificate accountability.

PKI has become the evidence layer for regulated machine identity. Certificates do more than authenticate systems. They also generate the audit trail regulators need to validate non-repudiation, integrity, and secure communication. That means certificate governance now sits at the intersection of machine identity, audit readiness, and resilience. Practitioners should treat PKI telemetry as compliance evidence, not just operational metadata.

From our research library:

What this signals

Certificate lifecycle governance is becoming the practical boundary between policy and proof. For IAM and NHI programmes, the important shift is that certificates are not just credentials, they are evidence-bearing identities that regulators expect to remain valid, traceable, and owned. Teams that cannot reconcile issuance, expiry, and retirement across environments will struggle to demonstrate control when it matters.

Third-party trust chains now deserve the same scrutiny as internal privileged access. When supplier certificates sit inside regulated service paths, the governance question is no longer only whether the partner is trusted, but whether their certificates are monitored, renewed, and revoked on a predictable lifecycle. That is where compliance and resilience now intersect.

Certificate lifecycle governance turns zero-trust assumptions into operational checks. Trust cannot remain abstract when mTLS, code signing, and audit trails depend on certificate state. Practitioners should expect certificate inventory, ownership, and expiry monitoring to become part of the core identity programme rather than a specialist PKI side function.


For practitioners

  • Map every certificate estate Build a complete inventory across servers, APIs, load balancers, containers, IoT devices, code repositories, and third-party services. Include issuer, expiry, owner, renewal path, and business dependency so that regulated services cannot hide unmanaged certificates.
  • Assign renewal ownership Attach a named owner and renewal deadline to each certificate, including vendor-managed certificates that support critical flows. Where ownership is ambiguous, route the certificate into a governance exception queue until accountability is explicit.
  • Separate internal and supplier trust domains Document which certificates are controlled internally and which depend on external parties, then require supplier evidence for renewal, revocation, and CA chain integrity. Treat shared trust chains as part of third-party risk governance.
  • Log certificate events as audit evidence Preserve issuance, renewal, revocation, and expiry events in a form that can support regulatory review and incident investigation. The goal is to prove continuity of trust, not just operational uptime.

Key takeaways

  • NIS2 and DORA move certificate management into the regulated identity control plane, where lifecycle discipline matters as much as cryptographic strength.
  • The article’s central risk is not the existence of certificates but the inability to continuously inventory, renew, and retire them across internal and supplier environments.
  • Practitioners should treat certificate ownership, expiry visibility, and third-party trust chains as part of identity governance and resilience oversight.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-01 — Improper OffboardingCertificate retirement and revocation are central to the lifecycle governance problem discussed here.
NHI-07 — Long-Lived SecretsLong-lived certificates and slow renewal cycles create the governance gap this article describes.
Recommendation — Retire certificates on schedule and revoke identities that no longer have a valid business need. Reduce certificate lifetime exposure and enforce renewal before expiry becomes operational risk.
NIST SP 800-53 Rev 5IA-5 — Authenticator ManagementCertificate issuance, renewal, and revocation are authenticator management concerns in regulated environments.
Recommendation — Apply authenticator management controls to track, rotate, and revoke certificate-based authenticators.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsCertificate-based authentication governs access permissions for systems and services.
Recommendation — Align certificate issuance and renewal with authorised access scopes and ownership records.
ISO/IEC 27001:2022A.5.15 — Access controlThe article links certificate governance to regulated access control and secure communication.
Recommendation — Document and enforce certificate-based access control rules across regulated systems.

Key terms

  • Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
  • Mutual Tls: Mutual TLS is a transport security method where both client and server present certificates and authenticate each other. In implant frameworks, it helps prevent impersonation, supports encrypted sessions, and ties each deployment to its own trust material rather than shared credentials.
  • Public Key Infrastructure: Public Key Infrastructure is the trust system that issues, manages, and revokes digital certificates used to prove identity. In practice it binds keys to entities and policies, making authentication, encryption, and non-repudiation possible across users, devices, and services.
  • Third-Party ICT Risk Oversight: Third-party ICT risk oversight is the practice of governing technology risk introduced by external service providers. It includes due diligence, contractual security requirements, monitoring, testing, and exit planning. The goal is to ensure outsourced services do not undermine resilience, accountability, or recovery during disruption.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity governance programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on July 12, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org