Wearable health AI adversarial injection: why the Apple Watch ECG is the highest-volume FDA-cleared attack surface

1. The scale problem: FDA-cleared wearable AI by the numbers

The wearable health AI landscape is unusual in that the highest-volume deployments are consumer devices that have achieved FDA clearance for diagnostic functions — a combination that concentrates both the attack surface and the clinical consequence at unprecedented scale.

Apple Watch ECG: 100M+ FDA-cleared classifiers in the wild

Apple Watch Series 4, cleared by FDA in September 2018 under 510(k) K192729, was the first direct-to-consumer ECG device to receive FDA clearance for AFib detection. Subsequent clearances (K223274 for Series 7/8/9/Ultra) extended the capability across newer hardware generations. Apple does not disclose Watch sales by individual model, but IDC estimates total installed base at approximately 100 million active Apple Watches globally as of 2025, the majority of which are ECG-capable Series 4 or later.

Each of those 100 million devices runs a deep neural network classifier on each 30-second ECG recording. The classifier's output — AFib, Normal Sinus Rhythm, Elevated Heart Rate, Low Heart Rate, or Inconclusive — is stored in Apple HealthKit, surfaced to the user as a notification, and explicitly recommended by Apple to be shared with a physician for follow-up. In practice, this creates a direct path from a wearable AI classification to a clinical consultation, an ECG referral, and in AFib-positive cases, to anticoagulation therapy decisions. Warfarin, rivaroxaban, and apixaban — the anticoagulants commonly prescribed following an AFib diagnosis — carry significant bleeding risk. The clinical decision chain that begins at the Apple Watch ECG classifier ends, in a non-trivial percentage of cases, at a prescription for a drug that can cause fatal haemorrhage if incorrectly prescribed.

Dexcom G7: 2 million+ users in automated closed-loop systems

Dexcom's G7 CGM system (FDA K230300) is the market-leading continuous glucose monitor. In the US, approximately 8 million people use CGM devices; Dexcom holds approximately 50% market share. A significant and growing fraction of those users run the G7 in a closed-loop configuration — paired with the Tandem t:slim X2 running Control-IQ software, or with Insulet's Omnipod 5. In a closed-loop system, the CGM reading is transmitted via Bluetooth LE to the pump controller, where an AI dosing algorithm adjusts basal insulin delivery rates and delivers correction boluses without requiring user confirmation for every adjustment.

This is not advisory AI — it is actuating AI. The classifier output triggers a physical pharmacological intervention. The adversarial consequence of a successful injection into the CGM-to-pump data channel is not an incorrect recommendation that a human can discard; it is an insulin delivery event that executes automatically. The FDA has acknowledged this risk class in its post-market surveillance guidance for automated insulin delivery systems and has required specific cybersecurity controls in submissions for closed-loop systems since 2019.

iRhythm Zio, Apple Watch irregular rhythm, and the long-duration ECG class

Beyond spot-check ECG, the wearable health AI landscape includes long-duration continuous monitoring: iRhythm's Zio XT patch (FDA-cleared, 27 million patient-days of data as of 2023) records a 14-day continuous single-lead ECG and processes the resulting time-series through an AI arrhythmia classifier that generates a clinical report reviewed by an electrophysiologist. Abbott's FreeStyle Libre 3 CGM adds factory-calibrated continuous glucose monitoring. Samsung Galaxy Watch ECG and Fitbit Sense ECG extend the consumer AFib detection class across additional platforms. The wearable health monitoring AI security page documents the full device and vendor landscape; the point here is that the combined deployment scale — across Apple Watch, iRhythm, Dexcom, Abbott, Samsung, and Fitbit — means that wearable health AI classifiers are making clinical-consequence decisions for tens of millions of patients every day, processing sensor inputs that no deployed PI scanner currently touches.

2. The ECG classification pipeline: where text-only scanners fail

Understanding why text-only scanners cannot protect wearable health AI requires understanding what the actual input pipeline looks like. The Apple Watch ECG flow is representative.

From electrode to inference: the waveform pipeline

