Firmware updates and software supply chain
Review an update's origin, supported installation path and effect on the deployed system. Check compatibility and rollback limits before scheduling the change.
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#
Physical security deployments combine embedded firmware, operating systems, codecs, protocol libraries, SDKs, drivers, containers, mobile applications, cloud services, browser components, and integration code. The assurance boundary includes every component that can alter data, policy, identity, or physical behaviour.
Product and dependency record#
For each deployed component record supplier, exact model/package, hardware revision, firmware/software build, bootloader where relevant, enabled modules, dependencies, licence, support end date, update source, signing identity, configuration compatibility, and rollback constraints. A marketing product name isn't a sufficient vulnerability identifier.
Update trust chain#
An update workflow should establish:
- provenance from an official authenticated distribution channel;
- integrity and publisher identity using a verified signature or equivalent mechanism;
- authorisation for the exact product, hardware and target version;
- anti rollback policy appropriate to recovery and safety needs;
- compatibility with configuration, profiles, integrations, certificates and evidence formats;
- atomic or recoverable installation and bounded reboot behaviour;
- post update version, configuration, trust and service state evidence;
- an environment validated recovery route that doesn't reintroduce known vulnerable trust.
Never treat a hash copied from the same unauthenticated location as independent provenance. Keep update signing trust separate from ordinary TLS distribution trust.
SBOM and component analysis#
An SBOM helps map a disclosed component issue to products, but presence alone doesn't prove reachability or exploitability, and absence from an SBOM doesn't prove absence from a binary. Preserve supplier statements, component versions, build features, exposure, compensating controls, and the evidence supporting the triage decision.
Physical service constraints#
Updates may interrupt recording, door decisions, alarm signalling, intercom, time, analytics, or failover. Sequence redundant components, preserve certified local functions, define maintenance state, notify operators, and avoid updates during high risk operating windows. Firmware procedures for life safety connected equipment must come from the manufacturer and qualified authority.
Developer controls#
- Protect source, build workers, signing services and release credentials as production assets.
- Pin and review dependencies; record why each dependency is needed.
- Generate reproducible provenance where the build system supports it.
- Sign artefacts after controlled build and before distribution.
- Separate development, test and production signing roots.
- Verify updates in the device boot/update path, not only in the management UI.
- Make downgrade and recovery decisions explicit and auditable.
- Publish vulnerability reporting, support period and end of support information.
Sources#
- NIST SSDF, NIST SP 800-218 Version 1.1, secure development and release practices, accessed 25 August 2026.
- NIST 800 193, NIST SP 800-193: Platform Firmware Resiliency Guidelines, protection, detection and recovery principles, accessed 25 August 2026.
- NTIA SBOM, NTIA Software Bill of Materials resources, accessed 25 August 2026.