Recently, I met with a former colleague to discuss the progress the Regulify.AI team is making. We previously worked together at the same MedTech company, and our conversation covered several Regulify.AI modules, including a deep dive into Risk Management.

Despite having comprehensive FMEA, detailed hazard analyses, and documented risk controls, he shared a question raised by an FDA reviewer:
“Where is your cybersecurity risk assessment, and how is it integrated with your safety risk management, especially for an internet-connected device?”

At that moment, it was clear they weren’t prepared. Like many teams, cybersecurity had been treated as a parallel IT concern rather than a core safety issue. What they hadn’t fully recognized is a fundamental shift in medical device risk management: cybersecurity is no longer adjacent to patient safety—it is patient safety.

Answering that question required months of additional work and a complete restructuring of their risk management approach. This blog is written so you don’t have to learn that lesson the hard way.

The New Reality: When Cyber Threats Become Patient Safety Threats

Let's acknowledge what many in our industry have been slow to accept: the era of isolated medical devices is over. Today, 93% of healthcare organizations have confirmed Known Exploited Vulnerabilities (KEVs) and insecure internet connections for their Internet of Medical Things (IoMT) devices. Over 76% of medical devices are impacted by supply chain vulnerabilities. And perhaps most alarming, only 13% of medical devices support endpoint protection agents.

These aren't abstract statistics. They represent real pathways to patient harm. Consider what we've witnessed in recent years:

Insulin pump vulnerabilities: In 2011, security researcher Jay Radcliffe demonstrated at Black Hat how he could remotely command an insulin pump to deliver a lethal dose. In 2019, the FDA recalled certain Medtronic MiniMed insulin pumps because attackers could alter device settings, potentially causing dangerous insulin overdose or complete delivery cessation.
Pacemaker recalls: In 2017, the FDA recalled 465,000 Abbott (formerly St. Jude Medical) pacemakers due to vulnerabilities that could allow attackers to deplete batteries or modify pacing—potentially fatal for patients. Researchers demonstrated they could reprogram these devices from anywhere using equipment costing as little as $15 to $3,000.
Healthcare ransomware: The 2017 WannaCry attack shut down radiology equipment across 48 UK hospitals. In 2024, healthcare experienced 444 reported cyber incidents—238 ransomware attacks and 206 data breaches—more than any other critical infrastructure sector. The Change Healthcare attack alone compromised 190 million patient records and disrupted claims processing nationwide.

The message from regulators is unmistakable: you cannot claim your device is safe and effective if it's vulnerable to cyber attack. The FDA's June 2025 final guidance makes this explicit—manufacturers must demonstrate "reasonable assurance of cybersecurity" as part of their premarket submissions. This isn't optional. Failure to provide adequate cybersecurity documentation is now grounds for Refuse to Accept (RTA) decisions.

Understanding the Regulatory Framework: FDA, EU MDR, and Beyond

FDA Requirements: Section 524B and the June 2025 Guidance

The FDA's regulatory framework for medical device cybersecurity has evolved significantly. Section 524B of the Federal Food, Drug, and Cosmetic Act now defines "cyber devices" as any device that: (1) includes software validated, installed, or authorized by the sponsor as a device or in a device; (2) has the ability to connect to the internet; and (3) contains technological characteristics that could be vulnerable to cybersecurity threats.

The June 2025 final guidance consolidates and clarifies what manufacturers must provide in premarket submissions:

Cybersecurity Management Plan: A comprehensive plan that must be continually maintained and updated as new threats emerge throughout the Total Product Lifecycle (TPLC).
Threat Modeling Documentation: Detailed analysis identifying all potential threats using methodologies like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege).
Cybersecurity Risk Assessment: Risk evaluation considering exploitability, vulnerability potential, and impact on device safety and effectiveness.
Software Bill of Materials (SBOM): A machine-readable inventory of all commercial, open-source, and off-the-shelf software components, with support level information and known vulnerability assessments.
Coordinated Vulnerability Disclosure (CVD) Policy: Documented processes for receiving, evaluating, and addressing vulnerability reports.
Security Testing Evidence: Including code review methods (SAST and DAST), vulnerability assessments, penetration testing results, and fuzz testing documentation.
Patch/Update Timelines: Defined processes for releasing updates aligned to risk level, including regular updates and out-of-band patches for critical vulnerabilities.

EU MDR and MDCG 2019-16 Requirements

