Cybersecurity

Since 2023, an Insecure Device Is an Unapprovable One.

Cybersecurity strategy for cyber devices — Section 524B, secure product development, SBOMs, and the postmarket vulnerability duties that never end.

From guidance to statute

Cybersecurity Stopped Being a Best Practice and Became a Filing Requirement.

For a decade, device security lived in guidance — recommended, negotiable, uneven. The 2022 omnibus ended that: Section 524B of the FD&C Act made cybersecurity a statutory condition of marketing authorization for any “cyber device,” effective March 2023, and since October 2023 FDA can refuse to accept a submission that arrives without it.

The definition is broad by design — software, an internet connection, and vulnerability to threats makes you a cyber device. The expectations are spelled out in FDA’s premarket cybersecurity guidance, finalized in June 2025 and revised in 2026 to align with the QMSR. We build security into the file the way the statute assumes it was built into the product — because a deficiency response is the most expensive place to do threat modeling.

A vivid close-up of colorful source code on a screen
The reviewable surface

Every dependency you ship is now a disclosure. The SBOM turns your codebase into a ledger.

The statutory spine

Four Obligations, Written Into the Act.

Section 524B(b) is short enough to memorize and demanding enough to reorganize an engineering department. This is the dossier the submission is screened against.

(b)(1)Monitor & address

A plan for postmarket vulnerabilities

Includes coordinated disclosure

Submit a plan to monitor, identify, and address vulnerabilities and exploits — with coordinated vulnerability disclosure and related procedures. A security researcher’s email needs a documented destination before clearance, not after the headline.

(b)(2)Reasonable assurance

Processes that make the device secure

The SPDF expectation

Design, develop, and maintain processes providing reasonable assurance that the device and related systems are cybersecure — and make updates and patches available on a reasonable schedule, plus out-of-cycle for critical vulnerabilities.

(b)(3)The bill of materials

A software bill of materials

Machine-readable

An SBOM covering commercial, open-source, and off-the-shelf components. FDA reads it the way an auditor reads a ledger — assembled the week of submission, it shows.

(b)(4)The open clause

Whatever FDA requires next

Future-proofing, by statute

Compliance with “such other requirements” the agency may add by regulation. The statute anticipates the threat landscape moving — your security program has to anticipate the statute.

And it screens at the front door: since October 1, 2023, FDA can refuse to accept a cyber-device submission that omits 524B content. Security gaps that used to surface as review questions now stop the clock before it starts.

A detailed close-up of a circuit board and its microchip components
Two risk files, one product

Safety risk asks what harms a patient. Security risk asks who can make that happen on purpose.

Secure product development

Threat Modeling Is an Engineering Artifact, Not a Diagram.

The premarket guidance asks for a secure product development framework running through the total product lifecycle: threat models that enumerate attack paths, a security risk assessment that stands apart from the ISO 14971 safety file (AAMI TIR57 is the bridge), architecture views that show trust boundaries, and testing — from static analysis to penetration testing — that exercises what the threat model predicted.

The 2026 revision folds these expectations into QMSR design controls, which is where they always belonged: security requirements as design inputs, verified like any other. We stand the SPDF up inside your existing quality system — one lifecycle, not a parallel security bureaucracy.

After clearance

The Duties That Begin at Launch and Never Expire.

Premarket security gets you authorized. Postmarket security keeps the fleet defensible — and it runs for the life of every unit in the field.

The working parts: a coordinated vulnerability disclosure channel that actually answers, monitoring that connects CVE feeds to your SBOM so you know when a dependency turns hostile, patch timelines you can defend as “reasonable,” and a legacy-fleet strategy for devices that will outlive their operating systems. One myth worth retiring: routine cybersecurity patches generally do not require new 510(k)s — the barrier to patching is almost always process, not regulation, and “we couldn’t update it” has stopped being an acceptable sentence in an inspection.

The operating facts

What a Cyber-Device Program Plans Around.

Three constants — one statutory, one calendrical, one cultural.

524B

The section of the FD&C Act your submission is screened against — cybersecurity as a condition of authorization, not a chapter of guidance.

Oct 2023

Refuse-to-accept authority began. Arrive without 524B content and the review clock never starts.

SBOM

Machine-readable, current, and complete — the artifact that proves your supply chain is known, not assumed.

Where cyber programs stall

Six Failure Modes We Are Brought In to Prevent.

Each of these is a security decision made by default — usually by a deadline.

1

Security bolted on at V&V

Threat modeling scheduled after design freeze, so every finding is a change request nobody budgeted — and the file shows it.

2

The hand-assembled SBOM

A spreadsheet built the week of submission, missing transitive dependencies — inconsistent with the binaries the moment anyone checks.

3

No answer for the researcher

A vulnerability report lands in a sales inbox and ages for months — the CVD plan 524B(b)(1) required now exists only as an incident timeline.

4

A threat model that’s a poster

Boxes and arrows with no attack paths, no scoring, no linkage to requirements or tests — decoration, and reviewers recognize it.

5

Legacy fleet, no path

Devices in the field running unsupported platforms with no patch route and no risk position — the install base as an unmanaged liability.

6

Safety file standing in for security

An ISO 14971 analysis presented as the security risk assessment — different threat sources, different methods, different file.

People who have filed it

Cybersecurity Regulatory Leadership That Reads Code and Statute.

Our leads have scoped 524B submissions, stood up SPDFs inside existing quality systems, and built SBOM pipelines that stay true between releases.

Two engineers collaborating at standing desks in a bright office

“FDA reads your SBOM the way an auditor reads a ledger. If it was assembled the week of submission, it shows — and so does everything that implies about the rest of the program.”

The discipline we bring to connected, implantable, and software-driven cyber devices.

524B submission strategy SPDF implementation Threat modeling & TIR57 SBOM pipeline design CVD & postmarket plans Legacy fleet programs

Filing a Cyber Device? Make Security a Design Input, Not a Deficiency Response.

Bring senior cybersecurity regulatory leadership in while the architecture is still on the whiteboard — 524B assumes it was there all along.

Senior-led. Embedded in your team. No junior hand-offs.