Who is accountable when a compromised identity system disrupts public services?

Accountability sits with the teams that own identity governance, incident response, and continuity planning together, because identity compromise crosses all three domains. Public sector frameworks such as Zero Trust and the NIST Cybersecurity Framework expect recovery and resilience to be part of the control design, not an afterthought.

Why This Matters for Security Teams

When an identity system fails, the damage rarely stays inside one team’s remit. Public services depend on directory services, privileged access paths, secrets storage, incident response, and continuity plans working together. If any one of those pieces is missing, authentication may still look “up,” while access control, token issuance, or recovery workflows are broken. That is why accountability sits with the teams that govern identity, operate security response, and own service resilience, not with a single administrator after the fact. NHI failures make this sharper because machines and service accounts often hold broad access and are harder to inventory; NHIMG notes that Ultimate Guide to NHIs reports only 5.7% of organisations have full visibility into their service accounts.

For public sector operators, this is not just a control issue, it is a governance issue. Zero Trust and NIST CSF both treat recovery and resilience as design requirements, while frameworks such as NIST Cybersecurity Framework 2.0 and NIST SP 800-207 expect identity to be part of the blast-radius reduction strategy. In practice, many security teams encounter accountability gaps only after a failed token revocation or an offboarding miss has already interrupted a service, rather than through intentional resilience testing.

How It Works in Practice

Operationally, accountability should be mapped across three ownership layers. Identity governance owns who can authenticate, what secrets exist, and how quickly credentials are rotated or revoked. Incident response owns detection, containment, and proof that compromised identities are disabled across all dependent systems. Continuity planning owns service restoration, fallback authentication, and the decision points for degraded-mode operation. For NHI-heavy environments, this should include service accounts, API keys, certificates, and automated workflows, because compromise often moves faster than human approval chains. The 52 NHI Breaches Analysis shows how often service credentials become the entry point or persistence layer in real incidents.

Practitioners should translate that shared accountability into specific controls:

• Give one owner for each identity class, including humans, service accounts, and third-party integrations.
• Require short-lived secrets and documented revocation paths for every privileged identity.
• Test token invalidation, directory rollback, and restoration of emergency access during exercises.
• Align incident severity with service impact, not just data loss, so public-service downtime is escalated properly.

Where possible, the control model should be tied to Zero Standing Privilege and just-in-time access so compromise does not leave durable access behind. Guidance from CISA Zero Trust Maturity Model and the NHIMG view in Top 10 NHI Issues both point to the same operational lesson: identity response and service recovery must be rehearsed together, not sequenced as separate workstreams. These controls tend to break down when legacy directories, shared admin accounts, and manually issued secrets are embedded in public service platforms because revocation cannot keep pace with the dependency chain.

Common Variations and Edge Cases

Tighter identity control often increases operational overhead, requiring organisations to balance faster containment against service continuity and staffing limits. That tradeoff is real in government environments with legacy applications, shared administration, and emergency access requirements. Current guidance suggests treating these as exceptions with explicit approval, not as a default operating model. Where the standard answer breaks down is during cross-agency services, outsourced operations, and federated identity setups, because no single team can unilaterally disable every dependent credential or recover every workflow.

This is also where public sector teams should be careful not to confuse technical ownership with policy accountability. A cloud provider may run the directory, but the agency still owns the business risk and the continuity outcome. The same applies to AI-driven or automated services: the more autonomous the workload, the more important workload identity, JIT secrets, and runtime policy checks become. That thinking is aligned with Anthropic — first AI-orchestrated cyber espionage campaign report and with NHIMG’s analysis in Ultimate Guide to NHIs — Why NHI Security Matters Now, which emphasise that identity compromise is now a resilience problem as much as a security problem. There is no universal standard for this yet, but the strongest programmes assign ownership to a named executive, define backup authority, and test whether public services can keep running after identity failure.

Related resources from NHI Mgmt Group

• Who is accountable when an identity platform falls out of support or drifts from policy?
• Who is accountable when delegated workload identity ownership drifts over time?
• Who should be accountable for machine identity assets that have no clear owner?
• Who is accountable when identity controls fail in a GRC programme?