How a Continuous Glucose Monitor Is Made: Sensors to Bluetooth Data

A continuous glucose monitor (CGM) is a thin enzyme coated sensor that sits in the fluid under your skin, an applicator that inserts it, and a small transmitter with a low power radio and firmware that sends a glucose estimate to a phone, reader or insulin pump every few minutes. The sensor uses the enzyme glucose oxidase, which turns glucose into a tiny electrical current that the transmitter converts into a reading.

Making one means coating a sensor probe, loading it into a single use applicator, building and sealing a battery powered radio, sterilising the sensor kit, calibrating each production lot at the factory and packaging everything in a sterile barrier. In the United States, CGMs that connect to other devices are regulated as integrated CGMs under 21 CFR 862.1355, and since March 2023 every connected medical device submission also has to carry a cybersecurity plan and a software bill of materials. This guide walks through each step, the Bluetooth data path and the security rules, and it gives no medical advice: talk to your clinician about anything to do with treatment.

Key takeaways

• A CGM measures glucose in interstitial fluid, the fluid between cells, not in blood. NIDDK describes it as "very similar" to the blood level, and it can trail blood glucose when levels change quickly, which is why fingerstick checks still have a place.
• At device level the sensor is an amperometric enzyme electrode. In the FDA's De Novo review of one widely used system, glucose oxidase oxidises glucose and produces hydrogen peroxide, and the resulting current is proportional to interstitial glucose.
• The finished product is a sterile sensor and applicator kit plus a transmitter that is either reusable or built into the disposable patch. The FDA review lists radiation sterilisation (ISO 11137), sterile barrier packaging (ISO 11607) and battery safety (IEC 62133) among the standards used.
• Most current sensors are factory calibrated: each lot is characterised at the factory so the user does not need to calibrate with a fingerstick, though many systems still allow it.
• An integrated CGM (iCGM) is a Class II device under 21 CFR 862.1355, with special controls covering accuracy bands, data gaps and a "secure and reliable" data transmission strategy for the devices that receive its readings.
• On 5 March 2024 the FDA cleared the first over the counter CGM, for adults 18 and older who do not use insulin.
• Under section 524B of the FD&C Act, a "cyber device" submission must include a software bill of materials covering commercial, open source and off the shelf components, plus plans to monitor and fix vulnerabilities after the device ships.
• Consumer CGM apps and cloud services are not automatically covered by HIPAA. The FTC's Health Breach Notification Rule covers many health apps that HIPAA does not.

What does a CGM measure, and how does the sensor work?

Interstitial glucose, not blood glucose

According to the National Institute of Diabetes and Digestive and Kidney Diseases (NIDDK), a CGM "estimates what your glucose level is every few minutes and keeps track of it over time." The key word is estimates. The sensor does not touch blood. It sits in interstitial fluid, the fluid that bathes the cells just under the skin, and NIDDK describes that glucose level as very similar to the level in blood.

Very similar is not identical. Glucose moves from capillaries into interstitial fluid, so when blood glucose is rising or falling quickly, the interstitial value trails behind. That physiological lag is one reason NIDDK still says users may need to compare a CGM reading with a fingerstick test and a standard meter if they doubt the reading, are changing an insulin dose, or get a warning alert. It is also why the iCGM rule in 21 CFR 862.1355 sets separate requirements for rate of change accuracy, not only for point accuracy. We do not quote a single lag figure here because it varies by device, sensor site and how fast glucose is changing; each manufacturer's labeling reports the performance its own clinical study observed.

The three parts

NIDDK breaks every CGM into three parts:

1. A sensor inserted under the skin, usually on the belly or arm, held by an adhesive patch. Most are disposable and replaced every 7 to 14 days depending on the model; NIDDK notes that some implantable sensors can last up to 180 days. The over the counter system the FDA cleared in 2024 is labeled for up to 15 days of wear.
2. A transmitter that sends readings wirelessly. On some systems it is a reusable unit clipped onto each new sensor; on others it is built into the disposable patch.
3. A display, which NIDDK lists as a smartphone app, an insulin pump or a dedicated receiver.

NIDDK also distinguishes three use patterns. Real time CGMs push readings automatically. Intermittent scan CGMs measure continuously but need the user to scan the sensor with a reader or phone to view and store data. Professional CGMs record data for a clinician to download later.

