CAN Bus Vulnerabilities in Medical Devices

Most medical-device threat models stop at Ethernet, BLE, and the cloud API. The CAN bus running between the motor drives and the main controller almost never makes it into the architecture diagram - and that's exactly where the most damaging attacks land.

Why this matters

The stakes are critical: unaddressed CAN bus vulnerabilities can lead to unauthorized control over device functions, patient harm, and significant compliance penalties. Many medical device threat models incorrectly stop at network interfaces like Ethernet or BLE, neglecting the internal CAN bus that often controls critical physical actions. The FDA's Cybersecurity in Medical Devices Final Guidance, dated February 3, 2026, explicitly requires manufacturers to address threats to all device components, including internal communication buses, citing them as a potential attack surface. This means that assuming an internal bus is secure by isolation is no longer acceptable. Manufacturers must integrate CAN and CANopen into their cybersecurity architecture views and threat models, per standards like AAMI TIR57 / ANSI/AAMI SW96:2023, and provide penetration test evidence. Failure to do so can result in submission delays, costly redesigns, and impact market entry of essential medical technologies. Proactive identification and mitigation of these vulnerabilities are paramount for patient safety and regulatory approval.

Where CAN and CANopen actually appear in medical devices

CAN (ISO 11898) and its higher-layer protocol CANopen (CiA 301) were inherited from industrial automation because they are cheap, deterministic, electrically resilient, and well-supported by every motor-drive vendor. That same supplier ecosystem is why they keep showing up inside medical devices, including:

• Surgical robotics - joint controllers, motor drives, and end-effector encoders on a CANopen backbone.
• Imaging systems - CT and MRI table positioning, C-arm motion control, gantry rotation feedback.
• Infusion - multi-channel pump manifolds and large-volume pump motor controllers.
• Lab analyzers and IVD instruments - sample handlers, pipettors, rotary carousels, reagent dispensers.
• Renal and dialysis - pump and valve coordination across the fluid path.
• Ancillary equipment - dental chairs, motorized OR tables, sterilizer racks, automated pharmacy dispensers, some legacy ventilators and anesthesia workstations.

If a device has more than one microcontroller moving something physical, there is a non-trivial chance a CAN bus is in the architecture - and a much smaller chance it appears in the threat model.

Why CAN is a soft target

CAN was specified in the 1980s for sealed automotive uses where the bus itself was considered the trust boundary. The protocol reflects that:

• No authentication. Any node on the bus can transmit any arbitrary ID.
• No encryption. Payloads are in the clear; sniffing a bus reveals command and telemetry semantics quickly.
• No replay protection. Captured frames can be re-injected verbatim and accepted as legitimate.
• Broadcast topology. Every node sees every frame; there is no per-link segmentation.
• Priority-based arbitration. A node continuously transmitting low-ID frames can starve higher-ID traffic - a trivial denial-of-service primitive.
• CANopen exposes more. Standardized object dictionary access, heartbeat, NMT state commands, and SDO/PDO mechanisms give an attacker a documented protocol to drive nodes through.

None of this is news to controls engineers. It becomes a medical-device cybersecurity problem the moment the bus is reachable from anything that is not equally trusted.

Realistic attack paths into the bus

The threats reviewers want documented are not "an attacker plugs in a CAN sniffer in the OR." They are the indirect paths that get an adversary to the bus without physical access to a sealed enclosure.

1. Service-port exposure. DB9, M12, or proprietary maintenance connectors behind a panel, often unauthenticated and sometimes documented in the service manual. Field service tools become the attack tool.
2. Compromised gateway IPC. Almost every modern device has an Ethernet- or Wi-Fi-connected controller that bridges to CAN for motion or sensor coordination. Compromise the IPC and you own the bus from the network.
3. Supply-chain motor-drive firmware. A trojanized firmware image on a node ships from the OEM and joins the bus with full privileges.
4. Malicious or replaced node. A consumable, cartridge, or accessory that participates in the CAN protocol can be substituted to inject frames or impersonate a sensor.
5. Wireless-to-CAN pivot. BLE-enabled service or commissioning interfaces that ultimately write to CANopen objects on the backbone.

