IoMT Forensics: Key Steps in Incident Response

The Internet of Medical Things (IoMT) connects critical medical devices like infusion pumps, ventilators, and monitors, improving patient care but exposing healthcare systems to cyber risks. Starting in 2026, compliance with Section 524B of the FD&C Act requires manufacturers to address these risks with robust incident response plans. IoMT forensics is complex due to limited logging, vendor restrictions, and the need to keep devices operational during investigations.

Key Takeaways:

• Challenges: Sparse logs, proprietary systems, and patient safety concerns make investigations difficult.
• Incident Response Phases: Preparation, detection, containment, recovery, and post-incident reporting are tailored for IoMT.
• Preparation: Maintain device inventories, classify devices by data volatility, and ensure synchronized clocks.
• Evidence Preservation: Act quickly to preserve volatile data without disrupting patient care.
• Collaboration: Work with clinical teams and manufacturers to balance technical investigations with patient safety.

IoMT forensics isn't just about technical fixes - it's about safeguarding lives while meeting legal and regulatory requirements.

Preparing for IoMT Forensic Investigations

Building an IoMT-Aware Incident Response Plan

To create an effective incident response plan for IoMT (Internet of Medical Things), start by conducting UDI (Unique Device Identification) scans and exporting device inventories. This step helps map serial numbers, firmware versions, and bedside locations to specific units ^[3]. Without this groundwork, investigators may waste valuable time during an incident just identifying the devices involved.

Once your inventory is complete, classify devices based on clinical impact and data volatility. For instance, logs from insulin pumps can be overwritten quickly, while EHR (Electronic Health Record) audit records can persist for months or even years - ranging from 90 days to 6 years ^[3]. Knowing which data needs to be captured first can be the difference between a successful investigation and a missed opportunity.

Additionally, maintain a Software Bill of Materials (SBOM) for each device version. This document allows your team to quickly determine which devices are affected when a vulnerability is disclosed, saving time and avoiding a tedious manual review ^[4].

Defining Roles and Responsibilities

After setting up an accurate device inventory and classification, it’s crucial to assign clear roles to ensure a swift and coordinated response.

IoMT forensic investigations demand collaboration across multiple teams that don’t always interact frequently. Here’s a breakdown of typical responsibilities:

A key step often overlooked is forming a Product Security Incident Response Team (PSIRT) with a clear RACI (Responsible, Accountable, Consulted, Informed) model before any incident occurs. Pre-defined decision-making authority ensures swift action without unnecessary delays when every moment counts ^[4].

Clearly defining roles lays the groundwork for proactive forensic readiness. This coordination is vital for taking the risk out of healthcare operations during a crisis.

Forensic Readiness Measures

Once your incident response plan and roles are in place, proactive readiness steps are essential to avoid unnecessary delays during an incident.

First, synchronize clocks across all IoMT devices, central stations, and forensic tools. Without synchronized clocks, correlating logs from different systems - like matching an EHR override with an edit on a bedside monitor - becomes unreliable or even impossible ^[2][3].

Next, ensure baseline logging through your CMMS (Computerized Maintenance Management System). Routine preventive maintenance should include capturing configuration snapshots to establish a "known-good" state. However, these baselines are often overwritten during subsequent maintenance cycles unless they’re formally archived ^[3]. Make archiving these snapshots a standard procedure.

Finally, establish a chain-of-custody process before you need it. For every log export - whether it’s from a pump, monitor, or ventilator - document the collector, timestamp, and cryptographic hash immediately. This initial hash serves as the foundation for verifying all subsequent activity ^[3]. Additionally, set up pre-approved "break-glass" protocols for emergency forensic data collection. This ensures investigators aren’t delayed by access controls during critical, time-sensitive moments ^[3][4].

sbb-itb-535baee

Detection, Triage, and Evidence Preservation

When building on a foundation of forensic readiness, the ability to detect incidents quickly and preserve evidence immediately is crucial for minimizing harm.

Detecting and Triaging IoMT Incidents

With your incident response plan and team roles established, the next step is recognizing potential incidents and responding swiftly. In the IoMT (Internet of Medical Things) world, incidents might manifest as unauthorized changes to infusion pump rates, unexpected silences in alarm systems, or unapproved edits to operational thresholds.

"Dose integrity starts at the pump - unauthorized basal or bolus changes are patient-safety events, not data theft." - fatcousin forensics ^[3]

