AAMI TIR57 (R2023): Cybersecurity Risk Management for Devices

Last updated: February 2026

AAMI TIR57 is one of the most practical “how-to” documents in medical device cybersecurity. If you already run an ISO 14971 risk process, TIR57 shows you how to apply that same rigor to cybersecurity—without turning it into a separate, disconnected IT exercise.

It’s also timely. FDA’s final cybersecurity guidance (February 2026) reinforces that cybersecurity should be built into your quality management system, with clear premarket evidence that your device is resilient and supportable over its lifecycle.

Key takeaways

TIR57 is an implementation guide for cybersecurity risk management in the context of ISO 14971—use it to make your security risk work audit- and review-ready.
The goal is traceability: threats → security requirements → implemented controls → verification evidence → residual risk rationale.
Premarket success depends on artifacts, not intentions—documented processes and objective evidence matter most.
Postmarket is part of risk control: monitoring, coordinated vulnerability disclosure, and secure update/patch capability are expected behaviors, not optional extras.

What is AAMI TIR57 (and what it isn’t)?

AAMI TIR57:2016 (R2023) is a Technical Information Report titled Principles for medical device security — Risk management. You can purchase it from the AAMI/ANSI webstore.

TIR57 is not a regulation. It’s not a one-page checklist. It’s a practical framework for running a repeatable cybersecurity risk management process that integrates with:

ISO 14971 (safety risk management),
software lifecycle practices (e.g., IEC 62304), and
security lifecycle practices (e.g., IEC 81001-5-1 / secure product development expectations).

Why it matters: FDA has recognized AAMI TIR57 as a consensus standard, and reviewers routinely look for the kind of disciplined, traceable risk approach that TIR57 promotes.

Where TIR57 fits in an FDA-ready cybersecurity program

If you want a simple mental model: FDA guidance describes what a solid cybersecurity story should include. TIR57 helps you execute the how—especially the mechanics of risk analysis, risk controls, and documentation.

In practice, TIR57 aligns well with a Secure Product Development Framework (SPDF) and supports the kind of evidence FDA expects in premarket submissions for devices with cybersecurity risk.

If you need help assembling a submission-ready package (SPDF, threat modeling, SBOM, and test evidence), see our FDA Premarket Cybersecurity Services.

How to run a TIR57-aligned cybersecurity risk assessment (practical workflow)

1) Define scope and intended use (including the “real” environment)

Start with what your device actually is in the field: connectivity, users, privileges, update paths, cloud dependencies, accessories, mobile apps, and the clinical workflow. Cyber risk changes dramatically depending on whether your device is isolated, hospital-networked, or cloud-connected.

Output: a clear scope statement and architecture/context description you can reuse in your risk file and premarket documentation.

2) Build a threat model that matches your architecture

TIR57 works best when your risk analysis is grounded in a threat model. Identify trust boundaries, data flows, privileged functions, and credible threat scenarios (e.g., unauthorized remote access, tampering, denial-of-service affecting essential performance).

Output: threat model + threat scenarios tied to architecture and intended use.

Need a structured approach? See Medical Device Threat Modeling Services.

3) Identify hazards and hazardous situations—including cybersecurity-driven ones

In a medical device context, cybersecurity events matter because they can impact:

safety (patient harm),
essential performance (loss or degradation of critical function),
effectiveness (incorrect output or therapy), and
confidentiality/integrity/availability of data and system behavior.

Output: a cybersecurity hazard list that can be incorporated into (or linked with) your ISO 14971 risk management file.

4) Analyze risk using defined criteria (not gut feel)

Define your scoring/acceptance criteria up front. Then assess each scenario using consistent logic. Good analyses distinguish between:

likelihood drivers (exposure, attack feasibility, required access, complexity), and
impact drivers (patient harm severity, essential performance degradation, clinical detectability, recovery time).

Output: risk ratings with documented rationale that a reviewer can follow.

5) Select risk controls that are testable (and don’t break clinical use)

Controls should be specific, implementable, and verifiable. Examples include:

