Why IEC 62304, ISO 14971, and Cybersecurity Should be Managed as One System

For years, medical device companies have managed software development, risk management, and cybersecurity as three distinct compliance disciplines, each with its own team, its own documentation stack, and its own audit rhythm. It’s a logical structure, since the standards themselves were written at different times by different bodies with different audiences in mind.

However, that approach no longer works. And in 2026, the regulatory environment has made it official.

The U.S. Food and Drug Administration’s (FDA) finalized Quality Management System Regulation (QMSR), which replaced 21 CFR Part 820 in February, formally aligns U.S. device manufacturing requirements with ISO 13485:2016. This move embeds risk-based thinking as a foundational thread across every phase of the product lifecycle, not just design controls. Simultaneously, Section 524B of the FD&C Act now legally mandates a Secure Product Development Framework (SPDF) for any device meeting the definition of a “cyber device,” which encompasses most medical products with software currently on the market. In addition, the FDA released updated cybersecurity guidance in February that further clarified premarket submission requirements, post-market monitoring expectations, and vulnerability disclosure requirements.

Taken together, these regulatory developments do not merely update three parallel compliance tracks. They unify them. The question for medical device makers is no longer whether IEC 62304, ISO 14971, and cybersecurity are connected; it is whether their business operations and processes are built to manage that connection.

The Architecture Regulators Now Expect

Understanding the new baseline starts with understanding the way these three domains interlock at a technical level, because the interdependencies are
not superficial. 

IEC 62304 is the foundational lifecycle standard for medical device software. It governs how software is developed, classified, maintained, and changed. Importantly, IEC 62304 cannot stand on its own: software safety classification (Class A, B, or C) is determined by the severity of potential patient harm, meaning the standard is dependent on risk management outputs generated under ISO 14971, the globally accepted framework for medical device safety risk assessment. Every risk control identified in a 14971-hazard analysis, including mitigations designed to reduce the hazard probability or severity, must translate directly into a software requirement within the IEC 62304 Software Requirements Specification. However, these are not parallel documents. They are the same document, maintained in different formats. 

Cybersecurity sits at the junction of both. The FDA guidance explicitly states that manufacturers should conduct both a safety risk assessment and a separate, but interconnected security risk assessment. The linking standard, IEC 81001-5-1, provides cybersecurity-specific activities such as threat modeling, vulnerability testing, and security architecture reviews that ISO 14971 was never designed to address. But the integration is bidirectional—security threats must be evaluated as potential causes of safety hazards already documented in the ISO 14971 risk file. A ransomware attack disrupting a drug infusion algorithm becomes a patient safety event, not just a cybersecurity incident. A safety feature exposing an unguarded API endpoint becomes a vulnerability, not just an oversight.

This is the architecture regulators now expect to see reflected in submissions, design and development files, and quality management systems—a single, traceable thread running from user need through hazard identification, software requirement, security control, verification test, and post-market monitoring activity.

Where Companies Most Often Fall Short

In practice, most organizations are not structured this way and the gaps become quickly visible under audit or during FDA review.

The most common failure mode is fragmented documentation. Software teams maintain IEC 62304 records in one system. Risk teams maintain the ISO 14971 hazard analysis in another. Cybersecurity assessments may live entirely in a separate repository, maintained by a different function under a different project timeline. When a reviewer asks to trace a software requirement back to its originating hazard, or to demonstrate that a cybersecurity control adequately mitigates a specific safety risk, the answer requires manual reconciliation across disconnected artifacts. That reconciliation takes time, and it often reveals inconsistencies missed during development.

A second failure mode is the incomplete integration of cybersecurity into the risk management file. Many organizations treat cybersecurity as an addendum to the risk file rather than a native component of it. Security threats are cataloged, but they are not systematically evaluated for clinical impact. The result is a risk file that addresses patient safety scenarios without accounting for the pathways by which a security breach could trigger them. This is precisely what the FDA’s updated guidance requires.

