Who is accountable when machine-to-machine authentication is not continuously verified in critical infrastructure?

Accountability should sit with the teams that own the workload, the identity control plane, and the operational system, because machine identity failures can cross application, infrastructure, and security boundaries. Governance should define ownership, review cadence, and escalation paths. Without clear accountability, gaps in authentication, auditing, and lifecycle management persist.

Why This Matters for Security Teams

In critical infrastructure, authentication that is only checked at login time is not enough when workloads can call APIs, chain tools, or change state after the initial handshake. Accountability becomes blurred across platform, operations, and security teams unless ownership is defined for the workload identity, the control plane, and the runtime policy. NIST control guidance expects access decisions to be managed continuously, not assumed once.

That matters because machine identities are not a niche problem. NHI Mgmt Group research shows that 82% of identity breaches involved compromised non-human identities such as service accounts and API keys, and many environments still depend on long-lived credentials. When continuous verification is missing, teams tend to discover it after an outage, a privilege escalation, or an unexplained configuration change. In practice, many security teams encounter broken accountability only after the machine has already moved faster than the review process.

For infrastructure operators, this is not just an IAM question. It is also a resilience and regulatory concern under frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls and EU NIS2 Directive, both of which assume clear control ownership and auditable enforcement.

How It Works in Practice

Accountability should be assigned to the party that can actually change the risk: the workload owner for business intent, the platform team for identity issuance and runtime enforcement, and the security function for policy oversight and exception review. That division is necessary because continuous verification is a technical control, but it only works when someone is responsible for operating it. For machine-to-machine traffic, best practice is evolving toward workload identity, short-lived credentials, and runtime policy checks rather than static trust based on network location or an old token.

Practically, this means each service or agent should prove what it is before it acts. Standards such as SPIFFE and SPIRE, or OIDC-based workload tokens, provide cryptographic workload identity instead of reusable secrets. Requests should then be authorized at runtime using policy-as-code, with tools like OPA or Cedar enforcing context-aware decisions based on destination, action, time, and current risk. For autonomous or semi-autonomous systems, that policy should also support just-in-time issuance and automatic revocation after task completion. This is the control pattern that helps prevent a service account from becoming an unbounded standing privilege.

• Define a named owner for every machine identity, not just every application.
• Separate credential issuance, policy evaluation, and logging so no single team can bypass verification silently.
• Use short TTLs, rotation, and revocation triggers for secrets and tokens.
• Require audit trails that show who approved the access model and who receives escalation alerts.

NHIMG analysis of the 2026 Infrastructure Identity Survey found that 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, which is a strong signal that accountability gaps often start with weak lifecycle ownership. These controls tend to break down when legacy service accounts are shared across teams because no single operator can verify or revoke them cleanly.

Common Variations and Edge Cases

Tighter continuous verification often increases operational overhead, requiring organisations to balance stronger assurance against latency, integration complexity, and on-call burden. That tradeoff becomes sharper in critical infrastructure where uptime, deterministic control loops, and vendor-managed systems can limit how aggressively identities are challenged.

There is no universal standard for every environment yet. In highly regulated plants, some systems still depend on allowlisted machine identities with compensating controls because synchronous verification may interfere with safety windows. In cloud-native environments, the guidance is clearer: continuous validation, short-lived credentials, and per-request authorization should be treated as the baseline. The real question is not whether verification exists, but whether it is enforced at the moment of action rather than at initial authentication.

Edge cases also include third-party integrators, emergency access, and offline control systems. Those cases need explicit exception handling, time-bound approval, and post-event review, not permanent bypasses. The strongest governance models use CISA cyber threat advisories and incident lessons to refine policy, while research such as the Schneider Electric credentials breach shows how quickly credential misuse becomes an operational issue when ownership is unclear.

Related resources from NHI Mgmt Group

• Who should be accountable for coordinating response when a critical infrastructure attack affects public services?
• Who is accountable for securing privileged access and cryptography in critical infrastructure programmes?
• Who is accountable when machine identity controls fail in critical infrastructure?
• Who is accountable when critical infrastructure organisations rely on weak authentication controls?