De Novo Cybersecurity Requirements: What the FDA Expects

Founder & CEO · Blue Goat Cyber

Published: June 3, 2026 · Last reviewed: May 1, 2026

Direct answer

De Novo submissions are subject to the same Section 524B cybersecurity requirements as 510(k) and PMA: a Secure Product Development Framework (SPDF), software bill of materials (SBOM), threat model, security risk assessment, security testing evidence, and a postmarket vulnerability management plan. Because De Novo devices have no predicate, the FDA reviews them as novel risk and frequently expects deeper threat modeling, stronger justification of residual risk, and clearer architectural rationale than a comparable 510(k).

Published June 3, 2026

A De Novo request is what you file when your device is low-to-moderate risk but has no legally marketed predicate. From a cybersecurity perspective that "no predicate" reality is the entire story: reviewers cannot lean on prior clearances, so they read your cybersecurity package as the first record on a brand-new device type. The bar is not different on paper — it is the same Section 524B floor — but the depth of justification expected in practice is usually higher than a routine 510(k).

Key Takeaways

De Novo cyber requirements come from Section 524B, the same statute as 510(k) and PMA.
Reviewers cannot lean on a predicate, so they scrutinize threat models and rationale more closely.
SPDF, SBOM, VEX, threat model, security risk assessment, testing, and postmarket plan are all required.
A granted De Novo creates a new classification regulation - your submission becomes the predicate for future 510(k)s.
Cybersecurity deficiencies on De Novo often pause the 150-day MDUFA goal clock just like 510(k).

What Section 524B Requires (and Why It Applies to De Novo)

Section 524B of the FD&C Act, added by the 2022 Consolidated Appropriations Act and operationalized by the FDA's February 3, 2026 premarket cybersecurity guidance, applies to any "cyber device" submitted via 510(k), De Novo, PMA, BLA, or PDP. A device is a cyber device if it includes software, can connect to the internet, and has technological characteristics that could be vulnerable to cybersecurity threats. Most De Novo candidates today meet that definition.

That means every De Novo for a cyber device must include:

a plan to monitor, identify, and address postmarket vulnerabilities and exploits
processes and procedures to provide reasonable assurance that the device and related systems are cybersecure
a software bill of materials (SBOM) for commercial, open-source, and off-the-shelf components
compliance with such other requirements as the FDA may require to demonstrate reasonable assurance of cybersecurity

The premarket guidance turns that statute into concrete documentation: SPDF, threat model, security risk assessment, security architecture views, SBOM with vulnerability assessment (typically a VEX), security testing evidence, and labeling.

Where De Novo Differs From 510(k)

The deliverable list is the same. The review posture is not.

No predicate, no shortcuts. In a 510(k) you can argue that your cybersecurity controls are at least as protective as a predicate's. In a De Novo there is no predicate, so every control needs intrinsic justification tied to your threat model and risk assessment. "Industry standard" alone does not carry weight.

Classification regulation gets written from your file. A granted De Novo produces a new classification regulation and special controls. The cybersecurity sections of your submission frequently end up shaping the special controls applied to your device type going forward. Reviewers know this and write deficiencies accordingly.

Stronger expectation of architecture rationale. Because the device type is new, reviewers tend to ask for clearer security architecture views and more explicit threat-control traceability than they would on a me-too 510(k).

Same MDUFA clock dynamics. De Novo has a 150-day FDA decision goal. Major cybersecurity deficiencies still pause the clock when an Additional Information (AI) request is issued, the same as in 510(k). See our breakdown of Major vs Minor deficiency grading for how that determination is made.

The Core Cybersecurity Deliverables for a De Novo

1. Secure Product Development Framework (SPDF)

You need evidence that cybersecurity is integrated into design controls under 21 CFR 820.30 and QMSR — not bolted on. The SPDF section typically maps to IEC 81001-5-1 or AAMI SW96 (see our IEC 81001-5-1 vs AAMI SW96 comparison) and shows how security requirements, design, implementation, verification, release, and maintenance are governed.

2. Threat Model