A third, often underappreciated failure mode is treating post-market compliance as a separate phase rather than a feedback loop. Under the TPLC mandate embedded in QMSR and reinforced by FDA cybersecurity expectations, post-market surveillance data—including Coordinated Vulnerability Disclosure reports, Common Vulnerabilities and Exposures (CVE) notifications, and field complaint data—must actively feed back into the design input stage of subsequent versions. Patches and bug fixes are not administrative tasks. Under IEC 62304 Clause 6, every software maintenance activity must follow the same Design-Risk-V&V lifecycle as the original development. Organizations that have not structured their maintenance processes accordingly are accumulating compliance debt with every release.

SBOM as a Compliance Infrastructure

In the U.S., one of the most significant practical changes introduced by Section 524B is the mandatory Software Bill of Materials (SBOM) requirement for any new FDA premarket submission. An SBOM is a machine-readable inventory of every software component in a device. It should include open-source libraries, commercial off-the-shelf software, and third-party dependencies, and is now a submission deliverable, not an internal tool.

But the regulatory value of the SBOM extends well beyond the submission itself. A well-maintained SBOM is the foundation of post-market vulnerability management. When a new CVE is published affecting a component in a device’s software stack, the SBOM enables manufacturers to immediately assess whether that vulnerability applies, evaluate its exploitability in context, and determine whether it constitutes a safety risk requiring a patch under IEC 62304 maintenance protocols. Without a current, complete SBOM, that assessment becomes a manual forensic exercise that is slow, resource-intensive, and prone to error.

This is why medtech teams are beginning to treat SBOM management not as a compliance checkbox, but as operational infrastructure for continuous compliance. The metrics matter too: Vulnerability introduction rates, patch velocity, and deployment timing across product lines are becoming the key performance indicators of a mature post-market surveillance program.

Structural Changes That Reduce Downstream Risk

The good news is the structural changes required to align with this integrated model are not as disruptive as they may initially appear, provided they are made early in development rather than retrofitted under submission pressure.

The highest-leverage change is establishing a unified product traceability matrix from the outset. This means building the link between hazard identification (ISO 14971), software requirements (IEC 62304), and security controls (IEC 81001-5-1) into the development workflow. A multidimensional trace matrix that connects requirements to safety and security risks to tests provides the evidence regulators expect and the operational visibility teams need to manage change efficiently.

A second high-leverage change is including formal threat modeling during design, using established frameworks such as STRIDE or PASTA to systematically identify attack vectors against software interfaces, APIs, and cloud connectivity pathways. The documentation produced during threat modeling— typically attack scenarios, applied mitigations, and residual risks—becomes a part of overall risk management documentation, including security management and safety hazards with security-derived causes. 

Organizations that embed cybersecurity into their design review cadence throughout development will benefit from fewer late-stage findings, fewer submission cycles, and lower remediation costs. 

The Baseline Has Shifted

For medtech OEMs, suppliers, and startups operating in the medical device software space, the IEC 62304, ISO 14971, and cybersecurity trinity is a foundational requirement that directly determines submission outcomes, audit performance, and commercial readiness.

Notified bodies conducting technical documentation reviews and FDA reviewers evaluating 510(k) and PMA submissions are increasingly applying this integrated lens. The question is not whether each standard has been addressed in isolation. The question is whether the connections between them are visible, traceable, and maintained across the full product lifecycle.

The organizations that navigate this environment most effectively are those that have stopped asking, “how do we comply with each standard?” and instead ask, “how do we structure our development so that compliance evidence is generated as a natural byproduct, not assembled after the fact?” That shift in approach—more than any single documentation change—is what will ensure the regulatory and commercial success of medical device software.

MORE FROM ENLIL—Stop Running Medtech ‘War Rooms’: Stay Inspection-Ready Every Day

Chiratana Pot is senior director of Product Management at Enlil Inc., where he builds platform capabilities that make regulatory readiness part of everyday medtech workflows. He partners with early- and mid-stage device companies to improve traceability, reduce documentation friction, and maintain audit-readiness without slowing innovation. In February, Enlil hosted a webinar on IEC 62304, ISO 14971, and cybersecurity convergence featuring guest experts from Quarem Consulting and Interlynk.