Join our Newsletter — 33% off our NHI Course

Who is accountable for stopping lateral movement across cloud, healthcare, and OT systems?

Accountability usually sits across network security, IAM, application owners, and operational technology teams because the control is shared. Security leaders need clear ownership for internal trust boundaries, delegated access paths, and exception handling. Without that governance, flat environments persist even when everyone agrees they are risky.

Why accountability for lateral movement has to be shared

lateral movement is not owned by one team because it crosses control planes. In cloud, healthcare, and OT, the same path can run through identity, network trust, remote administration, and vendor access, so accountability must be shared across the teams that control those boundaries. MITRE ATT&CK Enterprise Matrix is useful here because it maps the attack chain from initial access to privilege escalation and movement.

The practical question is not who “owns” the whole problem, but who can actually stop movement at each hop. Network security usually owns segmentation and east-west controls, IAM owns authentication and privilege boundaries, application owners own exposed trust paths inside services, and OT teams own the constraints that keep industrial environments from behaving like flat IT networks. Cloud and hybrid estates make this sharper, because one weak trust link can bridge multiple environments.

That is why the right accountability model is boundary-based. Whoever controls the trust boundary is accountable for enforcing it, and whoever approves exceptions is accountable for the risk they create. In healthcare, that often includes shared responsibility with clinical systems and third-party vendors; in OT, it often includes engineering and operations teams that understand safety, uptime, and remote maintenance realities better than central IT.

Where the control usually breaks down

The most common failure is not missing tooling, it is ambiguous ownership. When no one owns internal segmentation, service-account scope, remote admin paths, or exception handling, environments drift toward flat trust and broad reachability. That makes one compromised credential or one abused admin channel much more valuable to an attacker.

Shared environments also fail when teams assume another group will enforce the hard part. IAM may harden authentication, but if applications still trust broad network access, movement continues. Network teams may deploy segments, but if application and OT operators keep permanent exception paths open for convenience, those paths become the attacker’s bridge. In practice, NIST Cybersecurity Framework 2.0 and NIST SP 800-207 Zero Trust Architecture both reinforce the need to define and enforce trust boundaries explicitly rather than relying on implicit internal trust.

Cloud, healthcare, and OT differ in detail, but the failure pattern is similar: excessive standing access, weak east-west visibility, and exceptions that outlive the incident that justified them. Once those exceptions are normalised, lateral movement becomes an operations issue rather than an exceptional security event.

For control design, the useful question is whether a team can prove who approved the access path, why it exists, and when it will be removed. If that cannot be answered quickly, accountability is not yet concrete enough to stop movement reliably.

How to assign accountability so movement can actually be stopped

The accountable model should follow control ownership, not organisational hierarchy. CSA Cloud Controls Matrix is helpful for cloud boundary ownership, while CISA Industrial Control Systems and NIST SP 800-82 Rev 3 are more relevant where OT segmentation and safety constraints govern what “good” looks like.

In practice, the named owner should be the team that can change the control without waiting on another group. Network teams own segmentation policy and firewall enforcement. IAM owns identity proofing, authentication strength, and privilege boundaries. Application owners own service-to-service trust and any internal admin functions. OT teams own remote engineering access, plant network zoning, and change windows. Security leadership owns the decision process for exceptions and the escalation path when those teams disagree.

Practitioner Guidance: What to prioritise: assign a single accountable owner for each internal trust boundary, then make every exception path expire by default. The first boundary to fix is usually the one that gives the broadest east-west reach, not the one that is easiest to report on.

What to verify: confirm that every high-value environment has an explicit owner for segmentation, privileged access, and exception approval, and that the owner can produce evidence of review, not just policy language. Where remote support or vendor access exists, verify that it is time-bounded, logged, and revocable without waiting for a manual project cycle.

Practitioner takeaway: lateral movement is stopped by the team that owns the boundary, but only if that ownership includes the power to remove trust, not just document it.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
MITRE ATT&CK Enterprise Matrix Maps credential access, privilege escalation, and lateral movement paths in this question.
Recommendation — Map movement paths to ATT&CK techniques and prioritize controls at the boundary they abuse.
NIST CSF 2.0 PR.AA-05 — Identity Management, Authentication and Access Control Shared accountability here depends on controlling who can cross internal trust boundaries.
Recommendation — Assign explicit owners for access paths and enforce least-privilege access at each boundary.
NIST Zero Trust (SP 800-207) Zero Trust Architecture The question centers on stopping movement by removing implicit internal trust.
Recommendation — Segment trust zones and verify every request before granting movement across environments.
CSA Cloud Controls Matrix IAM — Identity and Access Management Cloud accountability depends on ownership of identity and privilege boundaries.
Recommendation — Tie cloud access paths to named owners and require review for standing privileges.