What breaks when INSM stops at the ESP and ignores boundary systems?

Why the ESP boundary matters to the control model

When INSM stops at the ESP, the control model is no longer anchored to the place where trust decisions are actually enforced. Boundary systems often mediate authentication, access control and virtualisation, so excluding them turns a control boundary into a paper boundary. The result is not just a narrower scope, but a false sense of coverage around the systems most likely to carry cross-domain traffic.

That matters because boundary layers are where IT and OT assumptions collide. If the programme only watches the endpoint side of the boundary, it can miss the system that brokers access, translates trust, or exposes the operational segment to enterprise monitoring. In practice, the standard then describes one visibility model while the environment operates under another.

What gets lost when boundary systems are omitted

The first loss is scoping accuracy. Boundary systems hold evidence that shows who accessed what, through which control point, and under which policy. If they are outside the programme, investigation teams may have to reconstruct events from incomplete endpoint logs and infer the rest, which weakens both incident scoping and post-incident assurance.

The second loss is accountability across ownership lines. Boundary infrastructure is often managed by a different team than the protected endpoints, so excluding it leaves a gap between operational responsibility and security assurance. That gap can hide drift in access policy, virtualisation configuration, or routing decisions that materially affect the attack surface.

The third loss is detection quality. If the monitoring model assumes the ESP is the whole boundary, traffic that transits intermediary systems can evade the expected alert path. AMITRE ATT&CK Enterprise Matrix is useful here because it highlights how adversaries rely on credential access, lateral movement and trust relationships once they reach infrastructure that sits between networks.

Boundary blindness and the security decisions it breaks

Operationally, the mistake is treating a policy boundary as if it were the same thing as a technical enforcement boundary. That can break evidence collection, incident triage and audit readiness even when endpoint controls are working as designed. It also weakens the ability to prove that authentication, authorization and session mediation were consistently applied across the real path of access.

Boundary systems also carry configuration risk. A mis-set virtualisation host, proxy, jump layer or broker can create an unmonitored path that still appears compliant on paper. The broader security pattern is well captured by NIST Cybersecurity Framework 2.0, which requires organisations to understand assets, detect abnormal activity and recover using evidence that reflects the actual environment, not just the intended design.

For control design, the most relevant lesson is that boundary systems are not auxiliary. They are part of the security mechanism that mediates trust, so leaving them outside the programme changes what can be observed, proven and responded to. Where the boundary includes identity or access brokers, NIST SP 800-53 Rev 5 Security and Privacy Controls is especially relevant because it ties access control, identification and authentication, audit and configuration management together as linked control outcomes.

Practitioner Guidance

What to verify: Confirm which systems actually mediate access between IT and OT, then test whether logs, alerts and evidence collection cover those systems rather than only the ESP-facing endpoints. If the answer depends on a broker, gateway or virtualisation layer, the boundary scope is incomplete.

Decision rule: If a system can terminate sessions, enforce policy, translate trust or expose the operational segment to enterprise access, treat it as part of the control boundary. If it only mirrors traffic or sits downstream of enforcement, treat it as supporting infrastructure, not the primary boundary.

What practitioners underestimate: Audit failure often starts as a visibility failure. The environment may still function, but the team can no longer prove who touched the boundary, what policy was applied, or whether the monitored path matched the real access path.

Practitioner takeaway: Scope the control boundary to the systems that make access decisions, not to the edge the programme happens to monitor, because assurance collapses quickly when enforcement and observability live in different places.

Related resources from NHI Mgmt Group

• How can organizations manage unauthorized agents in their systems?
• What breaks when MCP governance stops at approval and ignores runtime behaviour?
• What breaks when API protection stops at the boundary?
• What breaks when remote systems are outside the organisation’s directory and management boundary?