How can organisations tell whether their IIoT trust model is working?

Why This Matters for Security Teams

An IIoT trust model is only useful if it can answer, in real operations, which devices are genuine, which systems are allowed to command them, and whether trust changes when the device’s state changes. That is the practical test for assurance. NIST’s NIST Cybersecurity Framework 2.0 emphasises continuous governance and measurable outcomes, which is exactly what IIoT environments need because assets are distributed, long-lived, and often difficult to patch or inspect.

The failure mode is usually not a lack of policy. It is a lack of verifiable evidence that policy is working across device identity, remote access, and revocation. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, and that visibility gap is a strong warning sign for IIoT trust as well. The same pattern appears in real incidents such as the Schneider Electric credentials breach, where trust in operational access can become a path to broader compromise.

In practice, many security teams discover a broken trust model only after a vendor session, maintenance login, or compromised credential has already altered a live industrial process, rather than through intentional assurance testing.

How It Works in Practice

A working IIoT trust model should be observable at three layers: identity, authorisation, and revocation. First, each device, gateway, and remote operator path needs a verifiable identity rather than a shared password or opaque network position. Second, access must be context-aware enough to distinguish routine telemetry from privileged control actions. Third, trust has to be withdrawn quickly when a device is decommissioned, moved, tampered with, or no longer compliant.

That is why mature programmes combine device inventory with certificate lifecycle management, conditional access, and event-driven revocation. In NHI terms, the trust anchor is the identity of the machine or service, not the surrounding subnet. NHI Mgmt Group’s Ultimate Guide to NHIs highlights why this matters: 97% of NHIs carry excessive privileges, and 71% are not rotated within recommended time frames. In an IIoT setting, those two weaknesses often combine into persistent access that outlives the device’s intended trust boundary.

• Verify that every critical asset has a unique machine identity and no shared administrative credential.
• Map who can issue commands, change firmware, or open maintenance channels, then compare that to actual access logs.
• Test revocation by disabling a certificate, account, or token and confirming that access stops immediately.
• Check whether trust is re-evaluated after maintenance mode, location changes, ownership transfer, or firmware drift.

Current guidance suggests using Zero Trust principles here, but there is no universal standard for IIoT trust attestation yet. The practical measure is whether the control plane can prove, on demand, that only approved identities can execute privileged actions. These controls tend to break down when legacy controllers depend on static credentials and cannot support runtime validation without interrupting production.

Common Variations and Edge Cases

Tighter trust enforcement often increases operational overhead, requiring organisations to balance stronger assurance against uptime, vendor access, and plant-floor continuity. That tradeoff is unavoidable in IIoT, especially where patch windows are rare and remote support is part of normal operations.

One common variation is the mixed fleet: newer devices support certificates, short-lived tokens, or policy checks, while older controllers only support static credentials or coarse network segmentation. In those environments, best practice is evolving toward compensating controls rather than pretending the whole estate can be normalised at once. Another edge case is third-party maintenance. A device may be trusted, but the support path into it may not be. That is why remote access should be validated separately from device identity.

The underlying question is not whether the organisation has a trust framework on paper. It is whether trust can be proven continuously across device state changes, supply-chain dependencies, and emergency access. If revocation cannot be demonstrated quickly, the trust model is only partial. NHI Mgmt Group’s research on the Schneider Electric credentials breach is a reminder that access paths often outlast assumptions about who should still be trusted.

Related resources from NHI Mgmt Group

• How can organisations tell whether their AI security model is actually working?
• How can organisations tell whether a unified identity model is working?
• How do organisations know whether secure access management is actually working in manufacturing?
• How do organisations know whether certificate governance is actually working?