Section 524B: The Medical Device Cybersecurity Requirements You Can't Ignore

On March 29, 2023, FDA began refusing to accept premarket submissions for cybersecurity-capable medical devices that do not meet the requirements of Section 524B of the Federal Food, Drug, and Cosmetic Act. If your 510(k), De Novo, or PMA submission includes any device with software or network connectivity — and that now describes the vast majority of devices in development — you cannot afford to treat cybersecurity as an afterthought.

What Section 524B Actually Requires

Section 524B, enacted as part of the Consolidated Appropriations Act of 2023, establishes statutory cybersecurity requirements for "cyber devices" — any device that contains software, is intended to connect to the internet or a network, or contains a technological characteristic that could be vulnerable to cybersecurity threats. In practice, this captures nearly every connected medical device.

The law requires manufacturers to submit to FDA:

• A plan to monitor, identify, and address cybersecurity vulnerabilities and exploits post-market
• Processes and procedures to provide a reasonable assurance that the device is secure, to make available post-market updates and patches, and to disclose vulnerabilities in a coordinated manner
• A Software Bill of Materials (SBOM) — a formal inventory of all software components, including commercial, open-source, and off-the-shelf software
• Any other information FDA determines necessary to ensure cybersecurity

The Software Bill of Materials Requirement

The SBOM requirement is the one that most commonly catches companies off guard. An SBOM is a machine-readable, structured inventory of every software component in your device — including third-party libraries, open-source components, operating system versions, and firmware. It needs to identify component names, versions, suppliers, and known vulnerabilities (typically cross-referenced against the National Vulnerability Database).

Why does FDA care? Because a significant percentage of medical device cyberattacks exploit known vulnerabilities in third-party components that manufacturers never tracked. If you do not know what is in your software, you cannot patch it. And if you cannot patch it, patient safety is at risk.

FDA recommends using established SBOM formats including CycloneDX and SPDX. Your SBOM must be updated whenever the software changes — meaning it needs to be a living document, not a one-time deliverable.

What FDA's Cybersecurity Guidance Documents Require

FDA's 2023 cybersecurity guidance document ("Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions") significantly expands on Section 524B's statutory requirements. Key additions include:

• Threat Modeling: A structured analysis of potential attack surfaces, threat actors, and attack scenarios. FDA expects STRIDE or similar frameworks applied systematically to the device architecture.
• Cybersecurity Risk Assessment: Combining threat model outputs with probability and impact analysis — integrated with your ISO 14971 risk management process, not siloed from it.
• Security Architecture Documentation: Data flow diagrams, trust boundaries, authentication mechanisms, encryption protocols, and audit logging capabilities.
• Security Testing Evidence: Penetration testing results, static code analysis, dynamic analysis, and fuzz testing results — with documented findings and their disposition.

Common Deficiency Patterns in 510(k) Cybersecurity Reviews

Based on FDA's published refuse-to-accept decisions and deficiency letters since March 2023, the most common cybersecurity failures in premarket submissions are:

• SBOM missing entirely or covering only first-party software (omitting open-source and third-party components)
• Threat model that is generic and not device-specific — using a template without mapping it to actual device architecture
• Cybersecurity risk assessment that is disconnected from the primary safety risk management file
• No post-market monitoring plan or a plan so vague it provides no meaningful commitment
• Security testing performed only on the device in isolation, not in its intended network environment

Pre-Submission Strategy for Cybersecurity

If your device is connected and you have not yet discussed cybersecurity with FDA, a Pre-Submission (Q-Sub) meeting is strongly recommended before you invest in full cybersecurity documentation. FDA's Division of Digital Health and FDA's Digital Health Center of Excellence have been active in Q-Sub responses for cybersecurity, and they will give you direct feedback on whether your security architecture and documentation plan are aligned with current review expectations.

The cost of redesigning security architecture after a deficiency letter — when you may be six to twelve months into your market timeline — vastly exceeds the cost of getting it right before submission.

The Cybersecurity Mandate That Is Holding Up FDA Submissions

Since March 29, 2023, the FDA has had the authority to refuse to accept submissions for devices that do not include adequate cybersecurity documentation. That authority comes from Section 524B of the Federal Food, Drug, and Cosmetic Act (FD&C Act), enacted under the Consolidated Appropriations Act of 2023. If your device connects to the internet, a network, another device, or any external software environment, this section applies to you — and ignoring it is one of the fastest ways to earn an Refuse to Accept (RTA) decision before your submission ever reaches a substantive reviewer.

