Who is accountable when a government digital service fails because certificate lifecycle management was not maintained?

Why This Matters for Security Teams

When a government digital service fails because certificate lifecycle management was not maintained, the issue is rarely just “an expired cert.” It usually reflects a broader failure in ownership, inventory, renewal, monitoring, and escalation across identity, platform, and governance functions. Certificate expiry is one of the most common machine identity failure modes, and it becomes a public-service outage when no team can prove who was responsible for keeping the estate current. NHIMG research on machine identity management shows that certificate expiry is the leading cause of outages for 45% of organisations, which is a strong reminder that operational accountability must be explicit, not assumed.

The control problem is bigger than technology. Certificates are non-human identities, so they need clear ownership, lifecycle policy, and audit evidence just like privileged human accounts. Guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both points toward defined governance, continuous monitoring, and recovery planning, but they do not remove the need for named internal owners. In practice, many security teams encounter certificate outages only after a citizen-facing service has already failed, rather than through intentional lifecycle testing.

How It Works in Practice

Accountability should follow the lifecycle, not just the incident. The team that owns the certificate estate is responsible for inventory, renewal scheduling, revocation, and exception handling. Security defines policy and minimum standards. Platform or service owners ensure the certificates are deployed, monitored, and replaced without breaking availability. Governance or risk functions verify that the process is auditable and that escalation paths exist when automation fails. This is why NHIMG’s NHI Lifecycle Management Guide and Regulatory and Audit Perspectives are useful references for separating operational execution from oversight.

In mature environments, the certificate lifecycle is treated as a managed control set:

• Maintain a complete inventory of certificates, services, owners, and renewal dates.
• Automate renewal and replacement where possible, with short validity periods where the environment can support it.
• Use alerting well before expiry, plus a tested escalation path for missed renewals.
• Document who approves exceptions, who executes changes, and who signs off after remediation.
• Retain logs and evidence so audit can confirm the control worked, not just that a ticket existed.

The NIST SP 800-53 Rev. 5 Security and Privacy Controls is relevant here because it reinforces control ownership, monitoring, and configuration management as operational disciplines, not paperwork. Where teams rely on manual tracking, spreadsheets, or ad hoc reminders, renewal misses become predictable. These controls tend to break down in large, distributed government estates because certificate ownership is split across agencies, platforms, and contractors, while no single system maintains authoritative lifecycle visibility.

Common Variations and Edge Cases

Tighter certificate governance often increases operational overhead, requiring organisations to balance service availability against approval friction and emergency-change risk. That tradeoff becomes sharper in government environments with legacy systems, third-party managed services, or shared infrastructure, where one expired certificate can affect many downstream services. Current guidance suggests the accountability chain should still be explicit even when execution is outsourced, because outsourcing the task does not outsource the responsibility.

There is no universal standard for this yet, but best practice is evolving toward shared accountability with clear RACI-style ownership. Service owners remain accountable for the service outcome, security owns the lifecycle policy, and infrastructure or IAM teams own operational implementation. Where certificate automation is partial, organisations should define manual fallback procedures, testing cadence, and break-glass authority before expiry events occur. NHIMG’s Top 10 NHI Issues and Guide to the Secret Sprawl Challenge are both relevant because poor certificate ownership often sits inside a broader secrets and identity sprawl problem.

For public-sector services, the hardest edge case is when the service is operationally outsourced but the data and trust boundary remain government-owned. In that situation, contracts should name the accountable internal function, require evidence of renewal controls, and mandate outage notification timelines. Otherwise, certificate failure becomes everyone’s problem and no one’s responsibility.

Related resources from NHI Mgmt Group

• How should organizations prioritize environments for NHI management?
• What is the difference between attack surface management and NHI governance?
• What problem does ownership attribution solve for service accounts and API keys?
• When do service accounts become a higher risk than ordinary user accounts?