SoC Security in Medical Devices: Reducing Attack Surface

Part of our Real-Time Operating System (RTOS) cybersecurity series. For the full overview, start with RTOS Security for Medical Devices: A Practical Guide.

Reviewed September 17, 2026

A System-on-Chip failure does not stay contained to one function. Because the CPU, memory, wireless radios, and cryptographic engine sit on the same die, a defect in the Bluetooth stack or boot logic can expose patient data, disable a monitor, or hand an attacker chip-level control. Connected medical devices, from insulin pumps to imaging consoles, depend on SoCs sourced from vendors who ship their own firmware, SDKs, and debug tooling, and manufacturers often inherit that risk without fully evaluating it. The FDA now expects hardware-level scrutiny as part of premarket cybersecurity review, not just application software testing. Devices cleared without documented SoC risk assessments face additional information requests or delayed clearance. This article explains the SoC attack surface, the controls that reduce it, and the documentation reviewers expect under the February 3, 2026 final guidance.

Why This Matters

Medical device manufacturers rarely design their own silicon. They buy SoCs from vendors like TI, NXP, or STMicroelectronics and build application software on top of a firmware and driver stack they did not write and cannot fully audit. That dependency means known SoC-level flaws, such as SweynTooth in BLE stacks or NUCLEUS:13 in embedded TCP/IP stacks, can affect a device even if the manufacturer's own code has no bugs. A single unpatched vendor library can crash a patient monitor, disable an infusion pump's wireless telemetry, or open a path to remote code execution.

The FDA's February 3, 2026 final guidance, following the September 2023 and June 27, 2025 final guidances, treats hardware and firmware as part of the same cybersecurity risk management file as application software. Reviewers expect a threat model that names the SoC, its radios, its boot chain, and its debug interfaces as discrete attack surfaces, each with a documented mitigation. AAMI SW96 (recognition number 13-131) reinforces this by requiring security risk management across the full device architecture, not just the top application layer. Manufacturers who treat the SoC as a black box invoice line rather than an engineering artifact are the ones most likely to receive additional information requests tied to hardware-level gaps.

What Makes SoC Security Different From Application Security?

SoC security differs from application security because a single chip integrates functions that used to sit on separate, isolated boards. A modern SoC combines a CPU core, RAM, flash controller, Bluetooth or Wi-Fi radio, and often a cryptographic accelerator on one die. That integration is efficient for low-power embedded medical devices, but it also means a vulnerability in one subsystem, like the radio firmware, can be used to reach memory or execution paths that have nothing to do with wireless communication.

[KEY REQUIREMENT] Threat models must treat each SoC-integrated function, radios, boot ROM, debug interfaces, and cryptographic engine, as a separate attack surface rather than bundling the whole chip into a single generic "hardware" risk line.

Why Do Secure Boot and Root of Trust Matter?

Secure boot and a hardware root of trust matter because they are the only controls that verify a device is running authentic firmware before any application code executes. A hardware root of trust anchors a cryptographic key in silicon that cannot be modified by software, and secure boot uses that key to validate each stage of the boot chain, bootloader, operating system, and application, before handing off execution.

Without this chain, an attacker who can write to flash can substitute their own firmware and the device will run it without complaint. With secure boot properly implemented, any unsigned or modified image simply fails to load, and the failure can be logged for postmarket monitoring. Manufacturers should verify that every link in the chain is checked, not just the first stage, since a partial secure boot implementation that only validates the bootloader still leaves the application firmware open to tampering.

What Happens When Debug and Test Interfaces Stay Enabled?

Debug and test interfaces that stay enabled in production hardware give an attacker with physical access the same control a developer had on the bench. JTAG, SWD, and UART headers are essential during development for flashing firmware and reading logs, but they typically bypass authentication and operating system protections entirely, exposing memory, registers, and sometimes plaintext keys.

Testers routinely find these interfaces active on production boards because engineering teams disable them in a configuration file rather than physically or cryptographically locking them out. A configuration flag can be reverted; a blown fuse or a debug authentication scheme cannot be undone with a simple firmware flag. Manufacturers should confirm through hardware-level testing, not just a design review, that production units actually block debug access.

How Do Chip Errata and Vendor SDKs Introduce Risk?

Chip errata and vendor SDKs introduce risk because they document known silicon defects and ship pre-written code that manufacturers rarely review line by line. Every SoC vendor publishes an errata sheet listing known hardware bugs, some of which have security implications, such as a cryptographic peripheral that behaves incorrectly under specific conditions or a debug lock that can be bypassed with a documented sequence.

