A networked infusion pump is a medical device. It is also a network endpoint. Your CMMS tracks one side of it. Your IT security team tracks the other. Between those two incomplete records lives the gap where cybersecurity incidents happen.
FDA Section 524B changed the rules in March 2023. Manufacturers of new cyber devices must now submit cybersecurity plans and software bills of materials (SBOMs) to the FDA before market clearance. The data exists. The question is whether your CMMS stores it, or whether it sits in PDF attachments nobody opens until after a breach.
This article covers the specific fields your CMMS needs to track for networked medical devices, which platforms support those fields natively, and the practical steps to close the gap between your medical equipment inventory and your network security posture.
For the full platform comparison, read our Best CMMS Software for Healthcare guide.
FDA Section 524B: what changed and why it matters
The Consolidated Appropriations Act, signed December 29, 2022, included Section 3305, which added Section 524B to the Federal Food, Drug, and Cosmetic Act. The provision took effect March 29, 2023.
The requirement is narrow but consequential. Manufacturers submitting premarket applications for “cyber devices” (devices with software, internet connectivity, or susceptibility to cybersecurity threats) must now include:
- A plan to monitor, identify, and address postmarket cybersecurity vulnerabilities
- A coordinated vulnerability disclosure process
- A software bill of materials (SBOM) listing all commercial, open-source, and off-the-shelf software components
- Evidence of device security through the total product lifecycle
This is a manufacturer obligation. It is not a direct hospital mandate. But the downstream effect on HTM departments is significant.
Manufacturers now produce SBOMs. Before 524B, requesting component-level software data from a device vendor was a negotiation. Now it is a regulatory output. Your department has access to data it never had before.
Cybersecurity vulnerabilities get formal tracking. Manufacturers must maintain postmarket monitoring for their devices. When vulnerabilities surface, they issue coordinated disclosures. Your department needs a system to receive, log, and act on those disclosures.
Surveyors and accrediting bodies are watching. The Joint Commission’s EC.02.04.01 elements of performance already address medical equipment risk. Cybersecurity risk is medical equipment risk. Documentation of your device security posture is becoming an audit expectation, not an optional enhancement.
The shift is clear: cybersecurity data for medical devices is no longer IT’s problem alone. HTM departments need structured fields in their CMMS to track it.
Nine fields your CMMS needs for every networked device
Your current equipment records include asset tag, model, serial number, location, PM schedule, and service history. For networked devices, you need nine additional fields. Some platforms support them natively. Others require custom fields or third-party integrations.
1. IP address and MAC address
The most basic network identifiers. Without them, you have no way to correlate a CMMS work order with a network security alert. When your IT security team flags an anomalous connection from 10.4.12.87, your CMMS should return the specific device, its location, and its service history in seconds.
IP addresses change. DHCP (Dynamic Host Configuration Protocol)-assigned addresses rotate. Track both the current IP and the MAC address (hardware identifier that stays constant). Record whether the device uses static or dynamic IP assignment.
2. Network segment and VLAN (virtual local area network) assignment
Medical devices should sit on dedicated network segments, isolated from general hospital traffic. Knowing which VLAN a device belongs to tells you its exposure level. A patient monitor on the general guest WiFi network has a different risk profile than one on a segmented biomedical VLAN.
Track the assigned network segment, the date of assignment, and any exceptions or temporary connections.
3. Operating system and version
Many medical devices run commercial operating systems. Ultrasound systems on Windows 10. Patient monitors on embedded Linux. Infusion pumps on proprietary RTOS (real-time operating system). The operating system version determines which vulnerabilities apply.
This field is critical for end-of-life tracking. Microsoft ended extended support for Windows 10 on October 14, 2025. Any medical device still running Windows 10 is operating on an unsupported OS. Your CMMS should flag these devices automatically.
4. Firmware version and last update date
Firmware updates patch vulnerabilities and fix bugs. But medical device firmware updates require validation, and many departments defer them. Track the current firmware version, the date of the last update, and whether a newer version is available from the manufacturer.
The gap between “firmware available” and “firmware installed” is one of the most common audit findings in device security assessments.
5. Patch status
Three states: current, pending, or not available.
Current means the device runs the latest manufacturer-released patches. Pending means a patch exists but has not been applied (document the reason: validation in progress, downtime scheduling, compatibility testing). Not available means the manufacturer has not released a patch for a known issue, or the device is end-of-life with no further support.
“Not available” is the most important status to track. It identifies devices where compensating controls (network isolation, enhanced monitoring) are the only mitigation option.
6. SBOM data
The software bill of materials lists every software component running on a device, including version numbers. Thanks to 524B, manufacturers of new devices produce this data. For legacy devices, SBOMs are harder to obtain but not impossible. The FDA’s SBOM guidance follows the NTIA (National Telecommunications and Information Administration) minimum elements, published in July 2021.
Your CMMS needs a structured field (or linked document) for SBOM data. When a vulnerability is disclosed in a common component, you need to search your inventory by software component, not by device model. The Log4j vulnerability in December 2021 demonstrated this. An SBOM-aware CMMS lets you answer “which of our devices run Apache Log4j?” in minutes instead of weeks.
7. Vulnerability status
Link each device to known vulnerabilities from CVE (Common Vulnerabilities and Exposures) databases. The ICS-CERT (Industrial Control Systems Cyber Emergency Response Team, now CISA) publishes medical device advisories. Manufacturers issue coordinated disclosures per their 524B obligations.
Track: number of open vulnerabilities, severity rating (CVSS, or Common Vulnerability Scoring System, score), mitigation status, and compensating controls in place. This field should update automatically through integration with vulnerability intelligence platforms.
8. Device risk classification
Not the FDA device classification (Class I, II, III). This is a cybersecurity risk classification specific to your environment. Common frameworks use a matrix of clinical impact (what happens if the device is compromised during patient care) and network exposure (internet-facing, connected to clinical network, isolated).
A high-risk device: network-connected, patient-adjacent, running an end-of-life operating system with known unpatched vulnerabilities. A low-risk device: isolated, no patient data, current firmware. Your CMMS should calculate or store this classification and drive PM prioritization from it.
9. Communication patterns
What does this device talk to, and how? Document expected communication endpoints (manufacturer cloud services, local servers, other devices), protocols (HL7 (Health Level 7, a clinical data exchange standard), DICOM (Digital Imaging and Communications in Medicine), HTTPS, proprietary), and port usage. Deviations from expected patterns are early indicators of compromise.
Most departments will not populate this field manually. It requires integration with network monitoring tools (Claroty Medigate, Ordr, Cylera, Asimily) that passively map device communication behavior.
Which platforms track cybersecurity data natively
Not all CMMS platforms treat cybersecurity as a first-class data domain. The split falls along a predictable line: healthcare-specific platforms have added cybersecurity fields. Generic maintenance platforms have not.
Healthcare-specific platforms with native fields
Phoenix AIMS includes fields for IP address, MAC address, operating system, patch level, encryption status, and Wi-Fi security configuration. The platform offers API integration with dedicated cybersecurity platforms, enabling automated data exchange between your CMMS and your security tools. For departments running Phoenix AIMS, cybersecurity tracking requires configuration, not custom development.
Accruent TMS includes built-in device security data fields and integrations with IoT and network monitoring platforms. The dual CE/facilities management architecture means both clinical engineering and facilities teams work from a shared security dataset. Accruent’s integration ecosystem is the broadest in this category.
Nuvolo operates on the ServiceNow platform, which means medical devices live in the same CMDB (configuration management database) as IT assets. This is a structural advantage. When IT security scans the network, the same device record that holds your PM schedule also holds its vulnerability data. No integration required. OT (operational technology) cybersecurity monitoring plugins extend this to real-time threat detection. The trade-off is cost: Nuvolo’s ServiceNow licensing creates total cost of ownership 3 to 10 times higher than standalone platforms.
TRIMEDX RSQ includes automated cybersecurity vulnerability work orders. When a new vulnerability is disclosed for a device in your fleet, RSQ generates a work order with remediation steps. This is tightly integrated with TRIMEDX’s managed services model. You get cybersecurity tracking, but only as part of the full TRIMEDX managed CE contract.
Generic platforms: the integration gap
MaintainX, Limble, UpKeep, eMaint, and Fiix do not include native cybersecurity fields for medical devices. These platforms were built for general maintenance and facilities management. They track work orders and PM schedules effectively, but device-level network security data is not part of their data model.
To track cybersecurity data on these platforms, you have two options:
-
Custom fields. Build the nine fields above as custom data fields. This works but creates maintenance overhead. Custom fields do not integrate with vulnerability databases or network monitoring tools. You are manually entering data that should flow automatically.
-
Third-party integration. Connect your CMMS to a medical device security platform: Claroty Medigate, Ordr, Cylera, or Asimily. These platforms specialize in medical device network monitoring, vulnerability detection, and risk scoring. The integration pushes security data into your CMMS or pulls device inventory data out. The quality of this integration varies by platform and requires evaluation during your CMMS selection process.
Neither option is as clean as native fields. If cybersecurity tracking is a priority for your department (and it should be), this gap is a meaningful differentiator during CMMS evaluation.
The IT/HTM convergence problem
For decades, HTM and IT operated in separate worlds. HTM maintained medical devices. IT managed the network. The two teams shared a building and little else.
Networked medical devices broke this separation. A patient monitor connected to your clinical network is simultaneously a medical device under HTM’s PM program and a network endpoint under IT’s security program. Neither team has the complete picture alone.
The data lives in two systems. IT security tools see an IP address, open ports, and traffic patterns. Your CMMS sees a Philips IntelliVue MX800 patient monitor, serial number XY12345, due for PM next month, located in ICU Room 412. A security incident requires both views. Without integration, IT calls HTM asking “what device is at 10.4.12.87?” and HTM searches spreadsheets because the CMMS does not store IP addresses.
Organizational structure creates friction. HTM reports to facilities or operations in most hospitals. IT reports to the CIO. Budget authority, reporting chains, and priorities differ. A networked ventilator patch requires HTM to validate clinical functionality and IT to verify network security. If the CMMS does not bridge these teams with shared data, the patch sits in limbo.
CMMS selection affects collaboration. A platform like Nuvolo on ServiceNow gives both teams a single device record. IT and HTM see the same data, file work orders in the same system, and track remediation in one place. Separate platforms require API integrations, data synchronization schedules, and reconciliation processes. The integration quality becomes a bottleneck during incident response.
The direction is clear: HTM departments with no visibility into their devices’ network posture will lose influence over how those devices are managed. If IT security drives all medical device decisions because HTM lacks the data, your department’s role shrinks. Cybersecurity fields in your CMMS are not an IT initiative. They are an HTM initiative to maintain authority over your equipment fleet.
Five steps to start tracking cybersecurity data
You do not need to solve this in a single project. Start with what you have and build toward full coverage.
Step 1: Inventory your networked devices
Pull a list of every device in your CMMS with network connectivity. Wi-Fi, Ethernet, Bluetooth. If it connects to anything, it goes on the list. Most departments are surprised by the count. A 300-bed hospital typically has 10,000 to 15,000 connected medical devices.
Step 2: Add the basic network fields
At minimum, add IP address and MAC address fields to your CMMS device records. If your platform supports custom fields, this takes hours, not weeks. Populate them using data from your IT team’s network management tools. This single step bridges the most common gap between HTM and IT during security incidents.
Step 3: Request SBOMs from manufacturers
For devices purchased after March 29, 2023, manufacturers are required to produce SBOMs. Request them. For legacy devices, ask your device vendors what SBOM data they provide. Some manufacturers (particularly larger ones like GE HealthCare, Philips, and Siemens Healthineers) have published SBOMs for older devices as part of their security programs.
Store SBOM data in your CMMS as either structured fields or linked documents. The goal: when a component-level vulnerability surfaces, you search your fleet by software component.
Step 4: Evaluate medical device security platforms
Claroty Medigate, Ordr, Cylera, and Asimily are the leading medical device security platforms. These tools passively monitor network traffic, identify devices, map communication patterns, detect vulnerabilities, and generate risk scores. All four integrate with major CMMS platforms through APIs.
If your CMMS lacks native cybersecurity fields, a security platform integration is the most effective path to comprehensive coverage. Evaluate these platforms on integration depth with your specific CMMS, not on standalone feature lists.
Step 5: Define a risk classification framework
Assign each networked device a cybersecurity risk score based on clinical impact and network exposure. A simple three-tier model (high, medium, low) works to start. Use the risk classification to prioritize which devices get firmware updates first, which get network isolation, and which drive work order urgency.
Document the framework. When a surveyor asks how you assess medical device cybersecurity risk, your answer should be a documented process, not a verbal explanation.
The cost of waiting
The average healthcare data breach cost $10.93 million in 2023, according to IBM’s Cost of a Data Breach Report. Medical device compromises are a growing vector. The FDA has received over 1,800 medical device vulnerability reports since 2020.
Your CMMS is the system of record for your medical equipment fleet. If it does not include cybersecurity data, you are managing 21st-century risks with a 20th-century tool. The platforms, the data, and the integration options exist today. The only missing piece is the decision to start.
For the full platform comparison, read our Best CMMS Software for Healthcare guide.
Sources
- U.S. Congress, Consolidated Appropriations Act, 2023, Section 3305 (adding Section 524B to the FD&C Act). Signed December 29, 2022; effective March 29, 2023.
- FDA Guidance, “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions,” September 2023.
- NTIA, “Minimum Elements for a Software Bill of Materials (SBOM),” July 12, 2021.
- IBM Security, “Cost of a Data Breach Report 2023.”
- The Joint Commission, Environment of Care Standards, EC.02.04.01.
- CISA, ICS Medical Advisories (ICS-CERT), ongoing.
- ANSI/AAMI EQ103:2024, “Alternate Equipment Management Program Requirements.”
- Microsoft, “End of Support for Windows 10,” October 14, 2025.
