Section 524B in Practice: What a Submission-Ready Cybersecurity Package Contains

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.