On this page
Key Takeaways
- De Novo devices carry no predicate, so reviewers cannot lean on a prior clearance's security posture. Every cybersecurity claim has to stand entirely on your own evidence.
- Section 524B applies to De Novo cyber devices exactly as it does to 510(k) devices: SBOM, a security risk management process, a plan for postmarket vulnerability handling, and evidence that the device can be updated.
- Because De Novo devices are often first-of-kind, threat modeling has to cover novel attack surfaces the FDA has no reviewer precedent for, which means the rationale has to be more explicit than a 510(k) submission would need.
- The special controls the FDA establishes in your De Novo decision become the baseline that future 510(k) submissions citing your device as a predicate will be measured against, so weak cybersecurity documentation here has downstream consequences.
- The most common De Novo cybersecurity deficiency is a threat model that assumes a benign network environment; reviewers now expect assumptions about connectivity and interoperability to be stated and defended.
A De Novo submission has no predicate device to lean on, which means your cybersecurity documentation has to be self-supporting rather than comparative. Under Section 524B and the February 3, 2026 FDA premarket cybersecurity guidance, that means a complete SBOM, a documented threat model built for a genuinely novel architecture, security risk analysis under ISO 14971, and a postmarket vulnerability management plan, all traced to objective test evidence in your design history file.
The De Novo pathway exists for novel, low-to-moderate-risk devices that have no legally marketed predicate. That novelty is exactly what makes cybersecurity review harder. A 510(k) reviewer can compare your security architecture against a predicate's cleared file. A De Novo reviewer has nothing to compare against, so every security claim you make has to be justified from first principles, with your own risk analysis, your own threat model, and your own test evidence.
How De Novo cybersecurity review differs from 510(k)
The statutory basis is the same. Section 524B of the Federal Food, Drug, and Cosmetic Act defines "cyber devices" and applies to any submission pathway, including De Novo, PMA, and 510(k). The difference is procedural, not substantive: a De Novo request also has to propose the special controls that will govern the new device type going forward, and cybersecurity is very often one of those controls.
That has two practical consequences. First, your security risk management report needs to be written knowing that FDA may lift language from it directly into the special controls that define the device type. Vague or hedged risk statements become problems for every future device that cites yours as a predicate, not just for your own review. Second, reviewers apply more scrutiny to your assumptions because there is no established review history for a device like yours. A 510(k) reviewer working a tenth-generation infusion pump platform has internalized what "good enough" looks like for that device type. A De Novo reviewer working a first-of-kind connected diagnostic has no such baseline, so they read your rationale more literally and ask more "why" questions.
What a complete De Novo cybersecurity package contains
Security risk management report
Your risk management file, built under ISO 14971 and informed by ANSI/AAMI SW96:2023, needs to trace cybersecurity risks with the same rigor as safety risks, including risks that only manifest as a security failure with a downstream safety consequence. For De Novo devices this document tends to be longer than a comparable 510(k) filing because there is more novel functionality to analyze and no shorthand of "consistent with predicate" available to compress it.
Threat modeling for a genuinely new architecture
Threat modeling for a De Novo device has to justify its scope decisions explicitly. If your device introduces a new wireless protocol, a new cloud dependency, or a new physiological data pathway that no cleared device uses in the same way, the threat model needs to show that the assessment considered that novelty specifically, not just applied a generic STRIDE pass. Reviewers increasingly flag threat models that read as templated because the boilerplate rationale does not survive contact with an architecture nobody has reviewed before.
Software bill of materials
An SBOM meeting the NTIA minimum elements is required regardless of pathway. For De Novo devices, pay particular attention to any custom or novel software components you built in-house, since these will not have existing CVE histories or community security scrutiny. Your SBOM entry for a proprietary component should be paired with a clear statement of how that component's security was verified, because there is no upstream vulnerability database doing that work for you.
Verification and validation evidence
Security testing for a De Novo device, including penetration testing, fuzz testing, and static and dynamic analysis, needs to specifically probe the novel attack surface the device introduces. If your De Novo device is the first cleared product to combine a specific sensor type with cloud-based inference, your V&V plan should say so and show that the test scope was designed around that combination, not just around generic network interfaces.
Postmarket management plan
Your postmarket vulnerability management plan has to describe a coordinated vulnerability disclosure process, a monitoring cadence for the SBOM against CVE feeds, and an update mechanism, consistent with the SPDF. Because De Novo devices set precedent, the FDA pays close attention to whether the postmarket plan is realistic for a company that may not yet have shipped a comparable device at volume.
The special controls dimension
When the FDA grants a De Novo request, it publishes special controls that all future devices of that type must meet, including any subsequent 510(k) submissions that cite your device as a predicate. If cybersecurity is identified as a special control, the FDA will describe, at a level of specificity that varies case by case, what security testing and documentation is expected. This is unique to the De Novo pathway. A 510(k) sponsor never has to worry that their submission language will become the industry baseline; a De Novo sponsor does.
Practically, this means your regulatory and engineering teams should treat the security risk management report and the summary of technological characteristics as documents that will be read by future competitors and future FDA reviewers assessing devices you have never seen. Overly narrow or overly permissive language in either direction creates problems: too narrow, and it constrains legitimate design variations in future devices of the same type; too permissive, and it invites a weak security posture from the next entrant to be waved through by citing your precedent.
Comparing De Novo and 510(k) cybersecurity documentation
| Element | 510(k) | De Novo |
|---|---|---|
| Predicate comparison | Central to the submission | Not available |
| Threat model scope justification | Can reference predicate architecture | Must be self-contained |
| SBOM requirement | Required under Section 524B | Required under Section 524B |
| Special controls impact | Inherited from predicate or none | Often established by this submission |
| Reviewer precedent | Established for similar devices | Limited or none |
| Typical documentation depth | Moderate, comparative | Higher, foundational |
Common pitfalls in De Novo cybersecurity submissions
The most frequent problem we see is a threat model that was clearly adapted from a template built for a different device category, with connectivity assumptions that do not match the device's actual interfaces. The second most frequent problem is a security risk management report that hedges on residual risk acceptability instead of making a defensible, documented decision, which is a bigger liability in a De Novo filing because there is no predicate acceptance to point to as precedent. The third is treating the SBOM as a compliance checkbox rather than an input to the postmarket monitoring plan, which becomes obvious to reviewers when the monitoring plan and the SBOM contents do not line up.
Interoperability assumptions deserve particular attention. If your De Novo device is designed to work alongside other systems, whether an EHR, a companion app, or another connected device, your threat model needs to state what security posture you assumed for those other systems and why that assumption is reasonable. Reviewers have become more pointed about flagging threat models that assume a "trusted network" without justifying that trust.
How Blue Goat Cyber approaches De Novo cybersecurity submissions
We start by mapping the device's genuinely novel attack surface before writing anything, because a De Novo threat model that reuses assumptions from an adjacent device type is the single most common source of deficiencies we see in this pathway. From there we build the security risk management report and threat model together, so the risk acceptability rationale in one document is consistent with the attack scenarios documented in the other, which matters more here than in a 510(k) because there is no predicate to reconcile against. Our testing team executes penetration testing and fuzzing scoped specifically to the novel components, generates the SBOM from the actual build artifact, and validates it against NTIA minimum elements before it goes into the submission. We have carried device manufacturers through this pathway knowing that the special controls language in the eventual decision may define the category for years, and we write the supporting documentation with that in mind. For manufacturers preparing a De Novo request, our FDA Premarket Cybersecurity Services engagement covers the full package, and FDA Cybersecurity Deficiency Response is available if you have already received questions back from a reviewer.
FAQ
What cybersecurity documentation does a De Novo submission need that a 510(k) does not?
Nothing is unique on the document list itself; both pathways require an SBOM, threat model, security risk management report, and postmarket plan under Section 524B. The difference is depth and self-sufficiency. A De Novo submission cannot lean on predicate comparisons, so every assumption in the threat model and every risk acceptability decision needs its own explicit justification rather than a reference to an established device type.
Does Section 524B apply to De Novo devices?
Yes. Section 524B applies to any device meeting the statutory definition of a cyber device, regardless of whether it is submitted through 510(k), De Novo, or PMA. The pathway determines the review process, not whether the cybersecurity requirements apply.
How does threat modeling differ for a De Novo device?
The methodology, typically STRIDE-based analysis aligned with ANSI/AAMI SW96:2023, is the same. What differs is the scope justification. A De Novo threat model needs to explain why the attack surface analysis is complete for a device architecture that has no reviewer precedent, rather than pointing to how a predicate device was assessed.
Can a weak De Novo cybersecurity submission affect future devices?
Yes, indirectly. If the FDA establishes cybersecurity special controls as part of your De Novo grant, those controls become the baseline for future 510(k) submissions that cite your device as a predicate. A security risk management report with vague or overly permissive language can create a weaker baseline for the entire device category.
Do I need penetration testing for a De Novo submission?
Yes, if the device meets the cyber device definition under Section 524B. Testing should specifically target the novel components of the architecture, since generic network-layer testing does not address the attack surface unique to a first-of-kind device.
How long does De Novo cybersecurity review typically add to the timeline?
There is no fixed figure the FDA publishes, but incomplete or unconvincing cybersecurity documentation is a common driver of additional review cycles for De Novo requests specifically, because reviewers have less precedent to fall back on when deciding whether an assumption is reasonable. Building a self-contained, well-justified package upfront reduces that risk more than it would for a comparable 510(k).
Where this fits in the cluster
- FDA Pathway Cybersecurity Differences
- FDA PMA Cybersecurity Requirements
- Section 524B Cybersecurity Requirements Explained
- STRIDE Threat Modeling for Medical Devices
- Full-Service Cybersecurity for PMA Submissions - if your device escalates to Class III.
Related from Blue Goat Cyber
Sources & primary references
- Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (FDA, February 3, 2026 final guidance)
- De Novo Classification Process (FDA)
- Section 524B of the FD&C Act
- ANSI/AAMI SW96:2023, Medical Device Security
- ISO 14971:2019, Application of Risk Management to Medical Devices
If your device is heading down the De Novo pathway, our team can build the threat model, SBOM, and testing evidence together so the final submission reads as one coherent security story rather than a set of disconnected documents. Talk to Blue Goat Cyber about your De Novo cybersecurity submission.
Sources & references
Primary sources cited in this article. Links open in a new tab.