For each of these, the architecture view must show the bus, the bridging node, and the trust boundary that was crossed.

What goes wrong when these paths are not modeled

The patient-safety consequences cluster into a small number of patterns:

• Spoofed motion commands to a motor drive (gantry, table, robot joint, pump piston).
• Falsified sensor telemetry to the main controller, causing it to make unsafe closed-loop decisions.
• Disabled or bypassed safety supervisors by injecting heartbeat or NMT frames that mask a fault.
• Bus flooding to starve safety-critical periodic messages, triggering watchdog failures or - worse - silent degradation.
• Persistence on a non-updatable node that re-infects the rest of the system after remediation.

These map cleanly to AAMI TIR57 / ANSI/AAMI SW96:2023 security risk and to ISO 14971 hazard analysis. The Feb 3, 2026 premarket guidance expects that mapping to be visible in the submission.

What the FDA expects in the submission

When CAN or CANopen is in scope, reviewers look for the same elements they expect elsewhere, applied to the bus:

• Architecture views that include the bus, every node attached to it, and the trust boundary around the enclosure or service port.
• Threats enumerated against the bus, not just against the network and wireless interfaces.
• Security controls tied to those threats with traceability into the security risk file.
• Pen-test evidence that exercised at least one realistic path to the bus and documented what was attempted, what worked, what was remediated, and what was retested.
• Postmarket plan that explains how a vulnerability in a CAN-connected component would be received, scored, and remediated, including any nodes that cannot be field-updated.

"Internal-only bus" with no further analysis is the answer that earns a deficiency letter.

See also: MQTT Vulnerabilities in Connected, NeuroTech Cybersecurity Risks, and Top 10 Medical Device Vulnerabilities.

Securing a CAN or CANopen medical device?

Blue Goat Cyber is a medical-device-only cybersecurity firm. Our team runs the threat modeling, penetration testing, and FDA-facing documentation MedTech submissions live or die on. → Medical device penetration testing

Controls that actually hold up

There is no single fix; the realistic posture is layered.

• CAN-FD with authenticated frames. AUTOSAR SecOC-style MACs, CANcrypt, or equivalent vendor schemes add per-frame authentication and freshness. Practical to adopt on greenfield designs, harder to retrofit.
• Gateway filtering and policy. The IPC that bridges Ethernet or wireless to CAN should enforce a strict allowlist of IDs and rate limits per direction. Treat the gateway like a firewall, not a pass-through.
• Physical access hardening. Tamper-evident enclosures, locking service connectors, and detection of unauthorized panel access.
• Secure boot and signed firmware on every node, including the small ones. A motor-drive controller running unsigned firmware is the persistence point that survives every other control.
• Bus monitoring. Bus-load thresholds, ID-frequency baselines, and heartbeat-loss alarms feeding the device's safety supervisor.
• Service-tool authentication. Cryptographic challenge-response on the maintenance interface, not a static service code printed in the manual.
• Defense in depth at the closed-loop layer. Sanity checks on commanded vs. measured motion, plausibility limits on sensor telemetry, and independent watchdogs that the bus cannot silence.

The right combination depends on whether you are designing a new device, fielding a 510(k) for an existing platform, or writing a postmarket SBOM/VEX program for a legacy system that cannot be modified.

How we test CAN and CANopen in a pen test

Our methodology mirrors how the realistic attacks unfold:

1. Passive capture. Hardware (CANable, PCAN, Kvaser) on the bus or downstream of the gateway. Build a working DBC by correlating frames with observed device behavior.
2. Protocol mapping. For CANopen, enumerate the object dictionary, NMT states, heartbeats, SDO and PDO mappings. Identify the safety-relevant objects.
3. Replay. Replay captured command frames against the live system and observe state changes.
4. Fuzzing. Targeted fuzzing of motion command payloads, SDO writes, and heartbeat timing.
5. Injection. Author and inject specific malicious frames - motion commands, falsified sensor reports, NMT resets - and document the device's response.
6. Pivot. Exercise at least one realistic path to the bus (service port, compromised IPC simulation, malicious accessory).
7. Detection and recovery. Assess whether the device noticed, what it did, how it logged it, and how it recovered.

