ISO 14971 + AAMI TIR57: The Connection

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

Every FDA submission with a network-connected feature now needs a security risk management process, and most manufacturers try to build one by stretching their existing ISO 14971 safety risk file to cover it. That stretch usually breaks, because security risk does not behave like safety risk: an attacker chooses when and how to exploit a weakness, so there is no meaningful "probability of occurrence" to estimate the way there is for a component failure rate.

AAMI TIR57 exists to fix that mismatch. It gives manufacturers a security-specific risk management process built on the same vocabulary and structure as ISO 14971, so the two can sit in a single coherent risk file instead of two disconnected documents. Understanding what TIR57 actually says, and how ANSI/AAMI SW96:2023 has since built on it, matters for anyone assembling premarket cybersecurity documentation today.

Why This Matters

The FDA's Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 3, 2026 final guidance) made cybersecurity documentation a gating criterion for clearance under Section 524B of the FD&C Act. That guidance expects a security risk management process that is distinct from, but integrated with, the device's ISO 14971 safety risk file, and it expects manufacturers to show their work: asset inventories, threat models, vulnerability assessments, and a documented benefit-risk decision for any residual security risk.

Reviewers routinely ask manufacturers to explain how their security risk terminology maps back to their safety risk terminology, because a security risk management report that cannot reconcile its severity scale with the ISO 14971 file creates an internal contradiction the FDA will flag. Citing TIR57 alone, without acknowledging that ANSI/AAMI SW96:2023 is now the FDA-recognized normative standard for the same subject matter, is itself a common source of first-cycle Additional Information requests.

What Is AAMI TIR57?

AAMI TIR57 is a Technical Information Report titled "Principles for medical device security, Risk management," published to give manufacturers a structured way to apply security thinking to the ISO 14971 risk management process. A Technical Information Report is informative guidance developed by an AAMI committee, not a normative consensus standard, which means it describes an accepted method rather than setting mandatory pass or fail requirements.

That distinction matters in practice. A manufacturer cannot claim "conformance" to a TIR the way it claims conformance to ISO 14971 or ANSI/AAMI SW96:2023, because a TIR does not carry the same normative status. What TIR57 does provide is a well-tested process that manufacturers, and later standards bodies, have relied on heavily when building formal security risk management programs.

Why Is Security Risk Different from Safety Risk?

TIR57's central and most cited contribution is drawing a firm line between security risk and safety risk, which is the idea that gets lost when teams try to reuse a safety risk template for cybersecurity. Safety risk in ISO 14971 combines the severity of harm with the probability that harm will occur, and that probability is estimated from failure rates, use error data, or engineering analysis of a component or process.

[KEY REQUIREMENT] A security risk management process should not attempt to assign a meaningful numeric probability to an exploit occurring, because exploitation depends on attacker motivation, capability, and opportunity, none of which behave like a hardware failure rate.

Security risk does not work that way, because exploitation is attacker-driven rather than random. TIR57's answer is to replace probability of occurrence with exploitability, a structured judgment of how easy a vulnerability is to find and use given the attacker's likely skill, access, and motivation. Severity of harm still uses the same scale as the safety risk file, which is what keeps the two processes connected instead of drifting apart.

What Process Does TIR57 Lay Out?

TIR57 defines a security risk management process that runs in parallel with, and feeds into, the ISO 14971 safety risk process. The stages are asset identification, threat modeling, vulnerability assessment, risk estimation and evaluation, risk control, residual risk evaluation, and a documented security risk management report.

Asset identification catalogs what needs protecting: patient data, device functions, network interfaces, and the software components that support them. Threat modeling maps how those assets could be attacked, typically using a structured method such as STRIDE. Vulnerability assessment identifies specific weaknesses in the design or implementation. Risk estimation and evaluation combines exploitability with severity of harm to reach a risk level, which then feeds a risk control decision the same way it would in ISO 14971. The security risk management report documents the full process and its outcome, and it is the security-specific counterpart to the ISO 14971 risk management report.

How Does TIR57 Connect to ISO 14971?

TIR57 connects to ISO 14971 at three specific points rather than being a fully separate framework. The first is harm vocabulary, since TIR57 uses ISO 14971's definitions of harm and hazard rather than inventing new terms, which keeps security findings traceable into the same hazard list a safety reviewer already understands. The second is the severity scale, where TIR57 deliberately reuses the manufacturer's existing ISO 14971 severity categories instead of creating a parallel security-only scale.

The third is the benefit-risk acceptance decision. When residual security risk cannot be reduced further, TIR57 routes that decision through the same benefit-risk framework ISO 14971 already requires, so a single risk acceptability policy governs both safety and security residual risk. For a deeper worked example of this mapping, including a side-by-side step comparison and a harm-taxonomy template, see ISO 14971 vs AAMI SW96: Safety Meets Security Risk.

How Does TIR57 Relate to ANSI/AAMI SW96:2023?