The European regulatory landscape presents its own requirements through the Medical Device Regulation (EU MDR 2017/745) and the MDCG 2019-16 guidance on cybersecurity. Unlike the FDA's consolidated approach, EU requirements are woven throughout the regulation's General Safety and Performance Requirements (Annex I).

Key EU MDR cybersecurity provisions include:

State-of-the-art development: Devices must be developed "according to the state of the art," considering IT security and defining measures to protect against unauthorized access (Annex I, 17.2 and 17.4).
Security-by-design: Cybersecurity considerations must be embedded at every stage of the device lifecycle, from conception through post-market surveillance.
Risk management integration: Security risks must be managed within the broader ISO 14971 framework, with clear traceability to hazards and controls.
Post-market surveillance: Continuous monitoring for cybersecurity vulnerabilities with documented incident response and problem resolution processes.

IEC 81001-5-1:2021, while not yet harmonized under EU MDR, is increasingly treated as state-of-the-art by notified bodies. This standard defines lifecycle requirements for secure health software development and complements both IEC 62304 and ISO 14971. Manufacturers should anticipate its requirements being enforced during audits.

The Integration Challenge: Connecting Safety and Security Risk Management

Here's where many manufacturers stumble: they understand the need for cybersecurity risk management, but they treat it as a completely separate process from their ISO 14971 safety risk management. This creates dangerous gaps.

The fundamental challenge is that safety and security risks are different in nature:

Safety Risks (ISO 14971 Traditional Approach)

Focus on unintentional failures and hazards
Probability can be estimated based on historical data and modeling
Harm is defined as physical injury or damage to health
Protection goals: patient safety, user safety, environmental protection

Security Risks (Cybersecurity Approach)

Focus on intentional exploitation by adversaries
Probability is difficult to predict—threats evolve constantly
Harm includes data breaches, system unavailability, and loss of device integrity
Protection goals: Confidentiality, Integrity, Availability (CIA)

The FDA guidance explicitly acknowledges this distinction: "Cybersecurity risks are difficult to predict, meaning that it is not possible to assess and quantify the likelihood of an incident occurring based on historical data or modeling. This non-probabilistic approach is not the fundamental approach performed in safety risk management under ISO 14971 and further underscores why safety and security risk management are distinct but connected processes."

Yet the connection is critical. A cybersecurity vulnerability can directly cause patient harm—the same harm that ISO 14971 is designed to prevent. An exploited insulin pump delivers the wrong dose. A compromised pacemaker delivers abnormal pacing. A ransomware attack on an infusion pump network denies patients their medications.

AAMI TIR57: The Bridge Between Safety and Security

AAMI TIR57:2016 (R2023), "Principles for Medical Device Security—Risk Management," provides the essential framework for integrating cybersecurity into your ISO 14971 process. This technical information report is explicitly referenced in FDA guidance documents and represents the current state-of-the-art for managing the intersection of safety and security.

The genius of TIR57 is its structure: it mirrors ISO 14971 chapter by chapter, showing exactly how security risk management activities map to safety risk management requirements. For each sub-chapter of ISO 14971, TIR57 names the activities necessary to identify, assess, and control IT security risks.

Key Concepts from TIR57

Extended Definition of Harm: TIR57 expands the traditional ISO 14971 definition of harm to include "physical injury or damage to the health of people, or damage to property or the environment, or reduction in effectiveness, or breach of data and systems security." This broader definition captures the full scope of cybersecurity impacts.

Assets, Threats, and Vulnerabilities: Security risk management introduces new concepts not found in traditional safety risk management. Assets are things of value (patient data, device functionality, intellectual property). Threats are potential causes of unwanted incidents. Vulnerabilities are weaknesses that can be exploited by threats.

The Connection Between Processes: TIR57 recommends linking security and safety risk management through a functional interface. When a security risk control might impact safety, or when a safety risk control has security implications, the processes must communicate.

Practical Implementation: Two Files or One?

A common question: should you maintain separate risk management files for safety and security? The answer depends on your organization's resources and complexity.

Option 1: Integrated Risk Management File

For smaller organizations or simpler devices, a single integrated risk management file can work. Cybersecurity risks are documented alongside safety risks, with clear indication of risk type and appropriate controls. This approach ensures nothing falls through the cracks but requires personnel comfortable with both domains.

Option 2: Parallel Risk Management Files with Interface

For larger organizations or complex connected devices, AAMI TIR57 recommends maintaining separate files with a defined interface. This allows security specialists and safety engineers to work in their domains of expertise while ensuring integration points are clearly documented. The key is documenting how security risks might impact patient safety and ensuring traceability between the two processes.

