The questions we get asked most, answered in the shortest defensible form, with a link to the guide or tool that carries the detail. Written against FD&C Act Section 524B and the FDA's February 3, 2026 final premarket cybersecurity guidance.
New to the rules? Start with our plain-languageFDA cybersecurity guidance explainer (2026): what the February 3, 2026 final requires and how Section 524B fits.
34 of 34 questions shown.
The terms people mix up, and which ones carry FDA rules.
MedTech is an industry term for technology that diagnoses, treats or monitors patients, including devices, diagnostics, medical software and some digital health products. A medical device is a legal term defined in Section 201(h) of the FD&C Act. Every medical device is part of MedTech, but not every MedTech product is a device. A wellness tracker with no medical claims is often called MedTech but is generally not regulated as a device.
Life sciences is the widest group. It covers pharmaceuticals, biotechnology and MedTech, plus research tools and lab suppliers. MedTech is the part that builds devices, diagnostics and health software rather than drugs or biologics. The split matters at the FDA, where drugs, biologics and devices follow separate review paths, so a device maker gains little from the broader life sciences label.
The FDA sorts devices into three classes by risk. Class I is low risk, such as scalpels and elastic bandages, and many are exempt from premarket review. Class II is moderate risk, such as sutures, infusion pumps and insulin pumps, and usually goes through a 510(k). Class III is high risk, such as pacemakers and heart valves, and usually needs a PMA.
No. A scalpel is a Class I device and most sutures are Class II, but neither has software or any way to connect to a network, so neither is a cyber device under Section 524B. Their regulatory focus is material safety, sterility and performance. Cybersecurity documentation comes into play only when a device has sponsor software and connectivity, such as a Bluetooth insulin pump.
No. Section 524B turns on software and connectivity, not risk class. A Class II connected insulin pump and a Class III pacemaker with wireless telemetry are both cyber devices. A Class II suture is not. Even a lower-risk device can fall under Section 524B if it runs sponsor software and can connect, so check every product against the cyber device definition early in development.
Whether the rules apply to you, and which ones.
It is if all three conditions hold: the device includes software validated, installed, or authorized by the sponsor; it can connect to the internet; and it has technological characteristics that could be vulnerable to cybersecurity threats. A USB port, a Bluetooth radio, or a cloud dashboard is usually enough to pull a device in. When it applies, the full premarket cybersecurity package applies with it.
The evidence set does not change; the review mechanics do. Every cyber device needs a cybersecurity plan, a threat model, a machine-readable SBOM, security architecture views, verification evidence, labeling, and a postmarket plan. De Novo adds special controls your postmarket program has to satisfy, and PMA adds supplement decisions for security-relevant changes after approval.
Yes, and usually a broader one. SaMD typically spans a cloud back end, APIs, and a companion mobile app, so the threat model and the SBOM have to cover the whole assembly rather than a single binary. Reviewers reject SaMD packages whose architecture views stop at the app boundary and never describe the server side.
Section 524B applies to submissions, but postmarket obligations follow the device. You still need vulnerability monitoring against the shipped software, a disclosure channel, a patch path, and published end-of-support dates. For devices whose components can no longer be patched, document compensating controls and communicate the residual risk to customers rather than staying silent.
What has to be in the submission, and what makes it credible.
A cybersecurity management plan, a system-level threat model, security architecture views, a machine-readable SBOM with supplier and end-of-support metadata, a vulnerability assessment with VEX, security control descriptions traced to verification evidence, penetration and fuzz testing reports with stated scope, cybersecurity labeling, and a postmarket monitoring and patching plan.
Completeness and traceability. Decompose the whole system into data flows and trust boundaries, apply a named method such as STRIDE per element, score each threat in patient-harm terms using ANSI/AAMI SW96:2023, and trace every threat to a control, a verification test, and a residual-risk entry in the ISO 14971 file. Incomplete trust-boundary coverage is the most common driver of first-cycle deficiencies.
Machine-readable CycloneDX or SPDX, covering commercial, open-source, and off-the-shelf components down to transitive dependencies, with supplier, component name, version, unique identifier, dependency relationship, author, timestamp, support level, and end-of-support date. A human-readable spreadsheet submitted in its place is a common Technical Screening failure.
Yes for any cyber device. Scope it from the threat model rather than from convenience: every external interface, wireless radio, physical port, companion app, and cloud service in the trust boundary. Report the methodology, tooling, duration, findings, and disposition. A web application test submitted for a device whose risk sits in firmware will draw a deficiency.
Yes. The threat model tells us what to test, and the hazard analysis tells us which findings could hurt a patient, so testing starts only once both exist. If you don't have them, we can build the threat model and the cybersecurity input to your hazard analysis first. If you already have them, we can run a gap assessment of both against the February 3, 2026 FDA guidance and fix what is missing. A light review is part of scoping; deeper rework is quoted separately.
Both, weighted heavily toward manual. Automated tooling handles scanning, protocol fuzzing, SBOM generation, and triage of known CVEs, and every test plan should use it. The majority of each engagement is manual penetration testing by a senior tester, because automation cannot find business logic flaws, authorization bypasses, clinical workflow abuse, or chained exploits. Reviewers recognize a scan export submitted as a test report, and it draws deficiencies.
At concept, before the architecture freezes. The threat model generates security requirements, and security requirements are design inputs. Teams that start after verification typically discover an unsigned update path or an unauthenticated interface they cannot change without reopening design controls and repeating testing.
What changes when the device learns.
CR515:2025, published June 23, 2025 and added to the FDA Recognized Consensus Standards database in March 2026, is a consensus report on cybersecurity considerations specific to machine learning-enabled medical devices. It supplies the ML threat catalog and asset taxonomy that generic threat modeling misses: training-data poisoning, adversarial evasion, model inversion, membership inference, model extraction, and pipeline compromise. If your device ships a model, it applies as method.
No. A consensus report contains no shall-statements and has no conformity assessment path, so there is nothing to conform to. Cite it as the method your ML threat model follows and show the resulting threats in the security risk file. Claiming conformity invites a reviewer question with no upside.
GMLP is the lifecycle discipline; cybersecurity is one of the risks it has to control. The GMLP principles on data management, training and test independence, model monitoring, and change control produce exactly the records a reviewer wants when they ask how you prevent poisoning or detect drift. Map your GMLP evidence to the cybersecurity questions rather than filing two unrelated stories.
It moves work earlier. A Predetermined Change Control Plan authorizes future model updates without a new submission, but only if the premarket package defines the cybersecurity envelope of those updates: the threat model, SBOM scope, and test boundary must cover the modifications the PCCP allows, and each modification needs a security testing gate and a rollback plan. Reviewers reject PCCPs whose cybersecurity package treats the model as static.
It is an extension, not a replacement. The SBOM inventories software components; the AIBOM adds the AI-specific artifacts an attacker cares about: pretrained models, weight files, ML frameworks, training and evaluation datasets, and hosted inference endpoints. Ship them as one linked inventory so a reviewer does not have to reconcile two documents.
They need conventional testing plus adversarial testing. Keep the application, firmware, and infrastructure testing, then add evasion attacks against the deployed model, robustness checks under distributional shift, artifact integrity tests, and where relevant, model extraction and inversion attempts. Report both in one methodology so reviewers are not reconciling two reports.
510(k) vs PMA, when a change needs a new filing, and how long cybersecurity work takes.
A 510(k) shows your device is substantially equivalent to a legally marketed predicate. A PMA is required for most Class III devices and must show reasonable assurance of safety and effectiveness on its own evidence. Section 524B and the February 3, 2026 final premarket cybersecurity guidance apply to cyber devices on both pathways, so the core package is the same. PMA reviews tend to look deeper because the device risk is higher.
21 CFR 814.39 requires a PMA holder to submit a PMA supplement, and get FDA approval, before making a change that affects the device's safety or effectiveness. The regulation puts the burden of deciding this primarily on the PMA holder. Listed examples include changes to performance or design specifications, circuits, components or principles of operation. A security patch can fall into this category when it changes how the device works.
A letter to file works when your documented assessment shows the change could not significantly affect safety or effectiveness and does not change intended use. Many routine security patches qualify. A change that adds connectivity, alters the security architecture or introduces new risk usually needs a new 510(k), often a Special 510(k) when the change is to your own cleared device. Your regulatory team makes the filing decision; the cybersecurity evidence supports it.
With Blue Goat Cyber, a full cybersecurity submission package typically takes 6 to 8 weeks once intake documents are in. A single deliverable such as a pen test or threat model usually takes 2 to 6 weeks. Responding to an FDA cybersecurity deficiency takes anywhere from 48 hours to 30 days, depending on whether new testing is needed. Starting during design avoids rework that adds months later.
Under its MDUFA performance goals, the FDA aims to decide a Traditional 510(k) within 90 FDA review days, a Special 510(k) within 30 days and an original PMA within 180 days. The clock stops while the FDA waits for your answers to an additional information request, so real calendar time is often longer. Cybersecurity deficiencies are a common reason that clock stops, which is why a complete package matters.
What goes wrong, and how to answer it.
Five patterns dominate: an SBOM missing supplier, version, or end-of-support fields; a threat model that stops at the device boundary; penetration testing with no stated scope or methodology; security controls that trace to no verification evidence; and a postmarket plan with no vulnerability intake path. All five are visible before you file if someone checks.
Answer in the reviewer's own structure, one deficiency at a time, with the evidence attached rather than promised. Where you disagree, supply the technical justification and the data behind it. Arguing without new evidence is the reliable way to spend another review cycle on the same question.
Yes. Technical Screening checks whether the Section 524B elements are present at all. A missing SBOM, an absent postmarket plan, or an SBOM that is not machine-readable can stop the submission before substantive review begins, which costs weeks before a reviewer has read a single technical argument.
What Section 524B(b)(2) expects after clearance.
Map every SBOM component to CVE feeds and the CISA KEV catalog, triage each hit against the device's intended use, publish a VEX statement for the ones that are not exploitable, and record the ones that are as risk file entries with a remediation timeline. Monitoring without triage produces an unbounded CVE list nobody can action.
Section 524B(b)(2) requires updates and patches on a regular cycle, plus out-of-cycle patches for critical vulnerabilities that could cause uncontrolled risk. Publish the cadence so hospitals can plan, and pre-scope a regression suite for security releases so an urgent fix does not trigger a full verification cycle.
Yes, and it has to be staffed. Publish an intake address or portal, state your acknowledgment and response timelines, and define how findings enter CAPA and the risk file. A disclosure policy that routes to an unmonitored inbox is worse than none, because it creates a documented failure to respond.
Enforcement escalates predictably: an inspection observation on Form 483, then a Warning Letter, then import alerts, seizure, injunction, or a consent decree. In parallel, hospital procurement pauses purchases and future submissions attract closer scrutiny. The regulatory penalty is rarely the largest cost.
30-minute strategy session. No cost, no commitment - just answers from people who've shipped 275+ devices supported.
