On this page
Published: · Updated:
Key Takeaways
- Section 524B applies to De Novo requests exactly as it applies to 510(k)s and PMAs.
- No predicate means no precedent argument, so each control must stand on its own rationale.
- Special controls created through your De Novo can include cybersecurity requirements that bind later devices.
- Novel technology usually means a novel attack surface that no existing guidance describes precisely.
- The threat model carries more weight here than in any other pathway.
- Interactive review gives you a chance to resolve questions, but only if your documentation is specific enough to discuss.
A De Novo request carries the same cybersecurity documentation obligations as a 510(k) under Section 524B, but with less room to lean on precedent. Because there is no predicate device, you cannot argue that your security approach matches a cleared product, and the special controls the FDA establishes for your new classification may themselves include cybersecurity requirements that then bind every future device in that category.
Reviewed September 17, 2026
The De Novo pathway exists for devices that are low or moderate risk but have no predicate to compare against. That absence of precedent is the defining feature of the pathway, and it changes how cybersecurity evidence is read. In a 510(k), a reviewer can measure your security approach against what has been cleared before. In a De Novo, there is nothing to measure against except the guidance, the standards, and the quality of your own reasoning.
That makes the De Novo a documentation exercise in the truest sense. Every assumption has to be stated, every control has to be justified on its merits, and the risk determination you present may end up shaping the requirements for an entire future device category.
Why the Absence of a Predicate Changes Everything
Substantial equivalence is the engine of the 510(k) pathway. It lets a manufacturer say, in effect, that their device is as safe and effective as one already on the market. For cybersecurity, that argument has limited force even in a 510(k), because a predicate cleared years ago may have been reviewed under expectations that no longer apply. In a De Novo, the argument is unavailable entirely.
What replaces it is the FDA's premarket cybersecurity guidance issued February 3, 2026, together with the recognized consensus standards and your own analysis. A reviewer evaluating a novel device is asking a harder question than whether you match a predecessor: they are asking whether your security approach is appropriate for a technology they may not have reviewed before.
This matters because Section 524B of the FD&C Act, added by the Consolidated Appropriations Act, 2023, applies to any submission for a cyber device, and refuse-to-accept enforcement for those requirements began on October 1, 2023. The statute makes no distinction between pathways. What differs is how much interpretive work your submission has to do on the reviewer's behalf.
The Documentation Set You Must Provide
The required elements are consistent across pathways. What changes for a De Novo is the depth of justification each one needs.
| Deliverable | What a 510(k) can lean on | What a De Novo must do instead |
|---|---|---|
| Threat model | Familiar architecture patterns from the predicate family | Derive the attack surface from first principles and explain the method |
| SBOM | Common component sets reviewers have seen before | Same format, plus rationale for unusual or novel components |
| Security architecture views | Conventional trust boundaries | Show boundaries that may not exist in any cleared device |
| Security risk assessment | Established harm patterns for the device type | Establish the harm patterns yourself, tied to ISO 14971 |
| Testing evidence | Testing scope typical for the device family | Justify why your scope matches your specific attack surface |
| Vulnerability management plan | Industry-standard postmarket process | Same, with a coordinated disclosure path stated explicitly |
| Labeling | Security information comparable to peers | Describe assumptions that customers have no prior product to infer |
[KEY REQUIREMENT] In a De Novo, the method matters as much as the output. State which threat modeling approach you used, which standards you followed, and why that approach fits your device, because the reviewer cannot infer it from a predicate.
Special Controls and Why They Outlive Your Submission
A granted De Novo does two things: it authorizes your device, and it creates a new classification regulation with special controls. Those special controls become the requirements that later devices of the same type must meet, typically through the 510(k) pathway using your device as the predicate.
When the FDA establishes special controls for a novel device type with a meaningful cyber footprint, cybersecurity elements can appear among them. That has two consequences worth planning around.
First, the controls that end up in the regulation are shaped partly by what you proposed and how well you justified it. A thin security rationale invites the agency to write requirements without your input. A well-reasoned one gives you the opportunity to influence a standard your competitors will later have to meet.
Second, whatever is codified applies to you as well. Special controls are not a one-time hurdle cleared at grant; they are ongoing requirements for the device type. A commitment that is easy to write and hard to sustain will follow your product line for years.
Where Novel Technology Creates Novel Attack Surface
De Novo devices are novel by definition, and novel technology frequently brings interfaces that existing guidance does not describe directly. Three patterns come up repeatedly.
| Pattern | Security question it raises | What the submission should contain |
|---|---|---|
| Machine learning in the clinical function | Can inputs be manipulated to change the output? | Threats specific to the model, not just the software around it |
| New wireless or physical interface | What does the interface authenticate and trust? | Protocol description, pairing behavior, and failure modes |
| Novel data flows to cloud or third parties | Who can read or alter data in transit and at rest? | Full data flow diagram with cryptographic controls named |
Machine learning deserves attention because the threats do not fit the traditional categories neatly. A model can be attacked through its inputs, through the data used to update it, or through the pipeline that delivers a new version. A threat model that covers the application hosting the model but says nothing about the model itself is one of the more visible gaps a reviewer can spot in an AI-enabled De Novo.
Using Interactive Review to Your Advantage
De Novo review includes substantive interaction with the review team, and cybersecurity questions are a common subject. The practical value of that interaction depends entirely on how specific your documentation is.
See also: 8 FDA Cybersecurity Deficiencies, Ranked From Real Letters, FDA IDE Cybersecurity Requirements: 2026, and SBOM Diffing & CVE Correlation Postmarket.
A submission that says traffic is encrypted invites a question asking which algorithms, which key sizes, how keys are generated and rotated, and what happens when negotiation fails. A submission that states those details up front turns the same exchange into a discussion about whether the choices are appropriate, which is a much better conversation to be having.
Pre-submission meetings are worth using for exactly this reason. A Q-submission that puts your threat model boundaries, testing scope, and architecture views in front of the review team before you file lets you correct a misalignment while it is still cheap to correct.
Common Reasons De Novo Cybersecurity Sections Draw Questions
The deficiency patterns are recognizable and mostly avoidable.
| Pattern | Why it happens | How to avoid it |
|---|---|---|
| Generic threat model | Reused from a template that predates the device | Derive threats from your own architecture and data flows |
| Testing scope narrower than the attack surface | Only the software was tested | Test every interface named in the architecture views |
| Security claims without cryptographic specifics | Marketing language reached the submission | Name algorithms, key sizes, and key lifecycle |
| Cyber risk disconnected from ISO 14971 | Two teams, two documents, no traceability | Trace each threat to a hazardous situation and harm |
| Silent environmental assumptions | The team assumed a controlled network | State assumptions in the threat model and the labeling |
| No plan for the model or firmware lifecycle | Update path was left for later | Describe how updates are authenticated and deployed |
The connection between cyber risk and safety risk is the one that costs the most time when it is missing. Reviewers expect to follow a thread from a threat through the hazardous situation it creates to the patient harm that results, and back to the control that reduces it. When the cybersecurity file and the ISO 14971 file were produced independently, that thread does not exist and the fix is rarely quick.
How Blue Goat Cyber Approaches This
We build De Novo cybersecurity packages from the architecture outward, because there is no predicate to borrow structure from. That means a threat model derived from your actual interfaces and data flows, architecture views that show real trust boundaries, testing scoped to what the views reveal, and traceability into the ISO 14971 risk file so the two tell the same story.
For novel devices, our threat modeling work establishes the analysis a reviewer will judge the rest of the submission against, and our medical device penetration testing produces evidence scoped to the interfaces your device actually has rather than to a generic checklist.
If you want one team to own the whole cybersecurity package, see our full-service FDA premarket cybersecurity submission support.
Frequently Asked Questions
Does Section 524B apply to De Novo requests?
Yes. Section 524B applies to any submission for a cyber device, which includes De Novo requests, 510(k)s, PMAs, and supplements. Refuse-to-accept enforcement of those requirements began on October 1, 2023. A De Novo request for a device with software and network connectivity must include the vulnerability management plan, the update commitment, and the SBOM the statute requires.
Is the cybersecurity bar higher for De Novo than for 510(k)?
The required elements are the same, but the burden of justification is higher because there is no predicate to compare against. In a 510(k) you can point to how comparable cleared devices handled a control. In a De Novo, each control has to be justified on its own merits against the guidance and recognized standards.
Can cybersecurity requirements become special controls?
Yes. A granted De Novo creates a new classification regulation with special controls that later devices of the same type must meet. For device types with meaningful connectivity, cybersecurity elements can appear among those controls, which means your submission may influence requirements that apply to your competitors and to your own future products.
Should we request a pre-submission meeting for cybersecurity questions?
It is usually worth it, particularly for novel interfaces or AI-enabled functions where guidance does not map cleanly. Putting your threat model scope, architecture views, and planned testing in front of the review team before filing lets you correct misalignment early, when changing course still costs weeks rather than a review cycle.
How should an AI-enabled De Novo handle model-specific threats?
By treating the model as an asset in the threat model rather than as an implementation detail. That means addressing manipulation of inputs, integrity of training and update data, authentication of model updates, and the clinical consequence of a degraded or altered output. A threat model that covers only the surrounding software leaves the novel part of the device unanalyzed.
What does the FDA do if the cybersecurity documentation is inadequate?
For requirements under Section 524B, inadequate content can result in a refuse-to-accept decision before substantive review begins. Once under review, gaps generate deficiency questions that add cycles. Either way the cost is schedule, which is why the documentation is worth getting right before filing rather than after.
Preparing a De Novo for a Connected Device?
Novel devices do not get to borrow anyone else's security rationale. We build the threat model, architecture views and testing evidence that let a reviewer follow your reasoning the first time. Book a strategy session.
Blue Goat Cyber specializes in medical device cybersecurity, from threat modeling and penetration testing through premarket submission support. Our team works exclusively with device manufacturers preparing FDA submissions. Learn more about Christian Espinosa, our founder and CEO.
About the author
Christian Espinosa, MBA · Founder & CEO, Blue Goat Cyber
U.S. Air Force Academy graduate and veteran with 30+ years in cybersecurity. Founded Alpine Security in 2014 (acquired 2020), then Blue Goat Cyber in 2022. Has supported 275+ medical devices, with no cybersecurity-related rejections to date. Author of three books including The Smartest Person in the Room. Ironman triathlete and mountaineer.