Change, firmware, and patching
Check updates against the interfaces your integration uses. Review authentication, events, codecs, storage, timing and rollback before deploying a new version.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Research and static guidance only; product and deployment specific behaviour requires controlled environment validation and authoritative product evidence.
On this page
Overview#
An update can change authentication, certificates, protocol profiles, codecs, schemas, SDK behaviour, database formats, device drivers, discovery, firewall flows, storage use and safety related integration timing. Read release notes and security advisories for every intermediate and target version.
Change record#
- purpose, risk and urgency;
- exact source and target versions;
- affected assets, protocols, profiles, dependencies and integrations;
- vendor support and artifact/signature evidence;
- configuration/data format and downgrade compatibility;
- expected service and physical impact;
- prerequisite backups and recovery credentials;
- staged sequence, hold points and stop conditions;
- environment acceptance cases and evidence;
- rollback/rebuild plan and decision authority;
- inventory, baseline and documentation updates.
Staging strategy#
Use representative non production equipment where available, then a bounded pilot that doesn't compromise required coverage or safety. Validate authentication, secure transport, discovery, streams, events, control authorisation, time, logging, storage, offline/failover, backup/restore, and integrations. Record expected and observed results, approval, limitations, and stop conditions before expanding the pilot.
Emergency mitigation#
When a fix can't be deployed immediately, record affected versions and exposure, disable the vulnerable interface/feature where safe, restrict network and identity paths, increase monitoring, preserve evidence, and set a dated replacement or remediation decision. A compensating control must not create an undocumented life safety or availability failure.
Rollback cautions#
Downgrade may be blocked, unsupported, erase configuration, invalidate signatures, require database rollback, re enable vulnerable defaults, or break certificate/key formats. Prefer a documented recovery image and configuration restore over assuming a version downgrade is reversible.
Sources#
- NIST 800 40, NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning, accessed 25 August 2026.
- NIST 800 82, NIST SP 800-82 Rev. 3, OT change and patch considerations, accessed 25 August 2026.