AAMI TIR57 vs TIR97: Medical Device Risk Management Guide

Compare AAMI TIR57 vs TIR97. Learn how these cybersecurity risk management standards differ and how to apply them for FDA premarket and postmarket compliance.

This guide is written for medical device manufacturers navigating AAMI TIR57 vs TIR97. It is built from real submissions, FDA correspondence, and the standards reviewers actually cite. Use it as a working reference: read straight through, jump to the section that matches your current gap, or hand it to your engineering and regulatory leads as a checklist.

Intro: The Ecosystem of Medical Device Risk Management

Medical device cybersecurity risk management is not a single document, it is a lifecycle split across two complementary AAMI technical information reports. TIR57 governs the premarket side: how you identify threats, assess risk, and build security controls into the design before you ever file a submission. TIR97 picks up where TIR57 leaves off, governing how you monitor, triage, and respond to vulnerabilities once the device is in the field. Manufacturers who treat these as one continuous risk file, rather than two disconnected exercises, produce submissions that hold up better under FDA review and postmarket audits alike. The rest of this guide walks through each standard on its own terms, then compares them directly.

Why TIR57 and TIR97 Matter for FDA Submissions

The FDA does not cite AAMI TIR57 or TIR97 as mandatory standards by name in the same way it cites ISO 14971, but reviewers consistently use both as the de facto framework for evaluating whether a manufacturer's security risk management process is adequate. TIR57 is the reference reviewers reach for when they assess your premarket threat model, risk assessment methodology, and security requirements traceability. TIR97 is what they expect to see underpinning your postmarket vulnerability monitoring and disclosure program. Submissions that cannot show a risk management process aligned to these reports tend to draw deficiency letters asking manufacturers to "justify" or "substantiate" their approach, which is slower and more expensive than building to the standard from the start.

The Relationship with ISO 14971

ISO 14971 governs safety risk management for medical devices generally, focused on harm to patients from device malfunction regardless of cause. TIR57 and TIR97 extend that same risk management architecture, specifically to security threats, recognizing that a cybersecurity exploit can produce the same patient harm as a hardware failure. In practice, this means your security risk management file should use ISO 14971's risk acceptability criteria, severity scales, and residual risk evaluation process, but apply them to threat actors and attack vectors instead of only random failure modes. Manufacturers who run two disconnected risk files, one for safety and one for security, routinely miss the interaction effects where a security exploit becomes a safety hazard.

Deep Dive: AAMI TIR57 (Premarket Security)

TIR57, "Principles for medical device security, risk management," lays out a security risk management process modeled directly on ISO 14971's structure, but scoped to security threats introduced by connectivity, software, and data exchange. It expects manufacturers to identify security-relevant assets, characterize threat sources and attack vectors, evaluate the resulting risk, and implement and verify controls, all before the device reaches the market. It is the standard most FDA reviewers implicitly expect your premarket threat model and security risk assessment to trace back to, even when it is not cited by name in your 510(k) or De Novo submission.

Core Principles of Security Risk Management

TIR57's core principle is that security risk management is inseparable from safety risk management, not a parallel or optional workstream. It asks manufacturers to identify assets (data, functions, and components an attacker could target), characterize the threat landscape realistically for the device's intended use environment, and evaluate risk using consistent, documented criteria rather than ad hoc judgment calls. Every identified risk needs a disposition: accepted, mitigated, or transferred, with the rationale captured in writing. This documented, repeatable process is what lets a reviewer or auditor reconstruct your reasoning years later, which is exactly what FDA reviewers are trained to look for.

Establishing the Security Risk Management Process

Setting up a compliant TIR57 process means defining, in a written procedure, how your organization identifies assets, models threats, scores risk, and closes out mitigations, before you apply it to any specific device. That procedure should specify who owns each step, what evidence gets generated (asset inventories, threat model diagrams, risk registers), and how the process interfaces with your existing ISO 14971 risk management file and design controls under 21 CFR 820.30 (or ISO 13485 Clause 7.3). Manufacturers who build this process once, at the quality system level, avoid reinventing the wheel for every new device or platform variant.

Impact on Product Design and Threat Modeling

