FDA Section 524B Cybersecurity Gap Assessment

Statutory & Guidance Requirements

What FDA Requires for Every Cyber Device Submission

Seven distinct content requirements apply to any device that contains software and connects to a network. Missing any one of them is grounds for an RTA finding.

Cyber Device Definition

Does My Device Qualify as a Cyber Device Under Section 524B?

Section 524B applies only to devices that meet FDA's three-part statutory definition of a "cyber device." All three elements have to be true — a device that fails any one of them falls outside 524B's scope, even if it otherwise resembles a connected product.

• Includes software. The device includes software the sponsor installed, put in place, or otherwise authorized to run on the device — firmware counts.
• Can connect to the internet. The device has the ability to connect to the internet, whether directly (Wi-Fi, cellular) or indirectly through another product, network, or gateway.
• Carries a cybersecurity vulnerability. The device contains technological characteristics the sponsor put in place or authorized that could be vulnerable to cybersecurity threats.

FDA reads "ability to connect" broadly — a device that connects only through a companion app, a charging station with network access, or an intermediary router still meets the second prong. Devices with no software at all, or software with no network-facing pathway of any kind, fall outside the definition. Most connected Class II and Class III devices submitted today meet all three prongs.

Qualification In Practice

Does Your Device Qualify? A Practical Walkthrough

The three-part test above is easy to state and surprisingly easy to misapply at the edges. In our gap assessments, the qualification question rarely gets stuck on the plain reading of the statute — it gets stuck on a short list of recurring edge cases.

• Software-only products and SaMD with no physical device. Still qualifies — a cloud-hosted or app-delivered SaMD product meets the connectivity prong the same way a networked hardware device does. Treat standalone software as in-scope by default.
• Legacy devices already cleared and never resubmitted. Doesn't qualify yet on its own, but the moment any new submission touches that device family — even an unrelated labeling change — 524B attaches regardless of the original clearance date.
• Accessories and companion apps. An accessory that itself contains software and can connect qualifies independently. A companion app that's the only network pathway for an otherwise offline device is what makes the primary device's connectivity prong true — not a reason to treat the app as out of scope.
• Devices with removable or optional connectivity modules. Qualifies if the sponsor authorizes the connective option at all, even if most units ship with it disabled — the test is "put in place or authorized," not "present in every unit sold."
• USB-only or Bluetooth-only devices with no internet or cloud dependency. Qualifies — the statute's connectivity prong is satisfied by connection to "another product" alone, independent of any internet access.

Rule of thumb: if your device's software can exchange data with anything outside itself — a phone, a hub, a cloud service, even over a USB cable — assume Section 524B applies until a documented three-prong analysis says otherwise.

Software Bill of Materials

FDA SBOM Requirements: What Section 524B(b)(3) Expects

Section 524B(b)(3) requires a Software Bill of Materials — a complete inventory of every software component in the device, including commercial, open-source, and off-the-shelf components, each with version information. FDA's expectation is a living document, not a one-time snapshot: it should stay current as components are patched or replaced across the device's lifecycle.

FDA does not require one specific SBOM file format, but its guidance and the eSTAR template point to the two machine-readable formats the industry has standardized on: SPDX (Software Package Data Exchange) and CycloneDX. Either is acceptable as long as it is machine-readable and carries, at minimum, the elements the NTIA's minimum-elements framework specifies — component name, version, supplier, and known dependency relationships. A spreadsheet or PDF component list does not satisfy the machine-readable expectation on its own; the underlying data needs to also exist as an SPDX or CycloneDX export.

The gap assessment reviews whichever component inventory you already have — even an informal one — against these completeness and format expectations, rather than requiring a specific starting template.

SBOM In Practice

SBOM in Practice: SPDX vs. CycloneDX and What Actually Gets Rejected

FDA's format-agnostic language above is accurate but incomplete on its own. In practice, the choice between SPDX and CycloneDX usually comes down to what a manufacturer's existing toolchain already generates rather than a regulatory preference — and reviewers reject far more SBOMs for completeness gaps than for format choice.

SPDX tends to fit organizations already documenting license compliance, since it originated in that space and carries strong licensing metadata. CycloneDX tends to fit organizations coming from a security-tooling background, since it was built for vulnerability and dependency-tracking use cases and integrates more directly with common software-composition-analysis scanners. Either format satisfies FDA's machine-readability expectation when it's complete.

