OT Remote Access 2026: The Third-Party Identity Gap

NERC CIP-003-9 took effect on 1 April 2026; NIS2 Article 21(2)(i) now mandates access control and MFA for remote maintenance sessions; IEC 62443-2-4 requires identity-bound just-in-time access. Three frameworks converge on one point — the named person behind a vendor technician's remote session must be verifiable. None of them tells you how to verify a technician from outside your jurisdiction.

For the first time, a North American utility, a European industrial operator, and a globally certified system integrator face nearly-identical demands for OT remote access: document every external session, bind it to a named individual, disable access on demand, and prove all of this to an auditor. The regulatory texts come from three different corners — NERC CIP-003-9, NIS2 Article 21, and IEC 62443-2-4:2023 — but the compliance outcome is the same. The one question none of them answers is how you verify the identity of a service engineer employed by a Japanese OEM, based in India, supporting a Polish substation.

Three OT Remote Access Frameworks Converging in 2026

Three OT remote access regimes reach operational force in 2026. Each was written independently; each lands on the same substantive requirement.

NERC CIP-003-9 (United States) took effect on 1 April 2026, introducing for the first time a standard that governs vendor electronic remote access to low-impact Bulk Electric System (BES) Cyber Systems — the SCADA and ICS environments at generation, substation, and control centres (NERC CIP-003-9 compliance — Tenable, 2026). Requirement R1 Part 1.2.6 mandates that Responsible Entities document and implement vendor-remote-access security controls covering three concrete capabilities: identify where vendor remote access exists, maintain a method to disable that access, and implement methods to detect malicious communications inside vendor sessions (Midwest Reliability Organization — Planning for CIP-003-9). Violations carry civil penalties up to $1 million per violation per day.

NIS2 Article 21(2)(i) (European Union) has been binding since enforcement began in October 2024, with 2026 marking the transition from formal transposition to operational audit. The Article requires — not recommends — access control policies and multi-factor authentication for remote maintenance sessions (Schneider Electric — NIS2 for OT). NIS2 Article 21(2)(d) layers supply-chain security on top: essential and important entities must document vendor and integrator identity as part of their TPRM register. If a vendor-related incident reaches the OT environment, the 24-hour notification clock to the national competent authority starts from awareness, not from containment.

IEC 62443-2-4:2023 (global) is the service-provider tier of the ISA/IEC 62443 family. It specifies security capabilities that service providers — the OEMs, integrators, and managed-service operators who remote into operator environments — must be able to offer. The 2023 edition is explicit that remote sessions should be temporary, just-in-time, tied to individual identities, and non-shared; credentials must not be reused across technicians; every session must be logged, auditable, and supervisable in real time (GE Vernova — IEC 62443-2-4 service provider certification; IEC 62443-2-4:2023 — IEC Webstore).

Taken together: a North American utility governed by CIP-003-9, a European industrial operator governed by NIS2 Article 21, and the IEC 62443-certified service provider reaching into both must all answer the same question from the auditor's first interview: who is on this session, and can you prove it?

What NERC CIP-003-9 Requires (US)

CIP-003-9 formalises what North American utility security teams have been doing in practice for most of the last decade. Before 1 April 2026, "vendor electronic remote access" was a known risk but not a specifically regulated control category for low-impact BES Cyber Systems. Now it is.

The requirement targets three gaps that repeated vendor-compromise incidents have exposed: the utility did not know the vendor session existed (no inventory), could not kill the session quickly (no kill-switch), or did not detect that the session had been hijacked (no anomaly detection). Part 1.2.6 demands each of those three capabilities as a documented control — with evidence that will be walked by a Regional Entity auditor.

What CIP-003-9 does not prescribe is how a vendor's remote technician is identified. The standard assumes the utility has a working vendor-identity control and uses that control consistently. In practice, most North American utilities have relied on a combination of vendor-provided credentials, utility-issued jump-host accounts, and case-by-case approvals. That works for an Illinois cooperative's contract with a domestic OEM. It breaks down when the OEM's support engineer is a subcontracted specialist based in a country that does not intersect the utility's existing identity-proofing infrastructure.

What NIS2 Article 21(2)(i) Requires (EU)

NIS2 Article 21 sets out ten cybersecurity risk-management measures that essential and important entities must have in place (NIS2 — European Commission digital strategy). Article 21(2)(i) is the access-control clause, and it is explicit about three elements: policies on access control, policies on asset management, and multi-factor authentication or continuous authentication solutions where appropriate. The ENISA Technical Implementation Guidance treats remote maintenance sessions as a primary use case for the MFA requirement.

