Updating connected machinery is not equivalent to deploying a routine web application release. A package can be authentic and technically valid yet still introduce an unsafe transient state, break communication with an older component, or leave operators with an unexpected restart sequence. A defensible update workflow must therefore combine cybersecurity controls with machine risk assessment, functional safety and disciplined change management.
Begin with the machine, not the update package
Before approving a release, define the system under consideration: controllers, HMIs, industrial computers, drives, safety controllers, engineering workstations, gateways, remote-access services and relevant data interfaces. Record current software and firmware versions, communication paths, and responsible owners. This inventory establishes where an update may travel and which dependencies could be affected.
The risk review should consider both cyber compromise and physical consequences. The practical IEC 62443 principles for industrial automation provide a useful structure for analysing assets, zones, conduits, identities, integrity and monitoring.
This does not replace the machinery risk assessment under ISO 12100. Instead, the two analyses meet where a loss of integrity or availability could alter machine behaviour, defeat an operating assumption or weaken a protective measure.
Authenticate the source and authorise the change
An update process needs to establish two different facts: that the package comes from an approved source and that its installation has been authorised for this particular asset. Vendor portals, service laptops and remote gateways should not be treated as trusted merely because they are familiar.
The team should verify the package against an approved release record and maintain a controlled route from receipt to deployment.
Installation rights should follow least privilege. Operators may need visibility of update status without being able to deploy firmware, while maintenance personnel may require access to selected assets but not unrestricted administrative control across the OT network. Individual accounts, strong authentication, and time-limited remote access make responsibility clearer. For critical interventions, a second-person approval can separate technical execution from release authority.
Verify integrity before changing the machine
Where the component supports it, validate a digital signature or a cryptographic hash supplied through a trusted channel. A filename, version label, or successful download is not sufficient evidence of integrity.
Record the verification result with the asset identity, package version, source, verifier, and time. If authenticity or integrity cannot be established, quarantine the package rather than improvising on the production network. Integrity checks must also cover configuration.
Firmware may install correctly while resetting parameters, changing protocol behaviour or introducing incompatible defaults. Capture approved PLC logic, safety configuration, drive parameters, HMI projects, recipes and network settings before deployment.
For safety-related control functions developed with reference to ISO 13849, determine whether the update could affect the validated architecture, diagnostics, response time or assumptions used in the performance-level calculation.
Test normal, degraded and transitional states
A representative test environment should reproduce more than the target device. It should include relevant versions on both sides of each interface, realistic timing and expected failure modes. Test cold starts, warm restarts, interrupted communications, power loss during installation, incompatible messages, and partial deployment. Connected machinery often fails at the boundary between versions rather than within either version alone.
Define acceptance criteria before the maintenance window. These should cover functional operation, safety functions, alarm handling, communications, data consistency and operator-visible behaviour. If an update affects start conditions, interlocks, acknowledgement logic or motion parameters, repeat the necessary risk review and validation. A successful installation message is not evidence that the machine remains suitable for production release.
Design rollback as an engineering operation
Effective planning for safe software updates in production requires a precise rollback point, not a vague promise that the previous version can be restored. Identify compatible backups, configuration dependencies, and data generated after cutover. Some infrastructure can be reverted quickly, but process records created under new logic may require reconciliation rather than simple restoration.
State who can order rollback, which symptoms trigger it, and what machine condition must be established first. A return to an earlier release must not create unexpected start-up, restore obsolete credentials, or load a configuration from another asset. Backups should be isolated from the production network where appropriate, identified by machine and version, and periodically tested on suitable equipment. An untested copy is only a recovery assumption.
Control deployment through zones and maintenance windows
IEC 62443’s zones-and-conduits model helps limit the deployment path. Update traffic should cross only approved conduits and reach only the intended assets. Temporary firewall rules, vendor access, and service accounts must have defined expiry points. If a component cannot be patched immediately, compensating controls may include tighter segmentation, disabling an unnecessary service, or restricting the vulnerable interface until a controlled update is possible.
The maintenance plan should name the release owner, deployment engineer, production representative, and person responsible for safety acceptance. It should also specify the approved package, target assets, sequence, stop conditions, and communication method.
For a retrofit or significant digital modification, the team should assess whether existing CE documentation, technical files, and risk assessments need revision. Cybersecurity services and standards can support that work, but they do not transfer the manufacturer’s responsibility or guarantee conformity.
Create an audit trail that engineers can actually use
The record should answer six questions without relying on individual memory: what changed, where, from which version, to which version, who approved it, and what verification followed.
Useful evidence includes authentication results, package hashes, test outcomes, timestamps, deployment logs, configuration baselines, exceptions and the final release decision. Logs must be protected against unauthorised alteration and retained according to the organisation’s risk and documentation policy.
Monitoring should continue after release. Watch for failed logins, unexpected configuration changes, unusual controller communications, repeated restarts and deviations from the approved version baseline. Define an observation period and assign someone to review alerts rather than merely collecting them.
The workflow closes only when the plant confirms stable operation, records residual issues, and feeds lessons into the next update cycle. Secure updating is therefore not a single tool or approval gate; it is a repeatable engineering process joining identity, integrity, recoverability and evidence.