The enzyme electrode at device level

The FDA's De Novo decision summary for an interoperable CGM system (DEN170088) describes the measurement plainly: the sensor probe "continuously measures glucose concentration in the interstitial fluid via an enzymatic electrochemical reaction using glucose oxidase." The enzyme catalyses the oxidation of glucose and produces hydrogen peroxide. The peroxide reacts at the electrode surface and generates a current proportional to the interstitial glucose concentration, and the transmitter converts that signal into a glucose value. The review classifies the method as a "quantitative, amperometric assay," which means the device measures current at a fixed applied voltage.

The engineering consequences:

• The enzyme layer is the product. How much enzyme is deposited, how evenly and how it is held in place sets the sensor's sensitivity. That is why coating is the most controlled step in manufacturing.
• Membranes do the hard work. Outer layers limit how fast glucose reaches the enzyme, so the sensor responds across the full physiological range rather than saturating, and they block interfering substances. The iCGM special controls require manufacturers to show clinically acceptable performance in the presence of endogenous substances, foods, supplements and medications.
• Current is tiny. The signal is small, so the analog front end in the transmitter has to be low noise and well shielded, and the firmware filters and smooths it before turning it into a number.
• Sensors drift. The body reacts to a foreign object, the enzyme slowly loses activity and the membrane changes over days. Calibration algorithms and a hard wear limit handle this. The iCGM rule requires "appropriate measures to ensure that disposable sensors cannot be used beyond its claimed sensor wear period," which in practice is enforced in firmware.

How a CGM is made: from raw material to sealed product

Manufacturers do not publish their production lines, and details differ between designs. The table below follows the stages the FDA review documents and the standards it lists, described as general categories rather than any one maker's process.

Steps 1 to 4: building the sensor probe

The working electrode starts as a conductor that can survive implantation and carry a stable current. Some designs use a fine wire, others print or deposit electrodes onto a flexible strip. Either way it must be electrically insulated everywhere except the active window, because any stray exposed metal changes the signal.

The enzyme layer is then laid down. The goal is a repeatable amount of active enzyme in exactly the right place, held so that it does not wash away in body fluid over two weeks. Over it go one or more membranes. The outer membrane deliberately slows glucose so the enzyme is never overwhelmed, which keeps the response proportional across the measuring range; other layers reduce interference from substances that would otherwise react at the electrode. Every additional layer is a source of lot to lot variation, which is why calibration exists.

A reference electrode completes the circuit so the transmitter can hold the working electrode at a constant potential. The finished probe ends in contacts that mate with the transmitter or the on patch electronics.

Step 5: the applicator

The applicator decides whether the sensor ends up at the right depth without kinking. In the FDA's description, the applicator is a single use disposable unit containing an introducer needle that holds the sensor probe; after insertion the needle withdraws and the applicator is removed, leaving the flexible probe behind. The same De Novo review compares study arms that used different applicator mechanisms, including an automated applicator, which shows how much the insertion step affects clinical results.

Step 6: adhesive

The adhesive has to hold for the full wear period through showers and exercise, then come off without injuring skin. NIDDK lists skin redness or irritation from the sticky patches as an issue some users have, and the FDA's over the counter clearance notice lists local infection, skin irritation and pain or discomfort as adverse events reported in that study.

Steps 7 and 8: electronics, firmware and identity

The transmitter is a small sealed radio module, covered in the next section. Each unit is programmed with firmware and a unique identity, usually a serial number the user enters or scans during pairing, and test fixtures check that it advertises, pairs and sends readings before it leaves the line.

Step 9: sterilisation

The sensor sits under the skin, so the kit must be sterile. The DEN170088 review lists ISO 11137 parts 1 and 3 (radiation sterilisation), ISO/TS 13004 (substantiating a sterilisation dose) and ISO 11737 parts 1 and 2 (microbiological methods) among the standards the sponsor used. Radiation is attractive for this kind of product because it penetrates the sealed package, but the dose has to be validated so it sterilises reliably without degrading the enzyme or the plastics.

Step 10: factory calibration

