What is IEC 62304?

IEC 62304:2006, amended in 2015 and currently under the IEC 62304:2006+AMD1:2015 designation, establishes lifecycle requirements for software that is part of a medical device or that is itself a medical device (Software as a Medical Device, or SaMD). The standard was developed jointly by ISO and IEC and is recognized by FDA, the EU MDR framework, and most other major regulatory jurisdictions.

The standard does not tell developers how to write software. It specifies what processes, activities, and documentation must exist throughout the software lifecycle: from planning and requirements through architecture, detailed design, implementation, testing, maintenance, and problem resolution. The depth of these processes scales with the software’s safety classification.

Software safety classification: the foundation of IEC 62304

IEC 62304 divides medical device software into three safety classes based on the severity of harm that could result from software failure.

Class A: Software whose failure cannot contribute to a hazardous situation, or whose failure can contribute only to a hazardous situation that results in no injury or only negligible injury. Class A software has the lightest documentation requirements under the standard.

Class B: Software whose failure can contribute to a hazardous situation resulting in non-serious injury. Class B requires most of the standard’s process activities but does not require the detailed unit-level testing that Class C demands.

Class C: Software whose failure can contribute to a hazardous situation resulting in serious injury or death. Class C carries the full weight of the standard’s requirements, including unit-level software testing, detailed software architecture documentation, and comprehensive traceability from requirements through testing.

Classification is determined through the risk management process conducted under ISO 14971. Software that controls drug delivery, performs diagnostic calculations that directly drive treatment decisions, or operates implantable devices typically falls into Class C. Administrative software, data archiving tools, and non-decision-support displays often qualify for Class A or B. Misclassification is one of the most common IEC 62304 compliance problems FDA encounters during device inspections.

Core lifecycle processes required by IEC 62304

Software development planning (clause 5.1)

Before development begins, a software development plan must define the lifecycle model to be used, the methods and tools for each activity, the standards to be applied, the approach to integration and testing, the configuration management approach, and the problem resolution process. For Class C software, the plan must also address the approach to software architecture and detailed design. The plan is a living document that must reflect the actual development approach, not a generic template filled in after the fact.

Software requirements analysis (clause 5.2)

All software requirements must be documented. This includes functional requirements, performance requirements, interface requirements, and requirements derived from the risk management process. Requirements must be traceable: every risk control measure that depends on software must appear as a software requirement, and that requirement must be traceable through design, implementation, and verification testing.

A common gap here is that requirements documents describe what the software shall do but omit the performance parameters and failure mode behaviors that determine whether the software meets its safety obligations. FDA reviewers specifically look for requirements that cover how the software behaves under abnormal conditions.

Software architectural design (clause 5.3)

The software architecture must identify all software items (the modular components that make up the system) and their interfaces, and must identify which software items implement security and safety-critical functions. For Class C software, the architecture must be documented in detail sufficient for subsequent detailed design. Architecture documentation must be reviewed and its ability to meet requirements verified before detailed design proceeds.

Software detailed design (clause 5.4)

Required for Class C software (and recommended for Class B), detailed design specifies the internal logic of software units to the level where implementation can proceed without ambiguity. This is the level at which code-to-design traceability is established.

Software unit implementation and verification (clause 5.5)

Each software unit must be implemented according to its detailed design and verified to confirm the implementation is correct. For Class C, unit testing is specifically required. Unit test procedures and results must be documented. For Class B, the verification approach at unit level is more flexible but must still be documented.

Software integration and integration testing (clause 5.6)

Software units are integrated into software items, and software items are integrated into the complete system. Integration testing verifies the interfaces between integrated components work as specified. Test procedures, expected results, and actual results must all be documented. Anomalies discovered during integration testing must enter the problem resolution process.

Software system testing (clause 5.7)

System-level testing verifies that the complete software system meets its requirements under all specified conditions, including boundary conditions and failure modes defined in the risk management process. Test procedures, expected results, and actual results must be documented. For Class C software, regression testing must be performed when the software is modified.

Software release (clause 5.8)

Before release, the manufacturer must ensure that all required activities have been completed and documented, that all known anomalies have been evaluated and either resolved or formally accepted, that the software version is identified in the software configuration record, and that the risk register reflects the final software risk evaluation. A software release record documenting all of this is required.

Software maintenance and problem resolution

IEC 62304 clause 6 covers software maintenance: changes to released software must go through a controlled process that re-evaluates safety classification, conducts impact analysis, and ensures all affected requirements, design elements, and tests are updated and re-verified. This is where organizations with weak change control processes accumulate significant compliance debt: software changes applied outside the formal lifecycle process create documentation gaps that are difficult to reconstruct under regulatory scrutiny.

