Cybersecurity for CGMs, insulin pumps, and AID systems.
Automated insulin delivery (AID) systems combine a CGM, an insulin pump, and a control algorithm - often spread across vendors and a smartphone. Each interop boundary is a cyber attack surface where a fault could cause hypo- or hyperglycemia. We secure the full closed loop end-to-end.
Automated insulin delivery (AID) is the most cyber-physical product in MedTech: a CGM, a controller, and a pump exchange dosing decisions over BLE in real time, often through a phone the patient owns. Every interop boundary is a defined attack surface under FDA's iCGM and iAGC special controls.
iCGM, iAGC, and ACE-pump pathways exist precisely because FDA wanted these boundaries explicitly modeled, tested, and documented. Reviewers expect threat models that name each interface, not a generic 'system security' narrative.
Typical clinical uses
Key data flows & integrations
Pump-to-CGM and pump-to-phone BLE links must use authenticated pairing, not Just Works, with rotating session keys.
Sensor spoofing or replay can drive an AID controller to over-deliver or stall insulin.
Companion-app account takeover can expose dosing history and, in some designs, change pump behavior.
CGM and closed-loop AID systems pair a worn sensor with a phone or pump over BLE, plus a cloud sharing back-end. Every layer between sensor and pump matters when an insulin command can be modified, delayed, or replayed.
Layers shown outermost (top) to innermost (bottom). Dashed rows are part of the surrounding system but out of scope for this view.
Diabetes devices have produced some of FDA's most-cited cybersecurity advisories. AID systems compound the risk because a fault at any boundary - sensor, pump, controller, phone, cloud - can drive hypo- or hyperglycemia.
Historical incidents
FDA's 2019 Safety Communication confirmed vulnerabilities in certain Medtronic MiniMed 508 and Paradigm series pumps that could allow a nearby attacker to wirelessly change pump settings or insulin delivery. Medtronic recalled affected models.
FDA Safety Communication, Jun 2019CISA ICSMA-19-178-01
A 2022 advisory disclosed that the wireless protocol used by the MiniMed 600-series pump and its remote controller could be exploited to deliver or block insulin doses if certain conditions were met. Medtronic instructed users to disable the remote-bolus feature pending remediation.
CISA ICSMA-22-263-01FDA Safety Communication, Sep 2022
Researcher disclosure showed the OneTouch Ping pump's wireless link to its meter remote was unencrypted and unauthenticated, allowing nearby attackers to deliver unauthorized insulin doses. J&J issued mitigations and ultimately exited the pump market.
Active threat scenarios
Pairing without authentication exposes link-layer eavesdropping, MITM, and unauthorized control commands - including dosing in some designs.
Out-of-range or fabricated glucose readings injected into the AID loop can drive over- or under-dosing if the controller does not enforce safety bounds and source authentication.
Account takeover on cloud companion accounts exposes dosing history (HIPAA + safety) and, in remote-bolus-enabled designs, can change pump behavior.
Special-controls boundaries between interoperable components are a documented FDA review focus and a frequent threat-model gap.
What FDA reviewers cite
Automated insulin delivery (AID) crosses 3+ devices and a phone in real time - every interop boundary is an attack surface where a fault can cause hypo- or hyperglycemia.
Interoperability special controls require explicit threat modeling of each defined boundary and tested mitigations - not just narrative claims.
Off-the-shelf phones aren't medical devices - your design has to compensate for OS variability, sideloading, and screen-lock bypass.
Adding crypto checks can't push closed-loop control out of clinically acceptable timing windows.
AID recalls disrupt therapy; secure update + staged rollout design is a premarket conversation, not a postmarket scramble.
What FDA scrutinizes
Each iCGM / iAGC / ACE boundary requires explicit threat modeling and tested mitigations - not narrative claims.
Off-the-shelf phones are not medical devices; the design must compensate for OS variability, sideloading, and screen-lock bypass.
Crypto checks cannot push control-loop latency outside clinically acceptable windows - performance evidence must accompany the threat model.
Standards & deliverables
Six deliverables FDA and notified bodies expect across MedTech, with the diabetes / cgm-specific wrinkle on each row. Use it as a scoping checklist before you brief vendors or your QA team.
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.
Yes. Interoperability special controls require explicit threat modeling of each defined boundary (sensor-controller, controller-pump, controller-app, app-cloud) and documented mitigations for spoofing, replay, and tampering at each one. The cyber package has to demonstrate that the cleared interoperability claim survives realistic adversarial conditions, and the SPDF cross-references the special controls so reviewers can trace each requirement to a specific control and test.
We exercise pairing modes (LE Secure Connections passkey, numeric comparison, OOB), verify session-key rotation and bonding storage, and run replay/MITM tests against bonded and unbonded sessions. Downgrade behavior, peer denylisting, and recovery from a lost or stolen peer device are all tested. The threat model documents the chosen pairing mode, the rationale, and the residual risk; the IFU tells the patient what 'good' looks like.
We model the controller as a trusted-but-isolated component with explicit assumptions about the host phone (OS version, lock-screen behavior, sideloading posture), test its API surface against pump and sensor, and document the constraints the IFU places on the patient's environment. Where the controller is third-party, the boundary is documented as an explicit interoperable interface and the cleared claim is exercised under realistic adversarial conditions including stale tokens, replay, and concurrent peer interference.
We inject malformed, out-of-range, and adversarially-crafted glucose readings into the controller and verify the algorithm's safety bounds, alerting, fallback dosing, and IEC 14971-aligned hazard mitigations. The test plan exercises both single-sample and time-series attack patterns because closed-loop algorithms are sensitive to trajectory, not just point values. Findings tie back to specific hazard entries in the risk file so safety and security teams act on the same evidence.
Yes. Our package maps the same artifacts to FDA's 2026 premarket guidance, AAMI SW96, ISO 14971, IEC 62304, MDR Annex I §17.2, and MDCG 2019-16 so you don't redo work for Europe. Notified-body specific deltas (e.g., evidence-of-conformity expectations) are flagged and addressed in the same package, and the postmarket plan satisfies both section §524B and MDR vigilance obligations.
Continuous SBOM monitoring across the pump, controller, sensor stacks, and any companion app; a Coordinated Vulnerability Disclosure intake with severity-based SLAs; a defined process for hot-fixing the mobile controller without breaking the cleared interoperability claim; and explicit handling for sensor and pump firmware updates that respect therapy continuity. The plan is delivered as part of the premarket package so it's ready for clearance.
Crypto and integrity checks added to the closed-loop control path can't push the loop out of the clinically acceptable timing window, so the design has to budget cryptographic overhead from the start. We measure end-to-end timing under realistic conditions, document the budget in the SPDF, and verify that the chosen primitives (e.g., AES-CCM/GCM, hardware-accelerated where available) hold within budget across the supported device variants. Findings that push timing out of budget are escalated as safety-relevant.
Off-the-shelf phones are not medical devices, so the design must compensate for OS variability, sideloading, accessibility-service abuse, and OS-level screen-lock bypass. We document the supported OS versions and platform constraints in the IFU, exercise the highest-impact platform-abuse scenarios in pen testing, and verify root/jailbreak detection, secure storage, and attestation (where available) behave as documented. Where the controller depends on phone-side controls, the residual risk is explicit.
Cloud APIs holding dosing history are tested for BOLA, multi-tenant authorization, scope confusion, JWT claim tampering, soft-delete/undelete tenancy leaks, and rate-limiting/abuse resistance. Encryption at rest and in transit, key custody, audit logging, and region/residency are documented in the SPDF. Findings are tied to specific code paths because in this segment a single authorization gap can expose continuous dosing data for many patients - which is both a HIPAA and a safety event.
Typical baseline: FDA 2026 final premarket cybersecurity guidance, AAMI SW96, AAMI TIR57, IEC 62304 (Class C for AID controllers), ISO 14971, IEC 60601-1 with applicable particulars (e.g., -2-24 for infusion pumps), IEC 81001-5-1 for the secure software lifecycle, OWASP MASVS for the controller app, and Bluetooth SIG profile-specific security requirements. EU manufacturers add MDR Annex I §17.2 and MDCG 2019-16; we map across both regimes.
For a connected AID system with pump, sensor, mobile controller, and cloud, end-to-end premarket cyber work generally runs 10-16 weeks. Threat modeling and SBOM front-load in weeks 1-4, pen testing across pump/sensor/controller/cloud and interoperability boundaries runs in weeks 4-12, and the consolidated submission package and postmarket plan close in the final weeks - all under a written deficiency commitment.
We test mobile apps, BLE pairing, and cloud control paths for closed-loop insulin delivery - and document it for FDA.
"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 CGMs, insulin pumps, and AID systems.