The completeness failures we see recur across both formats: dependency depth that stops at the first layer of libraries instead of tracing transitive dependencies, component entries missing version numbers — the single most common finding — and a generation date that predates the device's current software build, which is evidence the document wasn't regenerated after the last release.

Before submission, we run a short self-check against whatever inventory a client already has: does every component carry a version, does the dependency tree go at least two layers deep, and does the generation date match the build under review. For a deeper walkthrough of SBOM construction, see our SBOM requirements guide.

Premarket Documentation

What Goes Into the eSTAR Cybersecurity Section for a Premarket Submission?

FDA's eSTAR template — used for 510(k), De Novo, and PMA submissions — includes a dedicated cybersecurity section for any device meeting the cyber device definition. That section expects five categories of documentation, each tracing back to the obligations above: a cybersecurity management plan describing how the sponsor will maintain security across the device lifecycle, a threat model, security architecture views, a vulnerability/risk assessment, and security testing evidence.

The security architecture views FDA expects typically include a system-level architecture diagram showing all interfaces, data flows, and trust boundaries; an interoperability diagram if the device connects to other systems; and a global system view for networked device families. These are the documents FDA reviewers use to check that the threat model's assumptions match how the device actually communicates.

Threat modeling follows a structured methodology — FDA references AAMI TIR57 (Principles for medical device security — Risk management) as an accepted framework. The threat model needs to identify assets, entry points, and attack surfaces, then map credible threats against each one with a documented risk rationale for what was, and wasn't, mitigated.

Collectively, FDA calls this lifecycle approach — security built into design, confirmed through testing, and maintained after release — the Secure Product Development Framework (SPDF). A submission's cybersecurity section is evidence that an SPDF was actually followed, not a static bundle of documents assembled at the end.

If your submission is a 510(k), see our 510(k) Gap Assessment for how cybersecurity documentation fits into the broader submission package.

Testing Evidence

Does FDA Require Penetration Testing for Cyber Device Submissions?

Yes — FDA's premarket cybersecurity guidance expects security testing evidence, and penetration testing is the specific method FDA names for confirming that a device's security controls hold up against realistic attack attempts, not just design-stage analysis. Vulnerability scanning — static and dynamic analysis of code and third-party components — is expected in addition to, not instead of, penetration testing.

FDA's stated expectation covers testing at multiple levels: fuzz testing of network-facing interfaces, vulnerability scanning against the SBOM's known-CVE data, penetration testing of the device and any companion apps or cloud backend, and testing that specific security controls — authentication, encryption, access control — function as designed. Devices with anti-rollback protection, which prevents an attacker from forcing a device back to an older, vulnerable firmware version, are expected to have that mechanism tested and documented as part of this evidence set when the device's architecture supports firmware updates.

The gap assessment does not conduct this testing — testing is a client-provided input, arranged through your own test lab or security firm — but it does review whether your existing testing evidence, or testing plan, covers what FDA's guidance expects before you submit.

Gap Assessment Service

One Flat Fee. Every Gap Identified Before Submission.

The gap assessment reviews your existing documentation against FDA's 524B content expectations and delivers a written report. Remediation services are scoped separately based on what the report finds.

524B Compliance & RTA Risk

What Does a Section 524B Refuse-to-Accept Deficiency Actually Look Like?

An RTA finding under 524B is rarely "the SBOM was missing entirely." In practice, the deficiencies FDA cites most often are narrower and easier to miss: an SBOM that lists components but not versions, a threat model that doesn't trace back to the device's actual architecture diagram, a vulnerability assessment that scores risk using raw CVSS scores instead of clinical-safety-adjusted severity, or a coordinated disclosure policy that describes a process but doesn't name a point of contact or timeline.

Because RTA resets the review clock rather than pausing it, a 524B-related RTA is one of the more costly submission mistakes available — the full administrative review cycle restarts once the missing elements are resubmitted. Sponsors researching section 524B compliance ahead of submission are almost always trying to avoid this specific outcome rather than resolve an open technical question.

The gap assessment is built around this pattern: it checks each 524B content expectation against what FDA reviewers are actually citing in deficiency letters, not just against the statute's plain text.

Deficiency Patterns

What 524B Deficiencies Actually Look Like

Across the assessments we run, the same handful of deficiency patterns account for most of what gets flagged — pattern-level observations, not any one client's specific finding.

