Reconnaissance Denial in OT: Using the Host Identity Protocol to Deny Asset Discovery

Many OT security programs assume that reconnaissance will succeed. An attacker gains a foothold through an IT workstation, vendor laptop, jump host, or flat engineering network. From there, they scan for reachable systems, identify PLCs, HMIs, historians, remote access services, file shares, or building automation devices, and then decide where to pivot.
This session asks a different architectural question: what changes when unauthorized systems cannot discover the OT assets in the first place?
The session introduces the Host Identity Protocol, defined in IETF RFC 7401, as a practical foundation for identity-based OT communication. HIP separates a host’s identity from its network location and uses a cryptographic exchange to mutually authenticate peers before a communication session is established. Paired with default-deny admission control, where a host declines to engage any identity that is not already authorized, this produces an important defensive property: protected systems can remain unreachable to hosts that cannot present an authorized identity. Because field controllers do not speak HIP natively, this protection is delivered by HIP-capable endpoints and gateways that authenticate on the device’s behalf.
We will walk through how HIP works at the protocol level, including the base exchange, host identity model, locator/identity separation, and the puzzle mechanism used to shift denial-of-service cost back to the initiator. We will be precise about where the reconnaissance-denial property actually comes from: cryptographic identity plus admission policy, not the bare protocol. We will also discuss the data-plane implications and compare HIP-based communication with approaches OT teams already use, including VPNs, IPsec and WireGuard tunnels, firewall ACLs, and Purdue-model segmentation.
The session places HIP in the context of familiar OT security frameworks, including NIST SP 800-207 zero trust principles and the IEC 62443 conduit model. The goal is not to position HIP as a replacement for visibility, monitoring, EDR, vulnerability management, or incident response. It does not stop an attacker who has already compromised an authorized identity or endpoint, where the protected assets become reachable as designed. It changes where network monitoring happens, since encrypted conduits move inspection to the endpoint or gateway rather than a passive midpoint. And it introduces real design considerations around identity lifecycle, key management, endpoint trust, physical access, and broadcast-dependent industrial protocols.
Attendees will leave with a practical framework for evaluating where HIP-based reconnaissance denial belongs in an OT security architecture, especially for legacy assets, remote sites, mobile systems, vendor access, and environments where patching or network redesign is difficult.