A cyberattack on ordinary software can disrupt operations. On a connected medical device, it can alter clinical performance, interrupt essential functions, or place a patient at risk.
That danger became difficult to ignore when the FDA and CISA identified serious vulnerabilities in Contec CMS8000 and Epsimed MN 120 patient monitors in January 2025. Attackers could potentially control affected devices remotely, interfere with their operation, and access sensitive patient information.
Still, many manufacturers rely heavily on scans, penetration tests, or CVSS scores. Regulators expect something broader: a documented process that connects security threats with safety consequences throughout the device lifecycle.
AAMI TIR57 principles for medical device security risk management helped establish that connection. Although SW96 now provides newer requirements, AAMI TIR57 remains recognized by the FDA.
This guide explores how its principles work, what evidence they require, and where they fit within modern medical device cybersecurity.
Key Takeaways
- TIR57 still gives manufacturers a useful starting point for bringing cybersecurity into medical device risk management.
- FDA recognition does not make it a complete route to compliance. Current submissions need additional evidence and lifecycle planning.
- Teams updating an older TIR57 process should use SW96 to identify missing requirements and strengthen governance.
- A cyber weakness matters most when it can interfere with device performance, clinical use, or patient safety.
- Section 524B places greater responsibility on manufacturers to manage software components and external security reports after release.
What Is AAMI TIR57?
AAMI TIR57 stands for Principles for Medical Device Security Risk Management. AAMI first published it in 2016 and reaffirmed it in 2023 as AAMI TIR57:2016/(R)2023.
It is a Technical Information Report, which means it offers practical recommendations rather than mandatory requirements. Its purpose is to help medical device teams include cybersecurity within their existing risk management process.
The report is relevant to manufacturers, software developers, cybersecurity specialists, quality teams, regulatory professionals, and risk managers working on connected devices, SaMD, embedded software, wireless products, cloud-connected systems, and AI-enabled medical devices.
Is AAMI TIR57 Still Current in 2026?
Yes. AAMI TIR57 remains current in 2026. AAMI reaffirmed it in 2023; the document is still officially available. The FDA continues to recognize it under Recognition Number 13 83. The FDA recognition record also links it to the February 2026 FDA cybersecurity guidance.
| Topic | TIR57 Position |
| FDA recognized | Yes |
| Current | Yes |
| Mandatory | No |
| Normative | No |
| Supports FDA submissions | Yes |
| Alone satisfies Section 524B | No |
Confusion often starts with the release of ANSI/AAMI SW96:2023. SW96 was introduced as a formal standard with defined requirements for security risk management across design, production, and post-production activities. It builds on earlier AAMI guidance and provides a more structured approach than a Technical Information Report.
The FDA references both documents because they serve different purposes. TIR57 offers established methods for connecting security risk with ISO 14971-based safety risk management. SW96 adds broader lifecycle requirements and clearer expectations for manufacturers.
Manufacturers should not treat TIR57 as a complete compliance framework. The FDA states that following it alone does not satisfy every Section 524B requirement or all recommendations in its current premarket cybersecurity guidance.
Core Principles of AAMI TIR57 Security Risk Management
TIR57 connects cybersecurity decisions with established safety risk management activities.
Coordinate Security Risk Management with ISO 14971 Safety Risk Management
Cybersecurity and safety require separate assessments, but the findings must remain connected. A security issue that alters device operation, data, or availability can create a patient safety hazard.
When a security scenario could lead to harm, teams should assess it within the safety risk process. Controls chosen for cybersecurity should also be reviewed for possible safety effects, and safety controls should be checked for new security weaknesses. This coordination keeps both risk files consistent throughout the device lifecycle.
Identify Assets Before Assessing Threats
Threat analysis starts with identifying what the device must protect. Relevant assets include:
- Firmware and therapy algorithms
- Patient data and authentication credentials
- Cryptographic keys and update packages
- Cloud services and APIs
- Audit logs
Missing an asset can also hide its interfaces, dependencies, and possible attack paths. The resulting threat model will therefore provide incomplete coverage. FDA guidance expects threat modeling to consider the complete device system and its lifecycle.
Build Threat Scenarios Instead of Listing Vulnerabilities
A vulnerability is a weakness. A threat is a possible harmful event, while a threat actor is the person or group capable of causing it. The attack path shows how the actor could reach the target. Together, these elements form a threat scenario.
Teams can develop scenarios using:
- STRIDE to categorize common threat types
- MITRE ATT&CK to understand adversary behavior
- CAPEC to identify known attack patterns
- Attack trees to map routes toward an objective
- Abuse cases to examine how device functions could be misused
A vulnerability list alone does not explain who could exploit a weakness, how the attack could occur, or what the result would be. STRIDE threat modeling supplies that context and feeds realistic scenarios into the security risk analysis.
Define Risk Acceptance Before Performing Risk Analysis
Set the decision rules before reviewing any findings. These rules should define:
- The scoring method and risk categories
- Acceptance thresholds
- Who reviews and approves each risk
- How uncertainty is recorded
- When a risk requires escalation
Creating the criteria after seeing the results allows teams to adjust thresholds around inconvenient findings. Predetermined rules support consistent scoring and defensible risk acceptance decisions. NIST defines acceptable risk as residual risk that falls within established risk appetite and tolerance.
Select, Verify, and Validate Security Controls
Choose controls that address the risks already identified. Common examples include:
- Authentication and authorization
- Secure boot and cryptography
- Secure updates and communications
- Logging and least privilege
- Fail-safe behaviour and tamper resistance
Each control should link back to a specific threat scenario and risk. Verification confirms that the control was implemented correctly, while validation checks whether it reduces the intended risk without affecting device safety or essential performance.
Evaluate Residual Risk
Even after safeguards are added, some exposure can remain. The team must review whether that remaining risk is acceptable, needs another control, or should be escalated.
A technical fix is not always possible, particularly for devices with hardware, usability, or clinical constraints. In such cases, compensating measures can reduce exposure, but their effectiveness and any new risks they introduce still need to be assessed.
The final decision should reflect the possible patient harm alongside the device’s clinical benefit. The reasoning, evidence, and approval must be recorded clearly in the risk file. FDA guidance treats residual risk as controlled only when the remaining chance of patient harm is sufficiently low.
Monitor Production and Post-Production Information
Manufacturers should keep reviewing security information throughout the device lifecycle, including:
- Published CVEs and vulnerability disclosures
- Threat intelligence and penetration test findings
- Supplier notifications
- Complaints and reported security incidents
- Observations from devices used in the field
These sources can reveal new weaknesses or change the assessment of an existing risk. The security risk file should be updated whenever new evidence affects the likelihood, impact, or adequacy of current controls.
AAMI TIR57 Security Risk Management Process
TIR57 places security risk management within the broader medical device safety process. The workflow below helps teams move from initial planning to postmarket review while maintaining traceability between risks, controls, tests, and decisions.
1. Establish the security risk management plan
Set the approach before the assessment begins. The plan should define the scoring method, acceptance criteria, responsibilities, review stages, escalation paths, and evidence required.
Cybersecurity, engineering, quality, regulatory affairs, and risk management teams prepare the plan using the product scope, intended use, development schedule, regulatory requirements, and existing safety procedures.
2. Describe the system and operating environment
Document how the device works, where it will be used, and what it connects to. Relevant inputs include architecture diagrams, data flows, network connections, user roles, external services, supported configurations, and deployment assumptions.
Software, systems, cloud, clinical, and security teams use this information to record device boundaries, interfaces, trust boundaries, dependencies, and expected operating conditions.
3. Identify assets
List everything that requires protection or supports an important device function. The review should cover the system architecture, software inventory, SBOM, stored data, credentials, cloud resources, communication channels, and supplier components.
The resulting asset inventory should record each asset’s purpose, location, owner, dependencies, and security needs. Cybersecurity, software, privacy, systems engineering, and supplier teams usually contribute.
4. Identify threats and vulnerabilities
Review available evidence for weaknesses and possible sources of harm. Useful inputs include:
- Vulnerability scans and code reviews
- Penetration test findings
- Supplier notices and security advisories
- Threat intelligence and known exploits
Product security teams, developers, testers, architects, and suppliers document the affected component, technical evidence, related asset, and source of the finding.
5. Develop threat scenarios
Connect individual findings to a realistic sequence of events. Each scenario should show who or what could initiate the event, how access could be gained, which asset could be affected, and what the outcome might be.
Threat modelers, developers, safety specialists, and clinical experts can use STRIDE, attack trees, abuse cases, MITRE ATT&CK, or CAPEC. The completed threat model becomes an input to the security risk analysis.
6. Estimate security risk
Apply the scoring method defined in the plan to each threat scenario. Consider attacker capability, exploitability, exposure, existing safeguards, potential consequences, and uncertainty rather than relying on a vulnerability score alone.
Cybersecurity, safety, clinical, engineering, and quality teams record the rating, assumptions, risk category, and any link to a patient safety hazard. FDA guidance expects threat modeling and security risk assessment to account for the complete device system and possible safety effects.
7. Evaluate risk against predefined criteria
Compare each result with the acceptance criteria agreed upon at the start. The assigned risk owner then decides whether the risk can be accepted, needs additional controls, or requires escalation.
The record should include the decision, reviewer, supporting evidence, rationale, and approval date. Security, quality, regulatory affairs, and engineering leadership take part when the issue falls within their area of responsibility.
8. Select security controls
Choose safeguards that address the identified scenario without creating problems for device safety, usability, or clinical performance. The selection should consider the architecture, technical constraints, intended environment, and existing safety requirements.
Security, software, systems, clinical, quality, and human factors teams document the chosen control, the risk it addresses, the implementation owner, and the planned test method.
9. Verify implementation effectiveness
Test whether each safeguard was built correctly and performs as expected. Testers should use the security requirements, design records, software builds, threat scenarios, and expected control behaviour as their basis.
Verification engineers, developers, security testers, quality teams, and penetration testers retain test cases, results, failures, fixes, and retest evidence. Every result should remain traceable to the related control and risk.
10. Evaluate residual risk
Review the exposure that remains after the controls have been applied. Test outcomes, control limitations, compensating measures, newly introduced concerns, and clinical benefits can influence the decision.
Cybersecurity, safety, quality, clinical, regulatory affairs, and designated risk owners record whether the remaining risk is accepted, escalated, or returned for further action.
11. Produce the security risk management report
Compile the main records created during the assessment into one report. It should bring together:
- The security risk management plan
- System and asset information
- Threat scenarios and risk results
- Selected controls and test evidence
- Residual risk decisions and unresolved actions
Cybersecurity, engineering, quality, regulatory affairs, and risk management teams review the report and confirm that the planned activities were completed. It should provide clear traceability from each identified risk to its control, evidence, and approval.
12. Monitor production and post-production information
Continue reviewing security information after release, including CVEs, vulnerability disclosures, threat intelligence, supplier notifications, complaints, incidents, penetration test findings, and field observations.
Product security, engineering, customer support, quality, regulatory affairs, suppliers, and incident response teams assess whether new evidence changes an earlier conclusion. The outcome could require an updated risk record, investigation, corrective action, disclosure, software update, or additional control.
AAMI TIR57 includes production and post-production information within its risk management approach.
AAMI TIR57 vs TIR97 vs SW96 vs ISO 14971
| Document | Purpose | Document Type | Lifecycle Coverage | Regulatory Role | Current Use | Relationship with FDA Expectations |
| AAMI TIR57 | Helps manufacturers connect cybersecurity risks with medical device safety risk management. | Technical Information Report containing recommended practices | Primarily design and development, with links to later lifecycle activities | FDA recognized under Recognition Number 13 83 | Still used for its established security risk methods and alignment with ISO 14971 | FDA’s February 2026 guidance refers to security risk management plans and reports described in TIR57 and SW96. |
| ANSI/AAMI SW96:2023 | Provides requirements and guidance for medical device security risk management. | Consensus standard containing normative requirements | Design, production, and post-production | FDA recognized under Recognition Number 13 131 | Stronger current reference for creating or updating a formal security risk management process | Its lifecycle structure closely supports current FDA expectations for planned, documented, and traceable cybersecurity risk management. |
| ISO 14971:2019 | Provides the main process for identifying hazards, evaluating safety risks, applying controls, and monitoring their effectiveness. | International consensus standard | Entire medical device lifecycle | FDA recognized under Recognition Number 5 125 | Forms the foundation of medical device safety risk management | Cybersecurity findings move into the ISO 14971 process when they can affect device safety or lead to patient harm. |
| AAMI TIR97:2019 | Supports the management of cybersecurity issues discovered after release. | Technical Information Report containing recommended practices | Production and post-production | FDA recognized under Recognition Number 13 112 | Used for vulnerability assessment, remediation, disclosure, and postmarket risk updates | Supports FDA expectations for monitoring, assessing, and addressing vulnerabilities throughout the marketed device lifecycle. |
Manufacturers do not need to choose one document and ignore the others. SW96 provides the stronger basis for a current security risk management program, while TIR57 can remain part of established procedures where its methods still work well.
ISO 14971 continues to govern the safety risk process. TIR97 adds the postmarket practices needed once new vulnerabilities, incidents, or field information emerge. Together, the documents can support a connected approach across development, regulatory submission, and ongoing device monitoring.
Migrating from a TIR57-Based Process to SW96
Moving from TIR57 to SW96 does not require manufacturers to discard every existing procedure or risk file. SW96 updates earlier AAMI guidance and introduces formal requirements across design, production, and post-production security risk management.
A practical migration can follow these steps:
- Review current procedures: Examine how the existing process handles planning, threat modeling, risk evaluation, security controls, approvals, and ongoing monitoring.
- Map TIR57 activities to SW96: Link each current procedure and record to the relevant SW96 requirement. This shows what already meets the standard and where gaps remain.
- Identify missing requirements: Look for mandatory activities that were optional, unclear, or absent under the earlier process.
- Strengthen governance: Confirm ownership, approval authority, escalation routes, independence of reviews, and coordination between security, safety, quality, and regulatory teams.
- Update terminology and records: Align procedures, templates, risk categories, and report language with SW96 so teams use consistent definitions.
- Improve traceability: Connect assets, threat scenarios, risk decisions, security requirements, controls, test results, and residual risk approvals.
- Integrate Section 524B expectations: Add the processes and evidence required for applicable cyber devices, including vulnerability monitoring, coordinated disclosure, updates, and an SBOM. Conformance to a recognized standard does not by itself satisfy every Section 524B requirement.
- Revise and test the workflow: Update procedures and templates, train the participating teams, then apply the revised process to a pilot project or representative device.
Legacy TIR57 files can remain useful when they contain reliable analysis and traceable evidence. A documented gap assessment should identify which records can be retained, which need updating, and which new documents are required.
How Qualysec Helps Medical Device Manufacturers Strengthen Security Risk Management
Manufacturers using TIR57 or moving toward SW96 often need reliable testing evidence to support their risk records. Qualysec assesses medical devices, SaMD, APIs, cloud systems, mobile apps, web applications, IoT components, and external networks based on the product architecture and threat model.
Its approach combines manual testing with automated tools to examine realistic attack paths and validate findings. Reports include reproducible evidence, remediation guidance, and retesting results that teams can use when updating cybersecurity documentation.
These assessments can support work related to FDA guidance, ISO 14971, OWASP, NIST, HIPAA, SOC 2, and ISO 27001 without replacing the manufacturer’s own compliance responsibilities.
Bring Qualysec into your security review to uncover weaknesses before they complicate device development or regulatory submission.
Conclusion
TIR57 still offers a useful foundation for understanding how cybersecurity decisions connect with medical device risk. SW96 now gives manufacturers a more formal structure for applying those ideas across the product lifecycle. FDA continues to recognize TIR57 and references it alongside its February 2026 cybersecurity guidance.
A strong program depends on regular review rather than one completed assessment. As devices, threats, and regulatory expectations change, manufacturers should keep refining how engineering, quality, regulatory, and postmarket teams manage security together.
FAQs
1. What is AAMI TIR57?
AAMI TIR57 is a Technical Information Report that explains how manufacturers can manage medical device cybersecurity risks within the safety risk process described by ISO 14971. AAMI published it in 2016 and reaffirmed it in 2023.
2. Is AAMI TIR57 mandatory?
No. TIR57 provides recommended methods rather than mandatory requirements. FDA recognizes the complete 2016 document under Recognition Number 13 83, so manufacturers can use it to support relevant submission evidence.
3. Does TIR57 satisfy FDA Section 524B requirements?
No. TIR57 supports cybersecurity risk management, but it does not cover every Section 524B obligation. Applicable cyber devices also require an SBOM and processes for vulnerability monitoring, coordinated disclosure, cybersecurity updates, and patches.
4. Is threat modeling enough to comply with TIR57?
No. Threat modeling helps identify assets, attack paths, and possible device effects. A complete process also requires risk evaluation, control selection, verification, residual risk decisions, and continued review after release.
5. Can CVSS replace medical device security risk analysis?
No. CVSS describes the technical severity of a vulnerability but does not fully reflect device architecture, clinical use, existing controls, or possible patient harm. FDA recommends considering exploitability when evaluating cybersecurity risk.
6. What documents should be included in a TIR57 security risk management file?
Include the risk management plan, threat model, security risk analysis, control requirements, verification evidence, residual risk decisions, final report, and monitoring records. These can sit within existing quality or design files as long as they remain complete and traceable.
7. Does TIR57 apply to Software as a Medical Device?
TIR57 principles can support SaMD when cybersecurity weaknesses could affect safety, effectiveness, data, or essential software functions. The scope should reflect the product architecture and include relevant APIs, cloud services, external components, user access, and deployment conditions.
8. How does penetration testing support the TIR57 process?
Penetration testing provides evidence about whether vulnerabilities and attack paths can be exploited. Findings can strengthen threat scenarios, test security controls, uncover missed risks, and support remediation and retesting records. It supports the risk assessment but does not replace it.