Calibration links the current the electrode produces to a glucose concentration. Older systems required users to enter fingerstick readings during each session. In the De Novo review, the system ships with a calibration code that the user enters at sensor start, so the system does not need user calibration across the 10 day wear period, while still letting users calibrate manually with a blood glucose meter if they choose. The calibration code captures the measured sensitivity of the production lot. Newer designs embed the parameters in the sensor so the user enters nothing.

Factory calibration only works if the manufacturing process is tight enough that every sensor in a lot behaves like the samples tested. That is the reason 21 CFR 862.1355 requires "adequate controls established during manufacturing and at product release."

Steps 11 and 12: packaging and release

The sterile barrier packaging must keep the kit sterile until the user opens it, which is why the review lists ISO 11607 parts 1 and 2. The label carries the lot, expiry date and, where used, the calibration code. Release is a paperwork step with real teeth: each lot's records must show it met the accuracy and sterility specifications before it ships.

What is inside the transmitter?

A CGM transmitter is a tiny embedded system with four main blocks.

The FDA's review of DEN170088 describes its transmitter as "a miniature radio transmitter that incorporates data processing functionality" with a Bluetooth radio transceiver, reusable across multiple sensing sessions and with a battery that lasts three months. Readings were updated every five minutes. The over the counter system cleared in 2024 presents readings in its app every 15 minutes. Many current products put the electronics inside the disposable patch so there is no separate transmitter to manage.

Firmware jobs

The firmware is small, but it does a lot of safety relevant work:

• Signal processing. Sampling the current, rejecting noise and outliers, and smoothing without hiding real change.
• Calibration and glucose estimation. Applying the factory code or embedded parameters, and incorporating optional fingerstick entries where supported.
• Session control. Starting a session, managing warm up, and ending it at the labeled wear limit, which the iCGM rule requires.
• Fault detection. Flagging sensor errors, signal loss and readings outside the measuring range instead of showing a wrong number.
• Storage and backfill. Keeping readings while the phone is out of range and sending them when it reconnects. The iCGM rule requires data showing the device does not allow clinically significant gaps that would stop connected devices from working.
• Radio and security. Advertising, pairing, encryption and bonding, and the message formats the apps and pumps expect.

Factory calibrated versus fingerstick calibrated

The De Novo review makes the point that the system does not require user calibration but allows it, and it reviewed calibration stability accordingly. Always follow your own system's instructions; this table explains design differences and is not guidance on how to use a device.

How do CGMs talk to phones, readers and insulin pumps?

Bluetooth Low Energy and the CGM profile

Almost every current CGM uses Bluetooth Low Energy (BLE). The Bluetooth SIG publishes a Continuous Glucose Monitoring Service (CGMS). Its page lists version 1.0.2 as adopted and describes it as exposing "glucose and other data from a personal Continuous Glucose Monitoring (CGM) sensor for use in consumer healthcare applications." A companion Continuous Glucose Monitoring Profile (CGMP) defined how a collector, such as a phone app, connects to the sensor; on 25 October 2026 the Bluetooth SIG lists CGMP 1.0.1 as withdrawn, so check the SIG's specification list for the current status before designing against it. If you are new to how BLE services, pairing and firmware fit together, our wireless earbuds build guide covers the radio side in more depth.

The CGMS 1.0.2 specification defines these characteristics, and its characteristics table marks every one of them "Authentication required":

Two details matter for safety and security. First, the specification defines an optional end to end CRC (E2E-CRC): when a sensor supports it, measurement and control point values carry a CRC so a collector can detect corrupted data. Second, the Start Session procedure deletes stored data from the previous session, which is why control point writes require authentication and why apps confirm before starting a new sensor.

In practice, many commercial CGMs use proprietary BLE services rather than, or alongside, the standard ones, often with their own application layer authentication. That is a design choice for each manufacturer. The regulatory requirement is outcome based: the iCGM special controls ask for a "detailed strategy to ensure secure and reliable means of iCGM data transmission," not a particular protocol.

Pairing

Pairing ties a sensor or transmitter to one or more displays. Typical flows ask the user to enter or scan a code printed on the sensor or transmitter, which helps bind the app to the right physical device. BLE itself supports several pairing methods with different protections against eavesdropping and interception; choosing the method and adding application layer checks are design decisions documented in the cybersecurity part of the FDA submission.

The DEN170088 review notes that its transmitter had to stay within 20 feet of the receiver with no obstacles between them. Range, body shadowing and phone power saving settings all cause signal loss, which is why backfill matters.