TIR57 pushes security risk identification upstream, into architecture and design decisions, rather than treating it as a late-stage checklist. That means threat modeling (often using STRIDE or a similar framework) needs to start when you are still deciding on communication protocols, authentication schemes, and data storage approaches, because retrofitting security controls into a finalized architecture is expensive and often incomplete. Design teams that adopt TIR57 early typically produce fewer late-cycle architecture changes and cleaner V&V evidence, because the security requirements were baked into the design inputs from day one.

Deep Dive: AAMI TIR97 (Postmarket Security)

TIR97, "Principles for medical device security, postmarket risk management for device manufacturers," addresses everything that happens after the device ships: ongoing vulnerability monitoring, triage of newly discovered threats, coordinated disclosure, and the decision process for when a vulnerability requires a corrective action versus routine patching. It assumes the risk landscape will change after clearance, because new vulnerabilities in third-party components, new attack techniques, and new connectivity contexts will emerge that could not have been fully anticipated during premarket development.

Managing Risks Throughout the Product Lifecycle

TIR97 requires manufacturers to maintain a living risk file that gets revisited whenever new threat intelligence, a reported vulnerability, or a software update changes the device's risk profile. This means your postmarket surveillance process needs a defined trigger for re-evaluating risk (a new CVE affecting a component in your SBOM, for example) and a documented method for deciding whether that new information changes your risk acceptability determination. Devices with long service lives, sometimes 10 to 15 years in the field, need this discipline the most, because the threat landscape at end of life looks nothing like it did at clearance.

Vulnerability Disclosure and Intake Mechanisms

An effective TIR97 program needs a functioning intake channel, whether that is a security.txt file, a dedicated vulnerability disclosure email address, or a formal bug bounty program, so that external researchers and customers have a clear, low-friction way to report suspected issues. Intake alone is not enough: you need a documented triage process that assigns severity, determines applicability across your product line, and sets a response timeline, ideally aligned with the timelines FDA has signaled it expects for actively exploited or high-severity vulnerabilities. Manufacturers without a working intake mechanism often learn about vulnerabilities from journalists or regulators first, which is the worst possible way to find out.

Coordinated Vulnerability Disclosure (CVD) Integration

CVD means working with the researcher who found the issue, and often with ISACs, CISA, or the FDA, to validate the vulnerability, develop a remediation, and agree on a disclosure timeline before the details go public. TIR97 expects manufacturers to have a CVD policy in place proactively, not improvised after the first report arrives, including defined roles for who communicates with the researcher, who decides on remediation timing, and who handles customer notification. A mature CVD program builds trust with the security research community and reduces the odds that a researcher goes public before you have a fix ready.

Direct Comparison: TIR57 vs TIR97

The cleanest way to think about the two reports is timing and orientation: TIR57 is forward-looking and design-focused, applied before market clearance to shape the device's security architecture. TIR97 is backward-looking and operations-focused, applied after clearance to manage a risk landscape that keeps shifting. Both use the same underlying risk management logic, so a manufacturer that builds a solid TIR57 risk file has a considerable head start on TIR97, because the asset inventory, threat catalog, and risk criteria carry forward directly.

Key Process Differences

TIR57's process runs on a project timeline: identify assets and threats specific to this device's architecture, evaluate risk, implement controls, verify, and close out before submission. TIR97's process runs on a continuous cycle: monitor for new threat intelligence, triage incoming reports, re-evaluate risk against the existing file, and deploy remediations, with no defined end point until the device reaches end of support. The practical difference shows up in staffing and tooling too: TIR57 work tends to sit with the design and regulatory teams, while TIR97 work usually needs a standing postmarket security function with defined SLAs.

Documentation Requirements: Pre- vs Postmarket

Premarket documentation under TIR57 typically includes a security risk management plan, a threat model, a risk assessment report, and a summary of implemented controls with verification evidence, all bundled into the submission. Postmarket documentation under TIR97 includes a postmarket surveillance procedure, vulnerability intake records, triage and disposition logs, CVD correspondence, and periodic risk file updates, most of which live in your quality system rather than in a one-time submission package. Auditors and FDA reviewers expect both sets of documentation to reference the same underlying risk criteria, so inconsistent severity scales between the two are a common audit finding.

When to Transition from TIR57 to TIR97 Guidance