When a user initiates an ECG recording, the Watch's optical ECG electrode (in the Digital Crown) and the case-back electrode complete a Lead I configuration across the user's chest. The electrode captures an analogue voltage signal at 512 Hz, which the Watch's signal processing pipeline filters, downsamples, and normalises into a time-series array — 512 samples per second × 30 seconds = approximately 15,360 sample points per recording. This array is the direct input to the classifier neural network. The network's output is a categorical prediction with associated confidence scores.

The data then moves to HealthKit storage on-device, syncs to iCloud Health encrypted backup, and becomes readable by any HealthKit-entitlement app the user has authorised. Third-party apps — cardiac monitoring apps, digital health platforms, EHR integration apps, telehealth services — can read these HealthKit ECG samples and feed them into their own secondary classifiers, display logic, or clinical decision support systems.

At no point in this pipeline does text appear as the primary attack surface. The adversarial payload, if any, is in the voltage time-series — a sequence of floating-point numbers that represent electrode voltage over time. A text-only prompt injection scanner positioned at any layer of this pipeline is scanning a channel that carries no attack-relevant content. It will always return a clean verdict, regardless of whether the ECG waveform has been adversarially manipulated. This is the same channel mismatch problem documented for image-layer attacks in why text scanners miss image prompt injection — applied to a 1D time-series rather than a 2D pixel grid.

The HealthKit write vulnerability

HealthKit's data model allows any app with the com.apple.developer.healthkit.background-delivery entitlement and user-granted write permissions to write new health data samples to the store — including ECG samples, glucose readings, and heart rate data. This design enables legitimate integration (a hospital app writing in-clinic ECG data to the Health app for continuity of care) but also creates a write injection vector: a rogue or compromised HealthKit-entitlement app can write adversarially crafted ECG samples that appear as device-captured recordings to downstream classifier apps.

The distinction matters because it separates the attack into two classes: hardware-layer injection (modifying the raw electrode signal before it reaches the classifier, requiring physical access or electromagnetic interference) and software-layer injection (writing adversarial data into the HealthKit store, requiring only a malicious or compromised app with write entitlement). Software-layer injection is considerably more scalable — a single compromised app, distributed via the App Store or sideloaded, can inject adversarial ECG samples across millions of devices. This is the equivalent of a prompt injection attack against a text-based AI system, translated to the waveform domain: instead of injecting malicious text into a prompt, the attacker injects malicious waveform data into the sensor data store that the AI reads from.

The telehealth and remote patient monitoring AI security page covers the broader ecosystem of digital health data injection vulnerabilities, including the FHIR API injection surface, the patient-generated health data pipeline, and the regulatory framing under ONC and CMS interoperability rules.

3. The closed-loop problem: automated insulin delivery as automated harm

The Dexcom G7 closed-loop configuration represents a qualitatively different risk class from advisory AI: it is an AI system whose output drives an autonomous physical intervention without requiring human confirmation for each action. This is the same architectural pattern that makes agentic AI multimodal prompt injection more dangerous than single-turn chat model injection — an agent that acts on a bad input causes real-world consequences; a chat model that responds to a bad input produces a bad text response. In closed-loop insulin delivery, the agent is the pump controller, the tool it calls is the insulin delivery mechanism, and a successful adversarial injection of the CGM reading is a direct pharmacological attack.

The Bluetooth LE channel: known vulnerabilities, known stakes

Dexcom G7 transmits glucose readings to the paired receiver or smartphone over Bluetooth LE every five minutes. The G7's Bluetooth LE implementation uses authenticated pairing, but the data payload format is documented in Dexcom's open developer SDK and has been studied extensively by the open-source CGM community (Nightscout, xDrip+, Loop). Academic research published at USENIX Security (2019) and IEEE S&P (2021) demonstrated that legacy CGM Bluetooth LE implementations could be manipulated to inject false glucose readings to paired receivers. While Dexcom has improved authentication in G6 and G7 relative to earlier models, the fundamental architecture — a low-power wireless channel carrying clinical sensor readings with constrained cryptographic capability — remains an attack surface that the FDA has required manufacturers to address in their premarket cybersecurity submissions since the 2023 guidance update.