Interoperability: the iCGM classification

On 27 March 2018 the FDA permitted marketing of the first integrated CGM through the De Novo pathway (DEN170088, received 8 December 2017). The FDA's announcement called it the first type of CGM permitted to be used as part of an integrated system with other compatible devices and electronic interfaces, which may include automated insulin dosing systems, insulin pumps and blood glucose meters, and said the authorisation classified the new device type in Class II with special controls. The regulation is now codified at 21 CFR 862.1355, "Integrated continuous glucose monitoring system," amended in the Federal Register at 87 FR 9238 on 18 February 2022. An iCGM is Class II with special controls, so later iCGMs can reach market through a 510(k) by showing they meet the same controls.

The accuracy part of those controls is unusually specific. For adult readings, the lower one sided 95 percent confidence bound of the share of readings within set bands of the reference blood value must exceed:

The rule also bans gross errors outright (no reading below 70 mg/dL may correspond to a blood value above 180, and the reverse) and caps wrong direction rate of change readings at 1 percent. For a security reader, the important part is what sits next to those numbers: special control (b)(2) puts secure and reliable data transmission on the same footing as accuracy, because a pump that doses insulin from a CGM value depends on that value arriving intact and on time.

The automated insulin delivery loop

NIDDK describes an artificial pancreas, also called automated insulin delivery (AID), as a CGM, an insulin pump and a program that shares information between them. The program calculates how much insulin is needed and the pump delivers it, raising, lowering or stopping insulin as glucose moves. That loop is why iCGM data integrity matters: a corrupted or replayed reading is not just a wrong number on a screen when another device acts on it.

What did the FDA's 2024 over the counter CGM clearance change?

On 5 March 2024 the FDA announced it had cleared the first over the counter CGM. The press release describes it as an iCGM intended for anyone 18 and older who does not use insulin, including people managing diabetes with oral medications and people without diabetes who want to see how diet and exercise affect glucose. The FDA said the system is not for people with problematic hypoglycemia, because it is not designed to alert users to that condition. Each sensor can be worn for up to 15 days, readings and trends appear in the phone app every 15 minutes, and the release says users should not make medical decisions based on its output without talking to a health care provider.

What changed in practice:

• No prescription. People can buy a CGM without involving a clinician, which moves the device into a consumer purchase path.
• Consumer apps and accounts. More users with no clinic relationship create accounts, sync data to cloud services and connect third party wellness apps. Privacy expectations shift from a clinical context to a consumer one.
• Same device class. The product is still an iCGM under 21 CFR 862.1355, with the same special controls, including secure transmission.

Separately, on 21 February 2024 the FDA warned consumers not to use smartwatches or smart rings that claim to measure blood glucose without piercing the skin, saying it had not authorised any such device. That warning matters for this topic because it draws a line between an authorised CGM and a wellness gadget that only claims to do the same job.

What cybersecurity rules apply to CGMs?

Section 524B of the FD&C Act

Section 524B of the Federal Food, Drug, and Cosmetic Act came from the Consolidated Appropriations Act, 2023 (the "Omnibus"). FDA's cybersecurity FAQ says the requirements do not apply to submissions sent before 29 March 2023, and that a later change to a previously authorised cyber device that needs premarket review brings the new submission under the law. FDA also says that from 1 October 2023 it expects cyber device submissions to contain the 524B information.

The law covers a "cyber device," defined in section 524B(c) as a device that includes software validated, installed or authorised by the sponsor, has the ability to connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats. FDA's premarket guidance says it reads "software" to include firmware and programmable logic, and reads the ability to connect to the internet to include devices that can connect "whether intentionally or unintentionally, through any means." A CGM whose readings travel through a phone app to a cloud service sits well inside that frame.

A sponsor of a cyber device must, among other things:

• Submit a plan to monitor, identify and address postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure.
• Design, develop and maintain processes and procedures that provide reasonable assurance the device and related systems are cybersecure, and make postmarket updates and patches available.
• Provide a software bill of materials, including commercial, open source and off the shelf software components.
• Comply with other requirements FDA sets by regulation.

The premarket guidance

FDA's guidance "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" was issued on 27 June 2025 and supersedes the 27 September 2023 version; it includes a section on cyber devices under 524B. It is nonbinding, but it sets out what FDA expects to see in a submission:

