IEC 81001-5-1: Secure Lifecycle Rules

Part of our Cybersecurity risk management series (AAMI TIR57, ISO 14971, IEC 81001-5-1). For the full overview, start with AAMI TIR57 Risk Management for Medical Devices.

Reviewed September 17, 2026

A recurring question in FDA cybersecurity reviews is which standard actually governs the secure development process, and whether newer publications like AAMI SW96 have made older references like TIR57 obsolete. Getting this wrong costs time. Reviewers who see a submission cite the wrong standard, or fail to show traceability between lifecycle process and risk management, commonly issue an Additional Information request, and each cycle can add six to twelve weeks to a clearance timeline. This post lays out exactly what IEC 81001-5-1 covers, how it relates to AAMI SW96 and AAMI TIR57, and what artifacts each one is expected to produce in a premarket submission.

Why This Matters

The FDA's February 3, 2026 final guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, expects every cyber device submission to demonstrate a Secure Product Development Framework and a documented security risk management process. IEC 81001-5-1 and AAMI SW96 are the two standards most commonly used to satisfy that expectation, but they answer different questions. IEC 81001-5-1 answers "did you run a secure lifecycle," while SW96 answers "did you identify, evaluate, and control security risk."

Manufacturers sometimes assume that because SW96 was published after AAMI TIR57, it supersedes it, or that citing one standard covers both lifecycle and risk needs. Neither assumption holds up under review. TIR57 is still referenced in FDA guidance history and remains useful as a methodology reference; SW96 is the current normative standard for security risk management and is FDA-recognized as Recognized Consensus Standard 13-131.

Reviewers look for a coherent picture: a named lifecycle standard, a named risk management standard, and evidence that the two connect. A submission that names IEC 81001-5-1 in its SPDF section but has no risk management standard behind its security risk file, or vice versa, draws predictable questions. Getting the mapping right the first time reduces review cycles and keeps the submission timeline on track.

What Does IEC 81001-5-1 Actually Cover?

IEC 81001-5-1 defines the secure development lifecycle activities that a manufacturer must perform across the life of health software, from initial security requirements through design, implementation, verification, release, and postmarket maintenance. It is a process-and-evidence standard, similar in structure to IEC 62304 for functional safety, but focused on cybersecurity activities instead of safety activities.

The standard does not tell a manufacturer how to score a threat or accept residual risk. Instead, it requires that security requirements be defined, that secure design and coding practices be followed, that security testing occur before release, and that a documented process exist for handling vulnerabilities after the device ships. Each of these activities needs traceable evidence, not just a policy statement.

Does AAMI SW96 Replace AAMI TIR57?

No, AAMI SW96 did not replace AAMI TIR57. SW96 is a normative consensus standard for security risk management in medical device software, published in 2023 and structured to mirror ISO 14971. TIR57, published years earlier, is an informative technical information report that offers methodology and worked examples for applying security risk management concepts to medical devices.

The two coexist deliberately. SW96 sets the requirements a manufacturer must meet for security risk analysis, evaluation, control selection, and residual risk acceptance. TIR57 can still inform how a team builds out its methodology, threat catalogs, or worked examples, but it is not the document reviewers look to for a normative requirement. Manufacturers building a risk management file for the first time often use TIR57 as a practical reference while conforming to SW96 as the controlling standard.

What Does the FDA Recognize?

The FDA maintains a list of recognized consensus standards, and AAMI SW96:2023 appears on it as Recognized Consensus Standard 13-131. IEC 81001-5-1:2021 is referenced in the FDA's February 3, 2026 premarket cybersecurity guidance as an acceptable standard for demonstrating secure development lifecycle processes. Neither standard is mandated by statute; Section 524B of the FD&C Act requires reasonable assurance of cybersecurity without naming a specific standard.

In practice, reviewers expect a submission to show at least one recognized standard covering lifecycle process and one covering security risk management, with clear traceability between the two. Citing a recognized standard in a declaration of conformity is useful, but reviewers still expect matching procedures and work products behind the citation.

Standards Comparison: Lifecycle, Risk, and Safety

See also: How SPDF Maps to IEC 81001-5-1 Activities, IEC 81001-5-1 vs IEC 62304 for Medical Devices, and JSP2 vs SPDF vs IEC 81001-5-1: Framework Pick.