Two adjacent sub-articles extend the reach. Article 21(2)(d) requires supply-chain security measures — meaning that the same essential or important entity must assess the cybersecurity posture of its OT vendors and integrators, and document the assessment (a supplier-identity register is now a standard audit artefact). Article 21(2)(j) adds multi-factor authentication and, where appropriate, secured voice-video-text communications — tightening the loop further for vendor engineering calls that accompany a live remote session.

In 2026, the operational bar moves from "we have a policy" to "we have evidence the policy was followed". Member State authorities are auditing, not transposing. A utility or operator that can show a written vendor-access policy but cannot produce per-session evidence of identity-bound authentication will see an audit finding. The specific kinds of evidence auditors are asking for read much like the NERC CIP-003-9 evidence bundle — session logs tied to named individuals, with a documented identity-proofing step behind those names.

What IEC 62443-2-4 Assumes (Global)

IEC 62443-2-4 is the service-provider side of the story. It does not regulate utilities or operators directly; it regulates what the integrator or OEM must be capable of offering. The 2023 edition was certified in the field by major vendors through 2024 and 2025, and in 2026 the certification is increasingly a tender-gating requirement — if a utility is NIS2-scoped, the OEM bidding to support their SCADA stack needs to demonstrate 62443-2-4 capabilities against a certified process, not just a marketing claim.

Inside 62443-2-4, the clauses that matter for OT remote access are the ones governing remote access security, user management, and event management and logging. The standard's language is deliberate: remote sessions are to be tied to individual identities, not shared credentials; they are just-in-time, not permanently open; they are supervisable and terminable in real time.

The standard assumes the service provider can identify its own technicians to its own satisfaction. That assumption holds for an OEM whose technicians are all on payroll in the company's home country. It holds less well for the service-desk model that dominates large OEMs today — distributed support teams across multiple countries, with contractors handling overflow. Siemens in Germany, ABB in Switzerland, Rockwell in the US, Honeywell in the US, Schneider in France, Yokogawa in Japan — each maintains technician populations in second and third countries, sometimes in countries where the home country's eID infrastructure does not reach.

The Cross-Border OT Technician Identity Gap

The identity-proofing step that the three frameworks assume but none prescribe is where the cross-border gap lives. Three concrete examples:

• A Polish utility's substation runs a Siemens Spectrum Power control system. When a firmware issue needs Siemens-level support, the engineer who responds from Siemens' EMEA support centre may be a German citizen, an Indian contractor via a Bangalore service partner, or a Turkish specialist contracted through Siemens' Istanbul office. The NIS2 audit asks the utility to prove the identity behind the remote session. The utility asks Siemens. Siemens attests internally but has no EU-recognised electronic-identity binding for the non-EU engineers — the EUDI Wallet does not extend to non-EU citizens.
• A Texas utility operating a generation asset under NERC CIP-003-9 receives remote support from a Yokogawa DCS engineer in Singapore. CIP-003-9 requires the utility to document that vendor remote access. The utility has a session log with a Yokogawa account identifier. What it does not automatically have is an identity-proofing record binding that account identifier to a specific named human who existed before the session started.
• A defence-adjacent German industrial operator supports NATO supply chains. An IEC 62443-2-4-certified OEM's service contract covers remote maintenance. The OEM's on-call engineer for this account is a contractor in Eastern Europe. The operator's NIS2 audit requires identity-bound access; the OEM's 62443 certification requires individual identities. Both requirements land on the same person, and neither framework specifies how that person is proofed.

The common thread is that all three frameworks assume an existing identity-proofing capability that reaches the specific human on the other end of the session. For technicians who are in-country, on the operator's or the OEM's payroll, that assumption is usually defensible. For the cross-border, subcontracted, gig-economy reality of 2026 OT vendor workforces, it is not.

The physical artefact that does reach every jurisdiction is the biometric passport. ICAO 9303 compliant passports are issued by roughly 180 countries and regions. NFC-readable, cryptographically signed via the country's signing certificate, they carry the photograph and biographical data that allow identity proofing against a document the state itself guarantees. Passport-chip identity verification is the layer underneath the three frameworks — the one that, once it is in place, makes the CIP-003-9 session log, the NIS2 audit trail, and the 62443-2-4 individual-identity binding all refer to the same verifiable person.

What This Means for Utility CISOs in 2026

Translating the three frameworks into a practical 2026 programme, the overlapping requirements collapse to five concrete capabilities:

• Inventory — a complete, up-to-date list of every third-party entity with electronic remote access to OT, including which technicians within that entity are authorised, and what systems they can reach. This is the first deliverable a CIP-003-9 audit and a NIS2 Article 21(2)(i) audit both ask for.
• Identity binding — for every named authorised technician, a documented identity-proofing record that predates the technician's first session. The identity-proofing record should reference a document the utility can independently verify. In practice, for a cross-border workforce, this is almost always a biometric passport.
• Session control — each session is initiated from a known endpoint, authenticated by the proofed individual (MFA per Article 21(2)(i) and (j); individual credentials per 62443-2-4), and scoped to the specific asset and time window.
• Kill switch — a documented method to disable vendor remote access on demand, exercised periodically to prove it works (CIP-003-9 Part 1.2.6).
• Audit trail — session logs tied to the proofed individual, retained long enough to survive both the NERC audit cycle and the NIS2 incident-investigation window. The signature that carries authority over the audit trail is an advanced electronic signature under eIDAS bound to the technician's verified identity; it survives cross-border scrutiny without requiring a qualified trust service.

For CISOs at utilities, transport operators, and industrial entities in NIS2 or CIP scope, the 2026 work is almost entirely in the identity-proofing layer. The session-management platforms — the privileged-access brokers, the jump-host architectures, the OT-specific remote-access gateways — have been mature for half a decade. What has moved from "optional" to "mandatory" in 2026 is the identity-proofing record that sits behind the technician-account identifier that the session broker already shows in its log.

The same cross-border identity-proofing problem that OT CISOs face in 2026 shows up in adjacent regulatory regimes: zero-trust architectures depend on identity-first verification as their foundational primitive; non-human identity governance still requires the responsible human behind the service account to be proofed against a verifiable document. OT remote access is where three regulatory frameworks make that problem explicit at once. The cross-border vendor technician layer is what customer onboarding addresses for network sessions; defence base access applies the same passport-chip primitive to physical perimeters at military and critical-infrastructure sites.

FAQ

What is the deadline for NERC CIP-003-9 vendor remote access compliance? 1 April 2026. The requirement is fully effective on day one — not phased in. Responsible Entities that do not have the Part 1.2.6 controls documented and operational face violations up to $1 million per day.

Does NIS2 Article 21(2)(i) apply to OT operators specifically? Yes. Essential and important entities in NIS2 scope include energy, transport, water, healthcare, digital infrastructure, and manufacturing — all of which operate OT. Article 21(2)(i) applies without carve-out; where the utility operates OT, its remote-maintenance access falls in scope.

What does IEC 62443-2-4:2023 require that 62443-3-3 does not? 62443-3-3 addresses the system-level technical security requirements of the asset owner's environment. 62443-2-4:2023 addresses the security capabilities of the service provider — the OEM, integrator, or managed-service operator reaching into that environment. Both apply to OT remote access, from opposite ends.

Can a non-EU technician legally sign an OT remote access authorisation? Yes — the signature's admissibility under eIDAS does not depend on the signatory's citizenship. What it depends on is whether the signature meets the Article 26 criteria for advanced electronic signatures, backed by an identity-proofing step the operator can independently verify. A biometric-passport-based identity verification satisfies the proofing step for the 180 countries that issue ICAO 9303 passports.

Is multi-factor authentication enough to satisfy NIS2 Article 21(2)(i) for vendor sessions? MFA is necessary but not sufficient. Article 21(2)(i) also requires access control policies — which in audit practice means the identity behind the MFA factor must itself be proofed, and that proofing must be documentable. An MFA challenge answered by a vendor-provided credential whose underlying human is not proofed will not survive a 2026 audit finding.

Sources

NERC CIP-003-9

• NERC CIP-003-9 compliance — Tenable, 2026
• Midwest Reliability Organization — Planning for CIP-003-9 and Vendor Electronic Remote Access
• NERC CIP-003-9: What You Need to Know — Shieldworkz
• NERC CIP-003-9 FAQs — ABS Group

NIS2 Article 21 (EU)

• NIS2 Directive — European Commission digital strategy
• NIS2 enforcement 2026 — Diamatix
• NIS2 for OT — Schneider Electric, October 2025
• NIS2 Compliance for OT — SANS Institute

IEC 62443-2-4 (global)

• IEC 62443-2-4:2023 — IEC Webstore
• IEC 62443-2-4 service provider certification — GE Vernova
• ISA/IEC 62443 Series of Standards — ISA
• IEC 62443 essential guide — Industrial Cyber

OT third-party access context

• NIS2 and zero-trust third-party vendor access — Cybele
• What OT Security Teams Need to Know About NIS2 — Rockwell Automation

About the author

Mairi Kutberg is co-founder of IdentiGate, where she runs operations and content. She works at the intersection of EU regulation (eIDAS, NIS2, AMLR, eFTI), cross-border digital identity, and the practical compliance angles of advanced electronic signatures.