The Hospital That Got Hacked Through a Wearable
In 2025, a mid-sized US hospital discovered that a vulnerability in their Remote Patient Monitoring (RPM) wearable fleet had been exploited to gain access to the internal hospital network. The attack vector was surprisingly simple: a Bluetooth Low Energy (BLE) vulnerability in the wearable’s firmware allowed an attacker to inject malicious packets, which then pivoted through the paired nurse’s tablet and into the main Wi-Fi infrastructure.
The financial and operational fallout was staggering. The hospital spent $2.3 million on incident response, forensic analysis, and legal fees. Patient data was compromised, triggering HIPAA breach notifications. The FDA issued a formal safety communication, and the device manufacturer faced a massive recall and firmware remediation effort.
Cybersecurity is no longer optional for medical wearables. It is a fundamental patient safety requirement.
When I started Geyan Technology Innovation in 2011, the conversation with our B2B clients was entirely about battery life, sensor accuracy, and BLE range. We spent our days optimizing power consumption on the TK67 Smartwatch and ensuring the mechanical durability of our early prototypes. Back then, a dropped BLE connection was our biggest security concern.
Fifteen years later, the landscape has completely inverted. Today, a dropped connection is a minor UX bug; a compromised BLE stack is a federal regulatory violation. The transition from standalone health trackers to networked medical devices has exposed a massive attack surface. According to a 2025 report by MarketsandMarkets, the medical device cybersecurity market is projected to reach $18.4 billion by 2030, growing at a CAGR of 12.8%. This growth isn’t driven by hospitals wanting to buy fancy software; it is driven by the absolute necessity to secure the millions of IoT endpoints entering clinical environments.
This article breaks down the FDA’s 2023 Premarket Cybersecurity Guidance, explains how to implement threat modeling and Software Bills of Materials (SBOMs), and details the practical realities of building Zero Trust architectures for resource-constrained wearable hardware.
FDA Premarket Cybersecurity Guidance (September 2023): What It Requires
On September 27, 2023, the FDA finalized the guidance document titled “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions.” This document officially replaces the 2014 draft guidance and carries the weight of statutory authority under the Consolidated Appropriations Act of 2023.
For B2B OEMs and brand owners, this means cybersecurity is now a hard gate for 510(k) clearance. You cannot simply submit a device and promise to “fix security later.” The FDA requires a comprehensive, documented approach to security throughout the entire product lifecycle.
Here are the eight core requirements for your premarket submissions, aligned with the transition to the new FDA QMSR (Quality Management System Regulation) and 21 CFR 820.
1. Secure Product Development Framework (SPDF)
You must document your cybersecurity risk management process. This isn’t just a policy document; it is a framework that proves how security is integrated into your design controls. You need to reference established standards like AAMI TIR57, ISO 14971, and the NIST Cybersecurity Framework. Our manufacturing process supports ISO 13485:2016 compliance, and we integrate AAMI TIR57 principles directly into our IEC 62304 software development lifecycle.
2. Threat Modeling
Identify cybersecurity threats for every component of the system. The FDA expects to see methodologies like STRIDE, Attack Trees, or CVSS (Common Vulnerability Scoring System). You must document threat sources, specific threat events, underlying vulnerabilities, exploitability, clinical impact, overall risk level, and the specific mitigations applied.
3. Cybersecurity Risk Management
Cybersecurity risks cannot live in a separate silo. They must be integrated into your overall device risk management file as dictated by ISO 14971. If a cyber event can cause a wrong dose of insulin or delay an arrhythmia alert, it is a patient safety risk. We detail this integration extensively in our FDA 510k submission guide.
4. Software Bill of Materials (SBOM)
This is the most operationally challenging requirement. You must provide a machine-readable list of all software components, including commercial, open-source, and custom code. The FDA strongly recommends SPDX or CycloneDX formats. The SBOM must include component names, versions, suppliers, licenses, and known CVEs (Common Vulnerabilities and Exposures).
5. Security Testing
You must conduct and document four types of testing: static code analysis (SAST), dynamic analysis/fuzzing, vulnerability scanning against the National Vulnerability Database (NVD), and penetration testing by a qualified, independent third party. Expect to spend between $20,000 and $50,000 per device line for comprehensive third-party penetration testing.
6. Cybersecurity Labeling
Device labeling must include cybersecurity information. What security features are included? What are the residual risks? What are the minimum network requirements? How does the end-user keep the device secure? This information must be clear to both the IT procurement team and the clinical end-user.
7. Coordinated Vulnerability Disclosure (CVD)
You must have a published plan for receiving, triaging, and disclosing vulnerabilities. This includes a dedicated point of contact (like a security@ email address) for independent security researchers. You cannot ignore bug reports; you must have a legal and technical framework to handle them.
8. Post-Market Cybersecurity
Security doesn’t end at clearance. You need a plan for ongoing monitoring, patch management, and vulnerability disclosure for the entire expected life of the device. If a new zero-day vulnerability affects your microcontroller three years from now, you must have a mechanism to push a signed firmware update.
Setting up the initial SPDF, SBOM pipelines, and testing infrastructure typically costs between $15,000 and $45,000 per device line. It is a significant upfront investment, but the cost of a rejected 510(k) or a post-market recall is exponentially higher.
Threat Modeling for Wearable Devices: A Practical Framework
Threat modeling is often treated as a theoretical exercise by software engineers who have never held a physical wearable device. In the wearable space, the attack surface is uniquely complex because it spans physical hardware, wireless protocols, mobile applications, and cloud infrastructure.
When we designed the TK30 Smart Ring, the physical form factor was tiny, but the attack surface was massive. We had to map out every possible entry point.
The Wearable Attack Surface
- Device Hardware: Physical access allows attackers to probe JTAG/SWD debug ports, perform side-channel attacks (like power analysis), or decapsulate microcontrollers to extract flash memory.
- Device Firmware: Buffer overflows, insecure Over-The-Air (OTA) update mechanisms, hardcoded credentials, and unencrypted local storage.
- Bluetooth/BLE: Eavesdropping on sensor data, man-in-the-middle (MitM) attacks, unauthorized pairing, and denial of service (DoS) via connection flooding.
- Mobile App: Reverse engineering the APK/IPA, insecure local data storage, extraction of hardcoded API keys, and insecure local IPC (Inter-Process Communication).
- Cloud API: SQL injection, authentication bypass, insecure direct object references (IDOR), and bulk data exfiltration.
- Hospital Network: Lateral movement from the IoT VLAN to the main clinical network, pivot attacks using compromised mobile devices.
STRIDE Analysis for a Medical Wearable
We use the STRIDE methodology to categorize threats. Here is a practical breakdown applied to a continuous blood pressure monitoring wearable, similar to the technology discussed in our BP technology guide.
| Threat Category | Attack Scenario | Mitigation Strategy |
|---|---|---|
| Spoofing | Attacker spoofs a legitimate wearable to send fake patient vitals to the cloud. | Device authentication using unique X.509 certificates and mutual TLS (mTLS). |
| Tampering | Attacker modifies the firmware via a physical debug port to add malicious code. | Signed firmware, secure boot chain, and hardware anti-tamper detection (mesh layers). |
| Repudiation | Attacker deletes local audit logs to hide unauthorized configuration changes. | Secure, append-only audit logging with cryptographic hash chaining. |
| Information Disclosure | Attacker captures BLE traffic in a waiting room to steal patient health data. | BLE encryption using LE Secure Connections and application-layer AES-256 encryption. |
| Denial of Service | Attacker floods the wearable with BLE connection requests, draining the battery. | Connection rate limiting, exponential backoff, and hardware watchdog timers. |
| Elevation of Privilege | Attacker exploits a buffer overflow to gain root access to the device OS. | Principle of least privilege, memory protection units (MPU), and secure OS configuration. |
Threat Model Architecture Diagram
+-------------------------------------------------------------+
| HOSPITAL / CLOUD ENVIRONMENT |
| +----------------+ +----------------+ +------------+ |
| | Cloud API |<-->| Mobile App |<-->| EHR/EMR | |
| | (HL7 FHIR R4) | | (iOS/Android) | | (Epic/Cern)| |
| +-------+--------+ +-------+--------+ +------------+ |
| | | |
| | TLS 1.3 / mTLS | BLE (Encrypted) |
+----------|---------------------|-----------------------------+
| |
+----------|---------------------|-----------------------------+
| v v WEARABLE DEVICE |
| +----------------+ +----------------+ |
| | Cloud Comm | | BLE Stack | |
| | Module | | (GAP/GATT) | |
| +-------+--------+ +-------+--------+ |
| | | |
| v v |
| +---------------------------------------------+ |
| | Application Layer (Sensor Fusion) | |
| +---------------------------------------------+ |
| | |
| v |
| +----------------+ +----------------+ |
| | Secure Boot & | | Hardware | |
| | Crypto Engine | | Sensors (PPG) | |
| +----------------+ +----------------+ |
+-------------------------------------------------------------+
Notice how the data flows through multiple boundaries. A vulnerability in the BLE stack doesn’t just mean someone can read your heart rate; it means they might be able to inject a payload that crashes the application layer, causing a missed arrhythmia alert. This is why we integrate our threat modeling directly into the IEC 60601-1 and IEC 62304 design inputs.
Software Bill of Materials (SBOM): What It Is, Why It Matters, How to Create One
An SBOM is a formal, structured list of all software components in a device. Think of it as a nutritional label for your firmware. It details every open-source library, commercial SDK, and custom module, along with their versions and dependencies.
Why does this matter so much? In December 2021, the Log4Shell vulnerability (CVE-2021-44228) was disclosed. It affected the Apache Log4j utility, which was embedded in millions of applications. Hospitals panicked. They needed to know immediately if their infusion pumps, patient monitors, and RPM wearables were affected.
Without an SBOM, hospitals had to send emails to every single manufacturer, asking, “Are you using Log4j?” Manufacturers had to manually grep through codebases, a process that took weeks. With a machine-readable SBOM, a hospital’s IT security team can query their asset management system and identify affected devices in minutes.
The FDA now requires an SBOM for 510(k) submissions. The accepted formats are SPDX (Software Package Data Exchange) and CycloneDX.
What is Included in an SBOM?
- Component Name and Version: Exact naming and semantic versioning (e.g., FreeRTOS v10.5.1).
- Supplier/Manufacturer: Who maintains the code.
- Unique Identifier: CPE (Common Platform Enumeration), PURL (Package URL), or SWID.
- Relationships: How components depend on each other (the dependency tree).
- Known Vulnerabilities: Current CVEs associated with the specific version.
- License Information: Crucial for avoiding GPL contamination in proprietary medical firmware.
How to Create and Maintain an SBOM
Generating an SBOM manually is impossible for modern firmware. You must automate it. We use tools like Syft (by Anchore) and the CycloneDX CLI to scan our build artifacts. For identifying known CVEs within those components, we integrate OWASP Dependency-Check and Trivy (by Aqua Security) into our CI/CD pipeline.
Here is a hard truth about SBOMs: generating the initial list is easy. Maintaining it is incredibly difficult. When a hardware engineer swaps a microcontroller and the firmware team updates the BLE stack to support the new silicon, the SBOM must be updated. If the SBOM is out of sync with the actual firmware shipped to the customer, it is worse than useless; it provides a false sense of security. We generate a new SBOM with every single build release and archive it alongside the firmware binary.
Zero Trust Architecture for Medical Wearable Systems
Zero Trust is a security mantra: “Never trust, always verify.” It assumes that the network is already compromised and that every access request must be authenticated, authorized, and encrypted, regardless of where it originates.
Applying Zero Trust to medical wearables is highly complex because wearables are resource-constrained. They have limited processing power, minimal memory, and run on tiny batteries. Implementing heavy cryptographic operations can drain a coin-cell battery in hours.
When we developed the V80 Smart Ring, we had to balance strict Zero Trust principles with the physical reality of a 20mAh battery. Here is how we implement Zero Trust across the device ecosystem, including our GE54 clinical gateway devices.
Zero Trust Implementation Steps
- Device Identity: Every wearable is provisioned with a unique, cryptographically verifiable identity (an X.509 certificate) during manufacturing. No anonymous devices are allowed to connect to the cloud.
- Least Privilege Access: The wearable’s API tokens are scoped strictly to its specific patient ID and required endpoints. It cannot query other patients’ data or access administrative cloud functions.
- Micro-Segmentation: In a hospital deployment, the wearables communicate with a local gateway, which sits on an isolated IoT VLAN. If a wearable is compromised, the attacker is trapped in the IoT segment and cannot pivot to the main hospital network.
- Continuous Authentication: Session tokens are short-lived. Every major API call requires re-validation. We avoid long-lived credentials entirely.
- Data Encryption: Data is encrypted at rest on the device (AES-256) and in transit (TLS 1.3). There is no plaintext patient data anywhere in the system.
- Secure Boot: The device’s hardware root of trust verifies the cryptographic signature of the bootloader and firmware at every power-on. If the firmware is tampered with, the device refuses to boot.
- Secure Firmware Updates: OTA updates are signed, encrypted, and verified before installation. We implement rollback protection to prevent attackers from downgrading the device to a vulnerable firmware version.
- Audit Logging: All security events (failed logins, update attempts, configuration changes) are logged, stored securely, and transmitted to the cloud for anomaly detection.
Zero Trust sounds perfect in a boardroom presentation. In a hospital ward with thick concrete walls and heavy 2.4GHz RF interference, maintaining continuous TLS 1.3 handshakes on a wearable can cause connection drops and battery drain. We had to implement asymmetric crypto optimizations and session resumption techniques to make it work without killing the battery life. Security must serve the clinical use case, not hinder it.
Zero Trust Architecture Diagram
[ Wearable Device ] --(BLE mTLS)--> [ Mobile Gateway / Hub ]
| |
| (X.509 Cert) | (IoT VLAN / Micro-segmented)
v v
[ Secure Boot ] [ Local Edge Processing ]
[ AES-256 Storage ] [ Anomaly Detection ]
| |
+-------------------------------------+
|
| (TLS 1.3 / mTLS / Short-lived Tokens)
v
+-------------------------+
| Cloud Platform |
| +---------------------+ |
| | Identity Provider | | <--- Continuous Auth / Least Privilege
| | (PKI / X.509) | |
| +---------------------+ |
| +---------------------+ |
| | FHIR API Gateway | | <--- HL7 FHIR R4 Integration
| +---------------------+ |
| +---------------------+ |
| | Encrypted Data Lake | |
| +---------------------+ |
+-------------------------+
Security Testing: What Your OEM Should Be Doing
Writing secure code is only half the battle. You must prove it is secure through rigorous testing. The FDA expects to see a comprehensive testing strategy in your 510(k) submission. Here is the testing stack we utilize and recommend for medical wearables.
Static Application Security Testing (SAST)
SAST analyzes source code for vulnerabilities without executing it. It looks for hardcoded credentials, buffer overflows, and insecure function calls. We use tools like Semgrep (open source) and SonarQube integrated directly into our pull request workflow. If a developer commits code with a critical SAST finding, the build fails automatically.
Dynamic Application Security Testing (DAST)
DAST tests the running application and cloud APIs for vulnerabilities like SQL injection and cross-site scripting. Tools like OWASP ZAP and Burp Suite are used to attack the cloud endpoints and the mobile app's network traffic.
Software Composition Analysis (SCA)
SCA identifies known vulnerabilities in third-party and open-source components. This is the tool that generates the data for your SBOM. We use OWASP Dependency-Check and Snyk to monitor our dependencies daily. If a new CVE is published for a library we use, we get an alert immediately.
Fuzz Testing
Fuzz testing involves sending malformed, random, or unexpected data to the device's interfaces (BLE, USB, UART) to find crashes and memory leaks. We use AFL (American Fuzzy Lop) and libFuzzer. For our BLE stack, we ran continuous fuzzing for 14 days straight. Fuzzing finds weird edge cases that human reviewers miss. However, engineers need to triage these results carefully; sometimes a "crash" is just the BLE stack resetting to recover from bad data, which is an acceptable fail-safe, not a security vulnerability.
Penetration Testing
You must engage a qualified, independent third-party security firm to attempt to compromise the device. This cannot be done in-house. The pen testers will attempt physical hardware hacks, BLE MitM attacks, and cloud API breaches. The resulting report, along with your remediation plan, must be included in the FDA submission.
Vulnerability Disclosure and Bug Bounties
Have a published Vulnerability Disclosure Program (VDP). Provide a security@ email address and a PGP key for encrypted communication. For high-risk devices, consider a Bug Bounty Program on platforms like HackerOne or Bugcrowd, paying independent researchers to find flaws before malicious actors do.
Hospital Procurement: 10 Cybersecurity Questions to Ask Your OEM
I sit in procurement meetings with hospital IT security officers regularly. They are highly skeptical, and they should be. When a hospital evaluates a new RPM wearable fleet, the clinical team cares about sensor accuracy, but the IT security team cares about network integrity. If the OEM cannot satisfy the IT team, the deal dies.
If you are procuring medical wearables, ask your OEM these 10 questions. Their answers will tell you everything you need to know about their security maturity.
- Do you have a documented Secure Product Development Framework (SPDF) aligned with AAMI TIR57 and NIST CSF? (Look for a detailed process document, not just a marketing brochure.)
- Can you provide a machine-readable SBOM (SPDX or CycloneDX) for the specific firmware version you are shipping? (If they say "we can generate one if you need it," that is a red flag. It should be ready now.)
- Has the device undergone penetration testing by an independent third party within the last 12 months? (Ask to see the executive summary of the report.)
- What specific encryption algorithms are used for data at rest and in transit? (Acceptable answers: AES-256, TLS 1.2/1.3. Reject anything mentioning DES, 3DES, or RC4.)
- How are firmware updates delivered, signed, and verified? (They must explain the cryptographic signature verification and rollback protection.)
- Do you have a Coordinated Vulnerability Disclosure (CVD) program? (Ask for the URL to their security policy and the contact email.)
- What is your guaranteed patch release timeline for critical (CVSS > 9.0) vulnerabilities? (Industry standard is 14 to 30 days. If they say "we will fix it in the next major release," walk away.)
- How is device identity managed and authenticated? (Look for unique X.509 certificates or hardware-backed secure elements.)
- Does the device and its companion app support network segmentation and micro-segmentation? (The device should not require broad access to the hospital network.)
- Can you provide your complete cybersecurity risk management documentation for our 510(k) and hospital security review? (A mature OEM will have a pre-packaged "Security Documentation Package" ready for B2B clients.)
The xdunmedical Cybersecurity Approach
At Geyan Technology Innovation, we have spent the last 15 years refining our manufacturing and engineering processes. We recognize that in 2026, a medical wearable is only as good as its security posture. Our cybersecurity framework is built into the DNA of our TK35Pro and other clinical devices from day one.
Our Secure Product Development Framework (SPDF) is strictly aligned with AAMI TIR57 and the NIST Cybersecurity Framework. We perform comprehensive STRIDE threat modeling for every new device design, ensuring that security is integrated into the IEC 62304 software lifecycle. We do not treat security as an afterthought.
For SBOM compliance, we generate a machine-readable SBOM in SPDX format with every single build. This is integrated into our CI/CD pipeline, ensuring that our customers always have an accurate, up-to-date inventory of their software components. You can learn more about our production workflows in our manufacturing model comparison guide.
Our security testing regimen includes static analysis via Semgrep, SCA using OWASP Dependency-Check, extensive fuzz testing on our wireless stacks, and mandatory third-party penetration testing for all major releases. We implement hardware-backed secure boot, signed firmware updates, and TLS 1.3 with AES-256 encryption across our ecosystem. For clients integrating with hospital EHRs, our systems are designed for secure FHIR integration without compromising data privacy.
We understand the regulatory burden our B2B partners face. That is why we provide a comprehensive cybersecurity documentation package—including our SBOM, threat model summaries, penetration test executive summaries, and vulnerability disclosure policies—to our customers to support their FDA 510(k) submissions and hospital IT security reviews. We detail this regulatory support in our certification roadmap and our broader RPM market report 2026-2030.
Building secure medical wearables is difficult. It requires balancing clinical utility, battery life, physical durability, and rigorous cybersecurity. But it is the only way forward.
Cybersecurity is built into our devices from day one. Request our cybersecurity documentation package: SBOM, threat model, penetration test summary, vulnerability disclosure program.
→ Request Cybersecurity Documentation: jine@xdunmedical.com