Clause 9 covers the problem resolution process: a structured feedback loop that captures field problems, software anomalies, and defects, evaluates their safety significance, initiates corrective action where required, and closes the loop with verification that the problem is resolved. This process must be active throughout the product’s market life, not just during development.

Relationship to FDA guidance and QMSR

FDA recognizes IEC 62304 as a consensus standard under the 510(k) and PMA submission process. A declaration of conformance to IEC 62304 in a submission provides reviewers with confidence that the software development lifecycle meets recognized standards without requiring submission of all lifecycle documentation. Submission of the Software Description, Software Level of Concern, and supporting documentation follows FDA’s guidance documents on software in medical devices.

Under the Quality Management System Regulation (QMSR), which took effect in February 2026 and aligns 21 CFR Part 820 with ISO 13485:2016, design and development requirements for software are evaluated under the design controls provisions. IEC 62304 activities map directly to the design planning, design input, design output, design verification, design validation, and design transfer requirements in QMSR and ISO 13485 Section 7.3.

FDA’s 2023 guidance on cybersecurity in medical devices also intersects with IEC 62304: security requirements for software must be captured in the requirements phase, security testing must occur during verification and validation, and the software bill of materials (SBOM) required under the Consolidated Appropriations Act of 2023 depends on the configuration management practices IEC 62304 requires.

Common IEC 62304 deficiencies in FDA inspections

Incorrect safety classification. Manufacturers classify software as Class A or B when the failure mode analysis supports Class C. FDA inspectors are trained to evaluate this, and misclassification found during inspection is a major finding.

Missing traceability. Requirements not traced to test cases. Test cases not traced to requirements. Risk control measures implemented in software but not appearing in the requirements document. Traceability matrices that exist on paper but were not maintained as the software evolved.

Incomplete anomaly management. Known defects in released software that were not formally evaluated for safety significance. A defect log managed informally in a bug tracker that was never reviewed for its relationship to the risk management process.

Inadequate problem resolution process. Post-market complaints and field problems that entered customer service processes but never reached the software problem resolution process for safety evaluation.

How a QMS supports IEC 62304 compliance

IEC 62304 generates a significant volume of controlled documentation: software development plans, requirements specifications, architecture documents, test protocols, test reports, anomaly records, change requests, and release records. Managing this volume in a paper-based or disconnected electronic system creates the traceability gaps that generate FDA findings.

An electronic QMS with design controls, document management, CAPA, and change control modules provides the structured environment these records need. When an anomaly enters the problem resolution process, it links to the relevant software requirement and test record. When a software change is made, the change control workflow ensures that impact analysis, requirement updates, and regression testing are all completed and documented before the change is released.

Cloudtheapp’s platform supports medical device software quality programs with design controls, document control, risk management, CAPA, and change management applications that can be configured to the IEC 62304 lifecycle structure. The 60+ applications available in the Cloudtheapp store give medical device software teams a complete quality infrastructure without building custom systems for each process. To see how Cloudtheapp supports medical device software quality programs, request a demo.

Conclusion

IEC 62304 compliance is not optional for manufacturers of software-embedded or software-as-a-medical-device products. It is the established standard by which regulators evaluate whether a medical device software development program produces reliable, safe output. The companies that execute it well treat it as an engineering discipline rather than a documentation burden: they classify software correctly, maintain traceability throughout the lifecycle, and run a problem resolution process that connects field experience back to the development record. Done with this mindset, IEC 62304 compliance produces better software, fewer recalls, and more predictable regulatory submissions.

This post created by and appeared first on Cloudtheapp

FDA's cybersecurity requirements for medical devices hardened significantly with the 2023 Consolidated Appropriations Act. Here is what device manufacturers must include in their QMS, from SBOM requirements to post-market monitoring, and how ISO 13485 and the QMSR frame the 2026 compliance picture.

Medical Device Cybersecurity: How QMS Requirements Changed Under FDA's 2023 Guidance and What's Next in 2026

TLDR

• The Consolidated Appropriations Act 2023 added Section 524B to the FD&C Act, effective March 29, 2023, requiring manufacturers of "cyber devices" to submit cybersecurity plans, Software Bills of Materials (SBOMs), and post-market monitoring commitments with every premarket submission.
• The FDA finalized the guidance "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" in September 2023, updated it in June 2025, and reissued it February 3, 2026 to align with the QMSR.
• Cybersecurity must now be embedded throughout the device QMS, in design controls, risk register management, post-market surveillance, change control, and CAPA, not treated as a standalone submission document.
• FDA can refuse to accept premarket submissions from cyber device manufacturers that lack adequate cybersecurity documentation.
• The QMSR's integration with ISO 13485 reinforces that cybersecurity risk management and the device risk management framework (ISO 14971) must be unified, not parallel.

