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.
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.
Yes - interoperability special controls require explicit threat modeling of each defined boundary and documented mitigations for spoofing and replay.
We exercise pairing modes (passkey, numeric comparison, OOB), verify session-key rotation, and run replay/MITM tests against bonded and unbonded sessions.
We model the controller as a trusted-but-isolated component, test its API surface, and document the assumptions your IFU places on the host phone.
We inject malformed and out-of-range glucose readings into the controller and verify the algorithm's safety bounds, alerting, and fallback dosing behavior.
Yes - our package maps the same artifacts to MDR Annex I §17 and MDCG 2019-16 so you don't redo work for Europe.
Continuous SBOM monitoring on the pump, controller, and CGM stacks; a CVD intake; and a defined process for hot-fixing the mobile controller without breaking the cleared interoperability claim.
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.
