Last reviewed: May 1, 2026
Section 524B of the FD&C Act applies the same baseline cybersecurity obligations to every "cyber device," but the depth of evidence, the review timeline, and the failure modes differ sharply by pathway. This guide compares cybersecurity expectations across the seven pathways MedTech teams encounter in practice.
Last reviewed: May 2026 against the FDA February 2026 final guidance, Section 524B of the FD&C Act, and 21 CFR Parts 807, 812, 814.
TL;DR — Pathway-by-pathway
| Pathway | What it is | Cybersecurity depth | Common failure mode |
|---|---|---|---|
| 510(k) | Demonstrates substantial equivalence to a predicate | Standard 524B package (SBOM, threat model, pen test, SPDF, postmarket plan) | RTA hold for missing SBOM or vulnerability management plan |
| De Novo | Novel low/moderate-risk device, no predicate | 524B package + special-controls language reviewers expect to see addressed | Special controls written too vaguely to test against |
| PMA | Class III, life-sustaining or implantable | Deepest scrutiny — full SPDF evidence, manufacturing controls, panel review | Threat model that fails to address long device service life |
| HDE | Humanitarian Use Device for rare conditions | Same 524B obligations as PMA, scaled to smaller population | Treating "humanitarian" as cybersecurity-light |
| IDE | Approval to use unapproved device in clinical study | Cybersecurity in investigational plan, informed consent, monitoring | Forgetting cybersecurity in the IRB-facing plan |
| Q-Sub (pre-submission) | Optional meeting to lock reviewer expectations | Targeted cybersecurity questions, threat model preview | Going in without specific questions — wasted opportunity |
| PDP | Product Development Protocol (Class III alternative to PMA) | Rarely used today; if used, PMA-equivalent depth | Mostly obsolete; defer to PMA |
What's the same across every pathway
Before the differences, the constants. Under Section 524B(c), every "cyber device" — software validated/installed/authorized by the sponsor, internet-capable, with characteristics that could be vulnerable — owes the FDA the same baseline:
- Security risk management file aligned to AAMI SW96:2023.
- Threat model that is diagram-driven, not a bullet list.
- Software Bill of Materials (SBOM) in CycloneDX or SPDX, with known-vulnerability assessment and VEX statements.
- Vulnerability management plan with documented triage SLAs.
- Secure Product Development Framework (SPDF) evidence mapped to IEC 81001-5-1 and NIST SP 800-218.
- Third-party penetration test report covering every external interface and protocol.
- Update and patch mechanism design — Section 524B(b)(2) is explicit.
- Coordinated vulnerability disclosure (CVD) policy with a published intake channel.
- Postmarket cybersecurity management plan — required by Section 524B(b)(1).
- Cybersecurity labeling — controls, ports/protocols, SBOM pointer, support lifecycle.
For the full deliverable list, see our FDA Premarket Cybersecurity Submission Checklist.
What changes pathway-to-pathway is depth, format, and timing. The sections below walk each pathway.
510(k) — Premarket Notification
The 510(k) is the most common pathway and the one the February 2026 guidance was tuned for. The cybersecurity content lives in eSTAR Section 14. Reviewers expect the standard 15-section package, scoped to your device's risk profile and predicate comparison.
Depth. Moderate. A Class II connected monitor gets interface and protocol pen testing; a Class II diagnostic with a companion app gets the app, the API, and the wireless link. Threat model is required even if the predicate didn't have one — predicates pre-524B are not a free pass.
Timing. Cybersecurity content is part of the RTA screen, not just substantive review. Missing SBOM, missing vuln management plan, missing pen test report, or a bullet-list "threat model" will hold the submission at RTA before the 90-day clock starts. See 510(k) cybersecurity deficiencies that trigger FDA holds.
Predicate considerations. You cannot inherit cybersecurity from a pre-524B predicate. Reviewers expect a fresh cybersecurity assessment of your device. Equivalence claims that lean on "the predicate didn't have to do this" get cut.
De Novo — Novel devices with no predicate
De Novo is for novel low/moderate-risk devices where no legally marketed predicate exists. The cybersecurity package is the same 15 sections as a 510(k), with one critical addition: special controls.
Depth. Same as 510(k), plus special-controls language. When FDA grants a De Novo, it creates a new device classification and writes special controls that all future 510(k)s for that device type must meet. Your special-controls section is where you propose how cybersecurity is enforced for the classification — SBOM cadence, vulnerability monitoring sources, patch SLA, postmarket reporting triggers. This text becomes the standard for everyone who follows you.
Failure mode. Special controls written too vaguely to test against ("the manufacturer will maintain an SBOM"). Reviewers push back and ask for concrete cadence, format, and verification. Write them like contract clauses, not aspirations.
PMA — Premarket Approval
PMA is for Class III devices — life-sustaining, life-supporting, or implantable. Cybersecurity scrutiny is the deepest of any pathway. See our FDA PMA cybersecurity requirements guide for the full deep dive.
Depth. Maximum. The SPDF evidence has to cover the whole product lifecycle — design controls, manufacturing controls, change control. Pen testing scope expands to include firmware reverse engineering, RF/protocol-level analysis, and supply chain attestations. CDRH may convene an advisory panel; cybersecurity is usually on the panel's agenda.
Service life. PMA devices often have 10–20 year service lives (implantable cardiac, neurostim). Your threat model must address cryptographic obsolescence over that horizon. See Q-Day is a present-day FDA compliance gap for why post-quantum readiness is now in scope.
Manufacturing. PMA cybersecurity extends into 21 CFR Part 820 manufacturing controls — secure boot key provisioning, firmware signing infrastructure, supply chain attestations for cryptographic components. 510(k) reviewers rarely probe this; PMA reviewers always do.
HDE — Humanitarian Device Exemption
HDE is for Humanitarian Use Devices (HUD) treating conditions affecting fewer than 8,000 patients per year in the U.S. The regulatory path is PMA-adjacent but with a probable-benefit standard instead of reasonable-assurance-of-effectiveness.
Depth. The temptation is to treat HDE as "PMA-light" for cybersecurity. Don't. Section 524B(c) makes no exemption for HDE; if the device is a cyber device, the full 524B package applies. The smaller patient population doesn't reduce the cybersecurity attack surface — it often increases per-patient risk because the population is more vulnerable and the device is more specialized.
Timing. HDE reviews are usually faster than PMA, but cybersecurity deficiencies stop the clock just like a 510(k). Don't compress the cybersecurity workstream to match the shorter review window.
IDE — Investigational Device Exemption
IDE is the approval to use an unapproved device in a clinical investigation. Required for significant-risk device studies under 21 CFR Part 812. Cybersecurity has been an explicit IDE topic since the February 2026 guidance.
Depth. Targeted, but non-trivial. The investigational plan must address:
- Cybersecurity risks to subjects — what could go wrong during the study, and what compensating controls are in place.
- Data handling and integrity — how clinical data captured by the device is protected from tampering and loss.
- Adverse event reporting — how a cybersecurity event (compromised firmware, lost data, unauthorized access) is detected, classified, and reported.
- Informed consent — subjects must be told about cybersecurity risks in plain language. "Your device connects to a study server and could theoretically be accessed by an unauthorized party" is the kind of statement IRBs now expect.
Failure mode. IDE sponsors often build the cybersecurity package for the eventual 510(k)/PMA but forget that the IDE itself needs cybersecurity content sized for the study. The IRB will catch what FDA might miss.
Practical sequencing. Build your full threat model and security risk file once. For the IDE, extract the subset that applies to the study population, study duration, and clinical environment. For the eventual marketing submission, reuse and expand the same artifacts.
Q-Sub — Pre-Submission
Q-Sub (pre-submission) is the FDA's program for getting written feedback or a meeting on specific questions before you file. It is optional, voluntary, and free — and dramatically underused for cybersecurity.
When to use it. Three high-value cybersecurity scenarios:
- Threat model preview. Bring a draft architecture and threat model and ask whether the trust boundaries and STRIDE coverage match reviewer expectations. A 30-minute Q-Sub here can save a six-month deficiency cycle.
- Novel architecture. Cloud-only SaMD, AI/ML device with PCCP, RF-telemetered implant — any architecture where you're not sure how 524B applies. Ask the question before you build the evidence.
- Predicate equivalence stretch. When your predicate is pre-524B and you're worried reviewers will argue your cybersecurity scope is different, ask up front.
How to scope. Q-Subs work when you bring specific written questions, not "review our package." Three to five sharp questions ("Does our SBOM cadence meet 524B(b)(1) for postmarket maintenance?") beats a 200-page package dump.
Important framing. Q-Sub is not the premarket submission. It is the meeting before the meeting. Naming clarity matters because "pre-submission" the colloquial phrase can mean either the Q-Sub program or "we haven't filed our premarket submission yet." When we use "Q-Sub" in this guide we always mean the formal FDA program.
PDP — Product Development Protocol
PDP is a Class III alternative to PMA, created under section 515(f) of the FD&C Act. It lets a sponsor and FDA agree up front on the protocol that, when followed, results in approval.
Reality. PDP is rarely used. Most Class III devices go through PMA. If you are pursuing PDP, treat the cybersecurity evidence as PMA-equivalent in depth. The agreed protocol must include cybersecurity activities, deliverables, and acceptance criteria — which is actually a strong fit for SPDF, because SPDF is itself a protocol-style commitment.
If you're considering PDP, talk to your reviewer in a Q-Sub first.
Side-by-side: what changes by pathway
| Cybersecurity deliverable | 510(k) | De Novo | PMA | HDE | IDE |
|---|---|---|---|---|---|
| Security risk file (AAMI SW96) | Required | Required | Required, deeper | Required | Required, study-scoped |
| Threat model | Required | Required | Required, lifecycle-wide | Required | Required for study scope |
| SBOM (CycloneDX/SPDX) | Required | Required | Required, with manufacturing chain | Required | Required |
| Pen test (third-party) | Required | Required | Required, including firmware/RF | Required | Required for clinical config |
| SPDF evidence | Required | Required | Required, with mfg controls | Required | Required |
| Postmarket plan | Required | Required | Required, panel-reviewed | Required | N/A (study only) |
| Special controls language | N/A | Required | N/A | N/A | N/A |
| Investigational plan cyber | N/A | N/A | N/A | N/A | Required |
| Informed consent cyber language | N/A | N/A | N/A | N/A | Required |
| Advisory panel review | Rare | Rare | Common | Possible | N/A |
Common cross-pathway failure patterns
Three patterns we see across every pathway:
1. Copy-paste cybersecurity. A team that successfully cleared a 510(k) tries to reuse the same package for a PMA without scaling. Reviewers can tell. Each pathway needs its own scoping pass.
2. Wrong-pathway pen test. A web-app pen test rebadged for a 510(k) device. A 510(k)-scoped pen test rebadged for a PMA. The pen test report must match the pathway's depth.
3. Q-Sub avoidance. Teams skip the Q-Sub to "save time" and then spend twice as long responding to deficiencies that the Q-Sub would have surfaced. The Q-Sub is the single highest-leverage cybersecurity activity for any novel device.
Frequently asked questions
Does Section 524B apply to every FDA pathway?
Yes — for every device that meets the Section 524B(c) "cyber device" definition, regardless of whether you're filing 510(k), De Novo, PMA, HDE, or IDE. The cyber-device determination is pathway-independent.
Is cybersecurity reviewed during IDE?
Yes. Since the February 2026 guidance, FDA explicitly expects cybersecurity content in the IDE — risks to subjects, data handling, adverse-event reporting for cyber events, and informed consent language.
Can I reuse my IDE cybersecurity package for the later 510(k) or PMA?
The artifacts (threat model, SBOM, pen test) carry forward and should be expanded — not rebuilt. The IDE versions are scoped to the study; the marketing submission versions are scoped to commercial use. Build once, scope twice.
Is HDE cybersecurity-lighter than PMA?
No. Section 524B applies the same baseline. HDE's smaller patient population doesn't reduce the attack surface or the regulatory expectation.
When should I file a Q-Sub for cybersecurity?
Whenever you have a novel architecture, an unusual predicate situation, or a specific cybersecurity question whose answer would change your submission package. The Q-Sub is free, voluntary, and dramatically under-used by MedTech teams. Bring three to five sharp written questions.
Is PDP still a real pathway?
Technically yes, practically rare. Most Class III sponsors go through PMA. If you're considering PDP, talk to FDA in a Q-Sub first to confirm it's the right path.
Do De Novo special controls cover cybersecurity?
They should. The De Novo classification order will include the cybersecurity expectations as special controls, and every subsequent 510(k) for that device type will have to meet them. Write the special-controls language carefully — it becomes the standard.
Where this fits in our content
- FDA Premarket Cybersecurity Submission Checklist — the 15 deliverables every pathway needs.
- FDA PMA Cybersecurity Requirements — the deepest pathway, deep dive.
- FDA 524B Cybersecurity Requirements Explained — the statute every pathway runs under.
- FDA Cybersecurity Guidance Summary 2026 — what changed in the February 2026 final guidance.
- eSTAR Cybersecurity Readiness Checklist — the format 510(k) and De Novo are filed in.
How Blue Goat Cyber helps
We ship the cybersecurity package for every FDA pathway — 510(k), De Novo, PMA, HDE, IDE — and stay through deficiency response. We also draft and run Q-Sub cybersecurity questions for clients who want to de-risk before they file. See FDA premarket cybersecurity services.
Sources & primary references
- FDA, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (final guidance, February 2026)
- Section 524B of the Federal Food, Drug, and Cosmetic Act
- 21 CFR Part 807 — Establishment Registration and Device Listing (510(k))
- 21 CFR Part 812 — Investigational Device Exemptions
- 21 CFR Part 814 — Premarket Approval of Medical Devices (PMA, HDE)
- FDA, Requests for Feedback and Meetings for Medical Device Submissions: The Q-Submission Program (guidance)