"Alarm suppression hides clinical deterioration - the silence window often predates the reported adverse event." - fatcousin forensics ^[3]

These issues go beyond data integrity; they directly threaten patient safety. When triaging, prioritize incidents that compromise dose integrity or alarm functionality over those focused solely on data breaches.

A key part of triage is verifying the device’s identity using a quick UDI (Unique Device Identifier) check. Swapped or tampered hardware can lead to configuration changes, and mismatches between the physical device and logs can derail your investigation ^[3].

If a device is flagged, isolate its network write paths to block unauthorized changes while ensuring it continues its clinical role ^[3]. Kevin Henry, Incident Response Lead, emphasizes:

"Prefer logical isolation over power‑offs for critical clinical systems." - Kevin Henry, Incident Response Lead ^[2]

Once the incident is confirmed, the focus should shift to preserving volatile evidence.

Preserving Evidence in IoMT Environments

Speed is essential when dealing with IoMT devices. These systems often rely on rolling logs that overwrite data quickly, especially after storage fills or a reset. Within the first 10 minutes of identifying an issue, take these actions:

• Isolate the device’s network write paths without disconnecting it from the patient.
• Photograph the device label, capturing details like the UDI, serial number, and firmware version ^[3].
• Export session logs from the central station and apply a cryptographic hash immediately ^[3].
• Retrieve the UDI record to verify the physical serial number ^[3].
• Collect break-glass audit logs to correlate emergency access events with configuration changes ^[3].

Centralized log collection minimizes interference with active clinical systems. Applying cryptographic hashes right away ensures the logs remain intact, preventing issues like altered timestamps or injected markers during re-export ^[3].

Evidence Sources: Traditional IT vs. IoMT Devices

After collecting evidence, it’s critical to understand how IoMT devices differ from traditional IT systems in terms of data sources and forensic needs. The table below highlights these differences:

The most striking difference lies in the consequences of taking a device offline. While imaging a traditional IT system is standard practice, doing the same with an IoMT device could disrupt therapy or silence alarms, putting patient lives at risk. This reality shapes every step of the investigation, from isolation methods to evidence handling.

Analyzing IoMT Devices and Networks

Goals of IoMT Forensic Analysis

Forensic analysis of Internet of Medical Things (IoMT) devices goes beyond traditional data protection concerns, focusing heavily on patient safety and the integrity of clinical outcomes ^[3]. Investigators aim to answer critical questions: Was a medication dose altered without proper authorization? Were alarms deliberately suppressed? Did a configuration change result in patient harm? These inquiries require connecting technical log data to clinical events. For example, recognizing that an alarm silence coincided with an adverse event is just as vital as tracing the path of an attacker through the network ^[3].

Another key objective is to determine whether adverse events stemmed from accidental errors or deliberate cyber-physical attacks. Maintaining a tamper-proof chain of custody is crucial in such investigations ^[5]. However, the dynamic nature of IoMT devices - such as wearables, implants, and mobile equipment - adds complexity. These devices often move between different units, making it challenging to document every interconnected asset ^[5].

Forensic Techniques for IoMT Environments

A core forensic approach involves creating a comprehensive timeline that aligns clinical events (like alarm silences or dose changes) with technical logs (such as break-glass access events or UDI swaps) ^[3]. Log authenticity scoring is another critical step, helping to identify anomalies like out-of-order timestamps or injected markers ^[3]. This is particularly important since vendors may re-export logs after an incident, potentially altering the data.

For vulnerability analysis, the SBOM-to-VEX (Vulnerability Exploitability Exchange) workflow is becoming a standard practice. This method evaluates whether a known vulnerability is exploitable within a device's specific execution flow. For instance, mutual TLS configurations can prevent man-in-the-middle attacks, rendering certain vulnerabilities irrelevant. By 2026, it’s expected that 35% of healthcare procurement leaders will refuse to consider devices lacking a Software Bill of Materials (SBOM) ^[6].

"A regular police officer, no matter how skilled, is not a digital forensic analyst. These tools frequently generate outputs reviewed by case officers who may lack experience in forensic data analysis... which may ultimately mislead courts." - Dr. Jan Collie, Managing Director and Senior Forensic Investigator, Discovery Forensics ^[5]

Bringing these techniques together requires coordination among all stakeholders to ensure effective and accurate forensic investigations.

Working with Manufacturers and Clinical Teams

