Legacy industrial systems complicate zero trust because they were built for stable connectivity, not continuous policy enforcement or per-session identity checks. Many OT assets cannot support modern federation or fine-grained authorization directly, so teams rely on brokers and gateways. That shifts trust to the access layer, which must be governed as carefully as the asset itself.
Why Legacy Industrial Systems Break Zero Trust Expectations
zero trust assumes every access request can be authenticated, authorised, and re-evaluated with current context. Legacy industrial systems were rarely designed that way. Many OT controllers, historians, and embedded devices still expect persistent network reachability, shared service accounts, or protocol-specific trust at the segment boundary. That makes continuous verification difficult and shifts the security burden to intermediaries, not the asset itself.
This matters because industrial environments often mix high-consequence physical processes with identities that were never built for modern federation. Guidance from NIST SP 800-207 Zero Trust Architecture is clear that trust should not be implied by location, yet many plants still rely on network placement as the control plane. NHI Management Group’s Ultimate Guide to NHIs notes that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, which is especially relevant when legacy systems cannot natively enforce it.
In practice, teams discover the gap only after a broker, jump host, or shared account becomes the easiest path into production.
How Zero Trust Is Usually Implemented Around OT Constraints
Because most legacy industrial systems cannot speak modern identity protocols directly, zero trust is usually implemented around them. That means placing policy enforcement at gateways, access brokers, remote maintenance platforms, or segmentation points, then issuing tightly scoped credentials to operators, vendors, or machine-to-machine workflows. The asset may remain unchanged, but the access path must become identity-aware, monitored, and short-lived.
Current guidance suggests treating the broker as a high-value control surface. If it authenticates users, injects credentials, or proxies sessions, it must be governed like privileged infrastructure. The OWASP Non-Human Identity Top 10 is useful here because many industrial access paths depend on service accounts, certificates, or API keys that are effectively non-human identities. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs also reinforces that lifecycle controls matter as much as authentication.
Operationally, practitioners usually combine:
- Network segmentation to reduce lateral movement across zones.
- Just-in-time access so vendor and admin credentials expire after use.
- Secrets rotation for brokered credentials, certificates, and API keys.
- Session recording and command logging for maintenance access.
- Policy-as-code at the gateway so access can be denied when context changes.
This model works best when the gateway can enforce per-session identity and the downstream system only accepts traffic through that path. These controls tend to break down when engineers bypass brokers for emergency maintenance because the legacy device cannot survive the latency, authentication flow, or protocol translation overhead.
Where the Model Gets Fragile in Real Plants
Tighter access controls often increase operational overhead, requiring organisations to balance zero trust discipline against uptime, vendor support, and safety constraints. That tradeoff is unavoidable in industrial environments because many assets are long-lived, undocumented, or certified in ways that make firmware changes risky.
One common edge case is vendor-managed equipment that still depends on static credentials or pre-shared keys. Another is air-gapped or intermittently connected OT segments, where continuous policy evaluation may be impossible. In those cases, current guidance suggests compensating controls rather than pretending full zero trust has been achieved. The Top 10 NHI Issues is a practical reminder that excessive privilege, poor rotation, and weak visibility are recurring failure modes, not edge cases. For broader governance context, the NIST Cybersecurity Framework 2.0 helps map these controls to governance, protect, detect, and respond functions.
Teams should also be realistic about visibility. NHI Management Group reports that only 5.7% of organisations have full visibility into their service accounts, which is a serious problem when those accounts are the only practical way to reach legacy systems. In environments with fragile protocols, safety-critical timing, or third-party remote support, zero trust becomes a staged architecture rather than a switch that can be flipped.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Legacy OT access needs least-privilege enforcement at gateways. |
| NIST Zero Trust (SP 800-207) | PR.AC | Zero trust requires continuous verification, which OT often cannot do natively. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Industrial brokers depend on service accounts and secrets that become NHI risks. |
Inventory broker credentials and rotate them as first-class non-human identities.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