What the 2023 Legislation Changed

On December 29, 2022, the Consolidated Appropriations Act, 2023 was signed into law. Section 3305, "Ensuring Cybersecurity of Medical Devices," amended the Federal Food, Drug, and Cosmetic Act by adding Section 524B, which took effect on March 29, 2023.

Section 524B created a new statutory category: the "cyber device." Under the statute, a cyber device is a device that contains software, including software as a device, that is or contains a component or components that are capable of connecting to the internet, and that contains technological characteristics that could be vulnerable to cybersecurity threats.

For manufacturers of cyber devices, Section 524B requires that every premarket submission include:

• A plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits on a reasonably justified regular cycle
• A process for coordinated vulnerability disclosure
• Procedures and processes to ensure the device and related systems are cybersecure, including software updates and patches for known unacceptable vulnerabilities
• A Software Bill of Materials (SBOM), including commercial, open-source, and off-the-shelf software components

These are statutory requirements, not guidance recommendations. A premarket submission for a cyber device that lacks any of these elements is subject to refusal to accept by FDA.

The Guidance Framework: September 2023 to February 2026

The FDA's formal guidance on cybersecurity in medical devices has gone through rapid evolution. The agency issued its first guidance on premarket cybersecurity submissions in 2014 (7 pages). By 2022, the draft guidance had grown to 53 pages. The September 2023 final guidance represented a full consolidation of the agency's requirements following the new statutory authority from Section 524B.

Key elements of the September 2023 guidance included a total product lifecycle (TPLC) approach requiring manufacturers to integrate cybersecurity into every phase from concept through post-market surveillance, detailed requirements for the Cybersecurity Risk Management Plan in premarket submissions, structured SBOM format requirements, specific guidance on what constitutes "reasonably justified" monitoring cycle frequencies, and expanded interoperability guidance for devices that connect with external systems, networks, and hospital infrastructure.

On June 27, 2025, the FDA issued an updated final guidance that added Section VII, formally addressing manufacturers' obligations under Section 524B of the FD&C Act. The June 2025 update defined the scope of "cyber device" more precisely and specified the submission content requirements imposed by the statute.

On February 3, 2026, the FDA reissued the guidance under the title "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions." The primary change in the February 2026 version replaced all references to the Quality System Regulation (QSR, 21 CFR 820) with references to the new QMSR (21 CFR 820 as harmonized with ISO 13485). The core cybersecurity requirements are unchanged from the June 2025 version, but the regulatory cross-references now align with the QMSR framework effective February 2, 2026.

The SBOM Requirement in Practice

The Software Bill of Materials is the most operationally demanding of the new requirements for most device manufacturers. An SBOM is a complete, machine-readable inventory of every software component in a device or related system, including the manufacturer's own code, commercial off-the-shelf (COTS) components, and open-source libraries.

The FDA recommends that SBOMs be submitted in widely used standard machine-readable formats and that they include, at minimum, the name and version of each software component, the component supplier or author, known licenses associated with each component, and known vulnerability identifiers (CVEs) associated with each component at time of submission.

The practical challenge of SBOM compliance is not just producing the document at submission time, it is maintaining an accurate, current SBOM throughout the device's commercial life. Every software update, patch, or component change requires an updated SBOM. Under post-market obligations, manufacturers must be able to monitor their entire software component inventory for newly discovered vulnerabilities, which requires the SBOM to be an active, maintained artifact, not a one-time submission document.

This transforms the SBOM from a regulatory document into a quality system process. The team responsible for maintaining it must have workflows that detect when a component in the bill of materials has been assigned a new CVE, evaluate the risk that vulnerability poses to the device, and initiate the appropriate response, whether that is a patch, a compensating control, or a postmarket safety report.

How Cybersecurity Integrates into the Device QMS

The most significant conceptual shift in the 2023 guidance is the explicit framing of cybersecurity as a QMS function, not a standalone regulatory exercise. FDA's guidance addresses cybersecurity across six QMS process areas.

Design Controls: Under ISO 13485 Clause 7.3 and the QMSR, design controls must document the identification of cybersecurity risks as part of the design input process. Cybersecurity requirements must be specified alongside functional, performance, and safety requirements at the beginning of the design process. Security architecture decisions, authentication, encryption, network isolation, data integrity controls, must be documented as design outputs and verified during design verification and validation. Design validation must include cybersecurity testing. Manufacturers should document what threat modeling method they used (e.g., STRIDE, PASTA, or attack surface analysis), what threats were identified, what controls were implemented, and how those controls were verified.