At ADB Consulting & CRO Inc., we work directly with startup founders and regulatory teams navigating this new landscape. The goal of this post is to give you a clear, actionable picture of what Section 524B actually requires, how it maps to FDA's current guidance, and what your submission package needs to look like.

How FDA Guidance Translates the Statute Into Practice

The primary reference document is FDA's final guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (September 2023). This guidance operationalizes Section 524B and should be treated as a mandatory framework for any cyber device submission going forward.

The guidance introduces a tiered approach based on cybersecurity risk. Higher Cybersecurity Risk devices — those with greater connectivity, more sensitive data handling, or more direct patient impact — require a more rigorous documentation package. Standard Cybersecurity Risk devices require a streamlined but still substantive set of deliverables. Determining which tier applies to your device is one of the first decisions your regulatory team needs to make, and it requires honest assessment of your threat landscape.

Key Documentation Elements the FDA Expects to See

For most submissions, FDA reviewers will look for evidence of the following:

• Threat Modeling: A systematic analysis of potential threats, attack vectors, and impact to device safety and effectiveness. STRIDE and PASTA are commonly used methodologies.
• Cybersecurity Risk Assessment: Mapped to a recognized framework such as NIST SP 800-30 or the MITRE ATT&CK for ICS framework. This should document residual risk and link directly to your device's risk management file under ISO 14971.
• Security Architecture Documentation: Network diagrams, data flow maps, authentication and authorization mechanisms, encryption standards, and interface controls.
• SBOM: A comprehensive inventory of all software components. The FDA expects this in a machine-readable format, such as SPDX or CycloneDX, and it must include version information sufficient to identify known vulnerabilities.
• Vulnerability Management Plan: How you will monitor for emerging CVEs, assess their applicability, and communicate with customers and FDA when a vulnerability is identified postmarket.
• Software Lifecycle Documentation: Evidence that security is integrated into your SDLC, consistent with secure development practices outlined in IEC 62443-4-1.

Where Startups Get Into Trouble

The most common failure mode we see at ADB Consulting is treating cybersecurity as a documentation afterthought rather than a design input. If your engineering team builds the device and then you ask your regulatory consultant to write a cybersecurity section around it, you are building toward an AI request or, worse, a Not Substantially Equivalent (NSE) decision.

Cybersecurity must be a design control. Under 21 CFR Part 820 and the Quality Management System Regulation (QMSR) effective February 2026 — which aligns Part 820 with ISO 13485 — your cybersecurity requirements belong in the design input record. Threat models should inform architecture decisions. Your risk management file under ISO 14971 should explicitly reference and integrate cybersecurity risks.

A second common gap is the SBOM. Many startups using commercial off-the-shelf software or open-source libraries have never fully inventoried their software stack. When FDA asks for a complete SBOM, discovering that gap mid-submission is an expensive problem.

The Secure Product Development Framework

FDA's September 2023 cybersecurity guidance centers on the Secure Product Development Framework (SPDF) — a lifecycle-based security engineering model that spans concept through post-market decommissioning. The SPDF is not a single standard; it is FDA's term for the integrated collection of security-focused development processes the agency expects to see reflected in your submission artifacts. Key standards FDA references in the SPDF context include AAMI TIR57 (principles for medical device security risk management), IEC 62443-4-1 (secure product development lifecycle requirements), NIST SP 800-30 (risk assessment methodology), and MITRE ATT&CK for ICS (threat intelligence). If your development team cannot map your SDLC artifacts to these frameworks, your submission package will be missing a foundational layer that FDA reviewers will notice immediately.

Common Submission Deficiencies That Will Get You an RTA

Based on patterns across recent submissions, these are the cybersecurity gaps most likely to trigger an Additional Information request or a Refuse to Accept decision:

• SBOM submitted as a spreadsheet or PDF rather than a machine-readable format — FDA's guidance is explicit that the SBOM must be machine-readable (SPDX, CycloneDX, or SWID tags) and exploitable by automated vulnerability tracking tools.
• Threat model without a recognized methodology — a narrative description of potential threats without systematic attacker-goal enumeration using STRIDE, PASTA, or a comparable framework is not adequate.
• Coordinated vulnerability disclosure policy that lacks response timelines — FDA expects defined windows: acknowledge within 24 hours, assess severity within 72 hours, communicate to healthcare delivery organizations within a defined period.
• One-time penetration test submitted as ongoing security validation — Section 524B and the September 2023 guidance require a systematic, ongoing vulnerability monitoring program, not a snapshot assessment from months before submission.
• No authentication, encryption, or audit logging addressed in the security architecture — these are baseline cybersecurity controls, and their absence in documentation signals they were not designed in.
• Cybersecurity omitted from the Instructions for Use — FDA expects the IFU to include operational cybersecurity guidance for healthcare delivery organizations, including network requirements, configuration instructions, and known residual risks.

Postmarket Obligations Are Not Optional

Section 524B does not stop at premarket. The statute explicitly requires an ongoing postmarket cybersecurity program. FDA's postmarket guidance, Postmarket Management of Cybersecurity in Medical Devices (2016, updated in scope by the 2023 guidance), outlines expectations for vulnerability disclosure, patch management, and communication with healthcare delivery organizations (HDOs). You need a published vulnerability disclosure policy and a coordinated vulnerability disclosure (CVD) process before your device ships.

Build Cybersecurity Into Your Regulatory Strategy From Day One

Section 524B has permanently changed the regulatory calculus for connected medical devices. Compliance is not optional, and the documentation burden is significant — but it is entirely manageable when addressed systematically and early. The companies that build cybersecurity into their design controls, risk management, and quality systems from the start will move through FDA review faster and with fewer surprises than those who treat it as a late-stage deliverable.

If you are preparing a submission for a cyber device, or if you are concerned your existing device program is not positioned to meet Section 524B requirements, book a free discovery call with ADB Consulting & CRO Inc. We will assess where you stand, identify gaps, and build a practical path forward. Visit adbccro.com to schedule your call today.

Section 524B Is Not Optional — And FDA Is Paying Attention

If you are preparing a 510(k), De Novo, or PMA submission for a device that contains software or is network-enabled, cybersecurity documentation is no longer a recommendation. Under Section 524B of the Federal Food, Drug, and Cosmetic Act — enacted through the Consolidated Appropriations Act of 2023 — FDA has explicit statutory authority to refuse acceptance of premarket submissions that fail to include adequate cybersecurity information.

That refusal-to-accept authority went into effect on October 1, 2023. Since then, FDA has been clear: submissions that arrive without a coherent, complete cybersecurity package face rejection before substantive review even begins. For a startup burning runway or a mid-size company managing a product pipeline, a Refuse to Accept (RTA) letter is an expensive problem that is entirely avoidable.

This post breaks down exactly what FDA expects, which guidance documents govern the requirements, and how to structure your documentation to pass muster the first time.

The Governing Framework: What You Need to Read

Section 524B itself establishes the statutory mandate, but the operational detail lives in FDA guidance. The primary reference is FDA's final guidance, 'Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions', finalized in September 2023. This document supersedes the 2014 and 2022 draft guidances and is the current controlling standard.

Complementary reading includes:

• FDA's 'Postmarket Management of Cybersecurity in Medical Devices' guidance (2016), which informs how your premarket design decisions are evaluated for lifecycle sustainability
• NIST SP 800-30 and SP 800-53, referenced throughout FDA guidance for risk assessment methodology
• IEC 62443 series, particularly relevant for networked device architectures
• AAMI TIR57, which provides a cybersecurity risk management framework recognized by FDA

Understanding where these documents intersect is essential. FDA does not evaluate cybersecurity in isolation — reviewers look for coherence across your risk management file, software documentation, and the cybersecurity submission package itself.

What FDA Actually Wants in Your Submission

1. A Cybersecurity Management Plan

FDA expects a documented plan demonstrating that your organization will manage cybersecurity risks across the total product lifecycle (TPLC). This is not a one-page policy statement. Reviewers want to see defined processes for vulnerability monitoring, coordinated disclosure, patch deployment, and end-of-life planning. If your plan does not address how you will respond after clearance, it is incomplete.

2. Threat Modeling and Risk Assessment

Your submission must include a structured threat model — typically developed using methodologies such as STRIDE or PASTA — that identifies assets, threat actors, attack vectors, and potential impacts. This feeds directly into your cybersecurity risk assessment, which should align with your ISO 14971 risk management process. FDA expects to see residual risk justification, not just a list of identified threats.

3. A Software Bill of Materials (SBOM)

