Medical Device Cybersecurity Hub

The Medical Device Cybersecurity Hub keeps one inventory of the connected medical devices in your hospitals, built from your clinical engineering records and network discovery tools. It matches each device to published vulnerabilities and manufacturer advisories, tracks patch status and compensating controls, and routes remediation and risk-acceptance decisions to the right people. Clinical engineering, security and clinical departments work from the same record, with the evidence kept for auditors and your risk committee.

The problem it solves

Most hospitals track infusion pumps, imaging systems, monitors and lab analyzers in a clinical engineering system that knows the asset tag and maintenance history but not the software version or network exposure, while the security team sees IP addresses with no idea what clinical device sits behind them. Manufacturer advisories arrive by email, patches can only be applied once the manufacturer has validated them, and many devices run operating systems that are no longer supported. When a new vulnerability is published, nobody can say quickly which devices are affected, where they are, or what has been done to protect them.

Who it’s for

• 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

1. InventoryDevice 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.
2. AssessPublished vulnerabilities, manufacturer security bulletins and MDS2 forms are matched to device models and software versions, and each match is scored for your environment.
3. RemediateEach 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.
4. GovernDevices 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.

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.

Device security analyst

Confirms vulnerability matches, scores findings and tracks remediation across the fleet

Clinical engineering technician

Maintains device records, applies validated patches and records what was done

Security leader

Approves risk acceptances, sets scoring and policy, and sees the whole program

Device owner

Department leader who sees their own devices, schedules downtime and co-approves risk acceptances

Procurement reviewer

Runs security reviews for new device purchases

Auditor (read-only)

Views devices, findings, decisions and the audit trail, with no ability to change them

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.

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.

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.

Data sources

We connect your clinical engineering system and network discovery tools and agree the import schedule. We need data extracts and contacts from clinical engineering and the security team.

Inventory reconciliation

Initial records are matched, and conflicts and unmatched devices are worked through with your teams so the inventory starts from an agreed baseline.

Risk policy

Scoring factors, clinical criticality categories and target dates by risk level are set with your security leader and documented.

Workflow and roles

Sites, departments, assignment rules, approval steps and roles are configured to match how your clinical engineering and security teams work together.

Existing findings

Open findings, controls and risk acceptances from your current spreadsheets or tools are loaded and reviewed, so history is not lost.

Training and go-live

Analysts, clinical engineering staff, approvers and department leaders are trained on their own parts of the workflow.

• 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.

• Load an extract from your clinical engineering system and your discovery tool and review how well the records match
• Pick a recent manufacturer advisory and check whether the Hub finds the devices you know are affected
• Ask a clinical engineering technician to record a patch and see how the finding closes
• Walk through a risk acceptance for an unsupported device, including both approvals
• Check that a department director sees only their own devices
• Review the device risk summary as your risk committee would receive it