Manufacturers frequently confuse which standard covers which concern. The table below separates scope, applicability, and expected output for the five standards most relevant to a medical device cybersecurity submission.

Reading the table left to right, the pattern is clear: IEC 81001-5-1 and IEC 62304 both govern lifecycle process, one for security and one for safety, while AAMI SW96 and ISO 14971 both govern risk management, one for security and one for safety. TIR57 sits alongside SW96 as a non-normative aid rather than a parallel requirement.

Which Evidence Does Each Standard Produce?

Each standard produces a distinct artifact that a reviewer will look for by name. IEC 81001-5-1 produces lifecycle process evidence: security requirements traceability, secure design records, security test results, and a documented vulnerability handling process. AAMI SW96 produces the security risk management file itself: identified threats, likelihood and impact analysis, selected controls, and residual risk acceptance decisions.

A submission that cites IEC 81001-5-1 without a security risk management file behind it will draw questions about how residual security risk was evaluated and accepted. A submission that cites SW96 without lifecycle process evidence will draw questions about where the secure design and testing records live. The strongest submissions show explicit traceability from lifecycle activities (81001-5-1) into risk analysis inputs (SW96), and from risk controls back into implementation evidence.

Where Do These Standards Fit in a Submission?

IEC 81001-5-1 is typically cited in the SPDF or quality system section of a submission, with supporting evidence distributed across design history file records. AAMI SW96 is typically cited in the security risk management section, anchoring the security risk file alongside the safety risk file built under ISO 14971. Placing these citations in the wrong section, or failing to cross-reference them, is a common source of confusion for reviewers working through a submission.

Manufacturers building a Secure Product Development Framework for the first time should map each 81001-5-1 lifecycle activity to the corresponding SW96 risk management step early, rather than retrofitting traceability after the fact. This mapping becomes the backbone of the response strategy if the FDA issues an Additional Information request touching either standard.

How Blue Goat Cyber Approaches This

We help manufacturers build a Secure Product Development Framework that maps cleanly to IEC 81001-5-1 for lifecycle conformance and a security risk management file that conforms to AAMI SW96, with traceability into threat models, SBOM and VEX documentation, and verification testing evidence. Rather than treating these standards as boxes to check in a cover letter, we build the underlying procedures and records that reviewers actually verify. If your submission needs a defensible mapping between lifecycle process and risk management, our FDA premarket cybersecurity services team can help structure both from the start of your development program.

Frequently Asked Questions

Is IEC 81001-5-1 mandatory for the FDA submissions?

No. The FDA does not mandate a specific consensus standard for cybersecurity. Section 524B requires reasonable assurance of cybersecurity, and IEC 81001-5-1 is one of the most efficient ways to demonstrate lifecycle process conformance. The February 3, 2026 premarket guidance recognizes it as an acceptable reference.

Is AAMI SW96 mandatory?

No, it is not mandatory either. It is FDA-recognized as Consensus Standard 13-131 and is currently the clearest normative path to a security risk management file that mirrors the structure of ISO 14971.

Did AAMI SW96 make AAMI TIR57 obsolete?

No. SW96 is the normative security risk management standard, while TIR57 remains an informative technical report offering methodology and examples. Many programs still use TIR57 as a practical reference while conforming to SW96 as the controlling standard.

Can a manufacturer use only one of these standards?

Yes, but it usually leaves a gap. Using only IEC 81001-5-1 leaves the question of how residual security risk is scored and accepted; using only AAMI SW96 leaves the question of where the lifecycle process evidence lives. Most submissions are stronger citing both with explicit traceability.

How does IEC 81001-5-1 relate to IEC 62304?

IEC 62304 governs the software lifecycle for functional safety, while IEC 81001-5-1 governs the secure development lifecycle for cybersecurity. The two standards are designed to coexist and are commonly invoked together within a single quality system.

CTA

If your team needs a defensible mapping between IEC 81001-5-1, AAMI SW96, and your quality system before your next submission, our premarket cybersecurity team can help you build the procedures and traceability reviewers expect. Schedule a discovery call to review your current SPDF and security risk management approach.