What the FDA's 2026 Cybersecurity Guidance Actually Requires from Medical Device Manufacturers

The FDA's updated cybersecurity guidance, released on February 3, 2026, reads at first like a light revision. It swaps references to the old Quality System Regulation for the new Quality Management System Regulation and little else on the surface. That impression is understandable. The QMSR had taken effect the day before, on February 2, 2026, and the guidance now points manufacturers to ISO 13485, the quality management standard the regulation folds in by reference. The core technical expectations did not change, and that part is genuinely true.

Treating the update as a citation swap, though, is the kind of assumption that comes back as a deficiency letter. The real change is one of posture, cybersecurity evidence is no longer a separate binder that sits next to the quality system. It now has to run through ISO 13485 itself, through design controls, risk management, and post-market surveillance, and it has to hold together when an auditor follows the thread. Known vulnerabilities are treated as reasonably foreseeable risks the quality system is expected to manage, not as engineering details you tidy up once the device is on the market.

If your organization is already certified to ISO 13485, that is good news, because the structure you need is mostly already there. If you have been keeping your security artifacts in their own stack, separate from the quality system, the February 2026 guidance is a fairly direct instruction to stop doing that.

The statute underneath the guidance

It helps to be clear about what kind of document you are dealing with. FDA guidance describes the agency's current thinking. It is not law, and on its own, it's non binding. The binding requirements come from Section 524B of the FD&C Act, which Congress added through Section 3305 of the Food and Drug Omnibus Reform Act of 2022. That provision was enacted on December 29, 2022 and became effective on March 29, 2023. The guidance exists to explain how you satisfy those statutory duties as a medical device manufacturer and how the FDA evaluates the evidence you submit. Read on its own, the guidance can feel like a wish list, but read next to the statute, it sorts cleanly into what you must do and what the agency would like you to do.

Section 524B applies to a defined category the law calls cyber devices. Under Section 524B(c), a product is a cyber device only if it meets all three of these conditions:

1. It includes software validated, installed, or authorized by the sponsor, either as a device or in a device.

2. It can connect to the internet.

3. It has technological characteristics, validated, installed, or authorized by the sponsor, that could be vulnerable to cybersecurity threats.

The second condition is a more tricky, yet interesting one. The FDA reads the ability to connect broadly. Wi-Fi and cellular are obvious, but so are Bluetooth and Bluetooth Low Energy, and so is a plain USB, Ethernet, or serial port that a technician only ever uses for servicing. The working assumption is that if a device can be connected, someone eventually will connect it, whatever the sponsor intended. So run the three-part test honestly, and run it early, because the answer decides whether the rest of Section 524B applies to your submission at all.

For devices that clear that test, Section 524B(b) sets out three obligations your premarket submission has to satisfy:

1. A postmarket plan, under Section 524B(b)(1): A plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits within a reasonable time, including a coordinated vulnerability disclosure process.

2. Secure processes, under Section 524B(b)(2): Processes and procedures, designed, developed, and maintained, that provide a reasonable assurance that the device and the systems it connects to are cybersecure.

3. A software bill of materials, under Section 524B(b)(3); A Software Bill of Materials otherwise called SBOM, that covers commercial, open-source, and off-the-shelf software components in your device.

These are not nice-to-haves you can defer to a later cycle. If a cyber device submission is missing the required cybersecurity content, the FDA can refuse to accept it, which means the review never starts. And failing to meet the Section 524B(b)(2) duty is treated as a prohibited act under the FD&C Act. Getting this wrong does not earn you redlines. It earns you a refused submission, months of delay, and the revenue that goes with a later launch

The SPDF, and why it lives inside ISO 13485

To meet the QMSR, the guidance recommends building what it calls a Secure Product Development Framework, or SPDF. If you remove the acronym, it because a familiar idea. Think of it as a set of processes that work to reduce the number and the severity of vulnerabilities across the whole life of the product, from the first design conversations through release, post market surveillance, and eventual decommissioning. What the February 2026 update makes plain is that the SPDF belongs inside your ISO 13485 quality system rather than beside it as a separate practice with its own paperwork.