• Threat modeling performed throughout design and covering the whole medical device system, with traceability between the threat model, the risk assessment, the SBOM and testing.
• Architecture views, including a global system view, a multi patient harm view, an updatability and patchability view, and security use case views.
• An SBOM in which each component comes with its level of support from monitoring and maintenance and its end of support date.
• Labeling for users, including SBOM information made available "on a continuous basis" in a machine readable format, and instructions on how to respond when a vulnerability or incident is detected.

We cover the guidance as a whole in FDA premarket cybersecurity guidance for medical devices.

Manufacturers also run coordinated vulnerability disclosure programs. For example, one major CGM maker's cybersecurity policy page describes a coordinated disclosure program that lets security researchers report device vulnerabilities, and a product advisories page for security updates. For a CGM, threat modeling has to cover the whole path the next section describes, not just the transmitter: the BLE link, the phone app, the pairing flow, the cloud service, follower sharing, the clinic portal and any connection to a pump.

Open source in the ecosystem: Nightscout and do it yourself loops

The CGM world has an unusually active open source community. Nightscout is a cloud application that people can install themselves (its documentation calls this do it yourself, or DIY) or run through a paid hosting service, so an uploader app on a phone can store readings for followers to view remotely. Its documentation says the project is not supported by any company and "is not officially approved or regulated for diabetes therapy," and that DIY users take full responsibility and run it at their own risk. Related community projects, such as the OpenAPS documentation, go further into do it yourself insulin automation, with the same message about personal responsibility.

From a security point of view, Nightscout's own documentation tells users that the API_SECRET must be at least 12 characters (longer is better, ideally generated by a password manager), never to reuse device account passwords for Nightscout, never to share the secret or admin tokens, to grant access with role based tokens, and to set AUTH_DEFAULT_ROLES to denied so that only someone with a token can view the data. Those settings matter because a Nightscout site is a public web application by default.

The CGM data path: who can see what

Two legal points sit on top of this table.

• HIPAA has limits. HIPAA applies to covered entities such as health plans and most providers, and to their business associates. HHS publishes health app use scenarios that explain when an app developer is acting as a business associate; a consumer app you choose for yourself, not one provided on behalf of your provider, often falls outside HIPAA.
• The FTC Health Breach Notification Rule fills part of the gap. The FTC amended the rule in 2024 (89 FR 47028, published 30 May 2024, effective 29 July 2024). It requires vendors of personal health records and related entities that are not covered by HIPAA to notify individuals, the FTC and in some cases the media of a breach of unsecured identifiable health data.

The privacy questions here are close to those for other wearables; our smart ring build guide covers health data privacy for consumer sensors.

Step by step: an SBOM and dependency check for a CGM companion app or data service

This walkthrough is for engineering teams who build software around CGMs: a companion app, a data bridge, a clinic integration or a self hosted dashboard. It produces an SBOM in CycloneDX format, checks the declared dependencies and wires a gate into CI. It does not touch a device or its radio.

Step 1: inventory the repositories that touch CGM data

List every repository in the data path: mobile apps, backend APIs, data import jobs, report generators and any service that reads from a health platform store. Note the language and package manager for each.

# Example layout for a team that builds around CGM data
ls ~/src
# cgm-companion-android   cgm-companion-ios   cgm-bridge-api   clinic-report-job

Step 2: generate a CycloneDX SBOM per repository

OWASP CycloneDX tools can generate an SBOM from the lockfiles and build files you already have. Run these in your own build environment.

# Node.js service (from the repo root, with package-lock.json present)
npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json

# Android app built with Gradle: apply the plugin in build.gradle.kts
#   plugins { id("org.cyclonedx.bom") version "3.5.1" }
# then build the aggregate SBOM (written under build/reports/cyclonedx/)
./gradlew cyclonedxBom

# Python data job using a requirements file
# (check the output options for your installed version first)
cyclonedx-py requirements --help
cyclonedx-py requirements requirements.txt

Keep the SBOM with the build artifacts for each release. Section 524B asks device makers for an SBOM; teams that sit next to device makers increasingly get asked for the same thing.

Step 3: record support level and end of support

FDA's premarket guidance expects each SBOM component to come with its support level and end of support date. CycloneDX does not fill those in for you. Track them in a sidecar file that your release process updates.

