Segmentation limits where traffic and compromise can move. Third-party identity governance limits who can enter, under what conditions, and for how long. In critical infrastructure, both matter, but identity governance is the control that prevents a trusted vendor account from becoming the initial foothold that segmentation must then contain.
Why OT Segmentation and Third-Party Identity Governance Solve Different Problems
OT network segmentation is an architecture control. It reduces blast radius by constraining which systems can talk to which others, so a compromise does not automatically become a site-wide or plant-wide incident. Third-party identity governance is an access control and lifecycle control. It reduces blast radius by constraining who can access OT-adjacent systems, what they can do, and how long that access remains valid.
That difference matters because segmentation assumes the network path is the main boundary, while identity governance assumes the account, token, certificate, or vendor session is the main boundary. In practice, they answer different questions: segmentation asks where traffic may flow, while identity governance asks whether the vendor should be trusted to enter at all.
For critical infrastructure, those controls are complementary rather than interchangeable. A well-segmented environment can still be exposed if a vendor account is overprivileged, long-lived, or poorly revoked. A tightly governed vendor identity can still face unnecessary risk if OT zones are flattened or east-west movement is unrestricted. Good practice is to treat network design and third-party access as separate layers of defense, not alternative choices.
Where Segmentation Ends and Identity Governance Begins
Segmentation is strongest when the main risk is lateral movement, propagation, or unintended reach across zones. It is especially useful for isolating safety systems, engineering workstations, historians, and remote-access jump points. The control is about topology and trust boundaries, not about the business relationship with the vendor.
Third-party identity governance is strongest when the main risk is external access, delegated trust, standing privilege, or weak offboarding. It covers sponsorship, least privilege, approval, time limits, revalidation, and removal. A vendor may need access for support, maintenance, telemetry, or incident response, but governance should ensure that access is narrow, monitored, and expiring by default. NHIMG’s Third-Party, B2B and Contractor Access Guide is the more direct navigation path for that control set.
That is why identity governance often prevents the initial foothold. If a contractor account is compromised, segmentation may reduce what follows next, but it does not solve the original trust decision. The more precise the access governance, the less often segmentation has to act as the last line of defense.
What Changes When the Vendor Is the Entry Point
In OT and industrial environments, compromise frequently starts with legitimate access rather than direct network exploitation. A vendor login, remote support channel, shared credential, or stale access grant can bypass the assumptions embedded in segmentation. Once authenticated, the attacker is no longer fighting the perimeter in the abstract, they are operating through a trusted identity path.
This is why identity governance must address lifecycle as aggressively as network architecture addresses reachability. If a supplier account persists beyond the work it was created for, or if approvals are not revalidated after role changes, the access path outlives the business need. NHIMG’s IAM and IGA Basics helps frame that distinction between authentication, authorization, and governance, while Top 10 NHI Issues highlights the lifecycle and privilege problems that also appear in machine and service access.
Segmentation still matters in this scenario because it can stop a trusted account from reaching every zone. But the decisive control is whether the account should exist, remain active, or be capable of reaching the OT environment at all.
Risk and Threat Considerations
Third-party identities create a trust path that attackers often prefer because it is easier to abuse legitimate access than to break hardened OT boundaries outright. If access is overly broad, long-lived, or weakly revoked, a vendor compromise can become a direct route into critical systems even when the network is segmented.
Failure mechanism: The failure usually begins with excess privilege, stale vendor access, weak sponsorship, or poor offboarding. Segmentation may slow movement, but it cannot compensate for a trusted identity that already has the right to enter the relevant zone.
Impact: The result can be unauthorized access to engineering, monitoring, or operational systems, followed by disruption, data exposure, or a broader incident that crosses IT and OT boundaries. The control failure is not that segmentation is useless, it is that segmentation is being asked to contain an access decision it was never designed to make.
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 | AC-20 — Use of External Systems | Covers limiting third-party access paths into OT-connected environments. |
| AC-6 — Least Privilege | Applies directly to third-party identities that should not hold broad OT reach. | |
| IA-5 — Authenticator Management | Relevant where vendor accounts rely on tokens, keys, certificates, or other authenticators. | |
| Recommendation — Restrict vendor sessions to approved external-use scenarios and time windows. Limit each third-party identity to the minimum OT access needed for the approved task. Rotate and revoke third-party authenticators promptly when access changes or ends. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Directly addresses supplier access governance and assurance for third parties. |
| A.5.18 — Access rights | Supports lifecycle control over who may enter OT-adjacent systems and for how long. | |
| Recommendation — Define supplier access conditions, monitoring, and revocation requirements contractually. Review and remove third-party access rights on a scheduled and event-driven basis. | ||
Practitioner Guidance
What to prioritise: Treat vendor onboarding, approval, review, and offboarding as the first control point for OT exposure. If the third party should not have standing access, remove it before tuning network paths. Use segmentation to limit reach after access is granted, not to justify granting access too broadly.
What to verify: Confirm that every third-party identity has a named sponsor, a defined business purpose, an expiry or review date, and a clear path for rapid revocation. Verify that remote support is time-bound and that emergency access is exceptional, documented, and removed afterward. Where OT networks are segmented, check that each allowed vendor path is tied to a specific business function rather than a generic remote-access rule.
Practitioner takeaway: Segmentation is the containment layer, but third-party identity governance is the trust decision layer. If the identity control is weak, you are relying on network architecture to compensate for a permission problem.
Related resources from NHI Mgmt Group
- What is the difference between managing employee identities and managing third-party identities?
- What is the difference between network segmentation and third-party risk assessment in OT security?
- What is the difference between governing cloud identities and governing private legacy systems?
- What is the difference between third-party risk management and NHI governance?