510(k) + Section 524B Cybersecurity: How to Scope Both for Connected Medical Devices

When Your 510(k) Also Triggers Section 524B: Scoping Cybersecurity for Connected Devices

If you are developing a connected medical device and planning a 510(k) submission, there is a strong chance your device also qualifies as a cyber device under Section 524B of the Federal Food, Drug, and Cosmetic Act (FD&C Act), as amended by the Consolidated Appropriations Act of 2023. That distinction matters enormously for your submission strategy, your development timeline, and the volume of documentation FDA will expect to review.

This post breaks down how FDA determines whether Section 524B applies to your device, how cybersecurity documentation integrates into a 510(k) package, and how to scope both work streams together from the start rather than treating them as parallel efforts that collide at the finish line.

What Makes a Device a 'Cyber Device' Under Section 524B

Section 524B of the FD&C Act establishes cybersecurity requirements specifically for devices that meet the statutory definition of a cyber device. FDA defines a cyber device as one that meets all three of the following criteria:

• It includes software validated, installed, or authorized by the manufacturer.
• It has the ability to connect to the internet.
• It contains any such technological characteristics that could be vulnerable to cybersecurity threats.

The practical implication: if your device runs embedded software and communicates over Wi-Fi, Bluetooth, cellular, or any other network interface, you are almost certainly within scope. FDA's 2023 final guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, provides the authoritative framework for how this definition is applied in premarket review. Sponsors should carefully review that guidance alongside the statutory language before scoping any submission.

Devices that rely solely on non-networked, non-connected software components may fall outside Section 524B scope, but that determination requires a careful, device-specific analysis. FDA does not provide a bright-line exemption simply because a device is not internet-connected in its primary function. If connectivity exists anywhere in the device architecture, assess the full system boundary before concluding Section 524B does not apply.

Cybersecurity Documentation Is Not a Separate Filing

One of the most common misconceptions we see from startup founders and regulatory affairs teams approaching their first connected device submission is the belief that cybersecurity documentation gets submitted separately from the 510(k). It does not.

Under FDA's current framework, cybersecurity information is submitted as part of the 510(k) package. It is reviewed alongside your predicate analysis, performance testing, labeling, and software documentation. If your cybersecurity documentation is incomplete or inconsistent with the rest of your technical file, FDA can issue a Refuse to Accept (RTA) determination or an Additional Information (AI) request that stops the review clock entirely.

FDA's acceptance checklist for 510(k) submissions, as reflected in the guidance and FDA's Refuse to Accept Policy for 510(k)s, now includes cybersecurity-specific line items for cyber devices. That means reviewers are assessing whether your submission includes a Software Bill of Materials (SBOM), a cybersecurity risk management plan, and evidence that your Security Development Lifecycle (SDLC) was followed, before substantive review even begins.

The Core Cybersecurity Documentation FDA Will Review

For a cyber device 510(k), FDA expects the submission to include documentation addressing the following areas, consistent with the 2023 premarket cybersecurity guidance:

• Cybersecurity risk management: A plan and process documented in alignment with recognized standards such as AAMI TIR57 or NIST frameworks, covering threat modeling and residual risk assessment.
• Software Bill of Materials (SBOM): A comprehensive inventory of all software components, including third-party and open-source elements, formatted to meet FDA's minimum expected elements.
• Security architecture: Diagrams and descriptions of the device's security controls, authentication mechanisms, data encryption approach, and network interfaces.
• Vulnerability management plan: A post-market plan demonstrating how the manufacturer will monitor, assess, and address cybersecurity vulnerabilities over the device lifecycle.
• Patch management plan: How software updates and security patches will be deployed, communicated to users, and documented.
• Labeling: Cybersecurity-specific labeling disclosures as called out in 21 CFR Part 801 and FDA's labeling guidance for cyber devices.

Scoping Both Work Streams Together: A Practical Approach

The mistake most teams make is treating the 510(k) work stream and the cybersecurity work stream as sequential. The 510(k) team finalizes predicate selection and performance testing while the cybersecurity team runs threat modeling in a separate lane. They meet three weeks before submission and discover the security architecture documentation does not align with the device description in Section 10 of the 510(k).

The right approach is to scope both at project initiation. Here is how to frame that work:

• Assess early: At the start of regulatory strategy development, assess whether Section 524B applies to your specific device based on its software content and connectivity profile. Do not defer this assessment.
• Align device description and security architecture simultaneously: The device description in your 510(k) and the security architecture in your cybersecurity documentation must describe the same system. Build them in parallel.
• Map predicate selection to cybersecurity posture: If your predicate is an older device without connectivity, be prepared to address how cybersecurity features represent technological enhancements that do not raise new questions of safety and effectiveness under 21 CFR 807.87.
• Review FDA's guidance against your SDLC records: FDA reviewers will assess whether your cybersecurity risk management documentation is consistent with how your development process was actually executed. Prepare records that reflect the actual development history.
• Build SBOM generation into your development pipeline: Do not attempt to reconstruct an SBOM after development is complete. It will be incomplete and inconsistent.

Why Getting This Right Matters Before You Submit

A 510(k) that lacks adequate cybersecurity documentation for a cyber device is not simply deficient in one section. It signals to FDA reviewers that the sponsor may not have a mature understanding of the device's risk profile. That perception can affect how the entire submission is reviewed. Taking the time to prepare a thorough, well-organized cybersecurity package that integrates seamlessly with your 510(k) is one of the highest-leverage investments a regulatory team can make before filing.

At ADB Consulting & CRO Inc., we work directly with medical device startups and established manufacturers to assess their cyber device status, prepare cybersecurity documentation aligned with FDA's premarket guidance, and scope 510(k) and Section 524B requirements as a single integrated work stream from day one.

If you are preparing a connected device submission and want an expert review of where your cybersecurity documentation stands relative to FDA expectations, book a free discovery call with Andre Butler today at adbccro.com. Let us assess your submission strategy before FDA does.

If this applies to your program, our 510(k) Gap Assessment walks through the process in detail.