FDA Medical Device Cybersecurity Guidance 2026: What to Build Into the Prototype
For founders and product teams building connected medical or firmware-heavy devices: what FDA's February 2026 cybersecurity guidance expects in design, and which controls belong in the next functional prototype.
September 21, 20266 min read
Written by Konstantin Dolgan, Ph.D., NPDP
Founder & CEO, Product Development Engineer
Published September 21, 2026
Short answer: On February 3, 2026, FDA issued revised final guidance Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions.
It supersedes the June 27, 2025 edition and aligns cybersecurity documentation with the Quality Management System Regulation (QMSR), which became effective February 2, 2026.
For connected medical and firmware-heavy devices, authenticity, authorization, availability, confidentiality, and secure, timely updatability belong in architecture and the functional prototype, not after enclosure freeze.
Key takeaways
- FDA revised the guidance on February 3, 2026. It supersedes the June 27, 2025 guidance in the same family and addresses section 524B of the FD&C Act for cyber devices.
- QMSR took effect February 2, 2026. Cybersecurity is part of device safety and the quality management system, including ISO 13485 design and development and risk management.
- FDA encourages a Secure Product Development Framework (SPDF). The goal is to reduce vulnerabilities across the total product lifecycle and support QMSR expectations.
- Premarket documentation should scale with risk. For devices with cybersecurity risk, that can include threat modeling, a cybersecurity risk assessment, an SBOM, architecture views, and cybersecurity testing beyond ordinary software verification and validation. An SBOM is required for cyber devices under section 524B(b)(3).
- FDA calls out five design objectives. They are authenticity, including integrity; authorization; availability; confidentiality; and secure and timely updatability and patchability.
- Prototype implication: Bake in unique identity and authentication, a signed update path, interface and debug-port discipline, logging, and SBOM and component tracking before freezing the PCB and enclosure.
What FDA issued on February 3, 2026
The FDA guidance is titled exactly Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. FDA materials identify docket FDA-2021-D-1158 and an issuance date of February 3, 2026. The revised final guidance supersedes Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, issued June 27, 2025.
The scope includes devices with software, firmware, or programmable logic. It is not limited to network-enabled devices. The listed premarket pathways include 510(k), De Novo, PMA and supplements, PDP, IDE, HDE, BLA, and IND submissions.
FDA guidance represents the agency's current thinking and is non-binding except where specific regulatory or statutory requirements are cited. For the related quality-system transition, see our FDA QMSR 2026 guide for medical device prototypes.
How This Differs from QMSR and from the EU Cra
This FDA cybersecurity guidance, QMSR, and the EU Cyber Resilience Act overlap in product-development practice, but they are not interchangeable. This article does not replace either our QMSR guide or our EU CRA prototype checklist.
Topic | This FDA cybersecurity guidance | QMSR, effective Feb. 2, 2026 | EU CRA |
|---|---|---|---|
Focus | Cybersecurity design, labeling, and premarket documentation, including section 524B cyber devices | Quality management system and ISO 13485:2016 in 21 CFR Part 820 | Horizontal cybersecurity for products with digital elements on the EU market |
Primary audience angle here | US medical and firmware devices with cybersecurity risk | Quality systems and design records for finished devices | Connected hardware sold into the EU |
Prototype hook | SPDF, threat model, SBOM, patch path, and interfaces | Evidence-grade build records and design-controls timing | Identity, OTA, disclosure, and SBOM for the EU market |
Section 524B Cyber Devices in Plain English
As summarized in the guidance, a cyber device under section 524B of the FD&C Act includes software validated, installed, or authorized as a device or in a device. Has the ability to connect to the internet. And contains technological characteristics that could be vulnerable to cybersecurity threats.
The ability to connect can be intentional or unintentional. Examples in the guidance include network or cloud connections, radio-frequency connections such as Wi-Fi, cellular, Bluetooth, or BLE, and hardware connectors such as USB, Ethernet, or serial interfaces.
For cyber devices, sponsors submitting covered premarket applications must provide information ensuring the device meets section 524B(b).
That includes a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits. Processes and procedures that provide a reasonable assurance the device and related systems are cybersecure, including timely patches. And an SBOM covering commercial, open-source, and off-the-shelf software components.
If your prototype already has a USB port or BLE radio, treat cyber-device planning as an architecture question early. This is a planning prompt, not a legal conclusion about a specific device.
Security objectives to design for
FDA calls out the following security objectives for device design:
- Authenticity, including integrity: Data and system states can be trusted as genuine and unaltered.
- Authorization: Users, services, and processes receive only the access appropriate to their roles.
- Availability: Safety-relevant functions and data remain available when needed.
- Confidentiality: Sensitive data is protected from unauthorized disclosure.
- Secure and timely updatability and patchability: The device can receive verified security fixes throughout its supported life.
Premarket information should describe how the device design addresses these objectives. The extent of documentation and testing should scale with intended use, interfaces, environment of use, vulnerability risk, exploitability, and the risk of patient harm.
Prototype cybersecurity gates checklist
Use these gates to decide what belongs in architecture and the next functional build before PCB, firmware, and enclosure choices become expensive to change.
Gate | Why it belongs before freeze |
|---|---|
1. Decide SPDF and secure-development ownership | Name who maintains the threat model and who accepts security requirements as the design changes. |
2. Draft the system threat model | Include supply chain, update servers, external services, and assumptions about the use environment. |
3. Link separate safety and cybersecurity risk assessments | Keep an ISO 14971-style safety risk assessment distinct from the cybersecurity risk assessment, while maintaining traceability between them. |
4. Inventory components and start an SBOM | Track commercial, open-source, and off-the-shelf software. Use machine-readable NTIA minimum elements, with support level and end-of-support where known. |
5. Design unique device identity and authentication | Identity and trust anchors can affect components, provisioning, manufacturing, and service workflows before PCB freeze. |
6. Design role-based authorization | Separate clinical, service, manufacturing, and other roles before temporary prototype access becomes a production assumption. |
7. Design a signed, authenticated update path end to end | Document how firmware is signed, delivered, verified, installed, rolled back, and supported in an updatability and patchability view. |
8. Map every electronic data interface | List wireless, USB, serial, cloud, and other interfaces, then decide which remain enabled in production builds. |
9. Lock down debug ports and factory backdoors | Remove or control development access before tooling and manufacturing fixtures make it harder to revise. |
10. Plan security-event detection and logging | Identify which events should be recorded, retained, reviewed, and made available without creating a new safety or privacy risk. |
11. Define key-storage and rotation assumptions | Decide where cryptographic keys live and how they can be provisioned, protected, replaced, or revoked. Do not claim protections the prototype has not demonstrated. |
12. Schedule cybersecurity testing beyond software V&V | Plan requirements testing, threat-mitigation testing, vulnerability testing, and penetration testing as appropriate to device risk. |
13. Sketch labeling and postmarket response | Outline user security information, vulnerability monitoring, patch planning, and a coordinated vulnerability disclosure process. |
14. Cross-check EU requirements when relevant | If the EU market is in scope, use the CRA prototype checklist without conflating the two regimes. |
Why this belongs before enclosure and PCB freeze
Device identity, cryptographic trust, the update path, the production interface set, and debug access are architecture choices. They can change processor and memory requirements, secure-element options, PCB routing, antenna layout, connectors, service procedures, and sometimes the housing itself.
Waiting until the enclosure and board are frozen can turn a documentation task into an electrical, firmware, and mechanical redesign. Treat cybersecurity gates as idea-to-functional-prototype decisions, using the same discipline applied to design for manufacturing around a critical interface. Our medical device prototyping services explain how these choices fit into an iterative hardware build.
What this article is not
- It is not legal or regulatory advice.
- It is not a claim that every bench model needs a complete SPDF on day one.
- It is not a substitute for reading the FDA guidance PDF and the FDA QMSR page.
- It is not a duplicate of our QMSR or EU CRA guides. Each addresses a different regulatory and product-development question.
Where to go next
If you are proving a connected medical concept, design identity, update trust, and component diligence into the functional prototype rather than around it later.
You can compare approaches through our guides to medical device design companies, medical device product development services, and medical device prototyping.
When you are ready to discuss a build, book a consultation or apply to partner with LA NPDT. This article is educational and is not legal advice.
Sources
- FDA guidance page: Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, February 2026.
- FDA guidance PDF: issued February 3, 2026; supersedes the June 27, 2025 guidance.
- FDA Quality Management System Regulation page: QMSR became effective February 2, 2026.
Frequently asked questions
When was the FDA medical device cybersecurity guidance revised in 2026?
FDA issued the revised final guidance on February 3, 2026. It supersedes the June 27, 2025 edition in the same medical-device cybersecurity guidance family. The revision aligns the document with QMSR terminology and the regulation's February 2, 2026 effective date.
Does this guidance replace QMSR?
No. QMSR is the quality management system regulation that became effective February 2, 2026. The cybersecurity guidance explains how cybersecurity fits quality-management considerations and what to include in premarket submissions for devices with cybersecurity risk.
What is a Cyber Device Under Section 524B?
It is software validated, installed, or authorized as a device or in a device, with the ability to connect to the internet and technological characteristics that could be vulnerable to cybersecurity threats.
Is an Sbom Required?
For cyber devices, section 524B(b)(3) requires an SBOM that includes commercial, open-source, and off-the-shelf software components. The guidance also recommends SBOM documentation more broadly for devices with cybersecurity risk.
What should founders put into the next prototype now?
Prioritize threat-modeling notes, unique identity and authentication, a signed update path, interface and debug-port discipline, security logging, and an early SBOM and component inventory that travels with the design file.
Is this legal advice?
No. This article is educational and is not legal or regulatory advice. Verify decisions against the current FDA guidance documents and consult qualified regulatory counsel for requirements specific to your device, submission pathway, intended use, and risk profile.
Tagged:Product Development
Services related to this guide
- Medical device design companiesWhich firms fit Class I, II and III — and what design controls really cost.
- Product design servicesIndustrial design and CAD taken all the way to manufacturable files.
- Rapid prototypingWorking prototypes in days, from 3D printing to vacuum casting.
- Product development examplesReal projects we designed, prototyped and shipped.