In practice that means wiring security into the parts of ISO 13485 you already operate. Design and development activity under Subclause 7.3. Risk management within product realization under Subclause 7.1. Corrective and preventive action under Subclause 8.5. The guidance also asks you to run a security risk assessment that sits next to, but stays separate from, the safety risk assessment you perform under ISO 14971. That separation matters because security risk does not behave like safety risk. A vulnerability does nothing on its own. It needs someone to choose to exploit it, and that human decision is exactly why ordinary probability math sits awkwardly on security estimates, a point AAMI TIR57 makes clear. The two assessments should talk to each other. A security issue with a safety consequence belongs in the safety file, and a safety issue with a security effect belongs in the security file. They should not be merged into one document that does neither job well.

This is where the standards in the room come in. AAMI TIR57 frames security risk as a function of threats, vulnerabilities, and impacts, and gives you a method that maps onto the ISO 14971 process you already know. ANSI/AAMI SW96:2023 takes that further as a dedicated security risk management standard written for device manufacturers. And the Playbook for Threat Modeling Medical Devices, which the FDA funded and MITRE and MDIC wrote, gives you a concrete way to ask the four questions that matter: what are we building, what can go wrong, what are we going to do about it, and did we do a good enough job. Used together, these let you show a defensible process rather than a pile of assertions.

Your documentation should scale with cybersecurity risk

The most useful idea in the guidance is easy to miss: the documentation you submit should scale with the device's cybersecurity risk, assessed through your security risk assessment, rather than being a fixed checklist applied to every device the same way. Section IV.D says cybersecurity design and documentation are "expected to scale with the cybersecurity risk of that device," and it is explicit that this depends on cybersecurity risk rather than on any documentation level set by a separate software guidance. A product can carry serious software risk and modest cybersecurity risk, or the reverse, and the guidance expects the depth of your cybersecurity documentation to track the second, not the first.

You see that scaling most clearly in two places, threat modeling and the security architecture views, and Appendix 4 of the guidance works through the example directly. A simple product, say one with a single USB port or a software application with limited connectivity, will likely need only one architecture view for each of the global system, multi-patient harm, and updateability perspectives, plus a small set of security use case views. Add networking, wireless, cloud connections, or a commercial operating system, and you will likely need several views, because each of those adds ways an attacker could reach patients or tamper with an update. The views are not there to decorate the file. They are how a reviewer sees, quickly, whether your controls actually sit on top of your real attack surface.

For a typical cyber device, the submission pulls together a cybersecurity risk management report with the threat models and security risk assessment, a set of security architecture views, evidence that each category of security control was built and tested, the security testing reports, labeling that tells users about connectivity and residual risk and secure configuration, the postmarket plan that Section 524B(b)(1) requires, and the SBOM with its supporting vulnerability information. Table 1 in the guidance lays these out in one place. The guidance is careful to add that this is not a checklist you tick off in isolation. The point is that a working SPDF produces these documents as a natural output, which is exactly what an auditor wants to find.

SBOM, security testing, and where CISA fits

Section 524B(b)(3) wants an SBOM covering your commercial, open-source, and off-the-shelf software, along with their transitive dependencies. The FDA asks for it in a machine-readable form consistent with the baseline attributes in the NTIA's Framing Software Component Transparency. On top of those minimums, the FDA further asks for two fields, for each component, that are easy to overlook: the level of support from the component's maker, meaning whether it is actively maintained, no longer maintained, or abandoned, and the component's end-of-support date. Those two fields matter because they tell you which components will stop receiving security fixes before your device leaves the market, which is exactly the information you need to plan updates and replacements.

