Does Device Class Decide FDA Cybersecurity Scope?

Part of our FDA 2026 medical device cybersecurity submission series. For the full overview, start with FDA Cybersecurity Requirements for Medical Devices (2026).

Published June 4, 2026

The most common misconception we hear from MedTech founders is "we're Class I, so cybersecurity doesn't really apply to us." It is wrong twice over. Class does not gate Section 524B, and Class I is not automatically 510(k)-exempt. This post unpacks what actually drives the cybersecurity burden and why class is the wrong question to start with.

Why this matters

Device class (I, II, or III) does not by itself decide your cybersecurity obligations under Section 524B of the FD&C Act. The FDA's Cybersecurity in Medical Devices final guidance dated February 3, 2026 makes the cyber-device definition in 524B(c), software validated/installed/updated by the sponsor and the ability to connect to the internet and technological characteristics that could be vulnerable, the actual trigger for cybersecurity deliverables, regardless of class. That means a Class II 510(k) wearable can have heavier obligations than a Class III implantable that lacks wireless connectivity. The FDA's FY2025 MDUFA Performance Report lists cybersecurity among the subject-matter expert areas that may be involved in reviewing a device submission, alongside sterility, biocompatibility and software. Getting the class-to-cyber-device mapping wrong at scoping creates a six- to twelve-week delay later, so this is one of the highest-value decisions a regulatory team makes during early planning.

Why "What Class Are You?" Is the Wrong First Question

Device class under 21 CFR Part 860 is about general risk control: how much premarket oversight the FDA wants for the device's intended use. Cybersecurity sits in a parallel statutory track added by the 2022 Consolidated Appropriations Act as Section 524B of the FD&C Act. The two were not bolted together. Section 524B has its own definition of who it applies to ("cyber device") and its own trigger (a premarket submission). Class never appears in the statute.

So if you walk into a conversation asking "what does a Class II device need for cybersecurity?" you have already framed the problem incorrectly. The right questions are:

1. Is it a cyber device under Section 524B(c)?
2. Are you filing a premarket submission?

The Section 524B(c) Cyber-Device Test

A device is a cyber device only if it meets all three of these criteria:

1. It includes software - firmware, programmable logic, and validated SaMD all count.
2. It has the ability to connect to the internet - intentionally or not. Bluetooth that bridges to a phone that bridges to the cloud counts.
3. It contains technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.

A mechanical Class I bandage fails the test at step one. A Class III implantable pacemaker with telemetry passes at all three. A Class II ultrasound cart with no connectivity may still fail step two. A Class I "smart" stethoscope with a Bluetooth recording app passes all three and is fully in scope.

The class of the device is irrelevant to this test.

The Second Trigger: A Premarket Submission

Section 524B(b) only attaches to a premarket submission. The covered pathways are:

• 510(k)
• De Novo
• PMA
• Product Development Protocol (PDP)
• Humanitarian Device Exemption (HDE)

If the device is 510(k)-exempt and you have nothing to submit, there is no premarket cybersecurity package to deliver under 524B. That does not mean cybersecurity goes away - QMSR (21 CFR Part 820) design control obligations and postmarket cybersecurity expectations still apply, and the FDA treats cybersecurity as part of device safety throughout the total product life cycle. But the premarket documentation set under 524B requires a submission to attach to.

When Does a Class I Device Actually Require a 510(k)?

This is the part that surprises most founders. Class I is the default, low-risk classification, but it is not synonymous with "exempt." Most Class I device types are exempt, but some still require a 510(k). It happens in three situations:

1. The classification regulation itself removes the exemption. When the FDA classified the device type under 21 CFR Parts 862-892, the regulation can explicitly state that 510(k) is required. This is usually because the device, although low-risk overall, has a specific failure mode the FDA wanted to vet before market entry. These are sometimes called "reserved" Class I devices.

2. The "limitations of exemption" are tripped. Even an otherwise-exempt Class I device loses its exemption under 21 CFR 868.9, 870.9, 880.9, and the parallel sections in other parts if it:

