Published: June 3, 2026 · Last reviewed: May 1, 2026
IEC 81001-5-1:2021 and ANSI/AAMI SW96:2023 are the two standards FDA reviewers most often expect to see referenced in a medical device Secure Product Development Framework (SPDF). IEC 81001-5-1 defines secure product development lifecycle processes for health software; AAMI SW96 defines security risk management for medical device software, paralleling ISO 14971 for safety. They are complementary, not competing — most strong submissions reference both: SW96 for the security risk file, 81001-5-1 for the lifecycle and process evidence.
Published June 3, 2026
The two questions we get most often after a Section 524B SPDF discussion are: "do I need IEC 81001-5-1?" and "isn't AAMI SW96 the same thing?" Short answer: they cover different things, the FDA reads both, and choosing one over the other is usually the wrong question.
Key Takeaways
- IEC 81001-5-1 = secure development lifecycle (processes, activities, evidence).
- AAMI SW96 = security risk management (parallels ISO 14971 for cyber).
- The FDA recognizes both; the Feb 3, 2026 premarket guidance references both as acceptable.
- Most mature SPDFs cite IEC 81001-5-1 for lifecycle conformance and SW96 for the security risk file.
- Neither standard alone fully satisfies Section 524B - they are inputs, not the requirement itself.
What Each Standard Actually Covers
IEC 81001-5-1:2021
IEC 81001-5-1 is the secure product development process standard for health software and software in medical devices. It defines what activities must exist across the lifecycle — security requirements, secure design, implementation, verification, release, problem resolution, software maintenance — and what evidence each activity must produce.
If you have read IEC 62304, the structure feels familiar: 81001-5-1 is to cybersecurity what 62304 is to functional software safety. It is process-and-evidence focused. It does not tell you how to score a threat; it tells you that you must perform secure design activities, document them, and maintain them.
ANSI/AAMI SW96:2023
AAMI SW96 is the security risk management standard for medical device software. Published in 2023, it intentionally mirrors the structure of ISO 14971 — risk analysis, risk evaluation, risk control, residual risk evaluation, overall residual risk acceptability — but for cybersecurity risks rather than safety hazards.
SW96 is what produces the security risk file: identified threats, likelihood and impact scoring, control selection, residual risk after controls, and overall acceptability. It is the natural home for the AAMI TIR57-style analysis the FDA expects, but as a normative standard rather than a technical information report.
Side-by-Side Comparison
| Dimension | IEC 81001-5-1:2021 | ANSI/AAMI SW96:2023 |
|---|---|---|
| Type | International (IEC) | National (AAMI / ANSI) |
| Focus | Secure development lifecycle processes | Security risk management |
| Parallels | IEC 62304 (software lifecycle) | ISO 14971 (safety risk) |
| Primary output | Process records, lifecycle evidence | Security risk file |
| Scope | Health software + software in medical devices | Medical device software cyber risk |
| Published | 2021 | 2023 |
| FDA recognition | Referenced in Feb 3, 2026 premarket guidance | Referenced in Feb 3, 2026 premarket guidance |
| Best used for | Anchoring the SPDF and lifecycle conformance | Anchoring the security risk assessment |
Which Should You Use?
In almost every FDA cybersecurity engagement we run, the answer is both — and they sit in different parts of the submission:
- SPDF section → cite IEC 81001-5-1 to demonstrate lifecycle process conformance.
- Security risk assessment / security risk file → cite AAMI SW96 (often with AAMI TIR57 as informative reference).
- Threat model → not the home of either standard, but feeds inputs into SW96.
Pick only one and you create a predictable gap:
- 81001-5-1 alone leaves reviewers asking how you score and accept residual security risk.
- SW96 alone leaves reviewers asking where the secure development process evidence lives across the lifecycle.
Both gaps show up frequently in Additional Information requests on 510(k) and PMA reviews.
What the FDA Actually Says
The FDA's February 3, 2026 premarket cybersecurity guidance names both standards as acceptable consensus-standard references for the SPDF and security risk activities. Neither is mandatory; the statute (Section 524B) does not name any specific standard. What the FDA does require is reasonable assurance of cybersecurity, and the standards are the most efficient way to demonstrate it.
In practice, reviewers expect to see at minimum one recognized standard for lifecycle process and one for security risk management, with traceability between them. IEC 81001-5-1 + AAMI SW96 is the cleanest pairing today.
Common Mistakes
- Treating SW96 as a lifecycle standard. It is not — it is a risk management standard. Using only SW96 for SPDF conformance leaves visible holes in your process evidence.
- Treating 81001-5-1 as a risk standard. It defines that security risk management must happen and references inputs, but it does not define the scoring methodology. SW96 (or 14971-aligned methods) fills that gap.
- Citing the standards in the cover letter and nowhere else. The FDA looks for actual traceability — procedures, work products, records — not just a name-check.
- Confusing SW96 with TIR57. TIR57 is an informative technical report. SW96 is a normative standard. Both can live together: SW96 sets the requirements, TIR57 offers the methodology detail.
How Blue Goat Cyber Helps
We build SPDFs that map cleanly to IEC 81001-5-1 for lifecycle conformance and security risk files that conform to AAMI SW96, with full traceability into threat models, SBOM/VEX, and testing evidence. The result is a cybersecurity package that holds up against reviewer questions instead of generating new ones. Contact us to align your SPDF with both standards.
FAQs
Is IEC 81001-5-1 mandatory for FDA submissions?
No. The FDA does not mandate any 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 Feb 3, 2026 premarket guidance recognizes it as acceptable.
Is AAMI SW96 mandatory?
No, also not mandatory. It is recognized in the Feb 3, 2026 premarket guidance and is the cleanest way today to structure a security risk file that mirrors ISO 14971.
Can I use one standard instead of both?
You can, but it usually creates a deficiency surface. The two standards cover different things — lifecycle process vs. security risk management — and most submissions are stronger with both.
How does AAMI SW96 differ from AAMI TIR57?
TIR57 is a technical information report (informative); SW96 is a normative consensus standard. SW96 sets the requirements for security risk management; TIR57 provides methodology detail and examples that can support an SW96-conformant program. See our AAMI TIR57 vs TIR97 comparison for the related risk-management standard pairing.
How does IEC 81001-5-1 relate to IEC 62304?
IEC 62304 governs the software lifecycle for safety; IEC 81001-5-1 governs the secure development lifecycle for cybersecurity. They are designed to coexist and are often invoked together in a single SPDF.
Where in the submission do I cite each standard?
IEC 81001-5-1 is typically cited in the SPDF / quality system section and referenced throughout the lifecycle evidence. AAMI SW96 is typically cited in the security risk management section and anchors the security risk file.
Related: IEC 81001-5-1 and Medical Device Security | Guide to IEC 81001-5-1 Security Risk Assessments | AAMI TIR57 vs TIR97 Comparison