FDA Deficiency: Insufficient Secure Boot Evidence

What FDA reviewer language looks like

Paraphrased patterns from real deficiency letters. Not verbatim FDA quotes.

• Pattern 1

  The submission states that the device implements secure boot but does not provide test evidence demonstrating that an unsigned or modified bootloader is rejected. Provide verification testing that demonstrates the secure boot mechanism prevents execution of unauthorized firmware.

• Pattern 2

  The chain of trust for software updates is described but not verified. Provide test evidence demonstrating that updates with invalid signatures or rolled-back versions are rejected.

• Pattern 3

  The device claims a hardware root of trust, but the evidence does not describe how the cryptographic keys are protected from extraction during service or end-of-life. Provide additional information on key protection.

Why this happens

• Secure boot is enabled in production but never tested with a deliberately invalid image.
• Update signature verification is unit-tested but not system-tested with a tampered or rolled-back update.
• Key storage is described as 'in secure element' without explaining the lifecycle — how keys are loaded at manufacturing, protected at runtime, and zeroized at end-of-life.
• Verification artifacts live in the engineering test report but are not surfaced into the cybersecurity submission.

How to fix it

• Add adversarial verification tests: boot with an unsigned image, boot with a modified image, install a downgrade update, install an update signed by an unauthorized key. Capture the device's rejection behavior.
• Document the key lifecycle: key generation environment, injection mechanism at manufacturing, runtime storage (with hardware reference), access controls, and end-of-life zeroization.
• Where a hardware secure element is used, provide the part identifier and reference to the security target or certification.
• Tie each control to a specific threat in the threat model and to the corresponding test in the verification protocol.

Configuration evidence is not verification evidence

The single most common cause of this deficiency is teams submitting screenshots of secure boot being enabled, fuse states, or build configuration files and treating that as the verification evidence. Reviewers want to see the negative test: an attempt to execute an unsigned image, an attempt to install an unsigned update, an attempt to roll back. The evidence package should show the input (the malicious artifact), the expected result (rejection with a specific error), and the actual result. Pen testers can produce this evidence quickly; engineering can produce it during system test; either way, it must exist.

Key protection is the second axis reviewers probe

Even when secure boot tests are present, deficiencies are often written against key protection. The chain of trust is only as strong as the keys that anchor it, and reviewers have learned to ask about the full key lifecycle. Where are signing keys generated? Who has access to them? Are device-side verification keys identical across the fleet, or per-device? How are keys revoked if compromised? A short, well-structured key management appendix often closes both the secure boot and the broader cryptographic concerns in one pass.

Standards involved

• ANSI/AAMI SW96ANSI/AAMI SW96:2023 - Standard for Medical Device Security - Security Risk Management
• FDA 2026FDA Premarket Cybersecurity Guidance (Feb 3, 2026)
• SPDFSecure Product Development Framework
• AAMI TIR57AAMI TIR57:2016 (R2023) - Principles for Medical Device Security - Risk Management

Already responding to this deficiency?

Our deficiency response engagement rebuilds the underlying artifact and produces a reviewer-ready response narrative.