Manufacturers should use one identity governance model across IT and OT, but enforce it through SCADA-specific controls such as unique user identities, role scoping, monitored vendor sessions, and controlled gateways for legacy devices. The key is to keep the access model consistent while adapting enforcement to systems that cannot support modern features internally.
Why a Single Identity Model Matters Across IT and OT
Manufacturers get into trouble when IT and OT are governed as separate trust worlds. A split model invites duplicate accounts, inconsistent approvals, and unmanaged vendor access. A single governance model gives the organisation one policy for ownership, review, and revocation, while still allowing OT enforcement to respect uptime, legacy constraints, and plant-specific access paths.
The practical objective is consistency in decision-making, not identical tooling. IT can usually absorb stronger authentication, faster recertification, and more granular logging, while OT often needs compensating controls around shared consoles, jump hosts, and vendor maintenance windows. The governance layer should define who may access what, on what basis, and how that access is reviewed across both environments.
That approach aligns well with broader identity programme thinking, especially when manufacturers need a common operating model for access ownership, recertification, and exception handling. Identity Security Programme Guide is useful when the challenge is less about a single control and more about how to run identity as a cross-environment function.
How SCADA-Specific Enforcement Keeps Governance Practical
SCADA and adjacent OT platforms often cannot support modern identity features internally, so the enforcement pattern has to shift. Unique user identities, role scoping, monitored vendor sessions, and controlled gateways let the organisation preserve accountability even where the plant system itself is limited. That prevents the access model from collapsing into shared credentials or permanently open maintenance paths.
For legacy devices, controlled gateways and brokered access are often the difference between governance and wishful thinking. They create a point where session context, approval, time bounds, and logging can be applied even when the endpoint cannot enforce those rules natively. That is why manufacturers should think in terms of compensating enforcement for OT, not a downgraded policy.
OT identity guidance is especially relevant when the reader needs to translate policy into plant-friendly control design. OT and ICS Identity and Access Guide covers the access patterns that matter most in industrial environments, including vendor remote access and segmentation.
What Good Governance Looks Like in a Manufacturing Environment
Good governance starts with a clear rule: the same identity lifecycle and approval logic should apply to both IT and OT, but the control implementation may differ by system class. OT exceptions should be explicit, documented, and time bound. If an account must exist for a maintenance workflow, the organisation should know who owns it, why it exists, when it expires, and how activity will be reviewed.
Manufacturers should also treat vendor access as a governed privilege, not a connectivity convenience. Monitored sessions, restricted gateways, and role scoping are the controls that preserve traceability when external support teams need access to production assets. Where possible, map these practices to the broader access governance pattern used for the rest of the enterprise, then tighten the operational execution around plant realities. NHI Lifecycle Management Guide and Top 10 NHI Issues both reinforce the need for ownership, rotation, offboarding, and visibility where access is persistent or operationally sensitive.
The same principle applies to platform selection and governance architecture: identity should be managed as a programme, not a collection of environment-specific exceptions. Identity Security Programme Guide is a sensible reference when the governance question spans policy, operating model, and accountability.
Risk and Threat Considerations
Split IT and OT identity models commonly create overprivileged accounts, unmanaged vendor pathways, and stale access that survives long after the original need has passed. In manufacturing, that is not just an admin problem, it can become an operational exposure because the same access path that supports maintenance can also reach production systems.
Failure mechanism: Shared credentials, weak session controls, and unmanaged exceptions erode traceability, then attackers or careless insiders can reuse legitimate access paths to move into OT or disrupt plant operations.
Impact: The result can be unauthorised changes, loss of accountability, lateral movement between IT and OT, and higher blast radius if a vendor or internal account is compromised.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | OT and vendor access often depends on system-to-system authentication. |
| AC-2 — Account Management | The question centers on consistent account ownership, review, and revocation across IT and OT. | |
| AC-17 — Remote Access | Monitored vendor sessions and controlled gateways are core to OT access governance. | |
| Recommendation — Use IA-9 to authenticate non-human access paths between OT systems and supporting services. Apply AC-2 to govern account creation, review, and removal across both environments. Use AC-17 to restrict and monitor remote vendor access into OT systems. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | A unified access model across IT and OT is an access-control governance problem. |
| A.8.5 — Secure authentication | Unique identities and controlled access paths require secure authentication enforcement. | |
| Recommendation — Define access-control rules that stay consistent across IT and OT while allowing compensating controls. Require secure authentication where OT systems and gateways can support it. | ||
Practitioner Guidance
What to prioritise: Start by inventorying every identity that can touch OT, including vendor, service, and maintenance access, then classify which ones require gateway mediation, session monitoring, or time-bounded approval. The first goal is to eliminate invisible access paths, not to force every OT system into the same technical pattern.
Decision rule: If the OT asset cannot enforce modern identity controls natively, keep the governance rule unchanged but move enforcement to a control point that can log, approve, and terminate sessions reliably. If you cannot name the owner of an OT account or justify why it still exists, treat it as a governance defect, not a harmless exception.
What good looks like: One authoritative identity model, clear exceptions for plant systems, no standing vendor access without review, and a repeatable process for offboarding and recertification across both environments.
Practitioner takeaway: Manufacturers should standardise who gets access and why, then tailor how access is enforced to the realities of OT, because consistency in governance matters more than technical uniformity at the endpoint.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities in cloud environments?
- How should organisations govern identity across hybrid cloud environments?
- How should security teams govern workload identity across mixed cloud environments?
- How should security teams govern app identity modernization across multi-cloud environments?