Look for evidence that access is issued only on demand, expires automatically, and can be tied to a named user, task, and session record. If audits still require manual reconstruction, the control is not working at the governance level. Strong OT access management produces verifiable traces, not just fewer help desk tickets.
Why This Matters for Security Teams
OT access controls are only real if they leave a clean evidentiary trail: who requested access, who approved it, what scope was granted, when it expired, and what activity occurred during the session. If those answers require spreadsheet archaeology or manual log stitching, the control exists on paper but not in operations. Current guidance from the OWASP Non-Human Identity Top 10 reinforces that identity controls must be observable, not just configured.
This matters more in OT because systems are often fragile, segmented, and hard to patch, so operators tend to tolerate standing access longer than they should. That creates a governance gap: access may be “restricted” in policy while still being broadly reusable in practice. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is exactly why audit evidence has to prove constraint, not assume it. In practice, many security teams discover access-control failure only after a contractor, integrator, or service account has already touched systems outside the approved window.
How It Works in Practice
Working OT access control is verified by testing the full request-to-revocation path, not by checking whether a PAM tool is installed. A valid control should issue access on demand, bind it to a named user and task, limit it to a specific asset or segment, and expire it automatically at the end of the session. That is the practical meaning of JIT access in OT, and it is closely aligned with the Ultimate Guide to NHIs — Standards and the session-centric expectations reflected in PCI DSS v4.0.
Teams should look for these operational signals:
- Access is approved against a ticket, work order, or maintenance window.
- Credentials or vault tokens are short-lived and revoked automatically.
- Session recording captures commands, targets, and timestamps.
- Logs tie activity back to a named identity, not a shared account.
- Reviewers can reconstruct the session without manual interpretation.
For OT environments, strong evidence also includes device-level traceability and exception handling for emergency access. If a control depends on after-the-fact narrative from operators, it is not yet measurable. The 52 NHI Breaches Analysis shows how often identity misuse becomes visible only after compromise, which is why verifiable telemetry matters. These controls tend to break down in flat legacy networks with shared engineering accounts and unmanaged vendor pathways because there is no trustworthy session boundary to enforce.
Common Variations and Edge Cases
Tighter OT access control often increases operational overhead, so organisations have to balance plant uptime against review depth and session friction. That tradeoff is real, especially where maintenance teams need rapid intervention and equipment vendors expect remote support. Best practice is evolving here, and there is no universal standard for every plant architecture.
Some environments rely on jump servers, others on brokered VPN access, and some on vendor-managed bastions. The control can still be effective if the same evidence exists: named identity, task-bound approval, automatic expiry, and immutable session records. If those are missing, shared accounts and permanent vendor tunnels usually hide the true access model. The Ultimate Guide to NHIs — Key Challenges and Risks is a useful reference when assessing why these exceptions become persistent weaknesses, and the OWASP guidance remains useful for checking whether identity, secret handling, and session control are actually enforced.
In mixed IT and OT estates, the clearest test is simple: can the organisation prove that access ended when the work ended, without reconstructing the story by hand? If not, the control is still compensating for process, not governing it.
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 surface, NIST CSF 2.0 set the technical controls, and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers access issuance, rotation, and revocation for non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Addresses access control enforcement and least-privilege verification. |
| PCI DSS v4.0 | 7.2.5 | Requires access to be limited, approved, and periodically reviewed. |
Use approval, expiry, and review evidence to prove privileged access is truly constrained.
Related resources from NHI Mgmt Group
- How do organisations know whether data disclosure controls are actually working?
- How can organisations tell whether SOX access governance is actually working?
- How do organisations know if patient access identity controls are working?
- How do organisations know whether passwordless access is actually improving security?