Does Device Class Decide FDA Cybersecurity Requirements?

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.

Key Takeaways

• Section 524B applies to any "cyber device," regardless of class.
• A device is a cyber device if it (1) includes software, (2) can connect to the internet, and (3) has technological characteristics that could be vulnerable to cybersecurity threats.
• 524B only attaches when you file a premarket submission - 510(k), De Novo, PMA, PDP, or HDE.
• Class I is the default classification, but roughly 5-7% of Class I devices are not 510(k)-exempt, and adding software or connectivity can strip the exemption.
• Postmarket cybersecurity expectations and QMSR obligations apply regardless of class or exemption status.
• The required documentation categories are the same for every cyber device; the breadth and depth scale with cybersecurity risk, not class.

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." Roughly 5-7% of Class I device types 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.

The FDA's February 3, 2026 premarket 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, scoped to its (relatively narrow) attack surface.

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. Full premarket package. Broad threat model, multiple architecture views, full pen test scope.

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. Full premarket package with the deepest architectural and supply-chain expectations and 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.

FAQs

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.

Why would a Class I device need a 510(k)?

Three reasons: the classification regulation itself removes the exemption (a "reserved" Class I device), the limitations of exemption in 21 CFR 868.9, 870.9, 880.9, etc. are tripped (most often by a new intended use or a different fundamental scientific technology), or the device is a Class I IVD subject to specific premarket requirements. Adding software, connectivity, or wireless interfaces to a traditionally passive Class I device usually counts as a different fundamental technology and strips the exemption.

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.

Is software risk the same as cybersecurity risk?

No. The FDA's premarket cybersecurity guidance is explicit that a device can have minor software risk under the Premarket Software Guidance yet carry significant cybersecurity risk, and the reverse is also true. They are assessed independently and produce different deliverables.

What if my device is 510(k)-exempt but has Bluetooth?

That is the most common gotcha. Adding Bluetooth (or any wireless or networked interface) to a traditionally passive Class I device often counts as a different fundamental scientific technology under the limitations of exemption, which strips the 510(k) exemption. Once you are filing a 510(k), and your device meets the 524B(c) cyber-device test, the full premarket cybersecurity package applies.

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.

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