Threat Modeling for Cardiac Rhythm Management Devices
STRIDE-per-interface threat models for pacemakers, ICDs, CRT-Ds, ILRs, programmers, and home monitors - tied to IEC 14971 and the named CRM public incidents reviewers cite.
Last reviewed March 2026 · Reviewed against the FDA Feb 3, 2026 final premarket cybersecurity guidance.
A CRM threat model has a fixed minimum bar: it must enumerate the implant link, the in-clinic programmer, the home-monitor backhaul, the cellular fleet-management plane, the clinician portal, and any patient-facing app as a single connected system - and it must explicitly address the public incident patterns the FDA references when reviewing this segment (St. Jude/Abbott Merlin@home, CareLink 2090, Conexus, URGENT/11). We build CRM threat models that meet that bar, traced to the IEC 14971 risk file so safety and security teams operate on the same evidence, and structured so that PMA Supplements for cyber-only changes (added remote monitoring, crypto upgrades, new programmer revisions) require a clean delta rather than a rewrite.
For each interface we apply STRIDE with CRM-specific decomposition: implant ↔ programmer (inductive / MICS / BLE), implant ↔ home-monitor (MICS / BLE / proprietary RF), home-monitor ↔ cloud (cellular / Wi-Fi), programmer ↔ manufacturer back-office, cloud ↔ clinician portal, cloud ↔ EHR (HL7v2 / FHIR), and patient app ↔ cloud. Trust boundaries, authentication assumptions, session lifetimes, key custody, replay windows, and downgrade paths are all explicit. We document the long-fleet crypto-agility plan - algorithm identifiers in protocol headers, primitive deprecation paths, post-quantum migration timeline - because reviewers expect to see a CRM implant survive 10-15+ years of crypto evolution. Residual risk is documented with explicit acceptance, and each control links back to the postmarket plan so that field updates and CVD response are traceable from threat to action.
Medical Device Threat Modeling engagement, end to end
Four phases, fixed fee, scoped to cardiac rhythm management architecture from kickoff onward.
-
01
Architecture intake
Data-flow diagrams, trust boundaries, and asset inventory captured directly from your design team.
-
02
STRIDE workshop
Joint working sessions to enumerate threats per element, mapped to Section 524B(b) and AAMI SW96.
-
03
Risk + mitigation pass
Each threat gets a residual-risk rating, mitigation, and a link to the verification activity that proves it.
-
04
Reviewer-ready package
Threat model document and SPDF section ready to drop straight into eSTAR cybersecurity attachments.
What we see in Cardiac Rhythm Management medical device threat modeling
The patterns we hit in this segment, this service, again and again.
-
Implant link modeled as 'trusted accessory channel'
Common in legacy threat models. Reviewers reject it on sight post-Conexus - the implant link is a primary attack surface with full read/write authority.
-
Programmer modeled as 'medical device' not 'networked computer'
Hides the entire CareLink 2090 attack class. Programmer needs full computing-system threat modeling: OS, supply chain, update path, physical ports, session and audit controls.
-
Cellular fleet-management plane absent from the model
Single highest-blast-radius surface in CRM, frequently missing entirely. Must be enumerated with explicit authentication, segmentation, and anti-rollback controls.
-
No documented crypto-agility plan over 10-15 year lifetime
Reviewers expect algorithm identifiers in protocol headers, key rotation procedures, and a post-quantum migration plan tied to the postmarket plan.
-
Fleet-heterogeneity assumption missing
Model assumes a single firmware version; real fleets span multiple generations and pairings. Compensating controls for un-patchable generations must be documented.
"Blue Goat's knowledge of regulatory requirements versus cybersecurity challenges was highly valuable and readily apparent as we were guided by and worked alongside their team towards the development of a comprehensive and compliant cybersecurity plan for our new medical device. Especially helpful for our company as we are a startup. Their team and competencies nicely filled our resource needs. Thank you Blue Goat!"
Standard Medical Device Threat Modeling deliverables
The same deliverables the parent Medical Device Threat Modeling service ships with - tuned to your cardiac rhythm management architecture.
- ANSI/AAMI SW96 + ISO 14971 alignment
- End-to-end medical device system coverage
- Threat-to-mitigation traceability
- Justified methodology and assumptions
What lands in your eSTAR submission
Reviewer-format documents ready to drop straight into the cybersecurity attachments of your submission - no reformatting on your side.
- ANSI/AAMI SW96 + ISO 14971 alignment
- End-to-end medical device system coverage
- Threat-to-mitigation traceability
- Justified methodology and assumptions
Standards that apply
The Cardiac Rhythm Management baseline, plus the call-outs that matter for medical device threat modeling in this segment.
Segment-specific call-outs
AAMI TIR57 + AAMI SW96
Threat model entries trace 1:1 to IEC 14971 hazards and SW96 controls. The same evidence supports SPDF, IFU, and MDS2.
ISO 14708-2 / 14708-6
Threats that affect pacing, defibrillation, or CRT delivery are analyzed against the essential performance requirements for active cardiac implants.
What's not in scope
We scope tightly on purpose. These items are either out-of-scope by design or belong in a separate engagement - we'll tell you up front, not after kickoff.
- Penetration testing execution (scoped separately)
- Clinical risk analysis under ISO 14971 (we feed it, we do not own it)
- Hospital network architecture review
Go deeper on Cardiac Rhythm Management and premarket
A practical, ungated guide to the threat modeling gaps that trigger FDA cybersecurity questions in 510(k), De Novo, and PMA submissions - and exactly how to close them before reviewers find them.
What CR34971 adds on top of ISO 14971, the AI-specific risk categories it covers, and how to integrate it with your existing risk file.
Compare AAMI TIR57 vs TIR97. Learn how these cybersecurity risk management standards differ and how to apply them for FDA premarket and postmarket compliance.
The threat intelligence sources medical device manufacturers should monitor to satisfy FDA Section 524B postmarket obligations: H-ISAC, CISA KEV, ICS advisories, NVD, MITRE ATT&CK for ICS, and vendor PSIRTs.
FMEA covers random and systematic failure modes; threat modeling covers adversarial action. Both are required for a 524B submission, and they do not substitute for each other. Here is how to scope them, link them, and avoid the gap.
What the CISA Known Exploited Vulnerabilities (KEV) catalog is, how medical device manufacturers should use it in SBOM/VEX triage, and how the FDA treats KEV-listed CVEs.
Other engagements for Cardiac Rhythm Management
Teams in this segment commonly bundle these alongside medical device threat modeling.
Keep going
Scope a Medical Device Threat Modeling engagement for your cardiac rhythm management program.
A 30-minute call with a senior engineer who has done this in cardiac rhythm management before - not a sales rep.