Regardless of approach, the MDCG 2019-16 guidance notes that "a separate process is not required for managing security risks related to medical devices"—what matters is that security risks are comprehensively addressed within your overall risk management framework.

Building Your Cybersecurity Risk Assessment: A Step-by-Step Approach

Step 1: Establish Your Security Risk Management Plan

Before analyzing risks, you need a documented plan that defines:

Scope of the security risk management activities
Criteria for security risk acceptability
Methods for threat identification and vulnerability assessment
Approach to security risk evaluation (including scoring systems like CVSS)
Requirements for verification of security controls
Interface with safety risk management process

Step 2: Define Your System Architecture and Assets

The FDA guidance recommends creating four types of architecture views:

Global System View: Shows the device within its broader ecosystem, including connections to healthcare networks, cloud services, other devices, and external entities.
Multi-Patient Harm View: Identifies scenarios where a single vulnerability could affect multiple patients simultaneously.
Updateability and Patchability View: Documents how the device can be updated securely and what dependencies exist for patch deployment.
Security Use Case Views: Identifies all use cases for operational states and clinical scenarios that have security implications.

For each component in your architecture, identify assets that need protection: Protected Health Information (PHI), device configuration data, cryptographic keys, software/firmware, communication interfaces, and even business reputation.

Step 3: Conduct Threat Modeling

Threat modeling is the systematic process of identifying potential security threats to your device. The FDA's Threat Modeling Handbook recommends the STRIDE methodology, which categorizes threats as:

Spoofing: Impersonating a legitimate user, device, or system
Tampering: Unauthorized modification of data or code
Repudiation: Denying responsibility for actions performed
Information Disclosure: Unauthorized access to sensitive information
Denial of Service: Making the device or system unavailable
Elevation of Privilege: Gaining unauthorized capabilities or access levels

Apply STRIDE-per-element analysis: for each component and data flow in your architecture, systematically consider which STRIDE categories apply and what specific threats exist.

Step 4: Assess Security Risks

For each identified threat, evaluate the security risk considering:

Exploitability: How easily can the vulnerability be exploited? Consider factors like required access level, attack complexity, and availability of exploit tools. The Common Vulnerability Scoring System (CVSS) provides a standardized framework.
Impact on CIA: What happens if Confidentiality, Integrity, or Availability is compromised?
Impact on Patient Safety: This is the critical bridge to ISO 14971. Can this security risk lead to patient harm? What is the severity?

Document the connection between security risks and safety risks. A threat that compromises device integrity might lead to a hazardous situation under ISO 14971. This traceability is essential for demonstrating comprehensive risk management.

Step 5: Implement Security Controls

The FDA guidance identifies key security control categories:

Authentication: Verifying the identity of users, devices, and systems
Authorization: Controlling access to device functions and data
Cryptography: Protecting data confidentiality and integrity (following NIST guidelines like FIPS 140-3)
Code/Data Integrity: Ensuring software and data haven't been tampered with
Confidentiality: Protecting sensitive information from unauthorized access
Event Detection and Logging: Recording security-relevant events for monitoring and forensics
Resilience and Recovery: Maintaining functionality under attack and recovering from incidents

For each control, verify its effectiveness through appropriate testing (code review, vulnerability scanning, penetration testing) and document the verification evidence.

Step 6: Create and Maintain Your SBOM

The Software Bill of Materials is now a mandatory requirement for cyber devices under Section 524B. Your SBOM must:

Be machine-readable (SPDX or CycloneDX format)
Include all commercial, open-source, and off-the-shelf components
Document component version, supplier, and license information
Identify support level (actively maintained, end-of-life, abandoned)
Include known vulnerabilities for each component

The SBOM isn't just a compliance checkbox—it's your foundation for ongoing vulnerability management. When a new CVE is published affecting a component in your device, your SBOM enables rapid impact assessment across all fielded versions.

Common Pitfalls and How to Avoid Them

Pitfall 1: Treating Cybersecurity as an IT Problem

Cybersecurity in medical devices is a patient safety issue, not just an IT security issue. Your regulatory team, quality team, and clinical team all need to be involved. The consequences of a breach aren't limited to data loss—they can include direct patient harm.

Pitfall 2: Point-in-Time Security Assessment

A security assessment performed once during development is insufficient. The threat landscape evolves constantly. New vulnerabilities are discovered in third-party components. Attack techniques become more sophisticated. Your cybersecurity risk management must be a continuous process throughout the Total Product Lifecycle.

Pitfall 3: Ignoring Legacy Device Requirements

