Medical Device Cybersecurity Hub

Principal workflows

• Inventory: Device records from your clinical engineering system are joined with what your network discovery tools see, so each device has one record with its model, software version, location, owner and network details.
• Assess: Published vulnerabilities, manufacturer security bulletins and MDS2 forms are matched to device models and software versions, and each match is scored for your environment.
• Remediate: Each finding is tracked to a patch, a compensating control or a documented risk acceptance, with the manufacturer's position and the clinical downtime it needs recorded along the way.
• Govern: Devices that cannot be patched are accepted as risks by the people with authority to do so, with an expiry date, and reviewed again. Purchases are reviewed for security before they arrive.

Who uses it

• Clinical engineering and healthcare technology management teams
• Medical device and IoMT security analysts in the information security team
• CISOs and IT risk leaders who answer for device risk
• Clinical department and biomedical leaders who own the devices and approve downtime
• Supply chain and procurement teams who review device security before purchase

Reporting

• Open findings by risk level, site and department
• Devices affected by a given advisory and the response status
• Patch status by manufacturer and model
• End-of-support devices and their controls
• Risk acceptances approved, expiring and under review
• Inventory coverage and reconciliation backlog

Features

• Unified device inventory: One record per device combining clinical engineering data and network discovery, with model, software version, location, owner and connection details.
• Reconciliation queue: Devices seen on the network but missing from clinical engineering records, and records with conflicting details, are listed for someone to resolve.
• Vulnerability matching: Published vulnerabilities, the CISA Known Exploited Vulnerabilities catalog and manufacturer advisories matched to models and software versions, with each match confirmed or rejected by an analyst.
• Clinical risk scoring: Findings ranked by severity, known exploitation, network exposure and how critical the device is to patient care, with the factors shown on each finding.
• Patch and manufacturer status: Whether the manufacturer has validated a patch, the version installed, and what the manufacturer recommends in the meantime, recorded on each device.
• Compensating controls: Network segmentation, access restrictions and other controls recorded against the devices they protect, with who verified them and when.
• Risk acceptance register: Requests to accept risk on devices that cannot be remediated, with approvers, conditions and an expiry date that triggers review.
• End-of-support tracking: Devices running operating systems or software the manufacturer no longer supports, flagged with their location and replacement plans.
• MDS2 and SBOM library: Manufacturer disclosure statements and software bills of materials stored by model, and used to match components to new vulnerabilities.
• Pre-purchase security review: A review step for new device purchases, recording the security questions asked, the manufacturer's answers and the decision.
• Advisory response: When a new advisory is published, one view shows every affected device, its location and owner, and the progress of the response.
• Audit trail: Who changed what, when and why for every device, finding, control and risk acceptance, exportable for auditors and your risk committee.

Integrations

• Clinical engineering system (CMMS): Asset records, models, locations and maintenance history from your computerized maintenance management system, by scheduled file or API.
• Network discovery tools: Device data from the passive network monitoring or medical device discovery tools you already run, mapped during implementation.
• Vulnerability and advisory feeds: The National Vulnerability Database, the CISA Known Exploited Vulnerabilities catalog, CISA medical advisories and manufacturer security bulletins.
• IT service management: Remediation tasks raised as tickets in your service desk, with status flowing back to the finding.
• Network access control: Segmentation and access policies recorded as compensating controls, including from Moraph's Network Access Control managed service.
• Single sign-on: Staff sign in through your identity provider (SAML or OpenID Connect).
• Work API: Device, finding and risk data available to your data warehouse and reporting tools through the Moraph Work API.

Deployment

• Moraph cloud: Hosted and operated by Moraph in the United States region. United Kingdom and Australia regions are available for organizations outside the US.
• Dedicated environment: A single-tenant environment for health systems whose policies require isolation, scoped in the proposal.
• With a managed service: Optionally run alongside Moraph managed services, such as Network Access Control, for help applying compensating controls.

Security and privacy

• Single sign-on: Staff sign in through your identity provider, so your password and multi-factor policies apply.
• Role-based access: What each person sees and does follows their role and department; requesting a risk acceptance is separate from approving one.
• Encryption and keys: Client data is encrypted, with keys Moraph staff cannot use without explicit, time-bound authorization.
• Complete audit trail: Every view, change, decision and export is logged with the person and time, and cannot be edited.
• Data residency: Data stays in the hosting region you choose: the United States, the United Kingdom or Australia.
• Business associate agreement: The Hub holds device data, not patient records, but Moraph signs a business associate agreement where your use could involve PHI.

Limitations

• The Hub does not scan or probe devices itself. It relies on your clinical engineering records and the network discovery tools you already run, and its inventory is only as complete as those sources.
• It does not patch devices. Patches and upgrades are applied by your clinical engineering staff or the manufacturer, once the manufacturer has validated them.
• Vulnerability matching depends on accurate model and software version data and on what manufacturers publish. Matches are confirmed by an analyst before they become findings.
• It is not a network access control or intrusion detection system. It records the controls your network tools enforce but does not enforce them.
• Risk scores support your decisions; risk acceptance and remediation priorities are decided by the people you designate.
• It does not perform the manufacturer's regulatory obligations, such as premarket cybersecurity submissions, and is not itself a regulated medical device.
• It is not designed to store patient records; device data and logs containing PHI should be kept out of the Hub unless agreed under a business associate agreement.
• Non-medical IoT and general IT assets can be recorded, but the workflows are designed for clinical devices.

Next steps

Book a demonstration or a technical briefing at www.moraph.com/solutions/medical-device-cybersecurity-hub. Purchasing routes and company information: www.moraph.com/how-to-buy.