authentication/authorization for privileged functions,
secure update mechanisms and rollback protections,
encryption and key management appropriate to the threat model,
logging and event detection aligned to safety impact,
hardening and secure configuration baselines,
software composition governance (SBOM + component control),
secure-by-design development practices (code review, SAST/DAST where appropriate).

Output: security requirements and design controls that map to each mitigated risk.

For SBOM creation and ongoing component tracking, see FDA-Compliant SBOM Services for MedTech.

6) Generate objective evidence: verification, validation, and security testing

This is where many submissions get weak: controls are described, but not proven. Build evidence that the control exists and works under expected conditions. Common evidence includes:

requirements-to-test traceability,
security verification results (including negative testing),
penetration testing focused on realistic attack paths,
vulnerability analysis of third-party components, and
secure update and recovery testing.

Output: test plans and reports that support your cybersecurity claims.

Need FDA-aligned testing? See FDA-Compliant Vulnerability & Penetration Testing.

7) Document residual risk and your justification

Residual risk decisions should be explicit: what remains, why it is acceptable, and what monitoring/response controls are in place. If you rely on user/administrator actions, include realistic labeling and instructions—not vague warnings.

Output: residual risk statements tied to evidence and postmarket controls.

8) Make postmarket part of the plan, not an afterthought

TIR57 emphasizes lifecycle risk management. That means you should plan for:

coordinated vulnerability disclosure (intake, triage, response timelines),
monitoring for newly disclosed component vulnerabilities,
patch development and deployment processes,
communication to customers and regulators when appropriate, and
periodic reassessment when the environment changes.

Output: vulnerability management procedures and update/patch governance that you can defend in audits and inspections.

For ongoing lifecycle support, see FDA Postmarket Cybersecurity Management Services.

Common pitfalls we see (and how to avoid them)

Threat model is missing or generic → Build it from your real architecture and clinical workflow.
Controls aren’t traceable to risks → Maintain a simple mapping: scenario → requirement → control → test evidence.
Testing is “security theater” → Focus on realistic attack paths and document what you did and didn’t test.
Residual risk is hand-waved → Write the rationale so a third party can follow it without assumptions.
Postmarket plan is vague → Define intake, triage, remediation, and customer communication steps.

Recommended references

AAMI TIR57 and Medical Device Cybersecurity FAQs

Is AAMI TIR57 required by FDA?

No—TIR57 is not a regulation. But it’s widely used because it provides a disciplined, reviewable way to manage cybersecurity risk using a risk management structure that regulators understand.

How is TIR57 different from FDA cybersecurity guidance?

FDA guidance explains what FDA recommends for device cybersecurity design, labeling, and premarket documentation. TIR57 provides practical methods to perform cybersecurity risk management in a structured, ISO 14971-aligned way.

How does TIR57 align with ISO 14971?

TIR57 fits cybersecurity risk work into a broader medical device risk management system: identify hazards, estimate and evaluate risk, implement controls, verify effectiveness, and document residual risk—using cybersecurity-appropriate inputs like threat models and vulnerability analysis.

What evidence should we have if we say we follow TIR57?

At a minimum: threat model, security requirements, risk control mapping, verification/validation results, and residual risk justification. Strong submissions also show postmarket monitoring, coordinated vulnerability disclosure, and update/patch capability.

What’s the fastest way to apply TIR57 to a legacy device?

Start with architecture and data flows, then run a focused threat model to identify the highest-impact scenarios. Prioritize compensating controls and update pathways you can realistically support, then build a minimal-but-traceable evidence set around those decisions.

Conclusion

AAMI TIR57 (R2023) is valuable because it turns “do cybersecurity” into a repeatable risk management process with artifacts you can defend. If your goal is an FDA-ready cybersecurity story, TIR57 helps you produce the traceable evidence reviewers and auditors can follow—without reinventing your quality system.

Book a Discovery Session

If you want help building a TIR57-aligned, submission-ready cybersecurity package (threat modeling, SBOM, testing evidence, and documentation), we can help.

Book a Discovery Session