• has a new intended use not covered by the existing classification,
• operates by a different fundamental scientific technology than the predicate device type, or
• is life-supporting, life-sustaining, intended for implantation, or presents a potential unreasonable risk of illness or injury.

The "different fundamental scientific technology" prong is the one that catches cybersecurity-relevant changes. The moment a traditionally passive Class I device gains connectivity, embedded software, or wireless interfaces it has almost certainly changed its fundamental technology and lost the exemption. A "smart" bandage with a wireless sensor, a connected manual stethoscope that records and transmits audio, a Bluetooth-enabled thermometer that pushes to a cloud dashboard - all of these are realistic Class I products that lose 510(k) exemption because of the addition of the software and connectivity that also make them cyber devices.

3. The device is a Class I IVD subject to specific premarket requirements under 21 CFR Part 809 or 864.

So a founder's instinct - "we're Class I, we're exempt, we owe no cyber package" - is doubly wrong: the Class I assumption may not hold once software and connectivity are involved, and even if it did hold, the cyber-device test runs on its own track.

What's Actually Required When a Cyber Device Files a Premarket Submission

Section 524B(b) lays out three statutory cybersecurity obligations for any cyber device filing a premarket submission:

• 524B(b)(1) - plans and procedures to monitor, identify, and address postmarket vulnerabilities and exploits in a reasonable time, including coordinated vulnerability disclosure.
• 524B(b)(2) - design, develop, and maintain processes that provide a reasonable assurance the device and related systems are cybersecure.
• 524B(b)(3) - a software bill of materials (SBOM) covering commercial, open-source, and off-the-shelf components.

See also: Breakthrough Device Designation and Cybersecurity, Does FDA 524B Apply to Legacy Medical Devices?, and FDA Section 524B Subsections Explained.

The FDA's FDA cybersecurity guidance turns those obligations into concrete deliverables (Appendix 4):

• Cybersecurity risk management report
• Threat modeling
• Cybersecurity risk assessment
• Security architecture views (global system, multi-patient harm, updateability/patchability, and security use case views)
• Cybersecurity testing results (static analysis, software composition analysis, vulnerability scanning, penetration testing)
• Labeling reflecting cybersecurity-relevant information
• Cybersecurity management plan for postmarket

Every cyber device that files a premarket submission owes evidence in every one of these categories. The categories do not change by class.

Scope Scales With Cybersecurity Risk, Not Class

What does change is the breadth of each artifact. The FDA is explicit in the guidance that documentation scales with cybersecurity risk.

A device with one hardware connection (say, a single USB port for clinician configuration) or a SaMD with limited external dependencies will typically need:

• a single global system architecture view rather than several,
• a narrower set of security use case views,
• a shorter threat model focused on a small attack surface,
• a penetration test scoped to a handful of interfaces.

A multi-patient infusion pump on hospital Wi-Fi talking to a cloud server, a mobile app, and a clinician portal will produce far more in each category. Same documentation set, very different page counts.

The trap to avoid: do not conflate software risk with cybersecurity risk. The FDA's guidance explicitly notes that a device can have minor software risk under the Premarket Software Guidance and still carry significant cybersecurity risk, and vice versa. They are assessed independently.

Worked Examples Across All Three Classes

Class I, 510(k)-exempt, no software - traditional manual stethoscope. Not a cyber device. No 524B obligations.

Class I cyber device requiring 510(k) - Bluetooth-enabled "smart" stethoscope that records and transmits audio. Lost its 510(k) exemption because added connectivity changed the fundamental technology. Cyber device under 524B(c). Owes the full premarket cybersecurity package; the attack surface is small, so each artifact is correspondingly shorter.

Class II, 510(k), non-connected, no software - rare but possible (e.g., certain passive surgical instruments). Files a 510(k), but not a cyber device. No 524B premarket package.