Vendor SDKs compound this because manufacturers build on top of reference code, Bluetooth stacks, TCP/IP stacks, and driver libraries, that the silicon vendor wrote and maintains on its own schedule. If the vendor patches a stack vulnerability, the fix does not reach the medical device until the manufacturer pulls the update, retests, and revalidates. Manufacturers should assign someone to read errata sheets and vendor security advisories on a recurring schedule, not just at initial chip selection.

Why Does Third Party Silicon Belong in the SBOM?

See also: What Is MedTech? MedTech vs Medical Device vs Life Sciences, CVSS Scoring for Medical Devices: A Complete Walkthrough, and Medical Device Software Development: A Compliance Guide.

Third party silicon belongs in the SBOM because Section 524B requires manufacturers to identify all software components capable of being affected by a vulnerability, and SoC firmware, bootloaders, and vendor libraries meet that definition even though they arrived pre-installed on a purchased chip. Many manufacturers document only the application code they wrote, leaving the SBOM silent on the RTOS, Bluetooth stack, or boot firmware that shipped with the SoC.

That gap matters in practice: when a CVE is published against a specific BLE stack version, a manufacturer without SoC firmware in its SBOM has no fast way to determine whether its own devices are affected. Reviewers increasingly ask for evidence that the SBOM extends to silicon-level components, and postmarket surveillance depends on that same data to drive patch decisions.

What Documentation Does the FDA Expect for Hardware Level Controls?

The FDA expects hardware level controls to be documented with the same specificity as software controls: named components, described mechanisms, and test evidence. The threat model should list the SoC's radios, debug interfaces, and boot chain individually, the SBOM should include SoC firmware and vendor libraries, and the security risk assessment should map each hardware attack surface to a control and a verification method.

[KEY REQUIREMENT] Firmware validation results, secure boot test evidence, and debug interface lockout confirmation must appear in the eSTAR cybersecurity documentation, not just be referenced as "addressed in design."

Manufacturers who submit generic statements like "hardware security was considered" without naming the SoC or its interfaces should expect an additional information request asking for the specifics above.

How Blue Goat Cyber Approaches This

Blue Goat Cyber evaluates SoC-level attack surfaces as part of the same design-controlled security risk management process used for application software. That includes threat modeling each radio, debug interface, and boot stage on the target silicon, reviewing vendor errata and SDK code for known issues, and building an SBOM that extends down to firmware shipped with the chip. Engagements are scoped to the specific SoC and device architecture rather than a generic hardware checklist.

This work feeds directly into premarket submission documentation, so the threat model, SBOM, and test evidence align with what reviewers expect under the February 3, 2026 guidance. For manufacturers preparing a 510(k) or De Novo submission, this is coordinated through our FDA premarket cybersecurity services, which cover threat modeling, SBOM development, and penetration testing scoped to the device's hardware and software architecture.

To keep your SBOM and vulnerability records current after clearance, GoatWatch matches components to new CVEs and tracks VEX decisions.

Frequently Asked Questions

If a device doesn't use its SoC's wireless radios, are they still a risk?

Yes. Many SoCs ship with Bluetooth or Wi-Fi radios embedded on the die whether or not the product uses them. If the radio firmware isn't disabled at the hardware level, it can often still be activated or exploited, so unused radios still need to appear in the threat model and be explicitly disabled or fused off.

Should SoC components be tested separately from application code?

Yes. Fuzzing and penetration testing focused on the BLE stack, TCP/IP stack, and vendor-supplied libraries frequently find issues that application-level testing misses entirely, since those components run at a different privilege level and were written by a different team.

How often should manufacturers check for SoC vulnerabilities?

Manufacturers should monitor vendor security advisories and the NVD on a recurring schedule, not just once during design. Postmarket surveillance plans should specifically name the SoC's firmware components so new CVEs can be matched against the device quickly.

Do purchased SoCs need to appear in the SBOM even though the manufacturer didn't write the firmware?

Yes. Section 524B doesn't distinguish between code the manufacturer wrote and code that shipped with a purchased component. Any firmware, driver, or library that came with the SoC and is capable of being affected by a vulnerability belongs in the SBOM.

CTA

Blue Goat Cyber helps manufacturers scope SoC threat models, SBOMs, and hardware-focused penetration testing before submission. Schedule a discovery session to review your device's silicon-level attack surface before your next FDA filing.