Section 524B explicitly requires an SBOM. This machine-readable inventory must capture all software components — including third-party libraries, open-source packages, and off-the-shelf software — along with version information. The SBOM is the foundation for post-market vulnerability monitoring. If your development team has not implemented an automated SBOM generation process, that gap needs to close before submission.

4. Security Architecture Documentation

FDA reviewers need to understand your device's attack surface. This means documented network diagrams, data flow diagrams, interface descriptions, and a clear accounting of security controls at each layer — authentication, encryption, audit logging, and session management at minimum. For devices interfacing with hospital networks or cloud infrastructure, expect scrutiny on how your architecture handles untrusted environments.

5. Evidence of Security Testing

Penetration testing results, vulnerability scanning reports, and fuzz testing outputs are expected for devices with significant cybersecurity risk. FDA guidance does not prescribe a specific testing methodology, but your testing approach should be commensurate with the device's risk profile and connectivity. Document your testing scope, tools, findings, and remediation actions — and include any residual vulnerabilities with your rationale for acceptance.

Common Mistakes That Trigger RTA or Deficiency Letters

• Submitting a generic cybersecurity policy rather than device-specific documentation
• Omitting third-party or open-source components from the SBOM
• Failing to align cybersecurity risk assessment outputs with the 14971 risk management file
• Providing penetration testing results without remediation documentation
• No postmarket vulnerability disclosure or patch management process defined

Structuring Your Submission for Review Efficiency

FDA's September 2023 guidance recommends organizing cybersecurity documentation as a dedicated section within your submission — not scattered across the software documentation, risk files, and labeling sections. A standalone cybersecurity section with a clear table of contents, cross-references to supporting documents, and an executive summary of your security posture gives reviewers what they need without forcing them to reconstruct your argument from fragments.

Labeling also matters. Section 524B requires that cybersecurity information provided to users — instructions for secure configuration, supported software environments, and known vulnerabilities — appear in device labeling. This is often missed by teams focused entirely on the technical documentation.

The Bottom Line

Section 524B raised the floor on what FDA will accept. The good news is that the requirements are well-defined, the guidance is specific, and a well-prepared submission can move through review without cybersecurity-related deficiencies. The challenge for most teams is that building compliant cybersecurity documentation requires regulatory expertise, engineering depth, and familiarity with how FDA reviewers actually read these packages.

At ADB Consulting and CRO Inc., we work directly with medical device startups and regulatory affairs teams to build submission-ready cybersecurity packages that satisfy Section 524B requirements from the ground up. We have reviewed the guidance, we know what triggers deficiency letters, and we know how to structure your documentation for first-cycle approval.

Book a free discovery call with Andre Butler today at adbccro.com and find out exactly what your submission needs — before FDA tells you what it is missing.

Section 524B Is Now the Baseline — Not a Bonus

Since the Consolidated Appropriations Act of 2023 gave FDA statutory authority under Section 524B of the FD&C Act, cybersecurity is no longer a check-the-box afterthought for medical device submissions. For any device that contains software or that connects to a network, the agency can — and does — refuse to accept a 510(k), PMA, or De Novo submission that lacks a compliant cybersecurity package. If your submission is going in without one, expect a Refuse to Accept (RTA) letter before a reviewer ever looks at your clinical data.

At ADB Consulting and CRO Inc., we work with device startups and mid-size companies to build these packages from the ground up. What follows is a practical breakdown of what a submission-ready cybersecurity package actually contains, grounded in FDA's 2023 final guidance, 'Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions,' and the requirements embedded in 21 CFR Part 820.

The Governing Framework: What FDA Is Actually Looking For

FDA's 2023 final guidance operationalizes Section 524B and replaces the earlier 2022 draft and 2014 guidance documents. It is structured around two core expectations: first, that manufacturers demonstrate a Secure Product Development Framework (SPDF) is embedded in their Quality Management System; and second, that each submission includes specific cybersecurity documentation tied to the device being cleared or approved.

The SPDF concept maps closely to recognized frameworks including NIST SP 800-218, IEC 62443-4-1, and the Medical Device and Health IT Joint Security Plan. FDA does not mandate a specific framework by name, but they do expect you to identify which one you are following and demonstrate that it is actually integrated into your design controls under 21 CFR 820.30.

The Seven Core Components of a Submission-Ready Package

1. Cybersecurity Management Plan

