AAMI SW96 vs TIR57
Side-by-side comparison of the two AAMI medical device cybersecurity risk-management documents most often cited in FDA submissions.
| Dimension | ANSI/AAMI SW96:2023 | AAMI TIR57:2016/(R)2019 |
|---|---|---|
| Document type | ANSI/AAMI consensus standard (normative). | AAMI Technical Information Report (informative). |
| Published | 2023 (ANSI/AAMI SW96:2023). | 2016, reaffirmed 2019 (AAMI TIR57:2016/(R)2019). |
| FDA recognition | Recognized consensus standard (FDA Recognition #5-148). | Cited in 2014 and 2018 FDA premarket guidance; superseded as the primary reference in the 2026 final guidance. |
| Risk-management framework | Aligns to ISO 14971 but adds a parallel cybersecurity risk process with explicit threat-modeling and exploitability inputs. | Adapts ISO 14971 vocabulary to security; introduces the security risk-management file concept. |
| Threat modeling | Required activity with explicit linkage to risk register entries. | Recommended; methodology left to the manufacturer. |
| Use today | Preferred reference for new submissions under the FDA 2026 guidance. | Still acceptable; many legacy quality systems and risk files reference it. |
| Relationship | Builds on TIR57 and supersedes it as the consensus standard. | Conceptual ancestor of SW96; remains a useful tutorial reference. |
When to use which
For any new FDA premarket submission planned under the Cybersecurity in Medical Devices final guidance (effective February 3, 2026), build the cybersecurity risk-management file against ANSI/AAMI SW96:2023. Map every threat in the threat model to a SW96 risk register entry and to a verification or mitigation artifact in the submission package.
Programs with mature, audited risk files written against AAMI TIR57 do not need to be rebuilt from scratch. Maintain TIR57 traceability and add a SW96 conformance overlay that demonstrates equivalence to reviewers - Blue Goat Cyber routinely produces this crosswalk as part of a deficiency-letter response.
What changes when you move from TIR57 to SW96
- Threat modeling becomes required, and each threat must link to an entry in the security risk register.
- Exploitability replaces probability. Security risk is scored on how easily a threat can be exploited, not on how likely it is to happen. Language like "unlikely" or "low probability" in a security risk file is a common reviewer flag.
- Traceability tightens. Each security control should trace to a threat, a risk entry and a test that shows it works.
- Security risk connects to safety risk. Where a security threat could cause patient harm, the security file feeds the ISO 14971 safety risk file instead of living on its own.
A practical migration checklist
- Inventory where your procedures and risk files cite TIR57.
- Update the security risk procedure to use exploitability scoring and require a threat model.
- Re-score open risks with the new method and document why any ratings changed.
- Add traceability from each control to its verification test.
- Keep the TIR57 history for audit, with a crosswalk showing how it maps to SW96.