The consequence of a successful CGM reading injection in a closed-loop system is not an incorrect dashboard display: it is the Control-IQ or Omnipod 5 algorithm receiving the injected value as ground truth and computing insulin delivery accordingly. If the injected reading is 280 mg/dL (hyperglycaemic) when the patient's actual glucose is 90 mg/dL (low-normal), the algorithm delivers a correction bolus appropriate to the injected value. Insulin delivery at a bolus sized for 280 mg/dL when the patient is actually at 90 mg/dL will produce blood glucose below 54 mg/dL within approximately 30–45 minutes — clinically significant hypoglycaemia with loss of consciousness risk. This is not a theoretical chain of consequences; it is the pharmacokinetic consequence of the documented attack, at the doses and time scales that closed-loop systems operate at.

Why this is an AI security problem, not just a device security problem

The framing of closed-loop CGM attacks as "medical device hacking" rather than "AI security" is technically accurate but strategically unhelpful for the teams who need to defend against it. The attack is AI security because the vulnerable layer is the AI inference pipeline: the adversarial input (injected CGM reading) produces a misclassification (hyperglycaemic state when the patient is euglycaemic) that drives an automated action (insulin bolus). Removing the AI from this description — treating it as a pure sensor spoofing attack — misframes the defence requirement. The control that defends against this attack is not just encryption of the Bluetooth LE channel (though that is necessary); it is input validation at the AI inference boundary — checking whether the incoming sensor reading is plausible given physiological constraints before passing it to the dosing algorithm. That is the multimodal scanning function applied to a 1D time-series input.

The wearable health monitoring AI security page documents the specific attack patterns — CGM dosing injection at threshold 50, ECG misclassification injection, PPG SpO2 spoofing injection — with Python implementation patterns for the validation gate at each inference boundary. The point here is the architectural argument: wearable health AI closed-loop systems require the same defence philosophy as agentic AI systems that take real-world actions — validate inputs at the AI boundary before any action executes, not after.

4. The regulatory stakes: FDA SaMD, HIPAA, and the digital health legal landscape

Unlike most sectors where AI security compliance is a recommended practice, wearable health AI operates under binding regulatory obligations that explicitly require documented security controls — and the 2023 FDA medical device cybersecurity guidance has tightened the standard precisely for AI/ML-based SaMD.

FDA's 2023 medical device cybersecurity guidance: what changed for AI

The FDA's 2023 final guidance "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" replaced the 2014 guidance and added specific requirements for AI/ML-based devices. Key changes relevant to wearable health AI:

Predetermined Change Control Plans (PCCPs): AI/ML devices that update their model post-clearance must submit a PCCP documenting the types of changes, the performance boundaries within which changes are acceptable, and the monitoring approach. A device that has a PCCP but lacks adversarial input monitoring has an incomplete monitoring framework under the guidance — the PCCP must document how the manufacturer will detect when the model's behaviour deviates from expected performance, and adversarial manipulation is an explicit failure mode category.

Threat modelling for AI input manipulation: The 2023 guidance explicitly adds "manipulation of AI/ML model inputs" as a threat category that must be addressed in the cybersecurity risk assessment. For an ECG classifier, this means the premarket submission must document what prevents an adversary from injecting malicious waveform data, and the documented control must actually operate on waveform inputs. A text-based input validation control cited against a waveform injection threat is a control mismatch that creates a Finding during FDA review.

Post-market monitoring requirements: The guidance requires manufacturers to monitor for known vulnerabilities in their cybersecurity bill of materials (CBOM) and to have a coordinated vulnerability disclosure (CVD) process. For AI components, post-market monitoring includes monitoring for adversarial attack publications targeting the specific model architecture used. An Apple Watch ECG manufacturer must monitor for published adversarial attacks against 1D CNN or ResNet-based ECG classifiers and have a process for assessing whether published attacks affect the cleared device.

HIPAA and PHI in the HealthKit pipeline