The threat model is where De Novo submissions get scrutinized hardest. STRIDE-based decomposition with data flow diagrams, trust boundaries, asset inventory, and threat-to-control traceability is the working expectation. Generic threat libraries copied from a template are routinely flagged as Major deficiencies.

3. Security Risk Assessment

Separate from ISO 14971 safety risk, the security risk assessment scores likelihood and impact for each identified threat, documents residual risk after controls, and justifies acceptance. AAMI TIR57 is the reference model most reviewers expect.

4. SBOM and Vulnerability Assessment

Machine-readable SBOM in CycloneDX or SPDX, covering commercial, open-source, and off-the-shelf software. Each component is checked against known vulnerabilities (NVD, KEV), and exploitability is documented in a VEX so the FDA can see which CVEs are not exploitable in your device context and why.

5. Security Testing Evidence

Static analysis, software composition analysis, vulnerability scanning, and penetration testing of the device and its interfaces. Pen test scope and methodology are documented; findings are tracked to closure or risk-accepted with rationale.

6. Labeling

Cybersecurity-relevant information for users and integrators: SBOM availability, security update plan, end-of-support timeline, hardening guidance, incident-reporting contact.

7. Postmarket Cybersecurity Management Plan

Coordinated vulnerability disclosure (CVD), monitoring sources, triage SLAs, patch and update mechanism, and how you will meet ongoing 524B obligations. This is required at premarket — you submit the plan, not just promise one.

Common De Novo Cybersecurity Deficiencies

Patterns we see most often in AI requests on De Novo:

threat model decomposition stops at the device boundary and ignores cloud, mobile app, and clinician portal
security risk assessment does not separate from ISO 14971 safety risk
SBOM is provided but no VEX, so every NVD hit is treated as unmitigated
pen test scope excludes a connected component "out of scope for this submission"
postmarket plan describes intent rather than committed processes and SLAs
no traceability from threats → controls → verification evidence

Any of these can land as Major and pause the clock.

How Blue Goat Cyber Helps

We support De Novo submissions end-to-end on the cybersecurity side: SPDF setup, threat modeling, security risk assessment, SBOM and VEX, penetration testing, and the postmarket management plan. Because De Novo packages often become the cybersecurity template for an entire new device classification, we write them to hold up under that scrutiny — not just clear the first review. Contact us to scope a De Novo cybersecurity engagement.

FAQs

Does Section 524B apply to De Novo submissions?

Yes. Section 524B applies to any premarket submission for a cyber device, including 510(k), De Novo, PMA, BLA, and PDP. The FDA's Feb 3, 2026 premarket cybersecurity guidance explicitly lists De Novo as in scope.

Is the cybersecurity bar higher for De Novo than 510(k)?

The statutory requirements are the same, but the practical review depth is usually higher because there is no predicate. Reviewers cannot rely on prior cybersecurity decisions and tend to scrutinize threat models, architecture views, and residual-risk rationale more closely.

What is the De Novo review timeline when cybersecurity deficiencies are issued?

The MDUFA goal for De Novo is 150 FDA days. When the FDA issues an Additional Information request for a Major cybersecurity deficiency, the clock pauses while you respond — same mechanic as 510(k).

Does my De Novo need an SBOM and VEX?

Yes. SBOM is a statutory requirement under 524B(b)(3). A VEX is not literally named in the statute, but the FDA's premarket guidance and current review practice effectively require exploitability triage for the components in your SBOM. Submitting an SBOM without a VEX is one of the most common deficiency triggers.

Will my De Novo cybersecurity package become a precedent?

Effectively yes. A granted De Novo creates a new classification regulation and special controls, and your cybersecurity submission frequently shapes the special controls that future 510(k)s under the same regulation will need to meet.

Do De Novo cybersecurity deficiencies become Complete Response Letters?

No. CRLs are a PMA construct. In De Novo, cybersecurity gaps come through Additional Information requests during the 150-day review, similar to 510(k). See FDA Deficiency Letter vs RTA vs Hold Letter for the full taxonomy.