Written and maintained by CASRAI Editorial Board
Last updated
ANSI/AAMI SW96:2023 (Standard for medical device security — Security risk management for device manufacturers) is the normative American National Standard—recognized by the U.S. Food and Drug Administration (FDA Consensus Standard Recognition No. 13-131)—that defines how medical device manufacturers perform cybersecurity risk management across the total product life cycle (TPLC). Building directly on the foundational technical report AAMI TIR57 and pairing with product verification standard ANSI/CAN/UL 2900-2-1, ANSI/AAMI SW96 establishes a rigorous process for evaluating threats, vulnerabilities, and exploitability in both SaMD and SiMD medical devices.
How Do ANSI/AAMI SW96 and AAMI TIR57 Structure Medical Device Security Risk Management Alongside ISO 14971?
ANSI/AAMI SW96:2023 elevates the informative guidance of AAMI TIR57 into mandatory, auditable requirements (“shall” statements) that mirror the clause-by-clause lifecycle of ISO 14971:2019 while linking a dedicated Security Risk Management Process to the Safety Risk Management Process.
Historically, medical device manufacturers relied on ISO 14971 and ISO/TR 24971 to manage physical, electrical, biological, and software safety hazards. However, ISO 14971 was designed for random hardware failures and foreseeable use errors, not adaptive human adversaries. First introduced in AAMI TIR57:2016 (Principles for medical device security — Risk management) and codified normatively in ANSI/AAMI SW96:2023, the security risk management architecture runs in parallel with ISO 14971 across Clauses 4 through 10:
| ANSI/AAMI SW96 Clause | Parallel ISO 14971:2019 Clause | Core Security Risk Management Deliverables |
|---|---|---|
| Clause 4: General Requirements for Security Risk Management System | Clause 4 (Risk Management System) | Security Risk Management Plan, criteria for security risk acceptability, competence of cybersecurity personnel, and Security Risk Management File. |
| Clause 5: Security Risk Analysis | Clause 5 (Risk Analysis) | System security architecture decomposition, data flow diagrams, trust boundary mapping, asset identification, threat modeling (e.g., STRIDE), and vulnerability identification. |
| Clause 6: Security Risk Evaluation | Clause 6 (Risk Evaluation) | Evaluation of each threat-vulnerability pair using exploitability and severity of impact against predetermined acceptability thresholds. |
| Clause 7: Security Risk Control | Clause 7 (Risk Control) | Design-in security controls (authentication, cryptography, least privilege, network segmentation), verification testing, and evaluation of new risks introduced by controls. |
| Clause 8 & 9: Overall Residual Security Risk & Review | Clauses 8 & 9 (Overall Residual Risk & Report) | Aggregate assessment of all residual vulnerabilities, companion disclosure documentation for healthcare delivery organizations (HDOs), and Security Risk Management Report. |
| Clause 10: Production and Post-Production Activities | Clause 10 (Production & Post-Production) | Continuous CVE/SBOM monitoring, coordinated vulnerability disclosure (CVD), threat intelligence intake, and field patch/compensating control loops. |
How Does Security Risk Evaluation (Threat, Vulnerability, Exploitability) Interact with Safety Risk Evaluation in ANSI/AAMI SW96?
ANSI/AAMI SW96 replaces ISO 14971’s statistical “probability of occurrence of harm” with vulnerability “exploitability” and connects the security and safety risk files through a mandatory two-way transfer bridge.
Both ANSI/AAMI SW96 and the FDA’s September 2023 final guidance (Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions) prohibit using historical failure probabilities to dismiss cybersecurity risks. Because a single weaponized exploit can simultaneously compromise thousands of network-connected infusion pumps or pacemakers, security risk is evaluated as a function of:
- Threat and Asset Impact: Compromise of confidentiality, integrity, or availability (CIA triad), business/reputational harm, or patient safety harm.
- Vulnerability Exploitability: The technical difficulty of executing an attack—commonly scored using metrics from the Common Vulnerability Scoring System (CVSS), such as Attack Vector (network vs. physical), Attack Complexity, Privileges Required, and User Interaction—evaluated first in an uncontrolled state and then after applying security controls.
The Bidirectional Bridge Between SW96 and ISO 14971
ANSI/AAMI SW96 and AAMI TIR57 define two explicit handoff points between the cybersecurity engineering team and the clinical safety risk management team:
- Security-to-Safety Handoff (Safety Impact Path): Whenever a security risk analysis identifies a threat scenario that could compromise device integrity or availability in a way that leads to a clinical hazardous situation (e.g., unauthorized command altering insulin basal delivery or denial-of-service disabling an ICU physiological alarm), that hazardous situation is transferred into the ISO 14971 Safety Risk Management File to evaluate patient harm severity and safety risk controls.
- Safety-to-Security Handoff (Control Verification Path): Whenever the ISO 14971 safety risk process introduces a software or hardware safety risk control (or when IEC 62304 software architecture changes are made), that control is routed back into the ANSI/AAMI SW96 Security Risk Management File to verify that the safety control does not create a new cybersecurity vulnerability (for example, an emergency clinical override password that could be exploited remotely).
What Does UL 2900-2-1 Require for Fuzz Testing, Static Code Analysis, and Penetration Testing of Medical Devices?
While ANSI/AAMI SW96 governs the security risk management process, ANSI/CAN/UL 2900-2-1 (FDA Recognition No. 13-104) defines the concrete software verification and vulnerability testing methods required to prove that network-connectable medical devices resist exploitation.
In FDA premarket submissions (510(k), De Novo, and PMA software documentation under Section 524B of the FD&C Act), manufacturers pair ANSI/AAMI SW96 risk management reports with test artifacts conforming to UL 2900-1 and UL 2900-2-1 (Software Cybersecurity for Network-Connectable Products, Part 2-1: Particular Requirements for Network Connectable Components of Healthcare and Wellness Systems):
- Static Application Security Testing (SAST / Static Code Analysis): Automated scanning of proprietary source code and build binaries against Common Weakness Enumeration (CWE) rulesets to eliminate memory-safety defects (buffer overflows, use-after-free), injection vectors, hard-coded cryptographic keys, and dead or unreachable code prior to compilation.
- Software Composition Analysis (SCA) & Known Vulnerability Testing: Automated correlation of every third-party, open-source, and commercial off-the-shelf (COTS) software component listed in the machine-readable Software Bill of Materials (SBOM) against the National Vulnerability Database (NVD / CVE), with documented remediation or risk justification for every identified CVE.
- Malformed-Input Fuzz Testing: Automated protocol robustness testing that bombards every physical and logical interface on the medical device—including Ethernet/TCP/IP stacks, Wi-Fi, Bluetooth Low Energy (BLE), HL7/DICOM listeners, and USB ports—with millions of mutated, boundary-violating, and malformed packets to confirm the device does not crash, leak memory, or enter an unsafe clinical state.
- Adversarial Penetration Testing: Goal-directed security testing performed by qualified testers with independent objectivity who attempt to chain vulnerabilities, bypass authentication, extract firmware keys, or escalate privileges, producing a formal penetration test report detailing scope, attack chains, and remediation verification.