Collaboration with manufacturers and clinical teams is essential to align technical forensic efforts with patient safety priorities. For instance, isolating a device without consulting clinical teams could inadvertently increase risks to patients ^[1].

"A purely technical decision to isolate devices without clinical input can create greater patient safety risk than the cyber incident itself." - MedDeviceGuide ^[1]

To address these challenges, organizations should establish a cross-functional Product Security Incident Response Team (PSIRT). This team should include cybersecurity experts, clinical safety officers, clinical engineers, and regulatory affairs professionals. Clinical engineers bring insights from CMMS work orders and configuration records, while regulatory affairs manage compliance and reporting. Clinical safety officers evaluate whether compensating controls, like manual bedside monitoring, can maintain continuity of care during an incident.

When working with manufacturers, it’s critical to scrutinize vendor-provided log exports before incorporating them into forensic reports ^[3]. VEX justifications can also help document why certain vulnerabilities don’t require immediate action - such as when a vulnerability isn’t part of the active execution path or when existing defenses already mitigate the risk ^[6].

"Incident response is no longer a separate IT function. It is part of the manufacturer's quality system." - MedDeviceGuide ^[1]

Finally, applying ISO 14971 Risk Management principles helps translate technical findings into actionable insights for clinicians and regulators ^[4]. Mapping the chain of events - from a vulnerability to an exploit, then to device behavior changes and specific patient outcomes - ensures that forensic reports are both technically thorough and clinically relevant ^[4].

Containment, Eradication, and Recovery

IoMT Containment Strategies

When dealing with a compromised Internet of Medical Things (IoMT) device, avoid disconnecting it immediately - this could disrupt patient care. Instead, collaborate with both cybersecurity and clinical teams to decide the best course of action. Ran Chen, a Global MedTech Expert, emphasizes the importance of this joint approach:

"Containment decisions must be made jointly between cybersecurity and clinical personnel. A purely technical decision to isolate devices without clinical input can create greater patient safety risk than the cyber incident itself." ^[1]

The containment strategy should be guided by the device's role in patient care. For instance, while disconnecting a billing system may have minimal impact, isolating a ventilator requires a much more cautious approach. Here's a quick breakdown of isolation strategies based on clinical importance:

To maintain device functionality while limiting risk, tools like VLANs and Network Access Control (NAC) can be used to isolate devices on separate network segments. If selective isolation isn't feasible, clinical compensating controls - such as manually verifying device outputs or increasing bedside monitoring - can ensure patient safety until a permanent solution is implemented.

Do not reboot a compromised device during triage. Rebooting erases volatile memory, which may contain critical forensic data like active processes and network connections.

Once containment is secured, the next steps involve systematically removing the threat and repairing affected systems.

Eradication and Remediation Steps

Eradicating threats in IoMT environments is more challenging than in traditional IT systems. Many devices rely on proprietary firmware, lack built-in endpoint detection and response (EDR) capabilities, and often require vendor involvement for reimaging. When EDR tools are available, use scripted remediation to remove persistence mechanisms like rogue scheduled tasks, unauthorized services, or WMI subscriptions that allow malware to survive reboots.

For devices at high risk of rootkits or severe tampering, a full rebuild may be necessary. Kevin Henry, an Incident Response expert, advises:

"Eradication must be thorough and repeatable. Prefer rebuilds for high-risk hosts; when cleaning, validate every persistence vector before returning systems to service." ^[7]

Rotating credentials is another critical step. Implement a formal Credential Reset Protocol to update passwords, API tokens, and certificates for all service and privileged accounts. Additionally, if a patch is applied to address a security risk, FDA 21 CFR 806 mandates filing a correction report within 10 business days ^[1].

After eradication and remediation, the focus shifts to validating recovery and ensuring operations can safely resume.

Validating Recovery and Restoring Operations

Recovery efforts must balance technical accuracy with patient safety. Validation involves confirming the integrity of systems, ensuring data continuity, and verifying clinical workflows. Use tools like file-integrity checks, multi-engine malware scans, HL7 interface tests, and EHR reconciliations to ensure threats have been eradicated and data remains accurate. Clinical workflow simulations, conducted with healthcare staff, are also essential to confirm that devices operate safely in real-world scenarios.

Before fully reintegrating restored devices, place them in a quarantine VLAN for a defined monitoring period. This step helps detect any lingering threats, such as lateral movement or reinfection, that might not be caught by technical scans.