Risk Management Integration with ISO 14971: The FDA guidance requires that cybersecurity risk management be integrated with the device risk management process under ISO 14971, not run as a parallel activity. Cybersecurity hazards (unauthorized access, malware, denial of service, data integrity attacks) must be evaluated using the same risk estimation and risk control framework applied to physical device hazards. The risk register for a cyber device should include cybersecurity risks alongside functional and use-related risks, with the same documentation requirements: hazard identification, hazard situation definition, harm severity, probability estimation, risk evaluation, risk control measures, and residual risk assessment. Where a cybersecurity vulnerability could result in patient harm (e.g., an insulin pump that could be commanded remotely to deliver an overdose), the risk severity must reflect the potential patient outcome, not just the likelihood of a successful cyberattack.

Post-Market Surveillance and Vulnerability Monitoring: Section 524B requires manufacturers to monitor, identify, and address postmarket cybersecurity vulnerabilities on a reasonably justified regular cycle. This means subscribing to and monitoring CVE databases and security advisories relevant to software components in the device, maintaining the SBOM as a live document that enables rapid cross-referencing of new vulnerability disclosures against the device's component inventory, establishing a defined response timeline for addressing identified vulnerabilities based on risk severity, and documenting the monitoring cadence and justification in the postmarket surveillance plan. This postmarket monitoring obligation is perpetual. It does not end at approval.

Coordinated Vulnerability Disclosure: Section 524B requires manufacturers to have a process for coordinated vulnerability disclosure, a formal policy under which the manufacturer commits to working with security researchers, healthcare delivery organizations, and other parties who identify vulnerabilities in their devices. The FDA recommends that manufacturers establish and publish a coordinated vulnerability disclosure policy that includes a point of contact for receiving vulnerability reports, a defined response timeline, and a commitment to coordinating remediation with the reporter before public disclosure occurs. This policy must be documented within the QMS and reflected in the postmarket surveillance plan.

Change Control and Software Updates: Every cybersecurity patch and software update for a regulated medical device is a design change. Under the QMSR's design change controls (ISO 13485 Clause 7.3.9), all changes must be evaluated for their impact on the device's safety, performance, and regulatory status before implementation. The FDA's cybersecurity guidance addresses how manufacturers should approach routine security patches (which typically do not require a new premarket submission) versus changes that affect device functionality or introduce new risks (which may require a supplemental submission). Manufacturers should establish clear, written criteria for making this determination, with documented rationale for each change decision.

CAPA Integration: Every identified cybersecurity vulnerability that meets the threshold for remediation should generate a CAPA record within the QMS. The CAPA record documents the root cause investigation, the corrective action (patch development, compensating control, label update), the effectiveness verification, and the timeline from identification to closure. Cybersecurity CAPAs differ from traditional device CAPAs in one important way: the root cause is often in a third-party software component, not in the manufacturer's own code. The CAPA process must account for dependencies on third-party suppliers, and the supplier qualification process under ISO 13485 Clause 7.4 should address how the manufacturer monitors and responds to cybersecurity issues originating in supplied software components.

What "Cyber Device" Scope Means for Your QMS in 2026

Not every medical device triggers Section 524B obligations. A device qualifies as a cyber device only if it contains software and is capable of connecting to the internet. Devices with no internet connectivity are not cyber devices under the statute.

However, the scope of internet-connected devices in healthcare has expanded dramatically. Infusion pumps, patient monitors, imaging systems, diagnostic analyzers, and implantable devices with remote monitoring capabilities all fall within the cyber device definition. The connectivity that makes these devices clinically valuable is the same characteristic that creates the cybersecurity obligations.

Device manufacturers should audit their product portfolio against the cyber device definition and determine which products are subject to Section 524B requirements. For devices currently in commercial distribution that were approved before March 29, 2023, the postmarket cybersecurity obligations under Section 524B apply to the extent practicable, and future design changes may trigger full premarket cybersecurity submission requirements.

Structuring Cybersecurity Documentation for ISO 13485 and QMSR Compliance

The QMSR's harmonization with ISO 13485 means that cybersecurity documentation must fit within the QMS documentation architecture that ISO 13485 requires. The key documents in a cybersecurity-integrated QMS are:

The Cybersecurity Risk Management File, which houses the threat model, the risk assessment using ISO 14971 methodology extended to cybersecurity hazards, risk control measures and their verification, and the residual risk evaluation. This file should be structured to enable efficient review during FDA inspection under the new QMSR inspection framework CP 7382.850.

The Software Bill of Materials, maintained as a living document tied to the device version control system and updated with each software change. The SBOM should be linked within the design history file.

The Postmarket Cybersecurity Surveillance Plan, documenting the monitoring sources, the monitoring cadence, the criteria for triggering a CAPA or a postmarket safety report, and the vulnerability response timeline framework.

The Coordinated Vulnerability Disclosure Policy, formally documented within the QMS with a defined point of contact, response commitment, and disclosure timeline.

The Cybersecurity Patch and Update Procedure, governing how security updates are developed, tested, verified, and released, including the change control evaluation criteria for determining premarket submission requirements.

Audit trail documentation for all cybersecurity-related changes must meet the same data integrity standards as any other QMS record, complete, consistent, enduring, and legible.

How Cloudtheapp Supports Medical Device Cybersecurity QMS Requirements

Managing cybersecurity compliance within a medical device QMS requires a platform that integrates design controls, risk management, CAPA, change control, and post-market surveillance into a unified system of record. Paper-based or disconnected systems cannot sustain the continuous monitoring and documentation obligations that Section 524B imposes.

Cloudtheapp is validated against 21 CFR Part 820 (QMSR), ISO 13485, and 21 CFR Part 11, and its integrated application suite directly supports the cybersecurity QMS documentation requirements.

Design controls: Design history files with full traceability from cybersecurity design inputs through design verification and validation records. Threat model outputs and security architecture documentation integrate with the design history file structure required by ISO 13485 Clause 7.3.

Integrated risk management: The platform's risk management capabilities support the ISO 14971 framework applied to cybersecurity risks, with risk records connected to CAPAs and design controls in a single system of record.

CAPA management: Every identified vulnerability generates a structured CAPA with assigned ownership, root cause investigation fields, corrective action documentation, effectiveness verification, and escalation rules. Nothing ages without supervisory visibility.

Change management: Software updates and security patches follow documented change control workflows that include the FDA's criteria evaluation for determining premarket submission impact. Every change decision is recorded with rationale.

Audit trail and data integrity: Cloudtheapp's immutable system audit trail captures every record creation, modification, and approval action, meeting the data integrity requirements that FDA inspectors evaluate under QMSR inspection techniques.

Post-market surveillance: The platform's configurable application structure supports postmarket monitoring workflows, including supplier change notifications, vulnerability monitoring records, and coordinated disclosure tracking.

What's Ahead in 2026 and Beyond

FDA's Digital Health Center of Excellence continues to publish technical guidance and clarification documents as manufacturers work through Section 524B implementation. FDA staff have indicated that cybersecurity documentation quality in premarket submissions remains highly variable, and the agency has issued Refuse to Accept decisions where SBOM content or vulnerability monitoring plans were inadequate.

The alignment of FDA's cybersecurity framework with the QMSR/ISO 13485 system means that cybersecurity will increasingly be evaluated as part of standard QMSR inspections, not only in the context of premarket submissions. Manufacturers should anticipate that inspectors may ask to review cybersecurity risk management files, SBOM maintenance processes, and postmarket vulnerability monitoring records as part of routine quality system inspections.

The intersection of cybersecurity and AI-enabled medical devices is a growing area of guidance development. Devices with machine learning components present particular challenges for SBOM maintenance and vulnerability monitoring because the software components may evolve through learning rather than discrete version updates.

Conclusion

The 2023 Consolidated Appropriations Act fundamentally changed the compliance landscape for connected medical devices. Cybersecurity is no longer a premarket submission checklist item, it is a QMS function that runs continuously through the device's commercial life.

The September 2023 guidance, updated through June 2025 and aligned with the QMSR in February 2026, establishes a clear framework: cybersecurity must be in design controls, integrated with ISO 14971 risk management, maintained through active post-market surveillance, supported by a live SBOM, governed by a coordinated vulnerability disclosure policy, and documented throughout in a QMS that can withstand FDA inspection.

Device manufacturers who built their quality systems before 2023 likely have cybersecurity documentation spread across multiple disconnected files, or absent from their QMS entirely. The gap between that posture and what Section 524B requires is significant and will not close without deliberate, systematic action.

Request a demo of Cloudtheapp at https://www.cloudtheapp.com/demo/ to see how medical device manufacturers build and maintain cybersecurity-integrated QMS programs across ISO 13485 and the QMSR.

This post created by and appeared first on Cloudtheapp