Check Update and Rollback Before Every Field Release

Use this before the first field release and before every update after it. Software, quality, security, and field-service leads sign it; “Manufacturers Should Build Devices to Be Managed as a Fleet” works it on the ventilator fleet.

FDA’s premarket cybersecurity guidance (current edition dated February 3, 2026; substance finalized June 27, 2025) lists updatability and patchability among its recommended security control categories. It asks manufacturers to consider how the update process works if communication is interrupted or fails, and to preserve full build environments so updates and patches can be applied safely. For cyber devices, section 524B requires updates and patches for the device and related systems: on a reasonably justified regular cycle for known unacceptable vulnerabilities, and as soon as possible out of cycle for critical ones.

Confirm every item below for each release. Hold the release until every item is true.

Before release

1. The update is signed, and the device verifies the signature before it installs anything.
2. The update declares the hardware revisions and software versions it’s compatible with, and the device refuses to install on anything else.
3. The SBOM is updated for this release.
4. The full build environment for this release is preserved, so the team can rebuild and patch it later.
5. The release notes state the clinical impact, changed settings, and any change to interfaces or to the meaning of data.
6. The update has been tested on every hardware revision in the field.

During rollout

1. The device never installs an update during clinical use or an active process cycle. The institution controls the installation window.
2. The rollout is staged: a named subset of units first, then a hold point with written criteria for continuing.
3. An interrupted download or installation leaves the device in a known safe state: the previous version or a defined recovery mode, never a half-installed one.
4. The device keeps journaling its events through the update and loses none of them.
5. Each unit reports its new version to the fleet view when installation finishes.

After installation

1. Rollback to the previous version is tested for this release, including configuration and data compatibility.
2. A rollback installs only a signed, authorized release. The device refuses unsigned or unauthorized downgrades. A rollback to a version with a known critical vulnerability needs an explicit, recorded risk decision.
3. The fleet view shows which units updated, which failed, and which rolled back.
4. A failed installation alerts both the institution and the manufacturer.
5. The release fits the stated patch cadence: a regular cycle for known vulnerabilities, and out-of-cycle releases for critical ones.

Teams most often skip the rollback test when a release is late. Don’t ship a release whose rollback hasn’t been tested on that release.