Accountability should sit with the organisation that defines, ships, and operates the machine lifecycle, with security, engineering, and safety functions sharing evidence and control ownership. The regulation makes this a governance issue, not just a technical one. Teams need clear responsibility for change tracking, remote access, runtime monitoring, and incident response across the full lifecycle.
What makes a connected machine a governance problem after deployment?
A connected machine can become unsafe after deployment because the risk does not end at commissioning. Software updates, remote support paths, configuration drift, sensor or actuator changes, and new operating conditions can all change the machine’s safety posture. That is why accountability has to follow the lifecycle, not stop at handover.
In practice, the question is not only who built the machine, but who can approve change, see runtime status, and decide when a degraded system must be paused or isolated. Those duties are part of operational governance, and they remain active after the machine enters service.
How responsibility should be split across the lifecycle
Accountability usually rests with the organisation that owns the machine’s lifecycle decisions, because it controls what is shipped, what is enabled remotely, and what conditions are acceptable for continued operation. Security, engineering, and safety functions each own different evidence: security validates access and monitoring, engineering validates change and reliability, and safety validates whether the machine can still operate within tolerance.
That split matters because no single team can honestly claim full control over an unsafe machine if it cannot explain the current software state, the remote administration path, or the incident handling process. For connected systems, lifecycle ownership is as important as design ownership.
Where remote administration or cloud-linked control is involved, the operational boundary should be explicit. EU NIS2 Directive is a useful benchmark because it treats ICT risk, access control, incident reporting, and supply-chain responsibility as governance obligations, not optional add-ons.
What evidence teams need when a machine turns unsafe
The minimum evidence set is usually a current asset and configuration record, a change history, remote access logs, runtime alerts, and a documented decision trail for when the machine was allowed to keep running. Without that evidence, accountability becomes retrospective and disputed, which is exactly when unsafe operation persists longest.
If the machine depends on machine-to-machine authentication, service accounts, or API access, the access model must be reviewed as part of the safety review. RFC 6749: The OAuth 2.0 Authorization Framework is relevant here because it shows how delegated machine access is usually structured, while RFC 9700: Best Current Practice for OAuth 2.0 Security highlights why token handling and sender-constrained protections matter when remote control paths exist.
For organisations that manage large fleets or vendor-connected equipment, NIST SP 800-53 Rev 5 Security and Privacy Controls gives a strong control catalogue for change control, auditability, access restriction, and system integrity expectations.
Risk and Threat Considerations
Once a connected machine is deployed, the main risk is that unsafe behaviour can emerge without a clean ownership trigger. Configuration drift, untracked updates, expired credentials, and weak remote-access controls can all let a machine keep operating after its safety envelope has shifted. If attackers can reach the same control plane, they may also abuse that trust to alter behaviour, suppress alarms, or maintain persistence.
Failure mechanism: A lifecycle gap lets the organisation lose sight of who can change the machine, what version is running, or whether the current operating state still meets safety assumptions. Remote access and update paths then become the most likely route for unsafe change or malicious abuse.
Impact: The result can be unsafe operation, delayed shutdown, incomplete incident containment, and unclear accountability after harm. In regulated environments, the governance failure can be as serious as the technical fault because it delays corrective action and weakens post-incident evidence.
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 NIS2 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIS2 | GV.RM-01 — Risk Management | Connected-machine accountability is a governance and operational risk issue. |
| Recommendation — Assign lifecycle risk ownership for connected machines and require ongoing control evidence. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Unsafe post-deployment behavior often follows configuration drift and uncontrolled changes. |
| AC-17 — Remote Access | Remote administration is a key control path for connected machines after deployment. | |
| AU-6 — Audit Review, Analysis, and Reporting | Accountability depends on evidence from logs and runtime activity records. | |
| Recommendation — Maintain approved machine baselines and compare runtime state against them. Restrict and monitor remote access to machine control paths. Review machine access and change logs to support incident and safety decisions. | ||
Practitioner Guidance
What to prioritise: Treat post-deployment safety ownership as a standing operational duty, not a project handoff. The first priority is to confirm who can approve software, configuration, access, and emergency stop decisions for the live machine.
What to verify: Check that the team responsible for the machine can produce current configuration state, access logs, change records, and an escalation path for unsafe conditions. If any of those are missing, the accountability model is already incomplete.
Decision rule: If a connected machine can be changed remotely, its safety accountability must include the remote control path, the monitoring path, and the incident-response path. If those three are owned by different groups, define a single accountable owner who can coordinate them before the next change or maintenance cycle.
Practitioner takeaway: The key test is not who designed the machine, but who can prove safe operation today and stop it when that proof no longer holds.