Who is accountable when a website serves expired or misconfigured SSL/TLS certificates?

Accountability usually sits with the teams responsible for identity, infrastructure, and application operations, because certificates are part of service availability and trust. Security governance should define clear ownership for issuance, renewal, chain validation, and deployment checks. If no owner exists, certificate failures become recurring operational incidents instead of controlled exceptions.

Why This Matters for Security Teams

Expired or misconfigured SSL/tls certificate are not just a website nuisance. They are an identity and trust failure that can interrupt availability, break browser trust, and expose weak ownership across infrastructure, application, and security operations. Current guidance increasingly treats certificates as machine identity assets, not one-time setup artifacts. The operational problem is that renewal, chain validation, and deployment checks often fall between teams, which makes failure predictable when no single owner is accountable.

That gap is visible in broader machine identity management research: NHI Management Group reports that 45% of organisations identify certificate expiry as the leading cause of outages, while only 38% have automated certificate lifecycle management in place in its Critical Gaps in Machine Identity Management report. That pattern aligns with the control emphasis in NIST SP 800-53 Rev 5 Security and Privacy Controls, which expects accountable control ownership, not ad hoc remediation.

In practice, many security teams discover certificate ownership only after user-facing outages, failed health checks, or blocked integrations have already occurred, rather than through intentional lifecycle governance.

How It Works in Practice

Accountability for certificate failures should be assigned along the full lifecycle, not only at issuance. The practical owner is usually a cross-functional service owner or platform team, with clear responsibilities split across identity management, infrastructure, and application operations. Security sets policy, but operations executes the controls that keep certificates valid, trusted, and deployed on time.

The control model should cover four tasks: issuance, renewal, chain validation, and deployment verification. Issuance determines who may request a certificate and from which authority. Renewal covers automation, notification, and fallback procedures before expiry. Chain validation confirms that the certificate path is trusted by clients and intermediaries. Deployment verification checks that the new certificate actually reached the load balancer, proxy, application server, or API endpoint in production.

• Assign a named owner for each service certificate and intermediate CA dependency.
• Automate discovery so expiring certificates are visible before users are impacted.
• Use short validity periods only when renewal is automated and monitored.
• Log failed deployments separately from renewal success, since those are different failure modes.

For machine identity context, NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful because it frames certificates as part of a broader lifecycle that includes ownership, visibility, and revocation. The OWASP Non-Human Identity Top 10 also reinforces that unmanaged machine identity sprawl creates recurring exposure when lifecycle controls are inconsistent.

This guidance tends to break down in multi-team environments where certificate renewal is automated but deployment rights remain fragmented across platform, DevOps, and application teams.

Common Variations and Edge Cases

Tighter certificate governance often increases coordination overhead, requiring organisations to balance reliability against deployment speed. That tradeoff becomes especially visible in complex environments where TLS termination happens in load balancers, reverse proxies, service meshes, CDNs, and application runtimes at the same time.

There is no universal standard for ownership in every environment, but current guidance suggests the accountable party should be the team that can actually prevent expiry and validate the deployed state. In a cloud-native stack, that may be the platform engineering team. In a legacy application estate, it may be infrastructure operations. In outsourced hosting models, the contract must still define who owns monitoring, replacement, and emergency rollback.

Edge cases also matter. Wildcard certificates can hide asset sprawl and make expiry harder to detect. Intermediate CA chain issues can cause outages even when the leaf certificate is valid. Misconfigured automation can renew certificates successfully but fail to reload them into the live service. For those reasons, certificate governance should not stop at “renewed successfully.” It must include evidence that the endpoint presents the correct chain and key material after deployment.

Where ownership is unclear, organisations should use the guidance in NHI Lifecycle Management Guide to define service-level accountability, then map those responsibilities to control objectives in NIST SP 800-53 Rev 5 Security and Privacy Controls.

Related resources from NHI Mgmt Group

• Why do expired or poorly managed SSL/TLS certificates create outsized risk for website security?
• What breaks when SSL/TLS is missing or misconfigured on a public website?
• Who is accountable for security and compliance when an LLM proxy is misconfigured?
• When should a website use SSL certificates instead of relying on plain HTTP?