AAMI TIR57 vs TIR97: Medical Device Risk Management Guide

Manufacturers should select these complementary references for their scope, rather than treating their numbering as a replacement sequence.

TIR57's historical role

AAMI TIR57, "Principles for medical device security - Risk management," was published in 2016 and for several years functioned as the closest thing the industry had to a dedicated cybersecurity risk management framework built on top of ISO 14971. It introduced device manufacturers to security-specific concepts that ISO 14971's safety-oriented risk process did not natively cover: threat modeling, adversarial risk (as opposed to random failure risk), and the idea that a security risk assessment needs to account for an intelligent, motivated attacker rather than a probability distribution of component failures.

TIR57 remains relevant security risk management guidance. The FDA cites both TIR57 and SW96 in its February 3, 2026 premarket cybersecurity guidance, pp. 11-12.

ANSI/AAMI SW96:2023: total product lifecycle security risk management

ANSI/AAMI SW96:2023, "Standard for medical device security: Security risk management for device manufacturers," was approved by AAMI on December 21, 2022, and by ANSI on January 13, 2023. It predates the 2026 FDA guidance and covers the total product lifecycle.

SW96 defines a security risk management process across the total product lifecycle. Its abstract states that it is intended for use "in conjunction with AAMI TIR57 and AAMI TIR97," not as a replacement for either.

AAMI TIR97: the postmarket standard

AAMI TIR97:2019/(R)2023, "Principles for medical device security: Postmarket risk management for device manufacturers," provides postmarket-focused guidance complementary to TIR57 and SW96. TIR97 covers:

• Establishing an ongoing vulnerability monitoring process, including SBOM-driven CVE matching.
• Triaging newly discovered vulnerabilities against the device's deployed configuration, the same discipline behind a VEX statement.
• Determining when a vulnerability warrants a patch, a compensating control, or a documented decision not to act.
• Coordinating with a coordinated vulnerability disclosure program to receive and process externally reported vulnerabilities.
• Communicating with users, providers, and regulators when postmarket risk changes materially.

Postmarket processes should be planned during development and maintained after release. Section 524B requires a postmarket vulnerability management plan, including coordinated vulnerability disclosure, but does not mandate citation of TIR97.

Head-to-head: what each document is actually for

Why manufacturers still get this wrong

The numbering does not indicate supersession. TIR97 is postmarket-focused, while SW96 explicitly calls for use alongside both TIR57 and TIR97.

What this means for your security risk management file

The practical answer for most manufacturers is not to choose between TIR57, SW96, and TIR97. It is to build one security risk management file that:

1. Uses SW96 across the total product lifecycle, with traceable risk decisions.
2. Uses TIR57 for security risk management principles, alongside SW96 as appropriate.
3. Uses TIR97 for postmarket risk management, while addressing the statutory Section 524B plan requirements.
4. Keeps ISO 14971 as the governing safety risk framework, with SW96 and TIR97 integrated into it rather than run as disconnected parallel processes. See our companion guide on ISO 14971 vs. AAMI TIR57 hazard analysis for how the safety and security risk processes intersect.
5. Traces every premarket risk decision forward into the postmarket plan, so a residual risk accepted at clearance has a defined postmarket monitoring trigger if new information changes that risk calculus.

How Blue Goat Cyber approaches this

We build security risk management files that cite ANSI/AAMI SW96:2023 as the premarket methodology and AAMI TIR97 as the postmarket methodology, rather than defaulting to whatever standard a legacy template happened to reference. For manufacturers still running a TIR57-based process, we assess how much of the existing analysis is salvageable and re-map it to SW96's structure rather than starting over, which is usually faster than a full rebuild. On the postmarket side, we tie the TIR97-aligned vulnerability management process directly into SBOM and VEX tooling so the monitoring commitment in your submission narrative reflects a system that is actually running, not a policy statement. This work is delivered through FDA Premarket Cybersecurity Services for the premarket side and FDA Postmarket Cybersecurity Services for the ongoing postmarket program.

Where this fits in the cluster

• ISO 14971 vs. AAMI TIR57 Hazard Analysis
• Security Risk Assessment and IEC 81001-5-1
• Postmarket Cybersecurity Monitoring Program
• The MedTech Cybersecurity Standards Decoder

Related from Blue Goat Cyber

• FDA Premarket Cybersecurity Services
• FDA Postmarket Cybersecurity Services
• FDA Cybersecurity Deficiency Response

FAQ

Is AAMI TIR57 still valid for FDA submissions?

TIR57 has not been formally withdrawn, and it remains a reasonable reference for the concepts behind security risk management. However, it is no longer the standard the FDA's current guidance points to for premarket security risk management; that role now belongs to ANSI/AAMI SW96:2023. Submissions built solely around TIR57 in 2026 are more likely to draw a reviewer question asking for alignment with the current standard than submissions that cite SW96 directly.

What is the difference between AAMI TIR57 and SW96?

TIR57 introduced adversarial security risk management concepts as an extension of ISO 14971. SW96 is the formal standard that succeeds TIR57 in the premarket role, structuring those same concepts into a documented process and evidence set that aligns with current FDA premarket cybersecurity expectations. They cover similar territory conceptually; SW96 is the version manufacturers should be citing as their active methodology today.

What is the difference between SW96 and TIR97?

SW96 governs premarket security risk management: threat modeling, risk assessment, and control selection before a device is cleared. TIR97 governs postmarket security risk management: vulnerability monitoring, triage, patch decisions, and disclosure coordination after the device is in the field. They are not competing standards; a complete security risk management program uses both, for different phases of the same device lifecycle.

Do I need both SW96 and TIR97 for FDA compliance?

Most cyber devices need both in substance, even if a submission does not cite every standard by name. The February 3, 2026 premarket guidance expects a premarket security risk management process, which SW96 structures, and a postmarket vulnerability management plan under Section 524B, which TIR97 structures. Citing both standards explicitly in your submission narrative gives reviewers a recognized framework to check your process against rather than making them evaluate a bespoke approach from scratch.

Should I rewrite my TIR57-based risk management file from scratch to use SW96?

Usually not entirely. Most TIR57-based threat models and risk assessments contain analysis that is still valid; what typically needs to change is the structure, terminology, and evidence mapping so the file reads as SW96-aligned rather than TIR57-aligned. A gap assessment against SW96's specific process steps is the faster path, reserving a full rebuild for cases where the underlying analysis itself is thin or outdated.

Sources & primary references

• Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (FDA, February 3, 2026 final guidance)
• ANSI/AAMI SW96:2023, Medical device security risk management
• AAMI TIR57:2016, Principles for medical device security - Risk management
• AAMI TIR97:2019, Principles for medical device security - Postmarket risk management for device manufacturers
• ISO 14971:2019, Medical devices - Application of risk management to medical devices

Free tools for this

• Cybersecurity Standards Mapper - see which consensus standards cover which submission requirement.