If you're submitting modifications to devices cleared before 2023, you may think you're exempt from cybersecurity requirements. You're not. The FDA's June 2025 guidance clarifies that any modification requiring a new premarket submission must include cybersecurity documentation—even if the original device had none. At minimum, you'll need to demonstrate no critical vulnerabilities exist.

Pitfall 4: Disconnected Risk Management Processes

Whether you maintain separate files or an integrated approach, the connection between security and safety risk management must be explicit and documented. Auditors and reviewers will look for traceability: How does this security risk map to potential patient harm? How does this safety risk control consider cybersecurity implications?

Pitfall 5: Incomplete Threat Modeling

Threat modeling must encompass the full end-to-end system the device operates within, not just the device itself. Consider the hospital network, cloud services, companion apps, update infrastructure, and all other connected components. A vulnerability in any part of the system can compromise your device.

A Modern Approach: How Technology Can Help

The complexity of integrating cybersecurity into medical device risk management has grown beyond what manual processes can reliably handle. Consider the challenge: you're maintaining an SBOM with potentially hundreds of components, monitoring multiple vulnerability databases, tracking CVEs, updating threat models, ensuring traceability to safety risks, and documenting everything for regulatory submission—all while the threat landscape evolves daily.

This is where purpose-built platforms like Regulify.ai transform the regulatory compliance landscape. Rather than managing disparate spreadsheets, documents, and databases, an integrated platform can:

Automate SBOM management: Track all software components, automatically monitor for new vulnerabilities, and generate machine-readable SBOMs in FDA-accepted formats.
Maintain live threat models: Keep threat models current as your architecture evolves and new threats emerge, with automatic mapping to risk assessments.
Enable traceability: Create clear connections between security vulnerabilities, threats, security controls, safety hazards, and safety controls—exactly what regulators want to see.
Generate compliant documentation: Produce the security risk management reports, threat modeling documentation, and SBOM-related materials required for FDA and EU MDR submissions.
Support continuous monitoring: Alert you when new CVEs affect your components, enabling rapid triage and response as required by post-market cybersecurity requirements.

Implementation Timeline: Getting Started

Phase 1: Foundation (Weeks 1-2)

Conduct gap analysis against FDA guidance and EU MDR requirements
Establish or update security risk management plan
Define interface between safety and security risk management
Assign roles and responsibilities

Phase 2: Assessment (Weeks 3-6)

Create system architecture diagrams (all four views)
Generate comprehensive SBOM
Conduct threat modeling using STRIDE
Perform cybersecurity risk assessment
Map security risks to safety risks

Phase 3: Control Implementation (Weeks 7-10)

Implement security controls for identified risks
Conduct security testing (SAST, DAST, penetration testing, fuzz testing)
Verify control effectiveness
Document residual risks

Phase 4: Documentation and Ongoing (Weeks 11+)

Compile security risk management report
Prepare premarket submission documentation
Establish post-market surveillance processes
Implement vulnerability monitoring and response procedures

Key Takeaways

Cybersecurity is patient safety: Security vulnerabilities can directly cause patient harm. Treat cybersecurity risk management with the same rigor as safety risk management.
Integration is mandatory: Whether through a single file or parallel processes with defined interfaces, security and safety risk management must be connected with full traceability.
AAMI TIR57 is your roadmap: Use this FDA-recognized framework to systematically address cybersecurity within your ISO 14971 process.
SBOM is non-negotiable: For cyber devices, failure to provide an adequate SBOM will result in Refuse to Accept decisions.
Continuous is the new normal: Cybersecurity risk management doesn't end at clearance. Post-market vulnerability monitoring and response are regulatory requirements.

Taking the Next Step

The integration of cybersecurity into medical device risk assessment isn't optional anymore—it's the price of market access. The good news is that with the right framework, tools, and approach, it's entirely achievable.

If your team is still treating cybersecurity as separate from your ISO 14971 process, now is the time to change. If your SBOM is a static spreadsheet rather than an actively managed component of your risk management system, now is the time to upgrade. If your threat model was created once during development and hasn't been touched since, now is the time to make it a living document.

Regulify.ai offers comprehensive tools for managing the full spectrum of medical device regulatory compliance, including integrated cybersecurity risk management. Our platform helps manufacturers build the kind of audit-ready, regulator-confident documentation that gets submissions approved—not returned with questions.

Ready to transform your approach to cybersecurity risk management? Schedule a demo with our team to see how Regulify.ai can help you build an integrated, compliant, and sustainable cybersecurity risk management program.