Firmware Security & OTA for Medical Devices

Medical-device submissions now fail on cybersecurity before they ever fail on clinical function: a refuse-to-accept letter for a missing SBOM, or a CVE in an unpatchable component discovered in postmarket surveillance. We build the firmware security and OTA pipeline so the device boots only signed code, accepts only signed updates, and ships the SBOM, vulnerability-management, and audit-trail evidence the FDA premarket guidance and IEC 81001-5-1 reviewer demand. This is the maintainability layer that keeps a fielded device patchable for years, not a one-time pen test.

Challenges specific to Medical Devices

• Refuse-to-accept over a missing SBOM

  FDA premarket cybersecurity review rejects the submission because there is no machine-readable software bill of materials enumerating every third-party and open-source component with its version and known vulnerabilities.

• A field device cannot be patched safely

  A Log4Shell-class CVE lands in a shipped component but the firmware has no signed update path, so the manufacturer faces a recall instead of pushing a remediated image to fielded units.

• Unsigned firmware lets an attacker persist

  Without Secure Boot the bootloader runs any image in flash, so a malicious or modified build survives reset and the device can no longer attest that it is running manufacturer-approved code.

• OTA rollback re-opens a patched hole

  An update mechanism that accepts an older signed image lets an attacker downgrade a patched unit back to a vulnerable version, defeating the entire vulnerability-management story in postmarket.

• No coordinated way to track and triage CVEs

  Postmarket surveillance requires monitoring the component inventory against new disclosures, but with no SBOM-to-CVE feed the team learns about exploitable vulnerabilities from customers or regulators first.

• Security events leave no defensible record

  A failed signature check, a rejected update, or a config change produces no tamper-evident log, so the manufacturer cannot reconstruct an incident or demonstrate control during an IEC 81001-5-1 audit.

How GizanTech solves them

1. Secure Boot v2 chain of trust. We enable hardware Secure Boot v2 with the public key digest fused in eFuse, sign every stage of the bootloader and application with RSA-3072/ECDSA, and disable JTAG and ROM download so only manufacturer-signed firmware executes.
2. Signed, rollback-protected OTA. Updates are delivered as images signed by an offline key, verified before activation, and gated by a monotonic anti-rollback version counter in eFuse so a downgrade to a vulnerable build is rejected at the bootloader.
3. Automated CycloneDX SBOM generation. The CI build emits a CycloneDX SBOM enumerating every component, version, and license, exported as the machine-readable artifact the FDA premarket submission and IEC 81001-5-1 software-of-unknown-provenance review require.
4. SBOM-driven vulnerability management. We wire the SBOM into a CVE feed (NVD/OSV) so each release is scanned against known disclosures, vulnerabilities are triaged by exploitability, and the patch-or-justify decision is recorded for postmarket surveillance.
5. Field-patchable A/B update partitions. Dual application slots with a confirm-and-revert watchdog let a remediated image be pushed and validated over the air, falling back to the last-good slot if it fails to boot, so patching never bricks a fielded unit.
6. Signed, append-only security audit trail. Boot integrity results, update acceptances and rejections, and security-relevant config changes are written to a hash-chained, HMAC-signed event log that exports as tamper-evident evidence for incident reconstruction and audit.