
On this page
Published: · Updated:
Key Takeaways
- A measure is a recorded fact (a date, a count); a metric is a calculation from measures with a target attached.
- The FDA guidance gives three example metrics: percentage of vulnerabilities patched, time from identification to patch, and time from patch availability to deployment.
- Premarket submissions describe the metrics, targets, and data sources; postmarket reporting shows the actual numbers.
- Missed metric targets should feed your CAPA system, not sit in a dashboard.
- In eSTAR v7, metrics are their own Cybersecurity Metrics attachment, and the cybersecurity management plan names them and the reporting cadence.
Part of our FDA 2026 medical device cybersecurity submission series. For the full overview, start with FDA Cybersecurity Requirements for Medical Devices (2026).
A cybersecurity measure is a raw number you record, such as the date a vulnerability was found or the date a patch shipped. A cybersecurity metric is calculated from measures and compared to a target, such as median days to patch. The FDA's February 3, 2026 premarket cybersecurity guidance asks manufacturers to track metrics showing they find and fix vulnerabilities on time, and to describe them in the premarket submission.
Most submissions get this section wrong in one of two ways. They list security controls and call them metrics, or they promise "continuous monitoring" with no numbers at all.
The FDA's final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 3, 2026), is specific. It gives three example metrics, all about how quickly vulnerabilities are found, fixed, and deployed.
This post explains cybersecurity measures and metrics in plain terms, shows what the guidance actually says, and walks through a worked example for a fictional insulin pump.
Why This Matters
Section 524B of the FD&C Act requires manufacturers of cyber devices to have a plan to monitor, identify, and address postmarket vulnerabilities, and to provide updates and patches on a reasonable timeline. Metrics are how you prove that plan works rather than just exists.
The FDA's Cybersecurity in Medical Devices final guidance, dated February 3, 2026, ties metrics to the secure product development framework (SPDF). The point is to show the process is effective over time, not that a single test passed.
The stakes are real. CISA's ICS medical advisories regularly describe device vulnerabilities that stayed exploitable for long periods because no patch reached the field. In the 2019 Medtronic MiniMed recall, the FDA's own safety communication explained that affected pumps could not be updated and had to be replaced. A device with no measured, working patch process ends up in the same place.
Metrics also connect to the standards your quality system already uses. ISO 13485:2016 clause 8.4 requires analysis of data to show the quality system is effective. AAMI TIR57 and ANSI/AAMI SW96 expect security risk to be monitored across the device lifecycle, and IEC 81001-5-1 includes vulnerability handling and timely update requirements.
Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); FDA eSTAR Program; FDA Cybersecurity in Medical Devices FAQs (Section 524B).
What is the difference between a measure and a metric?
A measure is a single recorded value; a metric combines measures into something you can judge against a target. Measures answer "what happened?" and metrics answer "is that good enough?"
| Measure | Metric | |
|---|---|---|
| What it is | A raw, recorded value | A calculation from two or more measures |
| Example | Date CVE-2026-XXXX was identified in your BLE stack | Median days from identification to patch release, last 12 months |
| Has a target? | No | Yes, such as "30 days or less for High" |
| Who uses it | Engineers logging events | Management review, the FDA, auditors |
If a number has no target and no trend, it is a measure. That is fine to collect, but it is not what reviewers mean by a metric.
What the February 2026 FDA guidance says about metrics
The guidance asks manufacturers to track measures and metrics that show the SPDF identifies and addresses vulnerabilities in a timely way. It lists three examples.
The guidance's example metrics are: the percentage of identified vulnerabilities that are updated or patched (defect density); the duration from vulnerability identification to when it is updated or patched; and the duration from when an update or patch is available to complete implementation deployment.
Three things stand out:
- All three are about speed and coverage of fixes. None of them count controls, tests run, or training completed.
- The third metric ends at deployment, not release. A patch sitting on a server does not count until it reaches devices in the field.
- They are examples. You can add metrics, but a reviewer will expect these three, or a clear reason one does not apply.
The guidance also asks for this information in the premarket submission, and for PMA devices it recommends including metric results in periodic (annual) reports.
Worked example: measures and metrics for an insulin pump
The table below shows the measures a fictional insulin pump team records, the metric each feeds, a target, and a sample 12-month result. The pump pairs with a phone app over Bluetooth and gets firmware through a cloud service.
| Measure recorded (per vulnerability) | Metric calculated | Target | Sample result (12 months) | Status |
|---|---|---|---|---|
| Vulnerability ID, severity, date identified, date patched or closed | Percentage of identified vulnerabilities patched (defect density) | 100% of Critical/High, 90% of Medium within the year | 7 of 7 High patched (100%); 11 of 14 Medium (79%) | Medium missed, CAPA opened |
| Date identified; date patch released | Median days, identification to patch | Critical 15, High 30, Medium 90 | High median 22 days; Medium median 71 days | Met |
| Date patch released; date each device reported the new version | Median days, patch available to 90% fleet deployment | 45 days | 63 days; phone app relay delayed updates on older Android versions | Missed, CAPA opened |
| Date SBOM component advisory published; date triaged | Median days from public advisory to triage decision | 5 business days | 3 business days | Met |
| Count of devices on unsupported firmware | Percentage of fleet on supported firmware | 98% or more | 96.4% | Watch |
The first three rows are the guidance's examples. The last two are optional additions that make the first three easier to explain.
See also: Home Use vs Hospital Device Cybersecurity Requirements, Indications for Use, Predicates, and Cybersecurity Scope, and Breakthrough Device Designation and Cybersecurity.
Notice what the "Status" column does: two missed targets each lead to a CAPA, so the metric drives a correction instead of just being reported.
Want this checked against your own plan? Our team reviews cybersecurity management plans and metric targets before submission. See our FDA postmarket cybersecurity services.
Where metrics go in the submission and after clearance
Before clearance, you describe the metrics; after clearance, you report the numbers. The premarket submission should define each metric, its target, the data source, and who reviews it.
In eSTAR v7, measures and metrics go in their own Cybersecurity Metrics attachment rather than inside the cybersecurity management plan, though the plan should still name them and say how often they are reported. Our FDA premarket cybersecurity deliverables eSTAR map shows which attachment each deliverable belongs in, and the eSTAR v7 cybersecurity mapping guide lines those attachments up with the February 2026 guidance sections. The cybersecurity management plan guide covers the rest of the plan.
After clearance, missed targets are quality events. Our CAPA and medical device cybersecurity post explains when a missed patch timeline becomes a CAPA and how to verify the fix worked. For the monitoring side, see the postmarket cybersecurity monitoring program guide.
Common mistakes with cybersecurity metrics
The most common mistake is calling a control a metric. "All communications use TLS 1.3" is a design fact, not a metric.
- No targets. "We track time to patch" means nothing without a number to compare against.
- Stopping at release. Measuring until the patch is published skips the guidance's third metric.
- No severity split. One average across Critical and Low findings hides slow fixes for the findings that matter.
- No data source. Reviewers ask where each date comes from: issue tracker, SBOM monitoring tool, device telemetry.
- Metrics with no action. If a missed target never opens a CAPA, the metric is decoration.
Related reading: JTAG UART Debug Port Security for Medical Device Hardware.
How Blue Goat Cyber Approaches This
We start from the patch process you actually run, not a template. We trace how a vulnerability is found, triaged, fixed, released, and deployed, and mark where each date is recorded today and where it is not.
From there we set targets by severity that your team can meet, add the three FDA example metrics and only the extra metrics that help explain them, and write the definitions into your cybersecurity management plan. We map each item to its eSTAR attachment and connect missed targets to your CAPA procedure.
Our team has supported 275+ devices through FDA cybersecurity work. If your metrics already exist, we review them against the February 2026 guidance as part of our FDA postmarket cybersecurity services.
Frequently Asked Questions
What are cybersecurity measures and metrics for medical devices?
Cybersecurity measures are recorded values, such as the date a vulnerability was identified or the date a patch reached a device. Metrics are calculated from those measures and compared to a target, such as median days from identification to patch for High findings. The FDA's February 2026 guidance asks manufacturers to track metrics that show vulnerabilities are found and fixed on time.
Which metrics does the FDA expect to see?
The February 3, 2026 FDA guidance gives three examples: the percentage of identified vulnerabilities that are updated or patched, the time from identification to patch, and the time from patch availability to complete deployment. They are examples rather than a fixed list, but reviewers expect to see them or a clear reason one does not apply to your device.
Is counting security controls a valid cybersecurity metric?
No, and this is a common misconception. A list of controls, such as encryption, secure boot, or multi-factor authentication, describes the design. A metric shows how a process performs over time against a target. The FDA's example metrics are all about how quickly and completely vulnerabilities get fixed and deployed, not how many controls exist.
Do I report actual metric numbers in a 510(k)?
A new 510(k) usually has no field data yet, so the submission describes each metric, its target, the data source, and how results are reviewed. Actual numbers come later through your postmarket processes. For PMA devices, the FDA guidance recommends including metric results in periodic annual reports.
What happens when a metric target is missed?
A missed target should be treated as a quality event. Investigate why, decide whether it meets your CAPA criteria, and verify the correction worked. For example, if fleet deployment of a patch takes longer than your target, find the cause, such as an app relay issue, fix it, and then measure the next release to confirm.
CTA
Need cybersecurity measures and metrics your team can actually hit, written the way the FDA expects? Request a quote for a review of your management plan and metrics. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.
Christian Espinosa, MBA, CISSP, Founder and CEO, Blue Goat Cyber. Christian has built postmarket cybersecurity programs for connected medical devices, including patch timelines and metric targets reviewed in FDA submissions. He previously led military red-team operations. Read more about Christian.
About the author

Christian Espinosa, MBA · Founder & CEO, Blue Goat Cyber
U.S. Air Force Academy graduate and veteran with 30+ years in cybersecurity. Founded Alpine Security in 2014 (acquired 2020), then Blue Goat Cyber in 2022. Has supported 275+ medical devices, with no cybersecurity-related rejections to date. Author of three books including The Smartest Person in the Room. Ironman triathlete and mountaineer.
Sources & references
Primary sources cited in this article. Links open in a new tab.