The transition point is market clearance, but the practical handoff should happen earlier, during late-stage V&V, so your postmarket monitoring infrastructure (SBOM tooling, vulnerability feeds, disclosure intake) is live before the device ships. Waiting until after clearance to stand up your TIR97 processes means your first few months in the field run without adequate monitoring, which is exactly the window regulators and customers are watching most closely for a new device.

Best Practices for Implementing Both Standards

Building a Unified Security Risk Management File

The strongest implementations maintain a single risk management file that carries the same asset inventory, threat catalog, and risk scoring methodology from premarket through postmarket, with TIR97 activity appended as new entries rather than started as a separate file. This avoids the common failure mode where postmarket risk scoring uses different criteria than premarket, making it impossible to tell whether a newly discovered vulnerability represents a genuinely new risk level or just a different measurement scale.

Integrating TIR Guidance into your Quality Management System (QMS)

Both reports work best when they are embedded as procedures inside your existing QMS, referenced from your design control procedures for TIR57 activities and your CAPA and postmarket surveillance procedures for TIR97 activities, rather than treated as one-off consulting deliverables. This integration is what makes the process repeatable across your product portfolio and auditable by both your own internal audit function and outside notified bodies or FDA investigators.

Conclusion: Ensuring Total Lifecycle Cybersecurity

TIR57 and TIR97 are not competing standards, they are two halves of the same lifecycle risk management discipline, split at the point of market clearance. Manufacturers who build a unified risk file, embed both processes into their QMS, and carry the same risk criteria across the full product lifecycle produce submissions that are easier for reviewers to evaluate and postmarket programs that catch problems before they become recalls.

How Blue Goat Cyber Approaches AAMI TIR57 vs TIR97

We treat AAMI TIR57 vs TIR97 as a regulated engineering workstream, not a one-time document drop. Every engagement is led by senior medical-device security engineers who have shipped 250+ FDA cybersecurity submissions across 510(k), De Novo, PMA, and EU MDR pathways. Here is how we run it end to end:

• Scoping against your device profile. We baseline connectivity, interfaces, data flows, and intended use before we touch a template - because reviewer expectations for a Class II wearable are not the same as a networked hospital platform.
• Standards mapping in writing. Every deliverable is traced to the February 2026 FDA premarket cybersecurity guidance, AAMI SW96, AAMI TIR57 / TIR97, IEC 81001-5-1, and ISO 14971 - with the citation in the artifact itself so reviewers do not have to guess.
• Evidence generated inside your QMS. Threat models, SBOMs, security risk assessments, and test reports are versioned under design controls so the traceability from requirement → test → residual risk holds up under audit.
• Independent testing where it counts. Penetration testing and vulnerability analysis are executed by a testing team that does not also write the design - the separation FDA reviewers increasingly expect on cyber devices.
• Deficiency-ready posture. We anticipate the RTA, AI-letter, and Major deficiency patterns FDA has issued over the past 24 months and pre-empt them in the initial submission, cutting the odds of a second review cycle.
• Postmarket handoff, not abandonment. Every premarket package leaves you with a working postmarket monitoring plan, CVD process, and update cadence so the evidence you shipped stays defensible after clearance.

If you want that treatment applied to your AAMI TIR57 vs TIR97 package, our FDA Premarket Cybersecurity Services and FDA Cybersecurity Deficiency Response engagements are the two most common entry points.

Frequently asked questions

What is the difference between AAMI TIR57 and TIR97?

TIR57 addresses premarket security risk management, the process of identifying threats, assessing risk, and building controls into a device before it is submitted for FDA clearance. TIR97 addresses postmarket security risk management, the process of monitoring for new vulnerabilities, triaging reports, and managing coordinated disclosure after the device is on the market. Both use a risk management structure modeled on ISO 14971, but they apply to different phases of the product lifecycle and are often owned by different teams inside a manufacturer's organization. Think of TIR57 as the design-time discipline and TIR97 as the operational discipline that keeps that design's risk posture current once real-world threat intelligence starts arriving.

Do I need both AAMI TIR57 and TIR97 for FDA compliance?

Yes, in practice you need both, because the FDA's premarket guidance expects a documented security risk management process for the submission, and Section 524B and postmarket guidance expect an ongoing vulnerability monitoring and disclosure program once the device ships. Neither report is a checkbox you complete once; TIR57 activity effectively continues as TIR97 activity the moment the device reaches the market. Manufacturers who only build a TIR57-style premarket risk file and never establish the postmarket monitoring TIR97 describes typically fail postmarket audits and struggle to meet the vulnerability response expectations regulators are now enforcing more actively.