HealthKit data that moves off-device to a covered entity or business associate becomes protected health information (PHI) under HIPAA. ECG recordings, glucose readings, heart rate data, and blood oxygen measurements are health information when associated with an identifiable individual — which HealthKit data always is, by design. A third-party digital health app that reads HealthKit ECG data, processes it through a secondary classifier, and transmits the result to a clinical review service is a business associate handling PHI, subject to HIPAA Security Rule requirements under 45 CFR §164.312(b) (audit controls) and §164.312(e)(1) (transmission security).

An adversarial injection into the HealthKit-to-classifier pipeline that produces a false clinical result is not just a security incident; it is a potential HIPAA breach if the false result is transmitted to a covered entity as if it were a legitimate clinical finding. The audit trail requirements under §164.312(b) require that the covered entity be able to reconstruct what happened — but if the injection occurs at the sensor data layer before the PHI boundary, the covered entity's audit trail begins with the already-corrupted data. The scan gate at the HealthKit query boundary is also the HIPAA audit control boundary: a scan record that documents the input validation step before each classifier call provides the §164.312(b) evidence that input integrity was verified at the point where PHI entered the AI pipeline. The HIPAA-compliant AI security page covers the full §164.312 control map for AI-based healthcare systems.

FTC Act §5 and the consumer digital health context

The FTC has jurisdiction over consumer-facing digital health apps that are not classified as medical devices under FDA. An app that reads Apple Watch ECG data and provides "wellness insights" rather than medical diagnoses may fall outside FDA SaMD jurisdiction but squarely within FTC unfair or deceptive practices enforcement. The FTC's 2023 action against BetterHelp — and its broader enforcement posture on health data — establishes that the FTC treats deceptive statements about data security for health information as an unfair practice under Section 5. A digital health app that represents its AI-based ECG analysis as secure without implementing input validation controls that actually operate on ECG waveforms has a potential Section 5 exposure if a manipulated result causes consumer harm and the misrepresentation is material.

The healthcare AI security compliance landscape at the federal level is covered across several verticals on this site: radiology AI, mental health and digital health AI, dental AI, and ophthalmology AI each operate under the same FDA SaMD / HIPAA / FTC triad with domain-specific variations. The wearable health context adds the consumer electronics distribution channel — Apple Watch, Samsung Galaxy Watch, Fitbit — which routes FDA-cleared AI diagnostic capability through App Store / Play Store update mechanisms, creating post-market modification pathways that are not present in hospital-installed device classes.

5. Defence architecture for digital health developers building on wearable AI

The defence architecture for wearable health AI follows the same structural principle as every other multimodal AI security deployment: scan raw inputs at the boundary between the data source and the AI inference call, before any downstream action executes. The specifics differ from image and audio scanning because the input is a 1D time-series, but the principle is identical.

The scan gate pattern for ECG classifiers

For an app that reads Apple Watch ECG samples from HealthKit and passes them to a classifier:

1. Query HealthKit for HKElectrocardiogram samples using the HealthKit query API.
2. For each sample, extract the voltage time-series array (the HKElectrocardiogramVoltageMeasurement sequence).
3. Pass the raw voltage array to the scan gate — a validator that checks: (a) sample count within expected range for a 30-second recording at the declared sample rate; (b) voltage amplitude within physiological range (typically ±2 mV for a Lead I surface ECG); (c) rate-of-change bounds (slew rate limits inconsistent with biological cardiac electrical activity); (d) anomaly pattern matching against known adversarial waveform templates.
4. If the scan returns a clean verdict (risk score below threshold), pass the voltage array to the classifier. If flagged, return HKElectrocardiogram.Classification.unrecognized equivalent and generate an audit record: scan_id, waveform_hash, risk_score, flagged_segment (time offset of anomalous window), timestamp.

The physiological constraint checks (steps 3a–3c) are inexpensive and catch the majority of synthetic adversarial waveforms, which often violate physiological plausibility to achieve classifier manipulation. The pattern-matching step (3d) handles adversarial waveforms that respect physiological bounds but are crafted to produce specific misclassifications.

The scan gate pattern for CGM closed-loop systems

