PRIVILEGED & CONFIDENTIAL ATTORNEY-CLIENT PRIVILEGED / ATTORNEY WORK PRODUCT DO NOT DISTRIBUTE WITHOUT PRIOR AUTHORIZATION
CYBERSECURITY PREMARKET SUBMISSION CHECKLIST
SOLSTICE LUMINA™ CGM SYSTEM
Privileged & Confidential Memorandum
Engagement Reference No.: 1037-00002 Date: May 2025
CONFIDENTIALITY NOTICE: This memorandum is protected by the attorney-client privilege and constitutes attorney work product. It has been prepared by Calderwood & Harkness LLP at the direction of Solstice Biomedical Devices Ltd. and its U.S. subsidiary Solstice Biomedical Inc. for the sole purpose of providing legal advice in connection with the premarket regulatory submission of the Solstice Lumina™ CGM System. This document should not be disclosed to any third party without the prior written authorization of Calderwood & Harkness LLP and Solstice Biomedical Devices Ltd. Inadvertent disclosure of this document does not constitute a waiver of any applicable privilege.
Right-click to update Table of Contents
I. Executive Summary
The purpose of this memorandum is to provide a comprehensive mapping of the requirements set forth in the U.S. Food and Drug Administration ("FDA") final guidance document entitled Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (September 2023) (the "September 2023 Cybersecurity Guidance" or the "Guidance") to the specific system architecture, communication interfaces, and software features of the Solstice Lumina™ Continuous Glucose Monitoring System (the "Lumina CGM System" or the "System"). This memorandum is intended to serve as an actionable checklist and framework for the preparation of all cybersecurity-related documentation that will be included in both the Pre-Submission ("Pre-Sub") meeting package and the eventual 510(k) premarket notification submission to the Center for Devices and Radiological Health ("CDRH") of the FDA.
The Lumina CGM System comprises two distinct but functionally integrated device variants that are being submitted as a single traditional 510(k) covering the system as a whole:
(a) the Lumina C14 Implantable Subcutaneous Continuous Glucose Monitoring Sensor (the "C14 Sensor"), a disposable electrochemical sensor designed for subcutaneous implantation with a maximum 14-day (336-hour) wear duration; and
(b) the Lumina R7 Wearable Reader/Transmitter (the "R7 Reader"), an arm-worn reusable device that receives glucose data from the C14 Sensor, processes that data through the LuminaPredict Algorithm, and displays real-time glucose values, trend arrows, and trend graphs to the user.
The System incorporates several cybersecurity-relevant features and communication pathways that fall squarely within the scope of the September 2023 Cybersecurity Guidance. Specifically, the Lumina CGM System utilizes Bluetooth Low Energy ("BLE") 5.2 wireless communication between the C14 Sensor and the R7 Reader; BLE communication between the R7 Reader and the Lumina Mobile Application (available on both iOS and Android platforms, version 1.0.3); and cloud connectivity for data synchronization, user account management, over-the-air ("OTA") software update distribution, and remote monitoring data sharing. Additionally, the LuminaPredict Algorithm version 2.1 runs on-device on the R7 Reader, employing machine learning and signal processing techniques to generate predictive glucose trend information.
The following software versions are under assessment in connection with the current premarket submission effort:
• Lumina Firmware v3.4.2 — embedded firmware running on the C14 Sensor microcontroller;
• Lumina Reader OS v2.1.0 — operating system and application software running on the R7 Reader;
• LuminaPredict Algorithm v2.1 — proprietary glucose prediction algorithm integrated within the R7 Reader software environment; and
• Lumina Mobile App v1.0.3 — companion mobile application for iOS and Android platforms.
Consistent with the FDA's September 2023 Cybersecurity Guidance and the requirements of IEC 62304:2006/A1:2015 (Medical device software — Software life cycle processes), the Software Level of Concern for the Lumina CGM System has been determined to be Major. This determination reflects the fact that a failure or malfunction of the software could result in incorrect glucose readings being displayed to the user, which in turn could lead to inappropriate clinical decision-making regarding insulin dosing or other therapeutic interventions, potentially resulting in serious injury.
The Lumina CGM System is being submitted under product code QKQ, classified as a Class II device subject to regulation under 21 C.F.R. § 862.1355 (glucose test system). The submission will follow the traditional 510(k) pathway, and the System will be compared against identified predicate devices as detailed in the separate Predicate Comparison Analysis prepared by Pinnacle Regulatory Consulting Group LLC.
This cybersecurity checklist will serve two primary purposes in the regulatory submission timeline:
1. Pre-Submission Meeting Package (Target Submission: June 16, 2025). The checklist will be used to prepare the cybersecurity-related sections of the Pre-Sub meeting package, including preliminary cybersecurity documentation and specific questions for the FDA regarding the agency's expectations for cybersecurity content in the 510(k) submission. The Pre-Sub meeting is currently scheduled for August 14, 2025, with CDRH, Office of Health Technology 2 ("OHT2"), Division of Chemistry and Toxicology Devices.
2. 510(k) Submission (Target Submission: April 30, 2026). The checklist will serve as the master tracking document for all cybersecurity documentation that must be included in the complete 510(k) premarket notification, with a target FDA clearance date of Q3 2026.
Calderwood & Harkness LLP is coordinating with Pinnacle Regulatory Consulting Group LLC ("Pinnacle Regulatory"), which was engaged by Solstice Biomedical Devices Ltd. on January 15, 2025, for the preparation of technical regulatory documentation in support of the 510(k) submission. Pinnacle Regulatory's team, led by Dr. Sandra Ellison (Managing Director) and Thomas Greenbaum (Senior Regulatory Specialist), will be responsible for the review and formatting of cybersecurity documentation to ensure compliance with FDA submission requirements and expectations.
It should be noted that cybersecurity is also identified as a discussion topic in the Questions for FDA section of the Pre-Sub meeting package currently under development. This checklist supports the formulation of those questions and will provide the foundation for interpreting and implementing FDA feedback received at the August 14, 2025 Pre-Sub meeting.
II. Applicable Regulatory Framework and Guidance
II.A. Primary FDA Guidance
The primary regulatory guidance document governing the cybersecurity content requirements for the Lumina CGM System premarket submission is the FDA's final guidance entitled "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions", published in September 2023 (the "September 2023 Cybersecurity Guidance" or the "Guidance"). This document supersedes the prior 2014 guidance on the same topic and represents the FDA's most current and comprehensive articulation of cybersecurity expectations for premarket submissions.
The September 2023 Cybersecurity Guidance applies broadly to medical devices that contain software (including firmware) or programmable logic, as well as software that is a medical device itself (SaMD). Critically, the Guidance applies to devices with "cybersecurity considerations," which the FDA defines to include devices with software functions that:
(a) are capable of connecting to another medical device or non-medical computing device (including through wired or wireless connections);
(b) connect to a network (e.g., local area networks, wide area networks, the internet);
(c) use or incorporate wireless communication technology (including, without limitation, Bluetooth, BLE, Wi-Fi, cellular, near-field communication, or radio frequency); or
(d) could be susceptible to cybersecurity threats.
The Lumina CGM System unambiguously falls within the scope of the Guidance on multiple grounds. The System employs BLE 5.2 wireless communication between the C14 Sensor and the R7 Reader, as well as between the R7 Reader and the Lumina Mobile App. The System also utilizes internet connectivity through the Lumina Mobile App and/or the R7 Reader for cloud-based data synchronization, software update retrieval, and remote monitoring data sharing. Accordingly, the System must be treated as a "cyber device" within the meaning of the Guidance, and the 510(k) submission must include a comprehensive cybersecurity section addressing all applicable requirements.
The September 2023 Cybersecurity Guidance is applicable to the Lumina CGM System's Class II classification and its submission via the traditional 510(k) pathway. While the Guidance applies across all premarket submission types (510(k), De Novo, PMA, and HDE), the specific documentation expectations are calibrated to the risk profile of the device and the nature and extent of its cybersecurity considerations. Given the Major Software Level of Concern, the safety-critical nature of glucose monitoring data, and the multiple wireless and internet-connected interfaces, the FDA will expect a thorough and detailed cybersecurity submission.
II.B. Supplementary Standards and References
In addition to the September 2023 Cybersecurity Guidance, the cybersecurity documentation for the Lumina CGM System should reference and align with the following supplementary standards, guidance documents, and frameworks:
IEC 62304:2006/A1:2015 — Medical device software — Software life cycle processes. This international standard establishes requirements for the software development lifecycle for medical devices, including software classification, development planning, requirements analysis, architectural design, implementation, verification, and maintenance. The cybersecurity documentation must be consistent with and cross-referenced to the software lifecycle documentation prepared under IEC 62304, particularly with respect to the classification of the Lumina CGM System software at Safety Class C (given the Major Level of Concern designation).
IEC 81001-5-1:2021 — Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle. This relatively new standard, which has been increasingly referenced by the FDA and by international regulators, provides a framework for integrating security activities into the product lifecycle of health software. The standard addresses security requirements analysis, security risk management, secure design, secure implementation, security verification and validation, and post-market security activities. Alignment with IEC 81001-5-1 is strongly recommended, as the FDA has signaled its intent to recognize this standard as a consensus standard for purposes of cybersecurity submissions.
AAMI TIR57:2016 — Principles for medical device security — Risk management. This technical information report provides guidance on applying risk management principles specifically to medical device cybersecurity. It describes a process for identifying, analyzing, evaluating, and controlling cybersecurity risks in the context of a medical device's intended use environment. AAMI TIR57 serves as a bridge between the general risk management framework of ISO 14971 and the specific cybersecurity threat landscape, and its methodology should be reflected in the cybersecurity risk management documentation for the Lumina CGM System.
NIST Cybersecurity Framework (CSF). The National Institute of Standards and Technology Cybersecurity Framework provides a voluntary framework of standards, guidelines, and best practices for managing cybersecurity risk. While the NIST CSF is not specifically designed for medical devices, the FDA has explicitly referenced it in the September 2023 Cybersecurity Guidance as a useful organizing framework. The five core functions of the NIST CSF — Identify, Protect, Detect, Respond, and Recover — provide a high-level structure for organizing cybersecurity controls and documentation.
NTIA Software Bill of Materials (SBOM) Minimum Elements Guidance. The National Telecommunications and Information Administration has published guidance establishing the minimum elements that should be included in a Software Bill of Materials. The FDA's September 2023 Cybersecurity Guidance incorporates and builds upon the NTIA's minimum elements, requiring that SBOMs submitted with premarket submissions include, at a minimum, the supplier name, component name, version string, unique identifier, dependency relationship, author, and timestamp for each software component.
FDA Guidance: "Content of Premarket Submissions for Management of Cybersecurity in Medical Devices" (October 2014, final guidance). This predecessor guidance document, while now superseded by the September 2023 Cybersecurity Guidance, is referenced here for historical context. Some FDA reviewers may still refer to concepts or frameworks from the 2014 guidance, and familiarity with this document remains useful for understanding the evolution of FDA cybersecurity expectations.
FDA Guidance: "Postmarket Management of Cybersecurity in Medical Devices" (December 2016, final guidance). While the primary focus of the current checklist is on premarket submission content, the post-market cybersecurity guidance is relevant to the extent that the FDA expects premarket submissions to demonstrate that the device has been designed with a total product lifecycle approach to cybersecurity. The patch management plan and software update architecture documentation (addressed in Section VIII of this memorandum) must reflect post-market cybersecurity management considerations.
II.C. Connection to Other Submission Requirements
The cybersecurity documentation described in this checklist does not exist in isolation but must be integrated with and cross-referenced to several other components of the 510(k) submission. The following cross-references are particularly important:
Software Documentation Requirements. The cybersecurity documentation is closely interrelated with the software documentation prepared under IEC 62304 and in accordance with FDA's guidance on software submissions. The Software Level of Concern determination (Major), the software description, the software requirements specification, the software architecture documentation, and the software verification and validation testing results all have direct bearing on the cybersecurity submission content. A separate Software Documentation Checklist and Gap Analysis has been prepared by this firm and should be consulted in parallel with the present document. The cybersecurity section of the 510(k) should cross-reference the software documentation and avoid unnecessary duplication while ensuring that cybersecurity-specific requirements are addressed with sufficient specificity.
Device Description in Pre-Sub Package. The Pre-Sub meeting package will include a detailed device description covering the hardware and software architecture of the Lumina CGM System, including the specific firmware and software versions under assessment (Firmware v3.4.2, Reader OS v2.1.0, LuminaPredict Algorithm v2.1, and Mobile App v1.0.3). The cybersecurity-relevant features of the device description — including communication interfaces, data flows, and network connectivity — should be consistent between the device description section and the cybersecurity section.
Quality System / Design Controls. The integration of cybersecurity considerations into the quality management system ("QMS") and design controls process is a significant emphasis of the September 2023 Cybersecurity Guidance. The Guidance explicitly states that cybersecurity should be addressed as part of the design and development process under the Quality System Regulation ("QSR"), codified at 21 C.F.R. Part 820. This means that cybersecurity requirements should be documented as design inputs, cybersecurity design reviews should be conducted, and cybersecurity verification and validation activities should be part of the design history file. The Solstice QMS must reflect these expectations, and the 510(k) submission should demonstrate that cybersecurity has been integrated into the design controls framework.
III. System Architecture — Cybersecurity-Relevant Features
This section describes the cybersecurity-relevant aspects of the Lumina CGM System architecture. The descriptions provided herein are based on the technical specifications and design documentation provided by the Solstice Biomedical Devices Ltd. engineering team as of the date of this memorandum. These descriptions will form the basis for the cybersecurity analysis presented in subsequent sections and should be updated as the design evolves during the development process.
III.A. Lumina C14 Sensor — Communication Interfaces
The Lumina C14 Implantable Subcutaneous Continuous Glucose Monitoring Sensor is a disposable, single-use electrochemical sensor designed for subcutaneous insertion via a spring-loaded applicator. The C14 Sensor contains an embedded microcontroller running Lumina Firmware v3.4.2, which manages the electrochemical sensing process, performs initial signal conditioning and filtering, and transmits processed glucose measurement data wirelessly.
The sole external communication interface of the C14 Sensor is a BLE 5.2 wireless transmitter that communicates with the R7 Reader. The C14 Sensor does not have any direct internet connectivity, wired communication ports, or any other communication interface beyond the BLE 5.2 link to the R7 Reader. All data generated by the C14 Sensor — including raw and processed glucose measurements — flows exclusively through the R7 Reader before reaching any other system component (the Lumina Mobile App or cloud infrastructure).
Key technical parameters of the C14 Sensor that are relevant to the cybersecurity assessment include:
• Measurement Range: 40–400 mg/dL
• Sensor Wear Duration: Maximum 14 days (336 hours), after which the sensor is discarded and replaced
• Warm-Up Time: ≤ 60 minutes from insertion to first glucose reading
• Alert Latency Requirement: ≤ 5 minutes from the time a glucose measurement is taken by the C14 Sensor to the time the corresponding alert notification is presented to the user on the R7 Reader. This alert latency requirement is safety-critical: any cybersecurity vulnerability or incident that delays or disrupts the transmission of glucose data from the C14 Sensor to the R7 Reader beyond the 5-minute threshold could have direct patient safety consequences, including failure to alert the user to hypoglycemic or hyperglycemic events requiring immediate intervention.
From a cybersecurity perspective, the C14 Sensor presents certain inherent constraints. The embedded microcontroller has limited computational resources (processor speed, memory, and power budget), which constrain the complexity and extent of on-device security measures that can be implemented. The cryptographic and authentication capabilities of the C14 Sensor are necessarily limited by these resource constraints, and the cybersecurity design must account for these limitations while still achieving an acceptable level of security for the BLE 5.2 communication link. Additionally, given the disposable nature of the C14 Sensor (14-day wear duration), the feasibility and necessity of firmware update capability for the implanted sensor requires careful consideration, as addressed in Section VIII of this memorandum.
III.B. Lumina R7 Reader/Transmitter — Communication Interfaces
The Lumina R7 Wearable Reader/Transmitter is a reusable arm-worn device that serves as the primary user interface and computational hub of the Lumina CGM System. The R7 Reader runs the Lumina Reader OS v2.1.0, which encompasses the operating system, application software, display management, communication stacks, and the integrated LuminaPredict Algorithm v2.1.
The R7 Reader has multiple communication interfaces, each of which represents a distinct cybersecurity-relevant attack surface:
(a) BLE 5.2 Interface — C14 Sensor Communication. The R7 Reader receives glucose measurement data from the paired C14 Sensor via BLE 5.2. This interface is the primary data acquisition pathway for the System and is critical to the safety and effectiveness of the device. The R7 Reader must authenticate the C14 Sensor to prevent pairing with unauthorized or counterfeit sensors and must protect the integrity and confidentiality of glucose data in transit.
(b) BLE Interface — Lumina Mobile App Communication. The R7 Reader communicates with the Lumina Mobile App (installed on the user's personal smartphone or tablet) via BLE. This interface enables the Mobile App to receive glucose data for display, trend analysis, and data synchronization, as well as to send configuration commands and software update payloads to the R7 Reader.
(c) Cloud Connectivity. The R7 Reader has the capability to connect to the Lumina cloud infrastructure for data synchronization (uploading historical glucose data) and for retrieving software updates. The specific connectivity pathway (whether the R7 Reader connects to the cloud directly via the user's Wi-Fi network or indirectly through the paired mobile device acting as a gateway) should be documented in the system architecture description.
The R7 Reader provides the following user-facing functions that are relevant to the cybersecurity assessment:
• Display of real-time glucose values with numerical readout
• Trend arrow indicators showing the rate and direction of glucose change
• 8-hour trend graphs showing historical glucose readings
• Configurable hypoglycemia and hyperglycemia alert thresholds with audible and vibratory notifications
• Execution of the LuminaPredict Algorithm v2.1 for glucose prediction
The LuminaPredict Algorithm v2.1 is a proprietary algorithm that runs on-device on the R7 Reader. It employs machine learning and signal processing techniques to generate predictive glucose trend information based on historical and current glucose measurements. The integrity and accuracy of the LuminaPredict Algorithm are cybersecurity-relevant because unauthorized modification of the algorithm or its inputs could result in inaccurate glucose predictions, potentially leading to inappropriate clinical decision-making.
III.C. Lumina Mobile Application
The Lumina Mobile App v1.0.3 is a companion software application available for iOS and Android platforms. The Mobile App communicates with the R7 Reader via BLE and connects to the Lumina cloud infrastructure via the internet (typically through the user's cellular data or Wi-Fi connection).
The Lumina Mobile App provides the following functionality:
• Display of real-time glucose values, trend arrows, and trend graphs received from the R7 Reader
• Historical glucose data viewing and analysis
• Cloud-based data synchronization, enabling the user to access glucose data across multiple devices and from web interfaces
• User account creation and management
• Remote monitoring data sharing, enabling designated family members, caregivers, or healthcare providers to view the user's glucose data in near real-time
• Software update delivery channel (the Mobile App may serve as a conduit for delivering software updates to the R7 Reader)
• Configuration of alert thresholds and other device settings
From a cybersecurity perspective, the Mobile App introduces additional complexity because it runs on consumer mobile devices with varied and potentially inconsistent security postures. The user's smartphone may have outdated operating system versions, may be jailbroken or rooted, and may have other applications installed that could interact with or compromise the security of the Lumina Mobile App. The cybersecurity design must account for these environmental uncertainties and implement appropriate protections, including secure data storage on the mobile device, protection against reverse engineering, and robust authentication and encryption for all communication pathways.
III.D. Cloud Infrastructure
The Lumina CGM System relies on cloud-based infrastructure for several functions that are integral to the overall system architecture:
• Data Storage and Synchronization: Historical glucose data is uploaded to the cloud from the R7 Reader (directly or via the Mobile App) and stored securely for access by the user, healthcare providers, and authorized caregivers.
• User Account Management: User registration, authentication, profile management, and access control are managed through cloud services.
• Over-the-Air (OTA) Update Distribution: Software updates for the R7 Reader OS, LuminaPredict Algorithm, and potentially the Lumina Mobile App are distributed through the cloud infrastructure.
• Remote Monitoring Data Sharing: The cloud infrastructure enables the sharing of glucose data with designated recipients, such as family members or healthcare professionals, in near real-time.
The cloud infrastructure is a significant component of the System's cybersecurity attack surface. The security of cloud services — including data encryption at rest and in transit, access control mechanisms, authentication protocols, logging and monitoring capabilities, and disaster recovery and business continuity provisions — must be documented in the cybersecurity submission. The specific cloud service provider(s) and their security certifications (e.g., SOC 2, ISO 27001, HIPAA BAA) should be identified in the submission documentation.
III.E. Data Flow Diagram Requirement
The September 2023 Cybersecurity Guidance specifically requires that premarket submissions include a comprehensive data flow diagram showing all external interfaces, communication pathways, data types exchanged across each interface, and trust boundaries within the system architecture. The data flow diagram is a foundational document for the cybersecurity analysis, as it defines the scope and boundaries of the threat model, vulnerability assessment, and security architecture documentation.
Action Item: The Solstice engineering team must prepare a detailed end-to-end data flow diagram for the Lumina CGM System. The diagram must depict, at a minimum, the following communication pathways and data types:
The data flow diagram should clearly identify all trust boundaries — i.e., the boundaries between system components with different levels of trust or security — and should indicate the security controls (encryption, authentication, access controls) applied at each trust boundary. The diagram should be prepared in a format suitable for inclusion in both the Pre-Sub meeting package and the 510(k) submission.
IV. Threat Modeling
IV.A. Methodology — STRIDE Framework
The FDA's September 2023 Cybersecurity Guidance requires that premarket submissions include documentation of a threat model that identifies and assesses cybersecurity threats to the device. The Guidance does not mandate a specific threat modeling methodology but states that the manufacturer should use a systematic, structured approach and should document the methodology, assumptions, and results.
For the Lumina CGM System, the threat modeling will be conducted using the STRIDE framework, a well-established threat modeling methodology originally developed by Ashbury Holdings and widely adopted in the cybersecurity industry. The STRIDE framework categorizes threats into six categories:
• S — Spoofing: An attacker pretends to be something or someone other than their true identity, such as impersonating an authorized device or user.
• T — Tampering: An attacker modifies data, code, or system components without authorization, potentially compromising the integrity of the system.
• R — Repudiation: An attacker performs an action and subsequently denies having done so, or a system fails to maintain adequate records of actions taken, undermining accountability.
• I — Information Disclosure: Sensitive or confidential information is exposed to unauthorized parties, including protected health information (PHI), personally identifiable information (PII), or proprietary data.
• D — Denial of Service: An attacker disrupts or degrades the availability or performance of the system, potentially preventing the device from performing its intended function.
• E — Elevation of Privilege: An attacker gains unauthorized access to capabilities or resources beyond their authorized level, potentially enabling further attacks.
The STRIDE analysis must be applied to each communication interface and data flow identified in Section III of this memorandum. The resulting threat model report must document, for each identified threat: (1) a description of the threat scenario; (2) the affected system component(s) and interface(s); (3) the potential impact on device safety, effectiveness, and data security; (4) a severity rating; (5) the mitigations implemented to address the threat; and (6) the residual risk after mitigations are applied.
The following subsections provide a preliminary mapping of STRIDE threat categories to the major communication interfaces and data flows of the Lumina CGM System. This preliminary analysis is intended to guide the Solstice engineering team in preparing the complete STRIDE threat model report. The analysis presented here is based on the system architecture as understood by Calderwood & Harkness LLP from the technical documentation provided to date and should be validated and expanded by the Solstice engineering team with detailed technical knowledge of the implementation.
IV.B. STRIDE Analysis — BLE 5.2 Sensor-to-Reader Link (C14 ↔ R7)
The BLE 5.2 wireless communication link between the C14 Sensor and the R7 Reader is the most safety-critical communication pathway in the Lumina CGM System. Any compromise of this link could directly affect the accuracy, timeliness, and integrity of glucose measurements presented to the user.
Spoofing. There is a risk that an unauthorized device could attempt to pair with the R7 Reader by impersonating a legitimate C14 Sensor. If successful, such an attack could result in the R7 Reader accepting fabricated glucose data from a rogue device, leading to the display of inaccurate glucose readings and potentially dangerous clinical decision-making. Conversely, a rogue device could impersonate the R7 Reader and intercept glucose data from a legitimate C14 Sensor. Mitigations should include the use of BLE 5.2 LE Secure Connections pairing mode, which employs Elliptic Curve Diffie-Hellman (ECDH) key exchange for secure pairing, along with device identity verification mechanisms that enable each device to authenticate its communication partner prior to exchanging data.
Tampering. The integrity of glucose data in transit between the C14 Sensor and the R7 Reader must be protected against unauthorized modification. If an attacker were able to alter glucose measurement data during BLE transmission, the resulting inaccurate readings could affect the System's Mean Absolute Relative Difference (MARD) accuracy performance and could lead to incorrect clinical decision-making by the user, including inappropriate insulin dosing. Mitigations should include the use of authenticated encryption (specifically, AES-CCM as specified by the BLE 5.2 standard) to provide both data confidentiality and integrity protection for all transmitted data.
Repudiation. The System should maintain adequate records of data transmission events between the C14 Sensor and the R7 Reader to support troubleshooting, audit, and accountability. There is a risk that, without adequate logging, data transmission failures or anomalies could go undetected or could not be investigated after the fact. Mitigations should include audit logging on the R7 Reader that records key events such as sensor pairing, data reception, transmission errors, and connection state changes.
Information Disclosure. Glucose data constitutes protected health information (PHI) under the Health Insurance Portability and Accountability Act ("HIPAA") and personally identifiable information (PII) under various state and international privacy laws. There is a risk that glucose data transmitted wirelessly between the C14 Sensor and the R7 Reader could be intercepted by an unauthorized party through passive eavesdropping on the BLE channel. While the clinical significance of intercepted glucose data in isolation may be limited, the privacy implications are real, and the FDA expects that appropriate encryption be applied to all wireless data transmissions. Mitigations include the use of AES-CCM encryption as specified by the BLE 5.2 standard, which provides confidentiality protection for data in transit.
Denial of Service. The BLE 5.2 wireless link between the C14 Sensor and the R7 Reader is susceptible to denial-of-service attacks, including BLE jamming (using radio frequency interference to disrupt BLE communications) and connection flooding (sending a high volume of connection requests to exhaust device resources). A successful denial-of-service attack on this link could prevent the R7 Reader from receiving glucose data from the C14 Sensor, directly impacting the System's ≤ 5-minute alert latency requirement. If the R7 Reader cannot receive updated glucose data, it cannot provide timely alerts for hypoglycemic or hyperglycemic events, creating a direct patient safety risk. Mitigations should include connection monitoring and automatic reconnection mechanisms, as well as fallback alert capabilities on the R7 Reader (e.g., alerting the user that sensor data has not been received within the expected timeframe, prompting the user to check sensor placement and proximity).
Elevation of Privilege. There is a risk that an attacker could exploit vulnerabilities in the BLE interface to gain unauthorized access to the C14 Sensor's firmware or the R7 Reader's operating system. Such access could enable the attacker to modify device firmware, extract proprietary algorithms or encryption keys, or disable security controls. Mitigations should include a secure boot chain that verifies the integrity and authenticity of all firmware before execution, firmware signature verification that prevents the installation of unauthorized firmware updates, and appropriate access controls that restrict the BLE interface to authorized communication functions only.
IV.C. STRIDE Analysis — BLE Reader-to-Mobile App Link (R7 ↔ Mobile App)
The BLE communication link between the R7 Reader and the Lumina Mobile App presents a threat profile that is analogous in many respects to the sensor-to-reader link described in Section IV.B above, with several important additional considerations arising from the mobile application environment.
Spoofing. An unauthorized application or device could attempt to impersonate either the R7 Reader (to intercept glucose data intended for the legitimate Mobile App) or the Lumina Mobile App (to send unauthorized commands or data to the R7 Reader). The risks are heightened in the mobile environment because the user's smartphone may be in proximity to multiple BLE-capable devices and applications. Mitigations should include mutual authentication between the R7 Reader and the Lumina Mobile App, ensuring that each party verifies the identity of the other before establishing a data exchange session.
Tampering. Data transmitted between the R7 Reader and the Mobile App could be subject to modification in transit, potentially affecting the accuracy of glucose data displayed in the Mobile App and the integrity of configuration commands sent from the Mobile App to the R7 Reader. Mitigations should include encrypted and authenticated communication using the BLE security features and application-layer integrity verification.
Information Disclosure. The same PHI/PII considerations described in Section IV.B apply to this communication link. Additionally, the Mobile App may transmit user credentials, device configuration data, and other sensitive information that must be protected against interception. Mitigations include encrypted BLE communication and application-layer encryption where appropriate.
Denial of Service. Disruption of the R7-to-Mobile App BLE link would prevent the user from viewing glucose data on the Mobile App. However, because the R7 Reader has its own display and alert capabilities, the patient safety impact of this particular denial-of-service scenario is less severe than a disruption of the sensor-to-reader link, provided that the R7 Reader continues to function independently. Nevertheless, the Mobile App may be the user's primary interface, and mitigations should include appropriate error messaging to the user and reconnection mechanisms.
Elevation of Privilege. The Lumina Mobile App runs on consumer mobile operating systems (iOS and Android) that have their own security architectures and privilege models. The Mobile App must be designed to operate within the security boundaries of the mobile OS and must not request or use excessive permissions. Additionally, the Mobile App must be protected against reverse engineering and code injection attacks that could enable an attacker to escalate privileges or modify app behavior. Mitigations include code obfuscation, runtime integrity checking, and adherence to platform-specific security best practices.
An overarching consideration for this communication link is that the Mobile App runs on consumer devices with varied security postures. Users may be running outdated operating system versions with known security vulnerabilities, may have disabled platform security features (e.g., screen lock), or may have installed the Mobile App on jailbroken (iOS) or rooted (Android) devices. The Lumina Mobile App should implement appropriate checks and mitigations for these scenarios, such as detecting jailbroken/rooted devices and warning the user of increased security risk. Mitigations also include certificate pinning to prevent man-in-the-middle attacks even on compromised devices.
IV.D. STRIDE Analysis — Cloud Connectivity (Mobile App ↔ Cloud; R7 ↔ Cloud)
The cloud connectivity interfaces of the Lumina CGM System present a distinct threat profile characterized by exposure to internet-based attack vectors, the involvement of third-party cloud service providers, and the need to protect large volumes of stored health data.
Spoofing. Man-in-the-middle ("MITM") attacks on the network connection between the Lumina Mobile App (or R7 Reader) and the cloud API servers could allow an attacker to intercept, modify, or redirect communications. An attacker could also attempt to impersonate the Lumina cloud API servers to capture user credentials or glucose data, or could impersonate a legitimate user to access cloud-stored health data. Mitigations should include the use of TLS 1.3 for all cloud communications, certificate pinning in the Mobile App and R7 Reader to prevent the acceptance of fraudulent server certificates, and robust user authentication mechanisms.
Tampering. Data stored in the cloud (including historical glucose readings, user account information, and software update packages) could be subject to unauthorized modification by an attacker who gains access to cloud systems or databases. Unauthorized modification of glucose data could affect clinical decision-making if the data is relied upon by healthcare providers; unauthorized modification of software update packages could result in the distribution of malicious firmware or software. Mitigations should include data integrity verification mechanisms (such as cryptographic checksums or digital signatures on stored data), access controls that limit who can read and modify data, and separation of duties for critical operations such as software update publication.
Repudiation. Comprehensive audit logging of all cloud access and data modification events is essential to support accountability, troubleshooting, and regulatory compliance. The cloud infrastructure should maintain immutable audit logs that record user authentication events, data access events, data modification events, and administrative actions. These logs should be protected against tampering and should be retained for a period consistent with regulatory requirements.
Information Disclosure. The cloud infrastructure stores significant volumes of sensitive health data, including glucose readings, user account information, and potentially data shared with healthcare providers and caregivers. This data constitutes PHI under HIPAA and is subject to stringent confidentiality requirements. Mitigations must include encryption at rest for all stored data, encryption in transit (TLS 1.3) for all data communications, access controls that implement the principle of least privilege, and compliance with HIPAA security rule requirements. User credentials must be stored using secure hashing algorithms (e.g., bcrypt, Argon2) and must not be stored in plaintext.
Denial of Service. Cloud service unavailability could impact multiple system functions, including data synchronization, OTA update delivery, remote monitoring data sharing, and user account access. While a cloud service outage should not directly affect the real-time glucose monitoring and alerting functions of the R7 Reader (which should continue to operate independently), it could affect the user's ability to access historical data, share data with caregivers, or receive software updates. Mitigations should include cloud infrastructure redundancy, geographic distribution, automatic failover mechanisms, and graceful degradation of non-critical functions when cloud services are temporarily unavailable.
Elevation of Privilege. The cloud infrastructure must implement robust API authentication and authorization controls to prevent unauthorized access to data and system functions. Role-based access controls ("RBAC") should ensure that each user (patient, caregiver, healthcare provider, system administrator) can only access the data and functions appropriate to their role. API endpoints should be protected against common web application vulnerabilities (injection attacks, broken authentication, excessive data exposure, etc.) as identified by the OWASP API Security Top 10.
IV.E. STRIDE Analysis — Software Update / OTA Update Channel
The software update and OTA update delivery channel is a particularly high-value target for cybersecurity attacks because a compromise of this channel could enable an attacker to distribute malicious firmware or software to a large number of devices simultaneously.
Spoofing and Tampering. The primary threat to the update channel is the injection of unauthorized or malicious firmware/software packages. An attacker who gains access to the update distribution infrastructure, or who is able to intercept and modify update packages in transit, could distribute firmware containing malicious code, backdoors, or functionality that compromises the safety or effectiveness of the device. This threat is critical for all software components of the Lumina CGM System:
• Lumina Firmware v3.4.2 (C14 Sensor, if firmware updates are supported)
• Lumina Reader OS v2.1.0 (R7 Reader)
• LuminaPredict Algorithm v2.1 (integrated in R7 Reader)
• Lumina Mobile App v1.0.3 (iOS and Android)
Mitigations must include a robust code signing infrastructure that ensures all update packages are digitally signed by Solstice using a private key that is securely managed, a secure boot chain on the R7 Reader (and C14 Sensor, if applicable) that verifies the digital signature of firmware before installation and execution, update integrity verification that confirms the update package has not been modified during transit or storage, and rollback protection that prevents the installation of older, potentially vulnerable firmware versions.
Denial of Service. Disruption of the update delivery channel could prevent devices from receiving critical security patches. Mitigations include redundant distribution infrastructure and the ability for devices to retry update downloads.
Elevation of Privilege. An attacker who compromises the update infrastructure could gain effective control over deployed devices. Mitigations include strict access controls on the update infrastructure, multi-factor authentication for administrators, and separation of the update signing process from the update distribution process.
IV.F. Threat Model Documentation Requirements — Action Items
Based on the preliminary STRIDE analysis presented in this Section IV, the following action items are identified:
Action Item 4.1: The Solstice engineering team (under the direction of Dr. Aisling Burke, CTO) must prepare a complete STRIDE threat model report documenting, for each identified threat: (a) a detailed description of the threat scenario; (b) the affected system component(s) and communication interface(s); (c) the potential impact on device safety, effectiveness, and data security; (d) a severity rating (using a defined severity scale); (e) the specific mitigations implemented to address the threat; and (f) a residual risk assessment after mitigations are applied. The report should be organized by communication interface / data flow and should cover all interfaces identified in Section III.
Action Item 4.2: Pinnacle Regulatory Consulting Group LLC (Dr. Sandra Ellison and Thomas Greenbaum) must review the STRIDE threat model report for compliance with the FDA's documentation format expectations, including completeness, clarity, and appropriate level of detail for an FDA submission.
Target Completion: Both action items must be completed prior to the finalization of the Pre-Sub meeting package for submission on June 16, 2025. A preliminary version of the threat model report should be available for Calderwood & Harkness review by June 1, 2025.
V. Software Bill of Materials (SBOM)
V.A. FDA SBOM Requirements
The September 2023 Cybersecurity Guidance establishes a clear and specific requirement that premarket submissions for cyber devices must include a Software Bill of Materials (SBOM). The SBOM is intended to provide the FDA and the device manufacturer with a comprehensive, transparent inventory of all software components included in the device, enabling the identification and tracking of known vulnerabilities associated with those components.
The FDA's SBOM requirements build upon and incorporate the minimum elements established by the National Telecommunications and Information Administration (NTIA) in its published guidance on SBOM minimum elements. Under these requirements, the SBOM must include, at a minimum, the following data elements for each software component:
The SBOM must cover all software components incorporated into the device, including:
• Proprietary software developed by Solstice Biomedical
• Commercial off-the-shelf (COTS) software components
• Open-source software (OSS) components
• Third-party libraries and frameworks
• Operating systems and real-time operating systems (RTOS)
• Communication protocol stacks (e.g., BLE stacks)
• Cryptographic libraries
• Cloud SDKs and API clients
The FDA has emphasized that the SBOM is not a one-time deliverable but should be maintained and updated throughout the device lifecycle as software components are added, removed, or updated. For premarket submission purposes, the SBOM must reflect the software composition of the device as of the time of submission, and any known vulnerabilities associated with the listed components must be identified and addressed.
V.B. SBOM Scope for Lumina CGM System
The SBOM for the Lumina CGM System must cover all four software components of the System, each of which has its own distinct software composition:
Lumina Firmware v3.4.2 (C14 Sensor). The C14 Sensor firmware runs on an embedded microcontroller with limited computational resources. The SBOM for this component is expected to include, at a minimum: the embedded real-time operating system (RTOS) or bare-metal runtime environment; the BLE 5.2 protocol stack (including the vendor and version of the BLE stack implementation); the sensor signal processing libraries used for electrochemical signal conditioning and glucose value calculation; and the cryptographic libraries used for BLE encryption and device authentication. Given the resource-constrained nature of the C14 Sensor, the software composition is expected to be relatively lean, but every component must be documented.
Lumina Reader OS v2.1.0 (R7 Reader). The R7 Reader software environment is more complex and will have a correspondingly larger SBOM. Components to be documented include: the operating system and kernel; the BLE 5.2 protocol stack; display drivers and UI framework libraries; the LuminaPredict Algorithm v2.1 and its dependencies (see below); the OTA update client software; cryptographic libraries; data storage and management libraries; and any middleware or framework components. The R7 Reader's cloud connectivity client (if the R7 connects directly to cloud services) must also be documented.
LuminaPredict Algorithm v2.1. The LuminaPredict Algorithm is integrated within the R7 Reader software but warrants separate SBOM documentation due to its use of machine learning and signal processing libraries, which may include open-source components with their own dependency trees and vulnerability profiles. The SBOM should document all machine learning frameworks, numerical computation libraries, and signal processing libraries used by the algorithm, along with their versions and dependencies.
Lumina Mobile App v1.0.3 (iOS and Android). The Mobile App SBOM is expected to be substantial, as mobile applications typically incorporate numerous third-party libraries and frameworks. Components to be documented include: the mobile development frameworks (native, cross-platform, or hybrid); BLE communication libraries; cloud SDK components (for API communication, authentication, data synchronization); UI frameworks and component libraries; data storage and encryption libraries; and any third-party analytics, crash reporting, or performance monitoring libraries that may be included in the app. The iOS and Android versions of the Mobile App may have different software compositions, and each platform's SBOM should be documented separately.
Cloud Backend Software Components. The extent to which cloud backend software components must be included in the device SBOM submitted to the FDA requires careful consideration. The September 2023 Cybersecurity Guidance focuses on the software that constitutes or is part of the medical device. To the extent that cloud services are integral to the device's safety and effectiveness (e.g., OTA update distribution, which directly affects device integrity), the cloud software components relevant to those functions should be documented. Calderwood & Harkness recommends that this scope question be raised with the FDA during the Pre-Sub meeting.
V.C. SBOM Format and Delivery
The FDA's September 2023 Cybersecurity Guidance recommends that SBOMs be provided in a machine-readable format to facilitate automated vulnerability analysis and tracking. Two widely accepted machine-readable SBOM formats are recommended:
• SPDX (Software Package Data Exchange): An open standard maintained by the Linux Foundation for communicating software bill of materials information. SPDX is an ISO/IEC standard (ISO/IEC 5962:2021) and is one of the NTIA-recognized SBOM formats.
• CycloneDX: An open standard for SBOM developed by the OWASP Foundation. CycloneDX is designed specifically for security and supply chain component analysis and supports rich vulnerability information.
In addition to the machine-readable SBOM, Solstice should prepare a human-readable summary of the SBOM for inclusion in the narrative portion of the 510(k) submission. This summary should provide an overview of the software composition of each system component, highlight any open-source or third-party components with known vulnerabilities, and describe the risk mitigation approach for any identified vulnerabilities.
Critically, the SBOM submission must include known vulnerability information (CVE references) for each software component at the time of submission. This requires that the Solstice engineering team conduct a vulnerability scan of all SBOM components against the National Vulnerability Database (NVD) and other relevant vulnerability databases at the time of submission and document the results. Any components with known unpatched vulnerabilities must be accompanied by a risk assessment explaining why the vulnerability is acceptable in the context of the Lumina CGM System, or a description of the planned mitigation timeline.
V.D. SBOM Action Items
Action Item 5.1: The Solstice engineering team must compile a comprehensive SBOM for all four software components of the Lumina CGM System (C14 Firmware v3.4.2, R7 Reader OS v2.1.0, LuminaPredict Algorithm v2.1, and Mobile App v1.0.3), in both machine-readable (SPDX or CycloneDX) and human-readable formats.
Action Item 5.2: The Solstice engineering team must conduct a vulnerability scan of all software components listed in the SBOM against the National Vulnerability Database (NVD) and document all identified CVEs, their CVSS scores, and their applicability to the Lumina CGM System's specific implementation.
Action Item 5.3: For any software components with known unpatched vulnerabilities, the Solstice engineering team must prepare a documented risk assessment explaining the applicability (or non-applicability) of the vulnerability to the Lumina CGM System, the potential impact if exploited, and the planned mitigations or remediation timeline.
Target Completion: A preliminary version of the SBOM should be available for the Pre-Sub meeting package (by June 2025). The complete and final SBOM, including vulnerability scan results, must be completed concurrent with the 510(k) preparation, with a target date of March 2026 to allow adequate time for review and revision before the April 30, 2026 submission date.
VI. Vulnerability Assessment and Management
VI.A. Pre-Market Vulnerability Assessment
The September 2023 Cybersecurity Guidance requires that premarket submissions include documentation of a vulnerability assessment demonstrating that the manufacturer has systematically identified, evaluated, and addressed known vulnerabilities in the device's software components, communication protocols, and system architecture. The vulnerability assessment is distinct from (but related to) the threat model: while the threat model identifies potential attack scenarios and their mitigations, the vulnerability assessment focuses on identifying specific, known weaknesses in the implemented system that could be exploited by threat actors.
The vulnerability assessment must address, at a minimum:
• Known vulnerabilities in third-party and open-source software components (as identified through the SBOM analysis and NVD scanning described in Section V);
• Known vulnerabilities in the operating systems and runtime environments used by each system component;
• Known vulnerabilities in the communication protocols used by the system (particularly BLE 5.2 and TLS 1.3);
• Vulnerabilities identified through security testing activities, including penetration testing, fuzz testing, and static/dynamic code analysis;
• Configuration weaknesses, default credentials, or insecure defaults that could be exploited.
The vulnerability assessment process should be documented in sufficient detail to demonstrate to the FDA that the manufacturer has employed appropriate tools and methodologies, has assessed all significant vulnerability classes, and has either mitigated or accepted (with documented rationale) each identified vulnerability.
VI.B. BLE 5.2 Protocol Vulnerabilities
The BLE 5.2 communication protocol used by the Lumina CGM System has been the subject of extensive security research, and several vulnerability classes affecting various versions of the Bluetooth and BLE specifications have been publicly documented. The Solstice engineering team must assess the Lumina CGM System's BLE 5.2 implementation against these known vulnerability classes and document the results. Key vulnerability classes include, but are not limited to:
KNOB Attack (Key Negotiation of Bluetooth). This attack exploits a vulnerability in the Bluetooth key negotiation process that allows an attacker to reduce the encryption key entropy to a single byte, rendering the encryption effectively breakable. While the KNOB attack was originally demonstrated on Bluetooth Classic, variants affecting BLE have been investigated. The Solstice engineering team must assess whether the BLE 5.2 implementation used in the Lumina CGM System is susceptible to the KNOB attack or its variants and document the assessment results.
BLURtooth. This vulnerability affects the Cross-Transport Key Derivation (CTKD) mechanism used in devices that support both Bluetooth Classic and BLE. If the Lumina CGM System's BLE implementation uses CTKD, the susceptibility to BLURtooth must be assessed.
SweynTooth. SweynTooth is a family of vulnerabilities affecting the BLE implementations of several major System-on-Chip (SoC) vendors. The specific SoC and BLE stack used in the C14 Sensor and R7 Reader must be identified, and the engineering team must confirm whether the specific SoC/BLE stack version is affected by any SweynTooth variants and, if so, whether patches have been applied.
BLESA (BLE Spoofing Attacks). BLESA exploits vulnerabilities in the BLE reconnection process that can allow an attacker to spoof a previously paired device during reconnection, bypassing authentication. The Lumina CGM System's reconnection behavior must be assessed against this vulnerability.
In addition to these specific vulnerability classes, the Solstice engineering team should assess the BLE 5.2 implementation against general BLE security best practices, including the strength of the pairing process, the robustness of the key exchange mechanism, the proper implementation of encryption and authentication, and the behavior of the implementation in edge cases (e.g., handling of malformed packets, response to unexpected connection state changes).
VI.C. Mobile Application Vulnerabilities
The Lumina Mobile App v1.0.3, as an application running on consumer mobile devices, is subject to a wide range of application-level vulnerabilities. The vulnerability assessment for the Mobile App should be structured around the OWASP Mobile Top 10 vulnerability classification, which identifies the ten most critical security risks for mobile applications:
1. Improper Platform Usage
2. Insecure Data Storage
3. Insecure Communication