Who is accountable when a privileged OT service account is exposed through SSRF?

Why This Matters for Security Teams

When a privileged OT service account is exposed through SSRF, the issue is not just a web flaw. It becomes an identity and control-plane problem that can cross application, OT operations, IAM, and network boundaries in minutes. Service accounts often carry broad standing access, weak lifecycle ownership, and inconsistent rotation, which makes them a prime escalation path after an SSRF entry point. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which helps explain why accountability is so often unclear.

This is where the practical risk concentrates: SSRF can turn an otherwise contained application weakness into access to internal services, secrets stores, or OT management interfaces. The relevant baseline guidance from the OWASP Non-Human Identity Top 10 is that non-human identities must be treated as first-class security assets, not as incidental technical credentials. NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now frames the same issue in operational terms: if no team owns the account end to end, nobody is positioned to revoke it fast enough after exposure.

In practice, many security teams discover the ownership gap only after the account has already been used for lateral movement or unauthorised OT access, rather than through intentional lifecycle governance.

How It Works in Practice

Accountability should be assigned by control domain, but the response must be coordinated. Application owners are usually accountable for the SSRF weakness and any outbound request path that made internal reachability possible. IAM or identity engineering is accountable for the service account lifecycle, including secret issuance, rotation, scope, and revocation. OT operations is accountable for the business impact of the account’s privileges on industrial systems, while network security owns segmentation and egress controls that should have limited what the application could reach.

That split matters because the failure is usually not a single mistake. It is a chain: an application can reach internal metadata or management endpoints, the exposed secret is harvested, and the privileged account is then reused outside its intended context. NIST control language in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it separates access control, auditability, and configuration management into different responsibilities instead of pretending one team can solve all of it alone.

Operationally, good response practice includes:

• revoking or rotating the exposed credential immediately, not at the next scheduled cycle
• reducing privilege scope to the minimum required for the OT function
• blocking the SSRF path and reviewing outbound allowlists, proxy rules, and internal route exposure
• confirming whether the account can reach safety systems, historians, or remote management planes
• assigning a named owner for the service account lifecycle so future changes do not drift across teams

For deeper identity context, NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is a useful reference because it ties visibility, rotation, and offboarding to real operational exposure. These controls tend to break down in OT environments where legacy protocols, shared service accounts, and vendor-managed systems make privilege inventory incomplete and revocation risky.

Common Variations and Edge Cases

Tighter control over OT service accounts often increases operational overhead, requiring organisations to balance resilience against change-management constraints. That tradeoff is real in plants where uptime, vendor access, and maintenance windows limit how aggressively credentials can be rotated or segmented. Current guidance suggests that shared accounts should still be minimized, but there is no universal standard for every OT stack, especially where legacy controllers or vendor support contracts depend on fixed credentials.

The edge cases matter. If the exposed account is used by a vendor integration, accountability may extend to procurement, third-party risk, and contract owners, not just internal technical teams. If the SSRF lands in an internet-facing web app but the privileged account controls OT systems, then the business owner of the OT function should still be part of the incident decision loop because the impact is operational, not only cyber. Where the account is embedded in code, responsibility shifts further upstream to software engineering and release management because the exposure may be repeated in every deployment.

NHIMG’s 52 NHI Breaches Analysis shows that identity-driven incidents frequently cascade across teams because ownership is fragmented. The lesson is simple: accountability should be explicit before exposure happens. If a privileged OT service account can be reached through SSRF, the most common failure is not the exploit itself, but the absence of a single owner for its lifecycle, privilege, and revocation path.

Related resources from NHI Mgmt Group

• How should teams respond when a service account token is exposed?
• Who is accountable when cloud data is exposed through a shared account or snapshot?
• Who is accountable when a service account used for API access is over-privileged?
• Who is accountable when a managed service account root key is exposed?