An illustrative update acceptance test
Suppose a supplier says that its networked environmental sensors accept signed firmware updates. On an isolated spare, the facilities team installs an approved release and checks the reported version. Using vendor-supported procedures, it then checks rejection of an altered package. Where rollback protection is required, it also checks rejection of an unauthorized older release.
These tests answer different questions. Rejecting an altered package addresses update authentication. Rejecting an unauthorized older release addresses the required rollback policy. A displayed version alone does not establish that every component changed. Record the hardware revision, bootloader, firmware package hash and update method so the conclusion applies to the unit and software path that were actually tested.
Following the device through its lifecycle
Compare the purchasing requirement with supplier documentation and observations from the device. If neither answers a question, leave it unresolved. Missing documentation is not a passed test. The acceptance record should make that uncertainty visible while there is still time to decide whether it is acceptable.
| Lifecycle stage | Acceptance question | Useful evidence |
|---|---|---|
| Provisioning | How does each unit acquire an appropriate identity, and can that identity be replaced? | Provisioning design and controlled enrollment test |
| Operation | Which local and remote interfaces remain enabled in operation? | Interface inventory and access restrictions |
| Update | Where are code authenticity and the required version policy enforced? | Documented trust chain and recorded update results |
| Recovery | Can an authorized operator recover the device while retaining the intended policy? | Recovery procedure tested on a spare |
| Retirement | What removes the unit’s credentials, ownership and stored data when it leaves service? | Decommission record and service-side revocation |
Test recovery without risking operations
Define the expected outcome and recovery procedure before introducing a failure. If interrupted updates are in scope, use an approved laboratory procedure on representative spare hardware. Improvised power interruptions on equipment controlling a live process can cause the operational consequences that the spare-unit exercise was intended to avoid.
Then examine the recovered unit as a running device again. Check its network identity, retained configuration, update permissions and running software. Returning to shared default credentials, for example, would change what successful recovery means. Repeat the relevant tests when a hardware revision changes the boot or storage path, even if the product name stays the same.
Check the support end date and latest deployable release too. Once firmware maintenance ends, assign the replacement or containment decision to an owner and set a review date. Network isolation may help contain the device, but it does not resolve the absence of firmware maintenance. The decision to keep operating it needs to account for both.
What a functional device test leaves open
A spare-unit test establishes the behavior reached by that procedure. It does not establish silicon-level security, resistance to physical extraction or resilience against advanced fault attacks. NIST control guidance helps organize integrity, identity and lifecycle decisions without certifying those properties of a particular device.
List inaccessible components and untested interfaces in the result. Specialized hardware analysis needs its own equipment, authorization and expertise. If the device affects a physical process, settle the operational and safety constraints before selecting the analysis method.
Sources and reference editions
- NIST security and privacy control catalogRevision 5, release 5.2.0 (2025-08-27)
- NIST Guide to OT SecurityRevision 3 final; Revision 4 initial public draft 2026-09-21