AAMI TIR57 and SW96 Medical Device Risk Guide: Running Security Risk Management Alongside ISO 14971

Medical device manufacturers already run safety risk management under ISO 14971, but security risk does not fit its probability-based model, and FDA reviewers now expect a security risk process that stands on its own and feeds the safety file. AAMI TIR57 and ANSI/AAMI SW96 are the two documents FDA recognises for exactly this job: TIR57 as the original guidance on running security risk management within the ISO 14971 framework, and SW96 as the newer standard that sets requirements across design, production and post-production. This guide explains what each covers, how they differ, how to build a security risk management process that satisfies both and links cleanly to the safety risk file, and where the FDA warns that conformance is not enough. It is for product security, quality and regulatory affairs teams at device manufacturers. The overall FDA submission content is covered in the FDA Medical Device Cybersecurity Guide, which this guide does not repeat. Both standards are paid AAMI documents; facts here come from FDA's recognition records and public summaries checked on 27 October 2026, so confirm clause-level detail against your licensed copies.

Key takeaways

• FDA recognises both. AAMI TIR57:2016 is recognised as a complete standard (recognition number 13-83, entered 27 June 2016) and ANSI/AAMI SW96:2023 likewise (13-131, entered 9 October 2023).
• TIR57 is guidance, SW96 sets requirements. TIR57 is a technical information report describing methods; SW96 is a standard that provides requirements and guidance for security risk management across the whole device life cycle.
• Two processes, deliberately linked. Both sit within the ISO 14971 framework but keep security risk analysis separate, passing security risks that could cause harm into the safety risk file; SW96 references the coordinated safety and security approach in Clause 9 of TIR57.
• Exploitability, not probability. FDA's recognition notes state that the ISO 14971 probability model does not apply to cybersecurity and that its guidance uses exploitability instead; your scoring method must reflect that.
• Conformance is necessary, not sufficient. FDA cautions that conforming to either document may not satisfy all section 524B requirements or the premarket cybersecurity guidance recommendations.

TIR57 and SW96 compared

In practice, manufacturers build their procedure to meet SW96 and use TIR57 for method detail and examples. A file written against TIR57 alone is still a recognised basis, but expect reviewers to look for the post-production activities that SW96 makes explicit.

How the security process links to ISO 14971

ISO 14971:2019 (third edition, reviewed and confirmed by ISO in 2025) remains the safety risk management standard for medical devices, from conception through decommissioning, with ISO/TR 24971:2020 as its guidance companion. The security process runs in parallel and exchanges information at defined points.

The decisive design choice is to keep two analyses with explicit links rather than forcing security into the safety spreadsheet. A single file tends either to discard security risks with no direct harm (data theft, ransomware staging) or to apply probability estimates to adversaries, which FDA's recognition notes say is the wrong model.

Building the security risk analysis

• Assets: list what an attacker could target: therapy functions, configuration and dosing parameters, patient data, cryptographic keys and certificates, update packages, service and maintenance interfaces, cloud back ends and mobile apps.
• Architecture views: draw the system with trust boundaries, every interface (wireless, USB, network, debug, cloud API) and every software component, including third-party and open-source software tracked in the SBOM. See the SBOM Guide.
• Threat model: apply a structured method such as STRIDE to each interface and component and record threat sources, including insiders, service technicians and compromised hospital networks. The Threat Modelling Guide covers method choice.
• Vulnerabilities: combine design weaknesses from the threat model with known vulnerabilities in components; CVSS can rate technical severity but does not replace the clinical impact assessment.
• Exploitability: score how easily each threat could be realised: access required (remote, adjacent, physical), skill and resources, availability of exploit information, and existing controls. Define the scale and acceptance thresholds in the plan before scoring.
• Impact: rate impact on patient safety, device effectiveness and data and systems security separately, so that a data-only risk is not dismissed because no patient is harmed.

Security controls and verification

Device credentials, service accounts and update signing keys are non-human identities with long lives and wide reach. Plan their issuance, rotation and revocation as part of the control set. See the Device and IoT Identity Guide and the Code Signing Security Guide.

Production and post-production activities

SW96's scope makes the post-market side explicit. The activities a reviewer or auditor will look for:

• Monitoring: watch vulnerability sources for every SBOM component and for the device class, and re-run the security risk evaluation when something relevant appears.
• Coordinated vulnerability disclosure: publish how researchers report issues, set response times and coordinate advisories. See the Bug Bounty and Vulnerability Disclosure Guide and the PSIRT Guide.
• Patching: define how fixes are validated, how quickly they are released by risk level, and how they are deployed in hospitals that control their own change windows.
• Customer communication: give healthcare delivery organisations security documentation, SBOMs, network requirements and advisories they can act on.
• Retirement: declare end of support dates and what happens to security updates after them, so hospitals can plan replacement.

The security risk management file

