CAN Bus and CANopen 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.

Key Takeaways

• CAN and CANopen sit inside many motorized and multi-node medical devices.
• CAN has no native authentication, encryption, or replay protection.
• "Internal-only bus" is not a sufficient control argument for FDA reviewers.
• Realistic attack paths exist via service ports, gateway IPCs, and supply chain.
• Pen-test evidence and architecture views must explicitly cover the bus.
• Defenses include CAN-FD with SecOC patterns, gateway filtering, and node secure boot.

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 robust, 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 harnesses 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 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.

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.