Cybersecurity for pacemakers, ICDs, CIEDs, and cardiac monitoring.
Cardiac implantable electronic devices (CIEDs) and remote monitoring platforms have a long history of high-profile cybersecurity recalls. We help cardiovascular manufacturers harden device-to-programmer, device-to-home-monitor, and home-monitor-to-cloud paths against the threats FDA reviewers now expect to see modeled.
Cardiac implantable electronic devices (CIEDs) carry the longest documented history of FDA cybersecurity advisories, 522 orders, and recalls. Reviewers, hospital procurement, and class-action attorneys all expect detailed, traceable evidence that lessons from past recalls are designed in.
A typical CIED ecosystem spans the implant, an in-clinic programmer, a home-monitor transmitter, a cellular or Wi-Fi backhaul, and a cloud follow-up portal feeding the EHR. Each link has been the entry point for at least one publicized vulnerability.
Typical clinical uses
Key data flows & integrations
Inductive and RF interfaces to in-clinic programmers must enforce mutual authentication, session keys, and anti-replay.
Cellular and Wi-Fi backhaul from home monitors needs certificate pinning, secure boot, and tamper-evident telemetry.
10+ year device lifetimes demand a postmarket vulnerability management plan and SBOM monitoring.
Cardiac implantable electronic devices have the longest documented FDA cybersecurity history of any device class. Reviewers expect detailed evidence that lessons from past advisories are designed in - not just referenced.
Historical incidents
FDA's 2017 Safety Communication confirmed exploitable vulnerabilities in the Merlin@home home-monitoring transmitter that could have allowed unauthorized access to a paired implanted cardiac device. A firmware update was required across the deployed fleet.
FDA Safety Communication, Jan 2017FDA Safety Communication, Aug 2017
Researchers disclosed that the proprietary Conexus radio-frequency telemetry protocol used by certain Medtronic implantable cardiac devices, programmers, and home monitors lacked authentication and encryption, allowing nearby attackers to read or modify therapy.
CISA ICSMA-19-080-01CVE-2019-6538CVE-2019-6540
A 2018 advisory disclosed that the CareLink 2090 programmer's software-deployment network could be abused to install unauthorized changes. Medtronic disabled the affected update path while remediation was developed.
CISA ICSMA-18-058-01
Active threat scenarios
Without mutual authentication and rolling session keys, a previously captured programming session can be replayed, including therapy parameter writes.
Cellular or Wi-Fi backhaul without certificate pinning and secure boot enables MITM against telemetry and configuration-fetch traffic.
Patient and clinician portal account takeover exposes longitudinal device telemetry and, in some designs, scheduling of remote interrogations.
Field updates to 10+ year fleets without staged rollout, signature verification, and rollback protection are a recall-risk pattern reviewers cite directly.
What FDA reviewers cite
Cardiac implantable electronic devices (CIEDs) carry the longest documented history of FDA cybersecurity recalls and 522 orders - reviewers expect detailed evidence of the lessons learned.
Active fleets span multiple firmware generations and pairings; postmarket plans must address all simultaneously without breaking patient care.
Adding remote monitoring or changing crypto often requires a PMA Supplement - we structure delta documentation reviewers can approve quickly.
Health systems demand MDS2, SBOM, and pen test summaries up front - inconsistencies between these and the FDA submission stall sales.
Cyber findings sometimes drive 522/recall decisions. Premarket-time documentation of secure update mechanisms reduces that downstream burden.
What FDA scrutinizes
Cyber-only changes (remote monitoring add, crypto refresh) often require a Supplement; documentation must trace deltas back to the original PMA risk file.
Hospital procurement compares MDS2, SBOM, pen test summary, and IFU. Inconsistencies stall both clearance and sales.
A documented secure-update mechanism is the difference between a software patch and a 522 order.
Standards & deliverables
Six deliverables FDA and notified bodies expect across MedTech, with the cardiovascular-specific wrinkle on each row. Use it as a scoping checklist before you brief vendors or your QA team.
| Deliverable | Status | Cadence | Standard / guidance | Cardiovascular note |
|---|---|---|---|---|
| SBOM + VEX Machine-readable SBOM (CycloneDX/SPDX) plus VEX feed for every CVE that touches a listed component. |
Required | Premarket + monthly refresh | FDA Cybersecurity Guidance §V · CISA SBOM minimum elements | SBOM must reconcile with MDS2 - hospital security review is the most common stall point for CIED sales. |
| Postmarket monitoring Continuous CVE / advisory monitoring against the SBOM, with a documented triage and disclosure path. |
Required | Continuous (≤30-day triage) | FD&C Act §524B · FDA Postmarket Cybersecurity Guidance | Long-tail fleets across multiple firmware generations require automated CVE-to-fleet mapping. |
| Penetration test scope Black/grey-box testing across device, wireless interfaces, mobile apps, cloud APIs, and service tooling. |
Required | Premarket + on material change | AAMI TIR57 · FDA Premarket Cyber Guidance §VI.A.5 | Programmer ↔ implant inductive/RF link plus home-monitor cellular backhaul are both in scope. |
| Threat model STRIDE-per-interface threat model with documented mitigations and residual-risk acceptance. |
Required | Premarket, refreshed each design change | AAMI TIR57 · FDA Premarket Cyber Guidance §V.A | Model the home-monitor and patient portal as untrusted edges, not extensions of your manufacturing network. |
| Secure update mechanism Signed firmware/software updates with rollback protection, integrity verification, and staged rollout. |
Required | Designed premarket, exercised lifecycle-long | FDA Cyber Guidance §IV · IEC 81001-5-1 | Cyber-only changes typically trigger a PMA Supplement - design the update path for that pathway up front. |
| Coordinated Vulnerability Disclosure Public CVD policy, intake channel, and SLAs for triage, fix, and customer communication. |
Required | Continuous, lifecycle-long | ISO/IEC 29147 + 30111 · Section 524B(b)(2) | 522 / recall history makes a mature CVD program a procurement differentiator, not just a compliance item. |
Machine-readable SBOM (CycloneDX/SPDX) plus VEX feed for every CVE that touches a listed component.
Continuous CVE / advisory monitoring against the SBOM, with a documented triage and disclosure path.
Black/grey-box testing across device, wireless interfaces, mobile apps, cloud APIs, and service tooling.
STRIDE-per-interface threat model with documented mitigations and residual-risk acceptance.
Signed firmware/software updates with rollback protection, integrity verification, and staged rollout.
Public CVD policy, intake channel, and SLAs for triage, fix, and customer communication.
We pair premarket work with a postmarket cybersecurity management plan under section 524B: continuous SBOM monitoring across implant firmware, programmer, and home-monitor; a Coordinated Vulnerability Disclosure (CVD) program; severity-based remediation SLAs; and a 10-15 year crypto-agility plan covering key rotation, primitive deprecation, and post-quantum migration. Cardiac is the segment with the longest documented FDA cyber-recall history, and reviewers expect to see lessons learned reflected explicitly.
Yes. Programmers are scoped as connected system components with their own threat model, OS hardening review, software-supply-chain analysis, and pen test. The inductive and RF link to the implant is exercised for mutual authentication, replay, downgrade, and stimulation/parameter authorization. Findings on the programmer are tied back to the implant threat model so the system view stays coherent and reviewable.
Home transmitters are tested for cellular and Wi-Fi configuration, certificate validation and pinning, secure boot, anti-rollback, and tamper-evident telemetry, plus the cloud APIs they call. The cellular fleet-management layer gets dedicated attention because compromise there can affect every patient device simultaneously. The threat model treats the carrier and the home network as explicit untrusted-but-contractually-bound parties.
Yes. We deliver a focused delta threat model, an updated SBOM with VEX, and an incremental test report scoped to the new path so reviewers can see the change clearly. The package cross-references the previously approved submission and the IEC 14971 risk file so the delta is unambiguous - which is exactly what PMA Supplement reviewers look for in cyber-only changes.
We help you produce an MDS2 that's consistent with your SPDF, labeling, and pen-test summary so hospital security reviews don't contradict your FDA submission. Inconsistencies between MDS2, SBOM, and the FDA package are one of the most common reasons cardiac products stall in procurement, and they're easy to avoid when the artifacts are produced together rather than reverse-engineered later.
We document the secure-update mechanism (signed payloads, anti-rollback, atomic install, staged rollout, rollback-safe) and the CVD process that triggers field updates - both expected by FDA reviewers and both relevant to 522 / recall calculus. Premarket-time documentation of secure update mechanisms reduces the downstream burden when a finding lands and forces a coordinated field action.
Active cardiac fleets typically span multiple firmware generations and pairings, so the postmarket plan addresses all simultaneously without breaking patient care. We document the supported configuration matrix, the patching strategy per generation, and the EOL/EOS communications plan, and we verify that compensating controls hold for older generations that can no longer accept secure updates. The matrix lives in the postmarket plan and is referenced by the SPDF.
Patient portals are tested for credential stuffing, MFA enforcement and bypass, session management, BOLA, multi-tenant authorization, and abuse paths against bulk-export and search APIs. Account-recovery flows get particular attention because they're a common takeover vector and a high-impact one in cardiac (telemetry exposure plus identity). Findings are tied to specific code paths and to the threat-model entries that should have prevented them.
Unattended programmers in clinics are an explicit threat-model entry: physical access, USB/serial service ports, lock-screen behavior, session timeouts, and audit logging are all reviewed and tested. The IFU and labeling document the operational assumptions the clinic is expected to enforce, and the SPDF makes the residual risk explicit so the institution understands the boundary between device and environment.
Typical baseline: FDA 2026 final premarket cybersecurity guidance, AAMI SW96, AAMI TIR57, IEC 62304 (Class C for active implantables), ISO 14971, IEC 60601-1 with applicable particulars (e.g., -2-31 for external pacemaker pulse generators), IEC 81001-5-1 for the secure software lifecycle, and ISO 14708 series for active implantables. EU manufacturers add MDR Annex I §17.2 and MDCG 2019-16; we map across both regimes.
For a new connected CIED platform with programmer, home-monitor, and patient portal, end-to-end premarket cyber work generally runs 12-18 weeks. Threat modeling and SBOM front-load in weeks 1-5, pen testing across implant link, programmer, home-monitor, cloud, and portal runs in weeks 5-14, and the consolidated submission package and postmarket plan close in the final weeks - all under a written clearance guarantee.
Threat models, SBOMs, and pen testing tuned to BLE/proprietary RF and clinician programmers - built for 510(k) and PMA.
"The timeliness of this project exceeded my expectations - this was not my experience with other vendors. Blue Goat Cyber delivered a thorough, detailed report and complete testing faster than I anticipated, without compromising quality."
Cybersecurity for pacemakers, ICDs, CIEDs, and cardiac monitoring.
