Zero Trust depends on identity because the perimeter is no longer reliable in distributed critical services. When IT, OT, mobile users, and devices all share the same operational fabric, every access request needs a trustworthy identity decision. Without that, network segmentation alone cannot provide meaningful control.
Why This Matters for Security Teams
zero trust is not a network design exercise; it is an identity decision model. In IT and OT environments, devices, workloads, service accounts, APIs, and operators all interact through shared control planes, so policy only works when each request can be tied to a verifiable identity. NIST SP 800-207 Zero Trust Architecture makes this explicit by treating identity as a core input to every access decision, not a one-time gate at the perimeter.
This matters most where operational uptime and safety depend on cross-domain access. In OT, legacy systems were often built for implicit trust and static segmentation, while modern IT estates rely on cloud services, remote admins, and automation. That combination makes broad network trust especially dangerous. NHIMG research shows that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, and the Ultimate Guide to NHIs explains why service accounts and API keys often become the weakest identity layer in the stack.
In practice, many security teams encounter identity failures only after lateral movement or privileged misuse has already crossed from IT into OT, rather than through intentional design review.
How It Works in Practice
Zero Trust depends on identity because the policy engine has to answer three questions at runtime: who or what is making the request, what it is trying to access, and whether the context is acceptable right now. That is why modern implementations pair identity with device posture, workload attestation, network location, and transaction risk. The practical goal is not to trust the network less in theory, but to replace network location with evidence.
For human users, that usually means strong authentication plus contextual authorization. For machines, the identity primitive is the workload or non-human identity. A secure design gives each service, agent, or device a unique cryptographic identity and uses short-lived credentials instead of static shared secrets. The Guide to SPIFFE and SPIRE is relevant here because workload identity gives cryptographic proof of what the workload is, which is much more reliable than inferring trust from an IP address or subnet.
- Authenticate the requester with a unique identity, not a shared account.
- Authorize each request at runtime using current context, not a fixed network zone.
- Issue short-lived credentials and revoke them automatically when the task ends.
- Separate operator access, service-to-service access, and device access into distinct policy paths.
- Log identity assertions and authorization outcomes so OT and IT teams can investigate exceptions quickly.
For OT environments, this usually means wrapping legacy assets with compensating controls such as brokers, jump hosts, certificate-based gateways, and granular policy enforcement rather than assuming the asset itself can speak modern identity protocols. Current guidance suggests that real-time policy evaluation is stronger than pre-defined allowlists, but there is no universal standard for every plant, vendor stack, or safety system. These controls tend to break down when OT vendors require persistent shared credentials or when legacy controllers cannot support per-session identity checks because the control plane cannot distinguish one actor from another.
Common Variations and Edge Cases
Tighter identity controls often increase operational overhead, requiring organisations to balance security gains against uptime, maintenance windows, and vendor support constraints. That tradeoff is especially visible in OT, where a single misconfiguration can interrupt production or trigger safety concerns. In those cases, best practice is evolving toward phased enforcement: observe first, then constrain, then automate revocation once the access path is well understood.
There are also cases where identity is necessary but not sufficient. Segmentation still matters, but it should be treated as a containment layer, not the trust decision itself. Shared engineering workstations, emergency access paths, third-party support tunnels, and scripted maintenance accounts often create identity exceptions that need explicit policy and review. NHIMG’s 52 NHI Breaches Analysis shows how compromise frequently follows weak secrets hygiene and excessive privilege, which is why identity governance must include rotation, offboarding, and visibility.
Where organisations still rely on static credentials, the Zero Trust model degrades quickly because the policy engine cannot tell whether the same secret is being used by the intended workload or by an attacker who copied it. That is why identity-based control is most effective when paired with least privilege, short TTLs, and continuous verification across both IT and OT.
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 Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | Defines identity-centric access decisions as core to Zero Trust. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers identity governance for non-human workloads and secrets. |
| NIST AI RMF | Supports risk-based, context-aware decisions for dynamic systems. |
Use identity, context, and continuous verification as the basis for every access decision.
