Cybersecurity for pacemakers, ICDs, CRT-Ds, leadless pacers, ILRs, programmers, and home monitors.
Cardiac Rhythm Management (CRM) devices - pacemakers, ICDs, CRT-Ds, S-ICDs, leadless pacers, and insertable cardiac monitors - carry the longest, most public cybersecurity track record of any medical device class. The St. Jude Medical / Abbott Merlin@home advisories (2017), Medtronic Conexus telemetry (ICSMA-19-080-01, 2019), and Medtronic CareLink 2090 programmer findings (ICSMA-18-128-01, 2018) define how the FDA reviews this segment today. We build premarket and postmarket cybersecurity packages tuned to the implant-to-programmer link, the home-monitor backhaul, and the 10-15 year deployed fleet.
CRM systems are the canonical example of what the FDA's 2026 premarket cybersecurity guidance is written for: long-lived implants (10-15+ years), wireless interrogation links to in-clinic programmers, home-monitor backhaul to manufacturer cloud, and clinician-facing portals that drive patient care decisions. Every layer is in scope under section 524B, and every layer has a public failure history that reviewers cite by name.
We build CRM cyber packages that address those lessons by design - authenticated and integrity-protected telemetry on the implant link, certificate-pinned and tamper-evident home-monitor backhaul, hardened in-clinic programmers with disciplined update paths, and a postmarket plan that can actually field a patch across multiple firmware generations without breaking patient care.
Typical clinical uses
Key data flows & integrations
Inductive, MICS-band, and BLE links between implant and programmer must enforce mutual authentication, session keys, and replay protection - Conexus-class flaws are the canonical reviewer reference.
Cellular and Wi-Fi backhaul from home monitors needs certificate pinning, secure boot, anti-rollback, and tamper-evident telemetry; the fleet-management plane can affect every patient device at once if compromised.
Cryptography chosen today must remain defensible across the implant's deployed lifetime, with explicit algorithm agility, key rotation, and a post-quantum migration plan.
In-clinic programmers are full computing systems on hospital networks - OS hardening, software supply chain, physical port lockdown, and session management are all in scope.
CRM systems span the in-clinic EP lab, the patient's home, and the manufacturer cloud. Every layer has documented public failure history - the implant link (Conexus), the programmer (CareLink 2090), and the home transmitter (Merlin@home) - and reviewers expect all three addressed in the threat model.
Layers shown outermost (top) to innermost (bottom). Dashed rows are part of the surrounding system but out of scope for this view.
CRM is the device class where the public cybersecurity history is most extensive and the FDA reviewer expectations most specific. Threat models that don't address the St. Jude/Abbott, CareLink 2090, and Conexus patterns by name routinely draw deficiency letters.
Historical incidents
The FDA issued a Safety Communication on cybersecurity vulnerabilities affecting St. Jude Medical (Abbott) implantable cardiac devices and the Merlin@home transmitter. Abbott issued firmware updates for the home transmitter and, separately, for the paired implants - the canonical example of a coordinated cyber field action in CRM.
FDA Safety Communication, Jan 9 2017ICS-CERT ICSMA-17-241-01
ICS-CERT advisory ICSMA-18-128-01 disclosed that the CareLink 2090 and Encore 29901 programmers used an unauthenticated software-deployment network for updates, allowing an attacker on the same network to install modified programmer software. Reviewers now treat in-clinic programmers as full networked computing systems on this basis.
ICS-CERT ICSMA-18-128-01FDA Safety Communication, Oct 11 2018
ICS-CERT advisory ICSMA-19-080-01 disclosed that the Conexus wireless telemetry protocol used by a wide range of Medtronic ICDs and CRT-Ds, the MyCareLink monitor, and the CareLink 2090 programmer lacked authentication and encryption (CVE-2019-6538, CVE-2019-6540), allowing an attacker within RF range to read, write, or modify implant data. This is the canonical reviewer reference for implant-link authentication and integrity.
ICS-CERT ICSMA-19-080-01CVE-2019-6538CVE-2019-6540FDA Safety Communication, Mar 21 2019
The October 2019 URGENT/11 disclosure covered eleven vulnerabilities in the VxWorks IPnet TCP/IP stack used in many programmers, bedside monitors, and implantable controllers. The FDA Safety Communication directed manufacturers across implant categories - including CRM - to assess and disclose exposure.
FDA Safety Communication, Oct 1 2019CISA ICSMA-19-274-01
Active threat scenarios
Conexus-class root cause: telemetry that lacks mutual authentication, integrity, and replay protection allows a nearby attacker to read or modify implant data. Modern designs must demonstrate positive evidence of all three properties at the link layer.
CareLink 2090-class root cause: unauthenticated software-deployment networks, exposed maintenance interfaces, or weak physical-port controls let a network-resident attacker install modified programmer software that then talks to implants with full authority.
The fleet-management plane behind home transmitters can affect every paired patient device simultaneously - segmentation, authentication, anti-rollback firmware, and tamper-evident telemetry are the controls reviewers expect to see exercised.
Portal account takeover exposes longitudinal arrhythmia and device telemetry across many patients - BOLA, MFA bypass, and account-recovery flows are tested aggressively.
Implants deployed today must survive 10-15+ years. Without explicit algorithm agility, key rotation, and a post-quantum migration plan, today's crypto becomes tomorrow's deficiency letter.
What FDA reviewers cite
Cardiac Rhythm Management is the device class with the longest documented FDA cybersecurity history - St. Jude/Abbott Merlin@home (2017), Medtronic CareLink 2090 (2018), and Medtronic Conexus telemetry (2019) define how reviewers approach this segment.
Unlike most segments, CRM submissions are reviewed against named public incidents (St. Jude/Abbott 2017, CareLink 2090 2018, Conexus 2019). Threat models that don't explicitly address those patterns draw deficiency letters.
Active CRM fleets span multiple firmware generations; postmarket plans must address all simultaneously without breaking patient care, including generations that can no longer accept secure updates.
Adding remote monitoring, changing crypto, or upgrading the programmer often requires a PMA Supplement - delta documentation that ties cleanly to the IEC 14971 risk file and the original submission is essential.
Academic medical centers demand MDS2, SBOM, and pen test summaries up front - inconsistencies between these and the FDA submission stall sales even after clearance.
Cyber findings here disproportionately drive field actions; premarket documentation of secure update and CVD processes reduces downstream burden.
What FDA scrutinizes
Reviewers explicitly look for Conexus-style root causes: unauthenticated, unencrypted, or replay-vulnerable telemetry. Positive evidence of mutual authentication, session keys, anti-replay, and integrity protection is expected in the SPDF and the pen-test report.
Post CareLink 2090, reviewers expect programmers treated as full networked computing systems - signed updates, hardened OS, locked physical ports, session and audit controls - not as 'accessories' to the implant.
The cellular fleet-management plane is treated as a high-impact, multi-tenant attack surface; the SPDF must show segmentation, authentication, and tamper-evident telemetry between fleet manager and devices.
CRM is the segment where cyber findings most often drive 522 orders and field corrections - reviewers want to see secure-update mechanisms, CVD process, and a per-generation patching strategy documented premarket.
Standards & deliverables
Six deliverables FDA and notified bodies expect across MedTech, with the cardiac rhythm management-specific wrinkle on each row. Use it as a scoping checklist before you brief vendors or your QA team.
| Deliverable | Status | Cadence | Standard / guidance | Cardiac Rhythm Management 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 | Itemize all third-party components and produce VEX entries for every CVE that touches them. |
| 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 | Continuous CVE monitoring tied to the SBOM, with a documented triage and customer-comms path. |
| 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 | Test the device, its wireless interfaces, companion apps, and cloud back-ends as a single system. |
| 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 | STRIDE-per-interface threat model, refreshed on every material design change. |
| 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 | Signed updates with rollback protection and a staged-rollout plan are non-negotiable premarket. |
| 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) | Public CVD policy and intake channel with documented SLAs for triage and fix. |
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.
CRM is the implantable-rhythm subset - pacemakers, ICDs, CRT-Ds, S-ICDs, leadless pacers, and ILRs - with their programmers and home-monitoring chain. It shares the long-fleet, implant-link, and home-monitor concerns of broader cardiovascular but adds two distinctive things: the documented public failure history that the FDA explicitly references (St. Jude/Abbott Merlin@home, Medtronic Conexus, CareLink 2090), and the rhythm-specific essential performance under IEC 60601-2-31 and ISO 14708-2/6. Reviewers expect a CRM submission to address those lessons in the threat model and the postmarket plan, not just generic cardiovascular controls.
We characterize the protocol with SDR (for MICS-band and proprietary RF) and BLE-aware tooling (for newer programmers), then exercise mutual authentication, session establishment, replay, downgrade, pairing-mode abuse, and parameter-write authorization on staging hardware - never on a clinical system. The Conexus disclosure (ICSMA-19-080-01) is the canonical pattern: unauthenticated and unencrypted telemetry was the root cause, so we explicitly test for those properties and document positive evidence of authentication and integrity for the submission.
Yes. Home transmitters are scoped as connected system components with their own threat model, OS hardening review, software-supply-chain analysis, and pen test. Cellular and Wi-Fi configuration, certificate validation and pinning, secure boot, anti-rollback, tamper-evident telemetry, and the cloud APIs they call are all tested. The cellular fleet-management layer gets dedicated attention because compromise there can affect every patient device simultaneously - the Abbott Merlin@home advisory is the reference reviewers cite.
The design includes explicit crypto agility: algorithm identifiers in protocol headers, key rotation procedures, primitive deprecation paths, and a documented post-quantum migration plan. The SPDF and the postmarket plan describe how a primitive becomes obsolete and how the deployed fleet is migrated without loss of therapy continuity. For battery-constrained implants we document the energy budget for each cryptographic primitive so reviewers can see the agility plan is physically realistic.
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 - exactly what PMA Supplement reviewers look for in cyber-only changes.
Active CRM fleets typically span multiple firmware generations and pairings. The postmarket plan documents 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 so the FDA reviewers and hospital procurement see the same story.
We 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 CRM products stall in procurement at academic medical centers - and they're easy to avoid when the artifacts are produced together rather than reverse-engineered later.
The CareLink 2090 advisory (ICSMA-18-128-01) is the canonical reviewer reference for programmer trust: unauthenticated update paths, exposed maintenance interfaces, and weak physical-port controls. We test programmers as full computing systems: OS hardening, software supply chain, lock-screen behavior, session timeouts, USB/serial service ports, audit logging, and update integrity. The IFU and labeling document the operational assumptions the clinic is expected to enforce, and the SPDF makes the residual risk explicit.
CRM is the segment where cyber findings most often drive 522 orders and field corrections - the Abbott firmware update for Merlin@home-paired implants is the public example. We document the secure-update mechanism (signed payloads, anti-rollback, atomic install, staged rollout, rollback-safe) and the CVD process that triggers field updates premarket, so that when a finding lands, the field-action path is already designed and documented rather than improvised.
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 IEC 60601-2-31 for external pacemaker pulse generators, IEC 81001-5-1 for the secure software lifecycle, and the ISO 14708 series (notably 14708-2 for cardiac pacemakers and 14708-6 for tachyarrhythmia devices). EU manufacturers add MDR Annex I §17.2 and MDCG 2019-16; we map artifacts across both regimes.
Yes. Long-lived CRM implants are exactly the use case section 524B and the 2026 guidance are written for. We deliver the CVD policy, public intake (e.g., security.txt, vendor portal), acknowledgment and remediation SLAs, severity-based triage, and the QMS process from CVE through controlled software change as part of the premarket package. Continuous SBOM monitoring runs against implant firmware, programmer, and home-monitor components.
For a new connected CRM platform with implant, in-clinic programmer, home-monitor, and patient/clinician portal, end-to-end premarket cyber work generally runs 14-20 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-16, and the consolidated submission package and postmarket plan close in the final weeks - all under a written clearance guarantee.
30-minute discovery call - fixed-fee proposal within 24-hours, no surprises.
"Blue Goat Cyber's depth of expertise was impressive. We had no in-house cybersecurity experience, and their team guided us through every step of the FDA process. The penetration testing and SBOM testing were thorough and gave us complete confidence."
Cybersecurity for pacemakers, ICDs, CRT-Ds, leadless pacers, ILRs, programmers, and home monitors.
