On this page
Published: July 21, 2026
Key Takeaways
- ANSI/AAMI SW96:2023 is the FDA-recognized normative standard for [medical device security](/medical-device-cybersecurity "medical device cybersecurity") risk management; AAMI TIR57 is informative.
- SW96 has not formally withdrawn TIR57 — both remain published, but reviewers expect SW96 conformance.
- The FDA's February 3, 2026 final [premarket cybersecurity](/services/fda-premarket-cybersecurity-services "FDA premarket cybersecurity") guidance points to SW96, not TIR57, as the reference standard.
- A TIR57-era security risk file usually needs restructuring, not rewriting, to conform to SW96.
- TIR97 (postmarket) and IEC 81001-5-1 (lifecycle activities) sit alongside SW96; TIR57 remains useful as methodology background.
No, ANSI/AAMI SW96:2023 did not formally withdraw AAMI TIR57. But SW96 is now the FDA-recognized normative standard (Recognition #44689) for medical device security risk management, while TIR57 remains an older, informative Technical Information Report. In a 2026 premarket submission you conform to SW96 and cite TIR57 only as supporting methodology.
Last updated: July 2026
The question comes up in nearly every Section 524B kickoff we run: teams that built their program around AAMI TIR57 want to know whether they need to redo it under SW96. The short answer is that SW96 is now the standard the FDA points to, and citing only TIR57 in a 2026 submission is a common trigger for a cybersecurity deficiency letter.
TIR57 was published in 2016 as a Technical Information Report — informative guidance, not a normative standard. ANSI/AAMI SW96 was published in 2023 as a full consensus standard and formally recognized by the FDA. Both documents still exist. Only one carries conformance weight.
This post explains the practical difference, what actually changes in your risk file, and how to migrate a TIR57-era program to SW96 without rewriting from scratch.
Table of Contents
- Why This Matters
- What Is the Difference Between SW96 and TIR57?
- Did AAMI Withdraw TIR57?
- What Does the FDA Actually Recognize?
- How Do You Migrate a TIR57 Program to SW96?
- Where Do TIR97 and IEC 81001-5-1 Fit?
- How Blue Goat Cyber Approaches This
- Frequently Asked Questions
Why This Matters
The FDA's Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions final guidance (February 3, 2026) is now the operative document for 524B submissions. It references ANSI/AAMI SW96:2023 as the consensus standard for security risk management. TIR57 is not called out with the same weight.
SW96 was added to the FDA Recognized Consensus Standards Database (Recognition Number 44689) in 2023. A declaration of conformity to SW96 lets you shortcut the reviewer's evaluation of your risk management process. A submission that cites only TIR57 does not get the same treatment — the reviewer has to evaluate your methodology from scratch, and any gaps against SW96 requirements come back as deficiencies.
This affects three concrete outcomes: submission review time, the volume of Submission Issue Requests you receive, and the defensibility of your risk file in a postmarket incident. Migrating from TIR57 to SW96 is not a big rewrite — SW96 is largely an evolution of TIR57's principles into normative requirements — but it does need to happen before your next filing.
What Is the Difference Between SW96 and TIR57?
SW96 is a normative standard; TIR57 is informative. That is the single most important distinction.
| Attribute | ANSI/AAMI SW96:2023 | AAMI TIR57:2016 |
|---|---|---|
| Document type | Normative consensus standard | Technical Information Report (informative) |
| FDA recognition | Yes (Recognition #44689) | No |
| Language | "Shall" (requirements) | "Should" (guidance) |
| Conformance possible | Yes — declare in submission | No — cite as reference only |
| Primary output | Security risk management file with defined contents | Principles for building one |
| Lifecycle scope | Design, production, post-production | Full lifecycle, principles-based |
| Alignment | Structured to complement ISO 14971 and IEC 81001-5-1 | Precedes IEC 81001-5-1; overlap with SW96 |
SW96 defines what the security risk management file must contain and what activities the manufacturer must perform. TIR57 explains the principles behind those activities. If you have a well-run TIR57 program, most of the content maps forward — the structure and traceability requirements are what tighten up.
Did AAMI Withdraw TIR57?
No. As of mid-2026, TIR57 remains a published AAMI Technical Information Report. It has not been withdrawn or superseded in the way that a revised standard supersedes an older revision.
AAMI's rationale is that TIR57 and SW96 serve different roles. TIR57 is educational — it walks a team new to security risk management through the concepts. SW96 is the standard you conform to when you have a program in place and need reviewer-recognized evidence.
Practically, most manufacturers now treat TIR57 as background reading and structure their actual deliverables to SW96. That's the pattern the FDA has come to expect.
What Does the FDA Actually Recognize?
The FDA Recognized Consensus Standards Database is the authoritative source. As of this writing:
[KEY REQUIREMENT] ANSI/AAMI SW96:2023 — Recognition Number 44689 — Standard for medical device security — Security risk management for device manufacturers. Recognized in full.
TIR57 is not listed with a current recognition number for security risk management. The 2026 premarket cybersecurity guidance cites SW96 alongside ISO 14971, IEC 81001-5-1, and IEC 62304 as the standards a modern SPDF should be built on.
See also: IEC 62304 Classes vs FDA Device Classes, Q-Sub vs Pre-Sub: FDA Cybersecurity Feedback Guide, and FDA SIR Cybersecurity Response: eSTAR Prep Guide.
The practical effect: a declaration of conformity to SW96 in your premarket submission triggers the abbreviated review pathway for that portion of your risk file. A citation of TIR57 does not.
How Do You Migrate a TIR57 Program to SW96?
Most TIR57-based programs can be aligned to SW96 in a few structured passes rather than a full rewrite.
Pass 1: Structure the security risk management file. SW96 defines specific artifacts — security risk management plan, security risk analysis, security risk evaluation, security risk control, residual security risk evaluation, and security risk management report. Reorganize your existing content into these buckets. Most content already exists; it just lives in the wrong files.
Pass 2: Trace to ISO 14971 hazards. SW96 requires that security risks with safety impact are traced to the ISO 14971 safety risk file. TIR57 encouraged this; SW96 requires it. Add the traceability matrix.
Pass 3: Tighten the threat model. SW96 expects a threat model with assets, threats, vulnerabilities, and controls, updated on architecture change. If your TIR57 threat model is a static document, convert it to a living artifact with a documented update trigger.
Pass 4: Declare conformity. Add the SW96 declaration of conformity to your premarket submission cover letter and cybersecurity documentation.
Teams typically complete this in 3–6 weeks per product family, not the multi-month rebuild people fear.
Where Do TIR97 and IEC 81001-5-1 Fit?
SW96 covers security risk management. It does not cover everything. The full 2026-ready stack is:
- ANSI/AAMI SW96:2023 — security risk management (conformance)
- IEC 81001-5-1:2021 — health software and health IT systems safety, effectiveness, and security (lifecycle activities)
- ISO 14971:2019 — application of risk management to medical devices (safety linkage)
- IEC 62304:2006/AMD1:2015 — medical device software lifecycle processes
- AAMI TIR97:2019 — principles for medical device security — postmarket risk management
- AAMI TIR57:2016 — retained as methodology reference
TIR97 is postmarket-specific and complements SW96's post-production requirements. IEC 81001-5-1 defines the security activities inside your software lifecycle. Together they cover premarket, postmarket, and lifecycle security in a way TIR57 alone never did.
For a deeper breakdown, see our AAMI TIR57 vs TIR97 vs SW96 comparison and SW96 vs TIR57 side-by-side.
How Blue Goat Cyber Approaches This
Our secure product design engagements deliver an SW96-conformant security risk management file, an ISO 14971 hazard trace, an SBOM in SPDX or CycloneDX, a living threat model, and postmarket monitoring tied to AAMI TIR97. TIR57 remains in our toolkit as methodology reference, but every deliverable and traceability artifact is structured to what the FDA recognizes today.
For teams migrating from a TIR57-era program, we run a fixed-scope gap assessment that maps existing artifacts to SW96 requirements and produces a migration plan sized in weeks, not quarters. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.
Frequently Asked Questions
CTA
Not sure whether your current risk file will hold up under SW96 in a 2026 submission? Book a gap assessment — we'll map your existing artifacts against SW96 requirements and give you a fixed-scope migration plan. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.
Christian Espinosa, MBA, CISSP, is Founder and CEO of Blue Goat Cyber. He has led hundreds of FDA premarket cybersecurity engagements and helped medical device teams align their security risk management programs with AAMI SW96, TIR57, TIR97, and IEC 81001-5-1. Read more from Christian.