This document — sometimes called a Cybersecurity Plan or Security Management Plan — describes how you will identify, assess, and respond to cybersecurity vulnerabilities throughout the total product lifecycle (TPLC). It should address your vulnerability disclosure process, patching cadence, coordination with sector-specific agencies like CISA, and how you will communicate with end users and the FDA post-market. FDA expects this to be a living document, not a one-time deliverable.

2. Threat Modeling Documentation

Threat modeling is the analytical backbone of your cybersecurity package. Using a structured methodology such as STRIDE, PASTA, or attack tree analysis, you must identify the threat actors relevant to your device's use environment, the attack surfaces, the potential impact of a compromise, and the mitigations applied. The output should map directly to your security controls — reviewers look for this traceability explicitly. Generic threat models that are not device-specific will generate FDA questions.

3. Security Risk Assessment

Distinct from your standard ISO 14971 risk management file (though it must be integrated with it), the cybersecurity risk assessment applies a security lens to your hazard analysis. This means evaluating risks based on exploitability, attack vector, and potential patient harm. CVSS scoring or an equivalent methodology should be used. FDA wants to see that security risks have been accepted with documented rationale or mitigated to an acceptable level before submission.

3. Software Bill of Materials (SBOM)

The SBOM requirement is one of the most operationally demanding aspects of Section 524B compliance. You must provide a comprehensive inventory of all software components — commercial, open-source, and proprietary — including version numbers, supplier information, and known vulnerabilities. FDA references the minimum NTIA SBOM elements as the floor. The SBOM should be maintained and updated as part of your post-market surveillance process, not generated once and filed away.

5. Security Architecture and Design Documentation

This includes network diagrams, data flow diagrams, interface specifications, and documentation of authentication, encryption, audit logging, and session management controls. Think of this as demonstrating the 'defense-in-depth' principle in practice. FDA expects to see your security architecture described at a level sufficient to evaluate whether the design controls are commensurate with the risk profile of the device.

6. Testing Evidence

Penetration testing, fuzz testing, static and dynamic code analysis, and vulnerability scanning results should all be part of the package. FDA is clear that testing alone is not sufficient — it must be risk-based and tied back to your threat model. Third-party penetration testing from a credentialed firm carries more weight and is strongly advisable for higher-risk devices or those operating in clinical network environments.

7. Labeling and User Communication Materials

Your device labeling, Instructions for Use (IFU), and any end-user security guidance must reflect cybersecurity responsibilities. This includes minimum network security requirements, guidance on password management, and what the operator should do in the event of a suspected breach. FDA considers this part of the submission and will flag omissions during review.

Where Companies Go Wrong

The most common failure modes we see are not technical — they are organizational. Companies treat cybersecurity documentation as a regulatory deliverable rather than an engineering output. That means the threat model is written by a regulatory consultant who was never in the design review meetings, the SBOM is incomplete because the engineering team was not looped in, and the security risk assessment does not connect to the ISO 14971 file in any traceable way. FDA reviewers are trained to spot these disconnects, and they will issue AI questions or Additional Information requests that add months to your timeline.

The second most common failure is submitting a cybersecurity package that was templated from a different device. FDA can tell. Your threat model, your architecture diagrams, and your SBOM are device-specific artifacts. They cannot be recycled.

Start Early — This Is Not a Pre-Submission Sprint

Cybersecurity documentation is a byproduct of doing security engineering correctly throughout your design and development process. If you are beginning to build your 510(k) package six months before submission and cybersecurity has not been part of your design controls, you have a remediation problem, not a documentation problem. The most efficient path is to integrate SPDF requirements at the design input stage, run your threat model in parallel with your hazard analysis, and build your SBOM as a living artifact from the first line of software code.

ADB Consulting and CRO Inc. helps companies get this right from the start — whether you are building your first connected device or remediating a cybersecurity gap identified in an FDA pre-submission meeting. Andre Butler and the ADB team bring deep regulatory expertise to translate FDA expectations into actionable engineering and quality system requirements, so your submission is right the first time.

Ready to Build a Cybersecurity Package That Passes FDA Review?

If you are preparing a 510(k), PMA, or De Novo submission for a connected device and you are not confident your cybersecurity package will survive FDA scrutiny, do not wait for an RTA letter to find out. Book a free discovery call with ADB Consulting and CRO Inc. at adbccro.com. We will review your current state, identify the gaps, and give you a clear roadmap to a submission-ready cybersecurity package — no guesswork, no generic templates.