Patches arrive on the owner's schedule, not yours
Monday morning operations review. The asset owner's commissioning team is going through the previous week's alarms when one of the engineers notices something unusual. Three of the wind turbines logged a controlled restart at 03:42 on Saturday. The restart was not in the change management system. The control room saw the restarts, recorded them as routine, watched the turbines come back online cleanly.
Investigation begins. The audit logs on the controllers show a firmware update was applied at 03:38, four minutes before the restart. The update package signature is valid. The update came from a connection the asset owner's security team is now examining: an outbound TLS session from the controller to a hostname that resolves to the manufacturer's update infrastructure. The connection was permitted by the firewall rule that allowed the controller to report telemetry — the rule that, on close reading of the manufacturer's documentation, was supposed to be outbound-only for diagnostic data, not bidirectional for software delivery.
The asset owner's security team escalates. The firmware update is benign in itself — a routine quarterly maintenance release, well-tested, no security implications either positive or negative. The mechanism is not benign. The manufacturer's controllers have just demonstrated that they can receive and apply software changes from outside the asset owner's control. Three out of fifty turbines applied the update; the other forty-seven did not, for reasons the manufacturer cannot immediately explain. The asset owner now has a fleet in mixed configurations, an audit trail with software changes that did not pass through change management, and a regulatory disclosure to consider under NIS2 .
The principle the asset owner expects is brief, and the manufacturer's bid did not address it. Software changes to the deployed equipment happen on the asset owner's schedule, under the asset owner's change management, with the asset owner's approval. The manufacturer's role is to make patches available — signed, documented, tested, accompanied by the information required for the asset owner to make a deployment decision. The deployment itself is the asset owner's act, not the manufacturer's.
Why OT patching differs from IT patching
A reasonable manufacturer's reaction at this point in the conversation is that the auto-update mechanism is industry-standard, supported by every major cloud platform, used by everything from consumer phones to enterprise software. It is. The difference is the operating context.
In information technology, an update can be hot-deployed during business hours, the affected user retries their action, the inconvenience is brief, the rollback is a software re-image. In operational technology, an update typically requires a restart, the restart requires coordination with the grid operator (because the plant briefly stops producing), the affected behaviour might have safety implications, the rollback might require physical access to the controller. A bad update applied to fifty turbines simultaneously can take a plant offline for the rest of the day, with revenue impact, grid stability consequences and contractual penalties under the connection agreement.
The asset owner is also the regulated entity. Under NIS2, the operator is responsible for the cybersecurity posture of the asset and for incident notification if something goes wrong. An update applied without the operator's knowledge that subsequently causes an incident is an incident the operator must report and explain to the national CSIRT, while not having had control over the change that caused it. This is a regulatory position no operator is willing to occupy.
The Cyber Resilience Act , in Article 13 (via Annex I Part II point 8), requires manufacturers to provide security updates promptly and free of charge during the declared support period. The Act does not require those updates to be pushed automatically. The deployment mechanism is the operator's to choose. The mature operator chooses controlled deployment because the consequences of uncontrolled deployment are exactly what the auto-update mechanism cannot mitigate.
IEC 62443-4-1 organises the manufacturer's responsibilities for security update management under the practice set known as SUM, covering qualification (SUM-1), documentation (SUM-2), dependent component documentation (SUM-3), delivery (SUM-4), and timely delivery of security patches (SUM-5). The standard makes the manufacturer responsible for making patches available with the necessary documentation and assurance evidence. It does not make the manufacturer responsible for deploying them — that responsibility, in a properly architected service relationship, sits with the asset owner.
The patch delivery contract
What replaces auto-update is a structured contract between the manufacturer and the asset owner. The contract has eight stages.
Release. The manufacturer publishes the patch in their controlled release infrastructure — a download portal that requires authentication, accessible to authorised asset owner representatives. Public download URLs, repositories accessible without credentials, and update servers that controllers reach autonomously are not part of this model. The manufacturer's release infrastructure is the point at which a new version becomes available; it is not the point at which it is deployed.
Notification. The asset owner is notified through the channel agreed in the contract. For security patches, this is typically the manufacturer's PSIRT advisory channel , with the advisory cross-referenced to the patch release. For feature and maintenance updates, the notification channel is usually the manufacturer's customer success or technical account management function. The notification specifies what the patch contains, why it is being released, what the assessed criticality is, and what the recommended deployment window looks like.
Delivery. The patch is delivered as a signed artefact — a firmware image, a configuration package, an application installer — with a cryptographic signature using the manufacturer's release signing key. The asset owner verifies the signature against a public key established at contract signature and held in their PKI. A patch whose signature does not verify is not deployable, regardless of how urgent the manufacturer's notification claims it to be.
Documentation. Each release includes a documentation set: release notes describing what changed and why; known issues and their workarounds; regression test evidence describing what was tested by the manufacturer and how; rollback procedure describing how to revert if the deployment causes issues; and a software bill of materials diff showing which components changed at what versions. The documentation set is what enables the asset owner's change advisory board to make an informed deployment decision rather than relying on the manufacturer's assurance alone.
The CSAF format — Common Security Advisory Framework, an OASIS standard — has emerged as the machine-readable structure for security advisories and patch metadata. Manufacturers that publish CSAF-format advisories integrate cleanly into the asset owner's vulnerability management tooling. Those that publish PDF advisories require the asset owner's team to transcribe the information, which slows the process and introduces error.
Testing. For SL-T 3 zones and above, the asset owner typically maintains a staging environment that mirrors the production configuration for representative equipment. Patches are deployed to staging first, run for an agreed observation period, evaluated for regression and unexpected behaviour, and only then approved for production. For lower security level zones, the asset owner may accept the manufacturer's regression evidence as sufficient and skip the staging step. The decision is the asset owner's to make.
Approval. The asset owner's change advisory board reviews the patch package, the documentation, the staging results if applicable, and the proposed deployment plan. Approval is granted under the asset owner's change management process, with the resulting change ticket carrying the audit trail.
Deployment. The patch is applied during a scheduled outage window, coordinated with operations and the grid operator. The deployment mechanism is the asset owner's, using their authenticated session against the controller through the secure remote access broker. The manufacturer's engineering team may be in attendance, but they are not the actors; their role is to advise if anything unexpected occurs.
Post-deployment verification. The asset owner verifies the patch has been applied successfully, runs functional tests against the updated equipment, monitors operational behaviour for the period agreed in the change ticket, and confirms successful completion in the change management system. Failed deployments are rolled back using the manufacturer's documented procedure.
This is the contract. It is more elaborate than auto-update because the consequences of getting it wrong are larger. It is also the discipline that every mature asset owner's change management operates under, regardless of EU regulation, because controlled change is the foundation of operational reliability.
Emergency patches and silent updates
A separate but related topic is what happens when a critical vulnerability is announced — exploited in the wild, scored at the top of the severity scale, demanding immediate response.
Emergency patches follow an accelerated path through the same contract, not a parallel path outside it. The PSIRT advisory is issued; the asset owner's PSIRT-watching function picks it up; the asset owner's emergency change process activates; a same-day or next-day deployment is scheduled if the risk warrants it; the manufacturer's release infrastructure provides the signed artefact and the documentation; the asset owner deploys under their authority. The compressed timeline does not change who performs the deployment or under whose authorisation.
The manufacturer does not deploy emergency patches on their own authority. Even when the manufacturer has the technical capability to do so — because the controllers can receive updates through some mechanism, perhaps the same one the auto-update incident in the opening scene revealed — the act of deploying without asset owner approval is a contractual violation in EU-financed projects. The asset owner's risk assessment may decide that the vulnerability is genuinely emergency-grade and approve deployment within hours; that decision is theirs.
The "no silent updates" principle has technical implications. Controllers must not accept software updates from external sources without explicit local authorisation. Telemetry channels must be strictly outbound, with the firewall rules and unidirectional gateway architecture enforcing the constraint at the network level. Update mechanisms must require authentication using the asset owner's credentials or PKI, not credentials the manufacturer holds independently. Local update applications — engineer at the cabinet with a laptop, USB drive with a firmware image — must follow the change management process, with the deployment tracked the same way a remote deployment would be. Software composition must be verifiable at any time, typically through the SBOM and a cryptographic attestation of the running firmware against the signed release.
A device that supports auto-update but allows it to be disabled is not adequate. A device that supports auto-update enabled by default, configurable to off at deployment, is also not adequate — the default configuration is what the asset owner's commissioning team has to remember to change, and the auto-update mechanism is what their security team has to remember to monitor for re-enablement. The expectation is that the equipment is delivered with auto-update structurally disabled — either not implemented in the project variant of the firmware, or implemented only against a release server that the asset owner controls.
At proposal stage
A manufacturer's bid that addresses the patch delivery contract — that describes the release infrastructure, the signature mechanism, the notification channel, the documentation set including SBOM diff, the support for rollback, the absence of auto-update mechanisms in the project variant — is a bid that has anticipated the conversation. The conversation that follows is operational: the cadence of expected releases, the channel for emergency advisories, the staging environment specifications, the rollback procedures specific to this equipment.
A manufacturer's bid that proposes "automatic firmware updates pushed from our cloud for security and feature improvements" signals an architectural model that the asset owner cannot accept. The work to close the gap involves disabling the auto-update path, providing a signed-artefact delivery mechanism, building or extending the manufacturer's release infrastructure to support authenticated download, and integrating with the CSAF format for advisories. The work is the work of weeks to months depending on the manufacturer's current state, not a procurement footnote.
The deeper observation is that the patch delivery contract is the topic where industrial operational technology has lagged behind general information technology in some ways and led in others. Lagged because the deployment discipline is less automated than IT, where patches can be hot-deployed and rolled back without coordination with the grid operator. Led because the change management discipline is more rigorous than IT, with engineering review, regression testing, and post-deployment monitoring that IT often skips. The patch contract described here combines the best of both — rigorous change management with modern release infrastructure, signed artefacts, machine-readable advisories, and structured rollback. A manufacturer who delivers patches this way has built capability that pays off across their global service organisation, not only in EU-financed projects.
The next article picks up the operational telemetry that flows in the opposite direction from patches: the logging and monitoring discipline where the asset owner's security operations centre, not the manufacturer's, is the system of record for security events.
This article reflects the regulatory and standards landscape at publication. The Cyber Resilience Act's implementing acts continue to evolve through 2026–2027 and may alter specific patch delivery and security update obligations. References to IEC 62443-4-1, CSAF and related standards may be superseded by revisions. If a citation has rotted or a clause has moved, LinkedIn is the way to flag it.