For closed-loop insulin delivery, the scan gate sits between the Bluetooth LE glucose reading and the dosing algorithm inference call:

1. Receive the Bluetooth LE CGM packet from the sensor.
2. Validate against the physiological envelope: (a) glucose value within sensor range (40–400 mg/dL for most CGMs); (b) rate of change since the previous reading within physiological bounds (CGM glucose typically changes at ≤3 mg/dL/min under normal conditions; values exceeding 6 mg/dL/min are physiologically possible during rapid glucose excursions but should trigger confirmation); (c) consistency with sensor calibration history and patient-specific baseline.
3. For values that pass physiological validation, pass to the dosing algorithm. For values that fail, trigger a fail-safe: pause automated dosing, present a user confirmation prompt with the raw reading value, and require explicit user confirmation before any automated insulin delivery. Log the anomalous reading with the same structured audit record format.

This is not the complete security architecture for closed-loop CGM — channel encryption, Bluetooth LE authentication, and firmware signing are all required — but it is the AI-layer control that sits closest to the point of harm: between the sensor data and the automated action it drives. A defence that secures the communication channel but does not validate inputs at the AI inference boundary has not defended the inference boundary; it has secured the channel while leaving the inference call exposed to inputs that arrive through it.

Audit records as regulatory compliance evidence

For FDA-regulated SaMD, each scan record from the validation gate is simultaneously a security control execution record and FDA post-market monitoring evidence. Under the 2023 guidance, manufacturers must monitor for anomalous inputs to their AI functions as part of post-market cybersecurity surveillance. A scan gate that logs every flagged waveform — with hash, risk score, anomalous segment, and timestamp — provides exactly the anomalous input monitoring record the guidance requires. For HIPAA covered entities and business associates, the same record satisfies the §164.312(b) audit control requirement for the PHI processing step. The audit record is written once; it satisfies multiple regulatory frameworks simultaneously. This is the same architectural principle described for multimodal AI prompt injection in healthcare compliance — the scan gate is both a security control and a compliance evidence generator.

6. What this means for teams building on HealthKit, Core Bluetooth, and wearable sensor AI in 2026

The wearable health AI landscape is different from most other AI security domains in one important respect: the attack surface is not a specialised enterprise system used by security professionals. It is a consumer product on 100 million wrists, used by patients with no security training, connected to healthcare systems via HealthKit and EHR integrations, and running AI classifiers that feed clinical decisions.

The teams building on top of this infrastructure — digital health startups, hospital system integration teams, telehealth platform developers — inherit the FDA SaMD security posture obligations even when their product is a software layer reading HealthKit data rather than the device itself. The FDA's business associate model for software reading PHI, and the FTC's enforcement posture on health app security claims, create binding obligations regardless of whether the developer's app touches the radio hardware. A secondary ECG classifier that reads Apple Watch waveform data from HealthKit and produces clinical recommendations is, in the FDA's framing, a Software Function that may constitute SaMD — and if it is SaMD, its cybersecurity risk assessment must document controls for adversarial waveform input manipulation that actually operate on the waveform.

The most common failure mode the teams encounter is the same one documented for FigStep, AgentTypo, and WhisperInject in the text-and-image domain: they have a text-based PI scanner in place (from an audit or compliance checklist requirement), they believe the scanner provides coverage, and the actual attack surface — the waveform data channel — is completely unmonitored. The scanner is accurate at what it scans; it is positioned at the wrong layer. Fixing this does not require replacing the text scanner; it requires adding a scan gate at the correct boundary — between the HealthKit read and the classifier call — that operates on the modality the attack actually uses.

The Glyphward API exposes a /scan/timeseries endpoint for exactly this use case: pass a voltage array (or glucose time-series, or SpO2 time-series), receive a risk score with a flagged window map. The free tier allows 10 scans/day for testing and prototype validation; the Pro tier at $29/mo handles 100k scans/month at the throughput required for a production HealthKit integration. For teams that need to satisfy FDA post-market cybersecurity monitoring requirements, the Pro plan includes structured audit export in the JSON-L format that maps to the FDA's anomalous input monitoring evidence requirement.