Published: June 12, 2026
IEC 62304 software safety classes (A, B, C) and FDA device classes (I, II, III) are not the same axis and do not map one-to-one. FDA class reflects patient risk and submission pathway (510(k), De Novo, PMA). IEC 62304 class reflects the worst-case harm a specific software item can contribute to. Both feed into the cybersecurity evidence the FDA expects under Section 524B and the February 3, 2026 final premarket cybersecurity guidance, but each drives different artifacts.
Sponsors regularly conflate IEC 62304 software safety classes with FDA device classes, and FDA reviewers see the confusion show up in submissions. The two classifications answer different questions, but both shape the cybersecurity package the FDA expects. Misalignment between them is a frequent source of deficiency letters, because the SPDF evidence, threat model depth, and verification rigor in a submission are supposed to track to the right classification for the right reason. This post separates the two, shows how they intersect for cybersecurity, and explains which artifacts each one drives.
Key Takeaways
- FDA device class and IEC 62304 software safety class are orthogonal classifications.
- FDA class drives the submission pathway and whether Section 524B applies.
- IEC 62304 class drives the rigor of software lifecycle evidence inside the SPDF.
- A Class II device can contain Class C software, and a Class III device can contain Class A software.
- Cybersecurity requirements under the Feb 3, 2026 guidance do not scale by 62304 class directly.
- Misclassifying software safety class is a recurring source of FDA deficiency questions.
Table of Contents
- What FDA Device Classes Actually Classify
- What IEC 62304 Software Safety Classes Actually Classify
- Why These Two Classifications Get Confused
- How the Two Classifications Intersect in a Real Submission
- Which Cybersecurity Artifacts Each Classification Drives
- How Blue Goat Approaches This in FDA Submissions
- FAQ
Why this matters
Sponsors who treat IEC 62304 class and FDA device class as the same axis end up with submissions that under-document software lifecycle evidence on high-risk software items, over-document it on low-risk ones, or miscalibrate the cybersecurity package entirely. The FDA's February 3, 2026 final premarket cybersecurity guidance, "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions," ties cybersecurity expectations to the Section 524B definition of a cyber device, not to 62304 class. Separately, AAMI SW96:2023 and IEC 81001-5-1 inform how security activities sit inside the software lifecycle that IEC 62304 governs. Mixing the two up leads to threat models that are too shallow for the actual software safety class, or to risk control verification that does not match the rigor a Class C software item demands. Both patterns are routinely flagged in deficiency letters.
What FDA Device Classes Actually Classify
Class I, II, and III Reflect Patient Risk and Pathway
FDA device classes are defined under 21 CFR Part 860 and reflect the level of regulatory control the FDA considers necessary to provide reasonable assurance of safety and effectiveness. Class I is low risk and mostly 510(k)-exempt. Class II is moderate risk and typically cleared via 510(k) or De Novo, with eSTAR mandatory. Class III is life-sustaining or life-supporting and goes through PMA. The class is a property of the finished device and its intended use, not of any one software item inside it.
How Class Determines Cybersecurity Applicability
Section 524B of the FD&C Act applies to any device that meets the statutory definition of a "cyber device": validated software plus internet or network capability plus the potential to be vulnerable to cybersecurity threats. That definition does not key off FDA class. Most Class I devices have no software and fall outside 524B entirely. Most connected Class II and nearly all Class III devices are cyber devices and must produce the full premarket cybersecurity package. The trigger is the 524B definition, not the device class itself.
What IEC 62304 Software Safety Classes Actually Classify
Class A, B, and C Reflect Worst-Case Harm From the Software Item
IEC 62304 classifies each software item by the worst-case harm it could contribute to if it failed and no risk controls outside the software prevented that harm. Class A means no injury or damage to health is possible. Class B means non-serious injury is possible. Class C means death or serious injury is possible. The class applies to a software item, not to the device. A single device can contain software items at different classes, and the manufacturer documents the rationale for each.
How Class Determines Lifecycle Rigor
The 62304 class drives how much of the software lifecycle process is required for that item: planning, requirements, architecture, detailed design, unit implementation and verification, integration, system testing, and release. Class A items skip several activities. Class C items require the full set, including detailed design and unit verification with documented acceptance criteria. 62304 class is about process rigor for the software item, not about the regulatory pathway for the device.
Why These Two Classifications Get Confused
The Numbers and Letters Both Look Like Severity Tiers
The confusion is partly cosmetic. Both classifications climb from low to high (I to III, A to C) and both correlate with patient risk. A Class III implantable cardioverter-defibrillator almost certainly contains Class C software for therapy delivery, which reinforces the mental shortcut that "III equals C." That shortcut breaks down quickly. A Class II infusion pump can contain Class C software for dose calculation. A Class III implant can contain Class A software for a non-safety logging function. Reviewers see both patterns and expect the submission to justify each software item's class on its own terms.
The FDA Does Not Scale Cybersecurity by 62304 Class
The Feb 3, 2026 guidance and Section 524B do not say "Class C software needs a deeper threat model than Class A software." The guidance scales cybersecurity expectations to the device's risk profile, attack surface, and intended use environment. The relationship to 62304 is indirect: a Class C software item typically lives inside a device whose threat model and security risk assessment need to address patient-harm consequences, but the cybersecurity rigor is driven by the security risk analysis, not the 62304 class label.
How the Two Classifications Intersect in a Real Submission
The Mapping Is Many-to-Many, Not One-to-One
In practice, the device-level class sets the submission pathway and the 524B trigger, while the 62304 class sets the lifecycle evidence requirements for each software item. Both feed into the cybersecurity package. The common combinations look like this:
See also: MedTech Cyber Standards Every Device Team Must Know, FDA Pen Test Timing: How Recent Does Your Penetration Test Need to Be at Submission?, and Infusion Pump Cybersecurity: FDA Expectations in 2026.
| FDA device class | Typical 62304 software classes | Typical cybersecurity profile |
|---|---|---|
| Class I (with software) | A, sometimes B | 524B applies only if cyber device; limited attack surface |
| Class II (connected) | A, B, and C across different items | Full Feb 3, 2026 package; threat model covers all interfaces |
| Class III (implant or life-support) | Often C for therapy items, A or B for ancillary items | Full package with deeper architectural and supply-chain evidence |
The cybersecurity artifacts the FDA reviews are the same set across Class II and Class III. The difference is depth of architectural evidence and, for PMA, expectations around manufacturing-environment security and annual reporting.
What Reviewers Look For at the Intersection
Reviewers expect the threat model and security risk assessment to acknowledge the safety consequences of each software item, including any that are 62304 Class C. They expect verification evidence (including security testing) to match the lifecycle rigor declared for each item. A submission that declares all software items as Class A while the device is a Class III implant draws an immediate question. So does a submission that uses a uniform 62304 class for every software item without documenting the rationale.
Which Cybersecurity Artifacts Each Classification Drives
Artifacts Driven by FDA Device Class
The FDA device class determines the submission pathway (510(k), De Novo, PMA), whether eSTAR applies, and the depth of architectural and supply-chain evidence reviewers expect. Class III PMA submissions require expanded architecture views, manufacturing-environment controls, and PMA annual reports that explicitly address cybersecurity changes. Class II submissions produce the same seven-section cybersecurity content set without the PMA-specific expansions.
Artifacts Driven by IEC 62304 Class
The 62304 class drives the software lifecycle evidence that sits inside the SPDF and feeds the cybersecurity package: requirements traceability, architecture documentation, unit verification records, integration test evidence, and release evidence. AAMI SW96:2023 layers security activities onto that lifecycle. A Class C software item that handles authentication, key management, or therapy decisions needs documented architectural decomposition, unit-level verification, and security-specific test evidence that a Class A item would not. Reviewers follow that evidence from the cybersecurity risk assessment back into the 62304 lifecycle records.
Artifacts Driven by the Cyber Device Definition Itself
Regardless of FDA class or 62304 class, any cyber device under Section 524B must produce an SBOM with VEX, a threat model, a cybersecurity risk assessment, security architecture views, security testing evidence including penetration testing, labeling that supports secure operation, and a postmarket plan. These are required by the Feb 3, 2026 guidance and are not scaled by 62304 class.
How Blue Goat Approaches This in FDA Submissions
We treat FDA device class and IEC 62304 class as independent inputs into the cybersecurity package, not as a single severity tier. Each software item gets its own 62304 classification with documented rationale, and the threat model, security risk assessment, and verification evidence are calibrated to both the device-level risk profile and the per-item lifecycle rigor. Our team holds CISSP, OSCP, and prior military red-team credentials, and our submission work is grounded in Section 524B, the FDA's February 3, 2026 final premarket cybersecurity guidance, AAMI SW96:2023, and IEC 81001-5-1. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Start with our FDA premarket cybersecurity services or compare pathways on the Class I/II/III cybersecurity reference page.
FAQ
Is IEC 62304 Class C the same as FDA Class III?
No. IEC 62304 Class C describes a software item whose failure could contribute to death or serious injury. FDA Class III describes a device that is life-sustaining, life-supporting, or implantable. A Class III device often contains Class C software, but a Class II infusion pump can also contain Class C software, and a Class III implant can contain Class A software for non-safety functions. They are different axes.
Does the FDA require a different cybersecurity package for Class C software?
The Feb 3, 2026 final premarket cybersecurity guidance does not scale cybersecurity artifacts by 62304 class. It ties cybersecurity expectations to the Section 524B cyber device definition and to the device's risk profile and attack surface. The 62304 class influences the depth of lifecycle and verification evidence inside the SPDF, which the cybersecurity risk assessment then references.
Can a Class I device be a cyber device under Section 524B?
Yes, if it has validated software, network or internet capability, and the potential to be vulnerable to cybersecurity threats. Most Class I devices have no software and fall outside 524B, but a Class I device that meets the definition must produce the full premarket cybersecurity package.
What standards govern the intersection of software lifecycle and cybersecurity?
IEC 62304 governs the software lifecycle. AAMI SW96:2023 layers security activities onto that lifecycle and is the FDA-recognized consensus standard for medical device security risk management. IEC 81001-5-1 covers security activities for health software. ISO 14971 governs overall risk management. The FDA's Feb 3, 2026 guidance points to all four.
What goes wrong when a sponsor treats the two classes as equivalent?
The most common failures are under-rigorous lifecycle evidence on Class C software items inside lower-class devices, missing per-item 62304 classification rationale, and threat models that do not connect to the safety consequences of high-class software items. Each pattern shows up as a deficiency letter during substantive review.
Ready to align your classifications and your cybersecurity package?
If you are preparing a 510(k), De Novo, or PMA submission and want the cybersecurity package and IEC 62304 lifecycle evidence to line up the way reviewers expect, we can help. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Schedule a discovery call.
Christian Espinosa, Founder, Blue Goat Cyber, CISSP, OSCP. Christian has led FDA premarket cybersecurity submissions across Class II and Class III devices and previously commanded military red-team operations. Read more at christian-espinosa.