Class II cyber device, 510(k) - infusion pump with Wi-Fi and cloud telemetry. Cyber device. Same documentation set, but the threat model, architecture views, and pen test cover a much larger attack surface than the smart stethoscope.

Class III PMA, no connectivity - mechanical heart valve with no electronics. Class III, life-sustaining, files a PMA, but not a cyber device. No 524B premarket package (general QSR/QMSR obligations still apply).

Class III PMA cyber device - implantable cardioverter-defibrillator with home-monitoring telemetry. Cyber device. Same documentation categories, taken to their most detailed form because of the device's complexity, life-sustaining role, and multi-channel connectivity, with PMA annual reports that explicitly address cybersecurity changes.

Notice the pattern: the burden tracks cyber-device status and submission pathway. Class is descriptive of the device, not prescriptive of the cybersecurity ask.

How Blue Goat Cyber Helps

We help MedTech sponsors answer the two questions that actually matter - is it a cyber device, and what submission is it going through - and then scope the cybersecurity package accordingly. That means right-sizing the threat model, architecture views, SBOM and VEX, security testing, and postmarket plan to the device's actual cybersecurity risk rather than overbuilding on a misread of class. If you are unsure whether your device is in scope at all, contact us and we will walk through the 524B(c) test against your specific connectivity and software profile.

If you want one team to own the whole cybersecurity package, see our full-service FDA premarket cybersecurity support.

FAQ

Does Section 524B apply to Class I devices?

It can. Section 524B applies to any cyber device that files a 510(k), De Novo, PMA, PDP, or HDE. A Class I device that meets the 524B(c) cyber-device definition and is filing a 510(k) is fully in scope. A Class I device that is 510(k)-exempt has no premarket submission to attach a 524B package to, but postmarket cybersecurity and QMSR obligations still apply.

Are the required cybersecurity artifacts different for Class II vs Class III?

The categories are the same. The depth differs. Class III PMA submissions typically include deeper architectural views, stronger supply-chain controls, and PMA annual reports that explicitly address cybersecurity changes. Class II 510(k) and De Novo submissions for cyber devices use the same documentation set, sized to the device's cybersecurity risk.

Does postmarket cybersecurity apply even without a premarket submission?

Yes. Postmarket cybersecurity expectations - vulnerability monitoring, coordinated vulnerability disclosure, patching, and reporting - apply throughout the total product life cycle regardless of class or exemption status, anchored by QMSR (21 CFR Part 820) design controls and the FDA's postmarket cybersecurity guidance.

Do I owe an SBOM if my device is 510(k)-exempt?

Not under Section 524B. The SBOM mandate in 524B(b)(3) is tied to a premarket submission, so a 510(k)-exempt device has no statutory SBOM filing obligation with the FDA. That said, an SBOM is now table stakes for hospital procurement (per HSCC and MDS2 expectations), CISA coordinated disclosure, and any future submission if you ever lose the exemption. We recommend producing and maintaining one regardless.

Does De Novo require the same cybersecurity package as 510(k)?

Yes. Section 524B(b) names 510(k), De Novo, PMA, PDP, and HDE in the same breath - the statutory cybersecurity obligations are identical across them. De Novo submissions for cyber devices owe the full premarket package: cybersecurity risk management report, threat model, architecture views, SBOM, security testing, labeling, and a postmarket management plan. The novelty of the device usually means deeper threat modeling and a more thorough security architecture rationale, because there is no predicate to lean on.

Are combination products (drug-device) in scope for Section 524B?

If the device constituent meets the 524B(c) cyber-device test and the combination product files a premarket submission that includes the device portion (often via 510(k), PMA, or BLA with a device constituent), then the cybersecurity obligations attach to the device constituent. A connected drug-delivery autoinjector with Bluetooth dose logging, for example is firmly in scope even though the regulatory pathway is driven by the drug constituent.

Related: FDA 524B Cybersecurity Requirements Explained | Medical Device Classes & Cybersecurity Requirements | De Novo Cybersecurity Requirements | 510(k) Cybersecurity Requirements Every Maker Must Meet