Applying ISO 14971 risk management principles ensures that patient safety risks are sufficiently minimized before declaring recovery complete. Clinical teams should be briefed on what has been restored, any remaining issues, and temporary workarounds in place. Keep in mind regulatory reporting requirements, such as notifying CISA about covered cyber incidents within 72 hours and ransomware payments within 24 hours, as mandated by CIRCIA ^[1].

Post-Incident Reporting and Continuous Improvement

Once recovery is confirmed, the focus shifts to thorough reporting and using insights to strengthen future defenses. Completing a robust post-incident analysis is the final step in the IoMT forensic process after containment and recovery.

Writing a Post-Incident Forensic Report

After an incident, it's essential to document what occurred, why it happened, and how it was resolved. An IoMT forensic report isn't just a technical summary - it also serves as a compliance record and a key patient safety document.

The report should include:

• Administrative Details: Incident ID, UTC timestamps, and coordinator information.
• Device Inventory: Model numbers, UDI-DI/PI, SBOM components, and a clinical risk evaluation in line with ISO 14971.
• Incident Actions: Every containment decision, configuration change, and patch applied, along with a chain of custody for preserved evidence (e.g., file hashes and storage locations).

Use clear, factual language, and differentiate between confirmed facts, analysis, and assumptions. Cite specific policies or risk criteria for each major decision - this ensures the report is defensible during audits. Below is a table outlining key reporting obligations:

Transforming Findings into Improvements

A report is only useful if it leads to action. Use forensic insights to update CAPA processes, addressing the root causes of the incident. This ensures the gaps that allowed the breach are effectively closed.

Since 2026, incident response has become part of the overall quality system. Ran Chen, a Global MedTech Expert, emphasizes this shift:

"Incident response is no longer a separate IT function. It is part of the manufacturer's quality system, subject to the same design control, corrective action, and management review requirements as any other quality process." ^[1]

Based on investigation findings, update monitoring rules, incident playbooks, and staff training. Joining an Information Sharing and Analysis Organization (ISAO) can also bring operational benefits, such as earning FDA enforcement discretion on patch deployment timelines ^[1].

Centralizing these updates within a risk management platform can streamline the process further, ensuring that lessons learned are effectively integrated into future response efforts.

Using Risk Management Platforms to Support Improvement

Post-incident improvements require a strong infrastructure. Censinet RiskOps™ simplifies this by centralizing risk and forensic data, ensuring every response activity ties back to specific requirements, risks, and CAPA records. This makes it easier to meet tight regulatory deadlines, like CIRCIA's 72-hour reporting window, without scrambling across disconnected systems ^[1].

Beyond compliance, the platform helps healthcare delivery organizations (HDOs) enhance their ISO 14971 risk files with real-world exploit data, coordinate tasks across clinical, security, and engineering teams, and incorporate post-incident metrics into device design roadmaps. This creates a continuous cycle where each incident improves the speed, coordination, and documentation of future responses.

FAQs

What makes IoMT forensics different from normal IT forensics?

IoMT forensics stands apart because it prioritizes patient safety while tackling the unique technical hurdles of medical devices. Unlike traditional IT systems, IoMT devices can't simply be powered down for analysis - clinical uptime is too important. Many of these devices are older models or restricted by vendor-specific constraints, offering only limited logging features. As a result, investigators often depend on live memory forensics and network telemetry rather than device-specific logs to examine and understand incidents.

What evidence should we collect first from a suspected IoMT device?

When investigating, prioritize collecting volatile data first - this includes memory dumps, running processes, active network connections, and encryption keys. These types of data disappear as soon as the device is powered down. Afterward, focus on obtaining disk images, capturing network traffic, and retrieving system or application logs. Throughout the process, ensure every step is documented, and always work with duplicates of the data to protect the integrity of the original evidence.

How can we contain an IoMT incident without risking patient care?

To manage an IoMT incident while keeping patients safe, the focus should be on maintaining clinical operations through carefully considered, risk-based decisions. Before taking steps to isolate affected systems, involve clinical leaders and biomedical engineers to assess how the device impacts patient care.

You can use compensating controls to minimize disruptions, such as redirecting patients, relying on backup equipment, or postponing non-urgent procedures. A tiered approach works well here: for high-risk devices, require clinical approval before isolation. On the other hand, lower-risk devices can often be quarantined using network segmentation or VLAN restrictions without as much oversight.

Related Blog Posts

• Incident Response Frameworks: Checklist for HDOs