The FDA does more than mention the CISA catalog. Section V.A of the guidance says that vulnerabilities listed in CISA's Known Exploited Vulnerabilities Catalog, should be designed out of the device, as they are already being exploited, and it treats them as an active risk to the device and its users. So this is not a soft suggestion. So this is not a soft suggestion. It is an expectation that you do not ship a device carrying a flaw that attackers are known to be exploiting. In practice, though, this is not a hard zero, and it would be misleading to treat it as one. The CISA catalog is updated constantly, so a vulnerability can appear on it after your design is locked. What the FDA is really assessing is how you evaluated the exploitability of that flaw in the device's actual use environment, and whether the compensating controls you applied, and demonstrated through testing, bring the residual risk down to a level that is acceptable for the people using the device. The guidance's approach to security risk is built on exploitability rather than probability, so a known-exploited flaw you cannot fully remove has to be answered with controls you can show work, not with an assertion that the risk is low.

What it is not, though, is a CISA mandate on you as the manufacturer. CISA runs the KEV catalog under a binding operational directive, but that directive requires federal civilian agencies to remediate listed vulnerabilities on a set timeline. It does not bind medical device manufacturers, who have no direct regulatory relationship with CISA. For a manufacturer, the obligation to address these vulnerabilities runs through the FDA guidance and Section 524B, not through CISA. The binding SBOM duty itself comes from Section 524B(b)(3) of the FD&C Act. If you also sell into the European Union, the obligation to track and manage components shows up again under the Cyber Resilience Act, Regulation (EU) 2024/2847, which is the parallel worth keeping on your radar.

On testing, the guidance is specific and concrete. It expects evidence that goes well past functional verification: abuse and misuse cases built around malformed and unexpected inputs, robustness and fuzz testing, attack surface analysis, vulnerability chaining, where several minor flaws are combined into a serious one, software composition analysis of the binaries you actually ship, static and dynamic code analysis including checks for hardcoded or default credentials, and penetration testing. For the penetration test in particular, reviewers want to know who did it and how independent and qualified they were, what the scope and duration were, what methods they used, and what they found. AAMI TIR57 adds that penetration testing is typically done on a production-equivalent or final configured system, and testing run against anything less tends to get noticed.

The testing section also carries a mindset shift worth stating plainly. In functional testing you might reasonably ship with a minor defect left in. In security testing, an anomaly that turns out to be exploitable usually has to be fixed, because the harm on the other side of it is a different kind of harm.

What this means in practice

The February 2026 guidance did not raise the technical bar so much as it removed the room to treat cybersecurity as a separate exercise. Security now has to live inside the quality system, traceable through design controls and risk management, and the depth of your file has to match the cybersecurity risk you are actually carrying, not a documentation level borrowed from a software guidance. The practical advice that follows from that is straightforward. Run the cyber device test at the start, not the end. Build the SPDF into ISO 13485 rather than beside it. Keep your security and safety risk assessments separate but connected. Treat the SBOM as something you maintain, not something you generate once and forget. Clearing Section 524B gets your submission through the door. Building these processes so they hold up under inspection, and keep holding up as new vulnerabilities surface across the years your device stays in the field, is the part that actually protects patients.

References

1. FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Guidance for Industry and Food and Drug Administration Staff. Issued February 3, 2026

2. Section 524B of the Federal Food, Drug, and Cosmetic Act, added by Section 3305 of the Food and Drug Omnibus Reform Act of 2022 (FDORA), enacted December 29, 2022, effective March 29, 2023.

3. Quality Management System Regulation (QMSR), amending 21 CFR Part 820 to incorporate ISO 13485:2016 by reference. Final rule, published February 2, 2024, effective February 2, 2026.

4. ISO 13485:2016. Medical devices, Quality management systems, Requirements for regulatory purposes.

5. ISO 14971:2019. Medical devices, Application of risk management to medical devices.

6. AAMI TIR57:2016. Principles for medical device security, Risk management.

7. ANSI/AAMI SW96:2023. Standard for medical device security, Security risk management for device manufacturers.

8. IMDRF/CYBER WG/N60FINAL:2020. Principles and Practices for Medical Device Cybersecurity. March 2020.

9. MDIC, MITRE, FDA. Playbook for Threat Modeling Medical Devices. November 2021.

10. National Telecommunications and Information Administration (NTIA). Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM). October 2021.