Whether an FDA reviewer, a notified body or an internal auditor is looking, the process is judged by its records. A complete file usually holds the following, each under document control and traceable to the design history file.

Keep the SBOM, the security labelling for customers and the residual risk statement consistent with each other: reviewers compare them, and contradictions between what the file accepts and what customers are told are a common finding. Where a residual risk depends on the hospital doing something (segmenting the device network, restricting a service port, applying a patch within a window), say so plainly in the customer documentation and record that transfer in the file.

Rolling out the process

1. Gap assessment: compare your current procedures with SW96 and with the recognised TIR57 method; list missing records, especially post-production ones.
2. Write the procedure: a security risk management procedure inside the quality management system, cross-referenced to the ISO 14971 procedure, with defined roles, exploitability and impact scales and acceptance criteria.
3. Pilot on one product: pick a connected device in development, run the full analysis, and test the hand-off of safety-relevant security risks into the safety file.
4. Calibrate scoring: run a calibration session so different analysts score the same threats consistently; adjust the scale wording rather than the scores.
5. Extend to legacy products: build retrospective security risk files for marketed connected devices, starting with those with remote interfaces.
6. Connect post-market: wire vulnerability monitoring and complaint handling into the security file so new information triggers re-evaluation.
7. Review and roll back: hold management reviews of residual risk across products; if a new scale or template fails in the pilot, revert to the previous procedure version under change control rather than running two methods in parallel.

Decision guidance

• Which document to claim: declare SW96 for new or substantially updated quality systems, because it covers the full life cycle; keep TIR57 as a cited method source. Do not claim either unless your procedure can be shown to meet it.
• Exploitability scale: a three to five level qualitative scale is easier to apply consistently than a numeric formula; numeric CVSS scores work as an input, not the result.
• Small manufacturers: a single cross-functional review board for safety and security risk is workable and keeps the hand-off simple; document both analyses separately even if the same people run them.
• Large portfolios: maintain shared threat libraries for common platforms (wireless modules, operating systems, cloud services) so each product file inherits reviewed analysis rather than starting again.
• Other markets: the same process supports EU MDR expectations and IEC 81001-5-1 secure development; map once and reuse. See the EU MDR Cybersecurity and MDCG 2019-16 Guide.

Detection and measurement

• Percentage of marketed connected devices with a current security risk file linked to the safety file.
• Number of security risks transferred into safety analyses per product, reviewed for completeness at each design review.
• Median days from a relevant new vulnerability to completed re-evaluation, and to customer communication.
• Percentage of security controls with recorded verification evidence.
• Analyst scoring agreement in calibration sessions.
• Number of devices approaching end of support with customers notified.

Common failure patterns

• Security forced into the safety spreadsheet: probability values are assigned to attacks, and risks without direct harm are closed as acceptable.
• No hand-off record: the security file exists, but nothing shows which security risks were considered in the safety analysis.
• Claiming conformance as compliance: the submission cites SW96 but omits 524B items FDA expects, such as a plan to monitor and address post-market vulnerabilities and an SBOM.
• Design-only analysis: the file stops at release; post-production monitoring, patching and retirement are not evidenced.
• Ignoring the hospital environment: the threat model assumes a trusted hospital network, which ransomware incidents in healthcare repeatedly disprove.
• Shared service credentials: a single maintenance password across the fleet is accepted as a residual risk instead of being designed out.

Framework mapping

Practitioner checklist

• Confirm which edition of each document you hold and cite the FDA recognition numbers (13-83 for TIR57:2016, 13-131 for SW96:2023) in your standards declaration.
• Write a security risk management procedure inside the QMS that cross-references the ISO 14971 procedure.
• Define exploitability and impact scales and acceptance criteria before any analysis starts.
• Keep separate security and safety analyses with recorded links for every security risk that can lead to harm.
• Base the analysis on architecture views, a threat model and the SBOM, and update it when any of them change.
• Record verification evidence for every security control.
• Run post-production monitoring, coordinated disclosure, patching and customer communication as recorded processes.
• Check the submission against section 524B and the current FDA premarket cybersecurity guidance, not only against the standards.
• Publish end of support dates and plan security updates up to them.

Standards and references

• FDA: Recognized Consensus Standard ANSI/AAMI SW96:2023
• FDA: Recognized Consensus Standard AAMI TIR57:2016
• ISO: ISO 14971:2019 Medical devices, Application of risk management to medical devices
• FDA: Cybersecurity in Medical Devices
• AAMI 1TechNation: FDA recognises ANSI/AAMI SW96:2023
• American Hospital Association: FDA recognizes ANSI/AAMI medical device standard
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: FDA Medical Device Cybersecurity Guide · Medical Device Security Guide · EU MDR Cybersecurity and MDCG 2019-16 Guide · Healthcare Cyber Regulation Map. This guide summarises AAMI TIR57 and ANSI/AAMI SW96 from public records and is not legal or regulatory advice.