How does AAMI TIR57 relate to ISO 14971?

TIR57 is built as a security-specific extension of ISO 14971's general risk management framework, using the same core concepts of hazard identification, risk evaluation, risk control, and residual risk acceptability, but applied to intentional threat actors rather than only random failure modes. The practical implication is that your security risk file should not be a separate, disconnected document from your ISO 14971 risk management file. They should share risk acceptability criteria and severity scales, and your risk management file should explicitly account for scenarios where a security exploit produces a safety hazard, since that intersection is exactly where FDA reviewers focus their scrutiny.

What are the postmarket reporting requirements in AAMI TIR97?

TIR97 expects manufacturers to maintain a documented postmarket surveillance process that captures vulnerability intake (from researchers, customers, or threat intelligence feeds), triage decisions with assigned severity, remediation timelines, and records of coordinated disclosure activity. It does not prescribe a specific reporting cadence to the FDA the way MDR (medical device reporting) does for safety events, but it does expect the underlying process to be auditable and current enough to support your postmarket management plan. When a vulnerability rises to the level of an uncontrolled risk, the standard's process should feed directly into your existing complaint handling and CAPA procedures, which do carry regulatory reporting obligations.

Which standard should I use for threat modeling medical devices?

Threat modeling itself is a technique, most commonly STRIDE or PASTA, not something either TIR57 or TIR97 fully specifies on its own, but TIR57 is the report that governs when and how threat modeling output feeds into your premarket risk assessment. Run your initial threat model during architecture and design, using TIR57's risk evaluation criteria to score the identified threats, and then carry that same threat catalog forward into your TIR97 postmarket monitoring process so newly discovered vulnerabilities can be mapped against threats you already characterized. This continuity between premarket threat modeling and postmarket monitoring is one of the more common gaps FDA reviewers flag in deficiency letters.

Is AAMI TIR57 required for 510(k) submissions?

TIR57 is not cited as a mandatory standard by name in the FDA's premarket cybersecurity guidance, but its risk management structure is effectively what reviewers expect to see underlying your threat model and security risk assessment for any 510(k) involving a cyber device. Submissions that do not follow a TIR57-consistent process still get evaluated against the same substantive expectations, identified threats, evaluated risk, implemented and verified controls, so manufacturers gain little by skipping the standard and typically lose time responding to deficiency letters asking them to justify an ad hoc methodology instead.

Where this fits in the cluster

This page sits downstream of our pillar resources on AAMI TIR57 vs TIR97. If you arrived here from a different starting point, these are the most useful adjacent pages:

• The MedTech Cybersecurity Standards Decoder
• The Postmarket Cybersecurity Readiness Plan
• FDA Premarket Cybersecurity Services
• FDA Postmarket Cybersecurity Services
• The SPDF Playbook for FDA-Ready Medical Devices

Related from Blue Goat Cyber

• Medical Device Threat Modeling
• Secure MedTech Product Design Consulting
• FDA Premarket Cybersecurity Services
• FDA Postmarket Cybersecurity Services
• 12 Critical Threat Modeling Gaps in Medical Device Submissions
• Glossary

Sources & primary references

• AAMI TIR57:2016 Principles for medical device security, Risk management. AAMI (Association for the Advancement of Medical Instrumentation)
• AAMI TIR97:2019/R2023 Principles for medical device security, Postmarket risk management for device manufacturers. AAMI (Association for the Advancement of Medical Instrumentation)
• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions. U.S. Food and Drug Administration (FDA)
• Postmarket Management of Cybersecurity in Medical Devices. U.S. Food and Drug Administration (FDA)
• ISO 14971:2019 Medical devices. Application of risk management to medical devices. International Organization for Standardization (ISO)

Talk to a regulatory cybersecurity team

If you are working through AAMI TIR57 vs TIR97 and want a second pair of eyes on your submission package, we ship cybersecurity deliverables for medical device manufacturers across 510(k), De Novo, PMA, and EU MDR pathways. Book a discovery session and we will walk your evidence with you.