# component-support.yaml (team maintained)
- purl: pkg:npm/express@4.21.2
  support: actively-maintained
  end_of_support: unknown
- purl: pkg:maven/com.squareup.okhttp3/okhttp@4.12.0
  support: actively-maintained
  end_of_support: unknown

Step 4: scan the repository and the SBOM

With the Safeguard CLI, scan the source tree and the SBOM file you produced. Results are written as JSON under ./output.

safeguard scan --dir .
safeguard scan --sbom sbom.cdx.json

Step 5: check the container image the API ships in

safeguard scan --image registry.example.com/cgm-bridge-api:1.8.0

Step 6: gate releases in CI

Policies and gates are evaluated in the platform. A gate can Block, Warn or Notify when a build carries a component that breaks policy, and approved exceptions provide the controlled way through when a team accepts a risk for a stated time. In CI, safeguard exec runs the CLI non interactively.

# .github/workflows/sbom-gate.yml (excerpt)
jobs:
  sbom-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Generate SBOM
        run: npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json
      - name: Scan with Safeguard
        run: safeguard scan --sbom sbom.cdx.json

Step 7: harden a self hosted Nightscout site (if you run one)

If you or your organisation runs a Nightscout instance, the project's security guidance comes down to a few settings. Set them in your hosting provider's environment variables, never in a public repository.

# Values are examples. Use a long random secret of at least 12 characters.
API_SECRET=<a long random value from your password manager>
AUTH_DEFAULT_ROLES=denied

Then create access tokens with only the roles each viewer or uploader needs, from the admin tools in the site, and check from a private browser window that the site does not show readings without a token.

Common mistakes

1. Sharing a follow or dashboard link publicly. Live glucose data reveals routines, location patterns and health status. Share with named people through the app's invitation feature, and review the follower list.
2. Leaving a self hosted dashboard open. A Nightscout site without an API_SECRET and denied default roles can be readable by anyone who guesses or finds the URL.
3. Installing unofficial or modified apps without review. Community builds can be valuable, but a modified app that talks to a medical device has no FDA clearance as a system, may not get security updates and may request broad permissions. Know who maintains it and how updates reach you.
4. Ignoring app and phone updates. The phone is part of the medical data path. Manufacturers publish compatible OS versions; updates fix security problems and compatibility issues.
5. Assuming HIPAA covers consumer app data. HIPAA is about covered entities and their business associates. A consumer wellness app you choose yourself may sit under the FTC's Health Breach Notification Rule instead, with different rights.
6. Treating a smartwatch glucose claim as a CGM. The FDA warned in February 2024 that it has not authorised any smartwatch or ring that measures blood glucose without piercing the skin.
7. Device teams producing an SBOM once. Section 524B expects postmarket monitoring. An SBOM that is not regenerated each release, and checked against new vulnerability data, drifts from reality within weeks.
8. Forgetting the cloud and portals in the threat model. Most CGM data exposure risk sits in accounts, sharing and integrations, not in the BLE link.

FAQ

How does a continuous glucose monitor work?

A thin sensor under the skin uses the enzyme glucose oxidase to react with glucose in interstitial fluid, producing a small current proportional to glucose. A transmitter measures that current, converts it to a glucose estimate with calibration data, and sends it over Bluetooth Low Energy to a phone app, reader or pump every few minutes.

Does a CGM measure blood sugar?

Not directly. It measures glucose in interstitial fluid, which NIDDK describes as very similar to blood glucose. When glucose changes quickly, the interstitial value can trail behind blood, which is why systems still describe when to check with a fingerstick meter.

What is an iCGM?

An integrated continuous glucose monitoring system, defined in 21 CFR 862.1355 as a Class II device designed to reliably and securely transmit glucose data to digitally connected devices, including automated insulin dosing systems. It carries special controls on accuracy, data gaps, interference, wear period and secure transmission.

Do CGM sensors need calibration?

Many current sensors are factory calibrated, so the user does not have to calibrate with fingersticks, though some systems allow optional manual calibration. Older or different designs require fingerstick calibration. Follow your own device's instructions.

How are CGM sensors sterilised?