The output is a report that an FDA reviewer can read alongside the architecture view and the security risk file, with each finding traced to a threat, a control, and a patient-safety impact.

Where to go from here

If your device has motors, multiple boards, or a service connector behind a panel, the CAN bus is probably in scope whether your current documentation says so or not. Two practical next steps:

• Pull the bus into the threat model before the submission, not after the deficiency letter. Even a one-page architecture annotation closes the most common gap.
• Scope at least one pen-test path to the bus in your testing plan. A wireless-and-cloud-only pen test on a motorized device is the pattern reviewers are calling out most often.

We do this end-to-end - architecture review, threat modeling, hardware and protocol pen testing, and submission-ready documentation. If CAN or CANopen is anywhere in your device, book a strategy session and we will walk through what reviewers expect to see for your specific architecture.

How Blue Goat approaches this

Blue Goat Cyber's approach to CAN and CANopen security starts with integrating these often-overlooked buses into your device's architecture and threat models, aligning with IEC 81001-5-1 requirements. Our team, with backgrounds as CISSP and OSCP certified professionals, including ex-military red team members, identifies realistic attack paths into these internal buses, extending beyond typical network interfaces. We conduct targeted penetration tests to validate these attack vectors and evaluate existing or proposed controls such as CAN-FD with SecOC patterns, gateway filtering, and secure boot for nodes. We provide actionable recommendations that enhance device security and comply with the FDA's February 3, 2026 premarket guidance. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Learn more about our services at https://bluegoatcyber.com/services/medical-device-penetration-testing.

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

Frequently Asked Questions

Are CAN bus and CANopen actually in the FDA's cybersecurity scope?

Yes. The FDA's February 3, 2026 final premarket guidance scopes "all interfaces that can affect device function or safety," not just network interfaces. An internal CAN bus that carries motor commands, pump setpoints, or sensor data is in scope - reviewers expect it modeled in the threat model and exercised in the penetration test, exactly like a wireless interface.

Do I need SecOC or CAN-FD authentication on a Class II device?

Not always - but you do need to justify the choice. If your hazard analysis shows that a forged CAN message can drive an unsafe state, the FDA expects an authenticated bus (CAN-FD with SecOC patterns or equivalent) or a credible compensating control (gateway filtering, segregated safety bus, mechanical interlocks). "We assumed the internal bus was trusted" is the most common deficiency trigger in this space.

What's the most common CAN-related deficiency in FDA cybersecurity letters?

A threat model that stops at the wireless or USB boundary and never enumerates the internal bus. Reviewers respond with a request to extend the model to every node that can write to CAN, plus evidence that spoofed messages were tested. Building the bus into the model up front avoids a 6-12 week AI-letter cycle.

Can secure boot alone protect a CAN-connected device?

No. Secure boot stops a compromised node from booting modified firmware, but it does nothing against a legitimate node that has been compromised at runtime or against a malicious node physically attached to the bus. CAN security needs authentication on the bus itself, not just integrity on the nodes.

How do you pen test a CAN bus without bricking the device?

On a staging unit, not on a clinical device. We use a CAN interface (e.g. PCAN-USB, Kvaser, or an SDR-backed use) to passively capture, then actively inject crafted frames - replay, spoof, fuzz CANopen object dictionary writes, and overload tests. Test results map back to specific hazard entries in the ISO 14971 risk file so safety and security teams act on the same evidence.

• FDA Section 524B cybersecurity requirements explained
• SBOM vulnerability management for medical devices
• VEX document guide for FDA submissions
• FDA deficiency-letter response service
• STRIDE threat modeling for medical devices