Accountability should follow the identity owner, the system owner, and the approver of the remote path. If an OEM, contractor, or internal support team created the session outside normal governance, that is a control failure the organisation owns. Frameworks such as IEC 62443, NIS2, and NIST SP 800-82 all push in that direction.
Why This Matters for Security Teams
Accountability for a remote CPS session is rarely just a technical question. The real issue is whether the session was authorised, monitored, and bounded by policy before the harm occurred. If a remote path bypasses approval, weakens segmentation, or exposes privileged access to an OEM or contractor, the organisation still owns the control failure. That is why guidance from NIST Cybersecurity Framework 2.0 and NIST SP 800-82-style operational thinking both place responsibility on governance, not on the accident alone. In NHI terms, the session is only as safe as the identity, secrets, and access path behind it. NHIMG research on the Schneider Electric credentials breach shows how fast credential misuse can become operational exposure when identity controls are not tight enough. The same pattern appears in CPS environments when remote support becomes routine rather than exceptional. In practice, many security teams discover the accountability gap only after the plant, line, or control loop has already been affected, rather than through intentional governance reviews.
How It Works in Practice
Accountability should be assigned across three layers: the identity owner, the system owner, and the approver of the remote path. The identity owner governs the credential or service account used for access. The system owner owns the CPS asset, its safety impact, and whether remote support is justified. The approver owns the decision to allow that path at that time, under that context. If an OEM technician, contractor, or internal support team creates a session outside normal governance, that is not a reason to transfer blame away from the organisation. It is evidence that the control environment failed to constrain the session.
Practitioners usually need four controls to make this work:
- Just-in-time access with short-lived approval windows, not standing remote access.
- Session recording and command logging so the path can be reconstructed after an incident.
- Segmentation and jump-host mediation so the remote user never reaches the asset directly.
- Revocation and offboarding workflows for third parties, including emergency access paths.
This is where NHI discipline matters. Long-lived secrets, shared vendor accounts, and weak offboarding are common precursors to loss of control. NHIMG research on the Schneider Electric credentials breach is a reminder that credential exposure in one workflow can become an operational issue elsewhere. The NIST Cybersecurity Framework 2.0 is useful here because it forces teams to connect identity governance, access control, and recovery, rather than treating remote support as a separate exception. These controls tend to break down when legacy CPS assets require always-on vendor access because the business has not funded a safer support model.
Common Variations and Edge Cases
Tighter remote-access control often increases operational friction, so organisations have to balance availability against blast-radius reduction. That tradeoff is real in utilities, manufacturing, and critical infrastructure, where downtime has immediate cost. Current guidance suggests that the safest answer is not “never allow remote access” but “allow only controlled, attributable, time-bounded access with explicit ownership.” There is no universal standard for every CPS topology, especially where safety systems, maintenance contractors, and emergency engineering support overlap.
Edge cases usually involve shared responsibility. For example, an OEM may run the tooling, but the asset owner still decides whether the tooling is permitted, what identity is used, and whether the session is supervised. Another common variation is break-glass access. Break-glass is acceptable only when it is rare, logged, time-limited, and reviewed after use. If the emergency process becomes the normal process, accountability becomes impossible to assign cleanly. The same is true for unmanaged service accounts or remote scripts that act like human operators. In those cases, the issue is not just access. It is whether the organisation has allowed an identity to operate without a clear owner, approval path, and revocation point. For governance framing, the NIST Cybersecurity Framework 2.0 and the control lessons from the Schneider Electric credentials breach both point to the same operational truth: remote CPS harm is usually an accountability design failure before it is an intrusion.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-63 set the technical controls, while NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Remote CPS harm is driven by weak access governance and approval paths. |
| NIS2 | NIS2 reinforces board and operator accountability for secure remote operations. | |
| NIST SP 800-63 | Identity proofing and authenticator management underpin accountable remote access. |
Use strong identity proofing, unique credentials, and revocation for every remote session.