The FDA review of one interoperable CGM lists radiation sterilisation standards (ISO 11137) and microbiological testing standards (ISO 11737) among those the sponsor used, along with ISO 11607 for sterile barrier packaging. Methods vary by manufacturer.

What Bluetooth profile do CGMs use?

The Bluetooth SIG publishes a Continuous Glucose Monitoring Service and Profile. Many commercial systems use proprietary BLE services instead of, or in addition to, the standard ones. FDA's rule requires a secure and reliable transmission strategy rather than a specific protocol.

When did the FDA clear the first over the counter CGM?

On 5 March 2024. The FDA cleared it for adults 18 and older who do not use insulin, and said it is not for people with problematic hypoglycemia.

Is CGM app data protected by HIPAA?

Only in some cases. HIPAA covers health plans, most providers and their business associates. Apps you choose for yourself often fall outside HIPAA, and the FTC's Health Breach Notification Rule may apply instead.

Do medical device makers have to publish an SBOM?

Under section 524B, makers of cyber devices must provide an SBOM to the FDA in their premarket submission, covering commercial, open source and off the shelf components. FDA's premarket guidance also recommends that manufacturers make SBOM information available to users on a continuous basis in a machine readable format.

Is Nightscout FDA approved?

No. Nightscout's documentation says it is not officially approved or regulated for diabetes therapy or treatment and is not supported by any company. DIY users take full responsibility and run it at their own risk.

Why software supply chain hygiene still matters for CGMs

A CGM's sensor chemistry is not software, but almost everything that carries its readings is: transmitter firmware, the BLE stack, the phone app, the cloud API and the clinic integrations all ship third party and open source components that the 524B SBOM has to list and the manufacturer has to keep patched. Safeguard does not analyse devices or firmware images, so the fit here is the software around the device, where the dependency updates and SBOM checks happen.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

To be plain about the fit: Safeguard does not test sensors, analyse firmware images, generate hardware bills of materials or manage devices, and it does not make any medical device secure on its own. It scans repositories, container images and SBOM files for dependencies, matches them against vulnerability data and shows which projects contain a given component and version. Policies and gates can Block, Warn or Notify, with approved exceptions as the controlled way through. If a firmware team already produces a CycloneDX or SPDX SBOM, the components it lists can be checked the same way. Gold Open Source at gold.safeguard.sh gives free CVE intelligence with affected and fixed versions.

The first demo is a real CLI session. Asked to fix a lodash CVE, the assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow fits a CGM companion API or clinic report job that pins an outdated library.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. Teams that handle health data often keep build systems on restricted networks, and the runner scans repositories where they are built.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. It is a quick way to ask which projects carry a given BLE library or HTTP client version on the day an advisory lands, with tool permissions you control.

Click through it at your own pace, or open it full screen.

To try the CLI, download Safeguard and follow the CLI documentation.

Quick check

Sources

• 21 CFR 862.1355, Integrated continuous glucose monitoring system (eCFR)
• NIDDK: Continuous Glucose Monitoring
• FDA De Novo decision summary DEN170088
• FDA: FDA Clears First Over-the-Counter Continuous Glucose Monitor, 5 March 2024
• FDA: Do Not Use Smartwatches or Smart Rings to Measure Blood Glucose Levels
• FDA: Cybersecurity in Medical Devices Frequently Asked Questions
• Bluetooth SIG: Continuous Glucose Monitoring Profile 1.0.1 (listed as withdrawn)
• Bluetooth SIG: Continuous Glucose Monitoring Service 1.0.2
• Nightscout documentation
• Nightscout security guidance
• OpenAPS documentation
• FDA De Novo database entry DEN170088 (received 8 Dec 2017, decision 27 Mar 2018)
• FDA: FDA authorizes first fully interoperable continuous glucose monitoring system, 27 March 2018
• FDA guidance: Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, 27 June 2025
• Bluetooth SIG: Continuous Glucose Monitoring Service 1.0.2 specification (HTML)
• Federal Register: Health Breach Notification Rule, 89 FR 47028, 30 May 2024
• HHS: Health Apps and HIPAA resources
• Abbott: Cybersecurity policy and coordinated disclosure
• CycloneDX Node.js npm SBOM tool README
• CycloneDX Python SBOM tool README
• CycloneDX Gradle plugin README

Last reviewed: 25 October 2026. This article explains device design and regulation and is not medical advice.