Protecting the network assumes security can be enforced at a shared boundary, while protecting the asset places control closer to each system or workload. In operational technology, that matters because devices may be distributed, wireless, or difficult to manage centrally. Asset-focused protection is more adaptable when the same control must follow the system wherever it operates.
Why the distinction matters in OT security architecture
operational technology environments often mix legacy devices, fragile uptime constraints, vendor-managed systems, and connectivity that changes over time. That makes the boundary-first model useful for macro segmentation, but it can fail when a control must stay with the asset itself. The practical question is not which model is “better” in the abstract, but where the trust decision can actually be enforced.
Protecting the network is most effective when traffic paths, zones, and conduits are the main enforcement points. Protecting the asset is stronger when the system must defend itself regardless of where it is attached, especially for portable devices, remote sites, wireless connections, or systems that move between operational contexts. In OT, those two approaches often complement each other rather than replace one another.
That difference also changes how you think about control failure. A network-centric design can leave a device exposed if it crosses a trusted boundary, while an asset-centric design can still provide protection if the surrounding network is flat, temporary, or only partially managed. For that reason, many OT programs use both: boundaries for containment, asset controls for resilience and portability.
Where network-centric protection breaks down, and where asset-centric control holds up
Network protection assumes you can reliably see and shape paths between users, controllers, sensors, historians, and remote access points. That works best when topology is stable and enforcement devices can inspect the relevant traffic. It becomes less dependable when assets roam, when wireless or vendor connectivity is introduced, or when the same equipment is deployed across multiple plants and segments.
Asset protection moves the control surface to the endpoint or workload, so the security decision travels with the system. In OT terms, that can mean local hardening, device identity, application allowlisting, secure configuration, or tightly scoped remote access on the asset itself. The advantage is consistency. The trade-off is that each asset becomes part of the enforcement fabric, so configuration drift and lifecycle management matter more.
For practitioners, the important distinction is whether the control must survive changes in network attachment. If the answer is yes, asset-centric protection is usually the more durable model. If the answer is containment of lateral movement across a stable industrial network, boundary controls still provide strong value, especially when they reduce blast radius between zones.
How to combine both models without creating blind spots
The strongest OT design usually uses the network to limit exposure and the asset to enforce local trust. That means zoning and segmentation should define where communication is allowed, while the asset should decide what it will trust, execute, or expose once communication exists. This is especially important when a device is remote-managed, vendor-serviced, or intermittently connected.
A useful way to test the model is to ask what happens if the boundary is bypassed, misrouted, or temporarily unavailable. If the system still needs to remain safe, then network protection alone is insufficient. If the system only needs to prevent cross-zone spread, then network controls may be the primary layer, with asset controls acting as a second line of defense.
OT teams often make the mistake of treating segmentation as a substitute for device-level control. Segmentation is valuable, but it does not remove the need to harden the asset, manage its configuration, and restrict what it can accept from local or remote sources. Asset-centric controls become more important as environments become more distributed and as operational uptime limits the ability to rely on centralized intervention.
Risk and Threat Considerations
Boundary-based designs can create a false sense of containment if the network changes faster than the security policy does. In OT, that can expose remote devices, contractor paths, wireless links, and temporarily connected assets to unintended trust assumptions.
Failure mechanism: A threat actor or malfunctioning integration reaches the asset through a path the boundary model did not anticipate, or the asset loses protection when it moves outside the assumed zone.
Impact: The result can be unauthorized control, unsafe process manipulation, wider lateral spread, or loss of operational continuity, especially where the same asset must function across multiple sites or connectivity states.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | OT segmentation and conduits are boundary protections for industrial traffic. |
| CM-2 — Baseline Configuration | Asset-centric protection depends on hardened, consistent device baselines. | |
| AC-4 — Information Flow Enforcement | The question contrasts boundary enforcement with local asset-enforced trust decisions. | |
| Recommendation — Enforce SC-7 to segment OT zones and limit traffic to approved conduits. Apply CM-2 to maintain secure baselines on OT assets wherever they operate. Use AC-4 to control allowed flows between OT systems and zones. | ||
Practitioner Guidance
What to prioritise: Start by identifying which OT functions depend on stable network zoning and which require protection to follow the asset. If a control must remain effective during roaming, vendor access, or temporary connectivity, treat asset-level enforcement as mandatory rather than optional.
What to verify: Validate that each critical system has a clear local trust model, a defined configuration baseline, and an explicit recovery path if network enforcement is degraded. The control should still be understandable after a topology change, not just while the network diagram is current.
Practitioner takeaway: In OT, network security reduces exposure, but asset security preserves trust when the environment is dynamic, distributed, or only partly governable from the boundary.
Related resources from NHI Mgmt Group
- What is the difference between privilege reduction and secret rotation?
- What is the difference between a rules-based secret scanner and a hybrid scanner?
- What is the difference between code scanning and runtime identity monitoring?
- What is the difference between zero trust for users and zero trust for NHIs?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