ANSI/AAMI SW96:2023 is the normative consensus standard that grew out of the same body of practice TIR57 established, and the FDA now recognizes it under recognition number 13-131. Where TIR57 is informative guidance describing a good process, SW96 sets requirements a manufacturer can be assessed against, and it extends TIR57's process with more explicit expectations for coordinated vulnerability disclosure, supply chain risk, and postmarket monitoring.

See also: AAMI SW96 vs TIR57: Did SW96 Replace It?, IEC 80001-1: Hospital Network Risk Management Explained, and MDCG 2019-16 & MedTech Cybersecurity.

SW96 does not erase TIR57's value. Much of TIR57's process description, especially its explanation of exploitability and its worked risk estimation logic, still holds up and is commonly cited as supporting methodology inside an SW96-conformant risk file. What has changed is which document a manufacturer should point to as its primary conformance claim.

Is AAMI TIR57 Still Relevant in 2026?

Yes, TIR57 is still relevant as methodology, training material, and supporting citation, even though it is no longer the primary document a 2026 submission should claim conformance to. Reviewers under the February 3, 2026 final guidance are used to seeing SW96 cited as the normative standard, with TIR57 referenced alongside it to explain process detail that SW96 assumes the reader already knows.

[KEY REQUIREMENT] A 2026 submission's security risk management report should cite ANSI/AAMI SW96:2023 as the conformance standard, with AAMI TIR57 referenced only as supporting methodology, not as the primary basis for the process.

Manufacturers that built their security risk programs on TIR57 before SW96 published do not need to start over. The practical step is updating the citation and confirming the process covers the additional expectations SW96 adds, particularly around supply chain and disclosure.

How Does TIR57 Compare to SW96 and ISO 14971?

What Does the FDA Expect Under the February 3, 2026 Guidance?

The FDA's February 3, 2026 final premarket cybersecurity guidance expects a security risk management report that is clearly integrated with the ISO 14971 safety risk file, built on a documented threat model, and grounded in a normative standard rather than informal practice. In practice that means citing ANSI/AAMI SW96:2023 as the conformance basis, showing the asset inventory and threat model that fed the risk estimates, and demonstrating that residual security risk went through the same benefit-risk acceptance decision as residual safety risk.

Manufacturers who can show the TIR57-style process underneath their SW96 conformance claim, meaning a clear exploitability-based risk estimation rather than a reused safety probability figure, tend to move through review with fewer questions about their methodology.

How Blue Goat Cyber Approaches This

Blue Goat Cyber builds security risk management files that conform to ANSI/AAMI SW96:2023 while keeping the TIR57 process logic that reviewers expect to see underneath it: exploitability-based estimation, a documented threat model, and a benefit-risk decision that reconciles with the existing ISO 14971 file rather than contradicting it. Our medical device threat modeling services produce the asset inventory and threat model that anchor this process, and our FDA-compliant SBOM services supply the supply chain visibility SW96 expects beyond what TIR57 originally covered. We scope every engagement to the February 3, 2026 guidance documentation set so the security and safety risk files read as one coherent story.

Frequently Asked Questions

What is AAMI TIR57?

AAMI TIR57 is a Technical Information Report, "Principles for medical device security, Risk management," that adapts ISO 14971's risk management structure specifically to cybersecurity threats. It is informative guidance rather than a normative standard.

Is AAMI TIR57 required for FDA submissions?

No document called TIR57 is itself an FDA submission requirement. The FDA-recognized normative standard covering this subject matter today is ANSI/AAMI SW96:2023, recognition number 13-131, with TIR57 cited as supporting methodology.

How is security risk different from safety risk under TIR57?

Safety risk combines severity of harm with a probability of occurrence estimated from failure data. Security risk replaces that probability with exploitability, a judgment of how easily a vulnerability could be found and used, because attacker behavior does not follow a predictable failure rate.

Did ANSI/AAMI SW96:2023 replace TIR57?

Not formally. SW96 became the FDA-recognized normative standard for the same subject matter, and it extends TIR57's process with added expectations around disclosure and supply chain risk, but TIR57 was not withdrawn and is still cited as supporting methodology.

How does TIR57 connect to ISO 14971?

TIR57 connects to ISO 14971 at three points: it reuses ISO 14971's harm vocabulary, reuses the same severity scale rather than creating a separate one, and routes residual security risk through the same benefit-risk acceptance decision.

What should a security risk management report include?

It should include an asset inventory, a threat model, a vulnerability assessment, exploitability-based risk estimates, the risk control measures applied, the residual risk evaluation, and a documented benefit-risk decision consistent with the device's ISO 14971 file.

CTA

If your security risk management report is still built entirely around a reused safety probability estimate, or still cites TIR57 alone without ANSI/AAMI SW96:2023, that is a gap a 2026 reviewer will likely raise. Blue Goat Cyber can review your current risk file and close it before submission. Contact us to get started.