• Missing or non-machine-readable SBOM. Reviewers flag a component list that exists only as a spreadsheet or PDF export. A sufficient response is an SPDX or CycloneDX export with version data for every component, regenerated against the submitted build.
• Threat model that doesn't map to the architecture. Reviewers flag a threat model built from a generic template that doesn't reference the device's actual data flows or trust boundaries. A sufficient response traces every identified threat to a specific interface or component on the submission's own architecture diagram.
• No postmarket vulnerability management plan. Reviewers flag a plan describing intent to "monitor for vulnerabilities" without naming who monitors, how often, or what triggers a patch decision. A sufficient response names the responsible role, monitoring cadence, and severity thresholds tied to the device's actual field-update mechanism.
• Generic SPDF boilerplate. Reviewers flag cybersecurity management plan language copied from guidance text rather than describing the sponsor's own development process. A sufficient response names the sponsor's actual design-control and testing procedures and maps them to each SPDF stage.
• Unaddressed third-party and off-the-shelf components. Reviewers flag an SBOM that lists OTS software — an embedded OS, a communications stack — without addressing whether known vulnerabilities in that component were assessed. A sufficient response includes a vulnerability cross-reference for every OTS component, not just custom-developed code.
• No update or patch pathway. Reviewers flag a postmarket plan that assumes field updates are possible without describing the mechanism, or assumes none are possible without addressing how a critical vulnerability would be handled. A sufficient response matches the device's actual update capability, including an honest answer for devices that have none.

Postmarket Obligations

What Postmarket Cybersecurity Obligations Does Section 524B Create?

Section 524B(b)(1)(B) and (b)(4) extend cybersecurity obligations past clearance. A postmarket vulnerability management plan needs to describe how the manufacturer will monitor for new vulnerabilities — including vulnerabilities discovered in third-party SBOM components after clearance — assess their severity, and issue patches or updates within a reasonable time relative to the risk.

Coordinated vulnerability disclosure (CVD) is the specific mechanism FDA expects for the disclosure half of this obligation: a documented process, typically aligned to ISO/IEC 29147 and 30111, for accepting vulnerability reports from external researchers, working with them on a disclosure timeline, and communicating fixes to affected customers without exposing the vulnerability before a patch exists. A policy statement alone isn't sufficient — FDA expects the underlying process (a security contact, an intake channel, a triage SLA) to actually exist.

Patching and update obligations aren't unlimited — FDA doesn't expect every device to receive over-the-air updates. What it expects is that the sponsor's plan matches the device's actual update mechanism, or lack of one, and that the plan is honest about how a device with no field-update capability will be handled when a critical vulnerability is found.

Legacy & Already-Marketed Devices

Does Section 524B Apply to Devices Already on the Market?

524B's documentation requirements attach to premarket submissions, not to the installed base directly — a device cleared in 2019 that has never had a new submission filed is not retroactively required to produce an SBOM or threat model today. The obligation is triggered the moment that device's manufacturer files any new premarket submission — a new 510(k) for a labeling change, a PMA supplement, even a De Novo for a related product — for a device that meets the cyber device definition.

This creates a practical planning issue for manufacturers with long-lived device families: a legacy device with no cybersecurity documentation on file can suddenly need a full 524B package the moment an unrelated design change requires a new submission. Sponsors with aging connected-device portfolios are often better served building the SBOM and threat model ahead of time, before a submission forces the timeline.

Separately, FDA's broader postmarket cybersecurity expectations — vulnerability monitoring, patching — apply as a general quality-system matter regardless of submission history. The 524B statute's premarket documentation trigger is distinct from the ongoing postmarket vulnerability management expectation that already-marketed connected devices are expected to maintain.

Effort & Cost

Effort and Cost, Honestly

The gap assessment itself is a $3,495 flat fee — a fixed two-week engagement regardless of device complexity, since its scope is a structured document review, not open-ended work. Where effort actually varies is in remediation, which is scoped from the assessment's findings rather than priced upfront.

Three factors drive remediation effort more than anything else: how mature the existing documentation already is — a device with a draft SBOM and threat model in hand needs far less work than one starting from a blank page; how many distinct network interfaces and communication pathways the device has, since each generally needs its own entry in the threat model and architecture views; and how much off-the-shelf and third-party software the device relies on, since each OTS component needs its own vulnerability cross-reference in the SBOM.

None of this is priced here — remediation is scoped per engagement once the gap report identifies what's actually missing — but knowing what drives the estimate before you start is usually more useful to a sponsor than a number would be.

How It Works

From Kickoff to Written Report in Two Weeks

Get Started

Tell Us About Your Device

Submit your details and we will confirm next steps within one business day. The kickoff call takes about 60 minutes — we review your current documentation and set the assessment timeline.