Healthcare · Moraph software

Medical Device Cybersecurity Hub

Know every connected medical device, what it is exposed to, and what is being done about it

Book a demonstrationRequest a technical briefingFactsheet

Overview

What you are buying

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.

  • Clinical engineering and security keep separate, incomplete device lists
  • Advisories and vulnerabilities are matched to devices by hand, if at all
  • Patch status, compensating controls and manufacturer approval are tracked in spreadsheets
  • Risk acceptance for devices that cannot be patched is rarely documented or reviewed

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

Requirements it supports

HIPAA Security Rule (45 CFR Part 164, Subpart C)FDA guidance: Postmarket Management of Cybersecurity in Medical DevicesFederal Food, Drug, and Cosmetic Act Section 524B (ensuring cybersecurity of devices)HHS 405(d) Health Industry Cybersecurity Practices (HICP)ANSI/AAMI/IEC 80001-1 (safety, effectiveness and security in networks incorporating medical devices)Manufacturer Disclosure Statement for Medical Device Security (MDS2)

The product supports these requirements; meeting them remains your organization’s responsibility.

See how it works

A short walkthrough

Illustrative screens with fictional sample data. They show the workflow, not any client’s data or configuration, and the layout of the product itself differs. A live demonstration uses the product with sample data.

  1. Step 1

    The device inventory

    One list of connected medical devices, combining clinical engineering records with what the network shows.

    Asset tagDevice typeLocationSoftwareOpen findingsSupport
    BX-10482Infusion pumpExample General, 4 Westv2.32 highSupported
    BX-20917Patient monitorExample General, ICUv5.11 mediumSupported
    BX-31554CT workstationExample General, ImagingLegacy OS3 highEnd of support
    BX-40126Lab analyzerExample Clinic, Labv8.0NoneSupported
    UnmatchedUnknownExample General, 2 EastNot observedNot assessedNeeds review
    One list of connected medical devices, combining clinical engineering records with what the network shows.

  2. Step 2

    A matched vulnerability

    Each advisory match shows the affected devices and the factors behind the score, for an analyst to confirm.

    Example infusion pump model · Manufacturer advisory (fictional)

    Affected versions
    v2.0 to v2.3
    Devices affected
    38 at 2 sites
    Known exploitation
    None reported
    Network exposure
    Clinical VLAN, internet access blocked
    Clinical criticality
    High
    Manufacturer patch
    Validated v2.4 available

    Score factors

    • Severity rated high by the advisory
    • Devices in use for medication delivery
    • Segmented network reduces exposure
    Each advisory match shows the affected devices and the factors behind the score, for an analyst to confirm.

  3. Step 3

    Planning the fix

    Clinical engineering and the owning department agree when devices can be taken out of use for the patch.

    SiteUnitDevicesWindowAgreed byStatus
    Example General4 West12Overnight, week 1Device ownerScheduled
    Example GeneralOncology9Overnight, week 1Device ownerScheduled
    Example GeneralPediatrics7Not yet agreedPendingAwaiting owner
    Example ClinicInfusion suite10Weekend, week 2Device ownerScheduled
    Clinical engineering and the owning department agree when devices can be taken out of use for the patch.

  4. Step 4

    A device that cannot be patched

    When no fix is available, compensating controls and the reason are recorded and sent for risk acceptance.

    BX-31554 · CT workstation, Example General Imaging

    Reason
    Manufacturer does not support an OS upgrade on this model
    Open findings
    3 high
    Replacement
    In capital plan, not yet funded
    Proposed review
    Sample date for review
    Approvers
    Security leader, Imaging director

    Compensating controls

    • Isolated network segment, imaging traffic only
    • Remote vendor access disabled except during supervised sessions
    • USB ports disabled, verified by clinical engineering
    When no fix is available, compensating controls and the reason are recorded and sent for risk acceptance.

  5. Step 5

    Responding to a new advisory

    From the moment an advisory is matched, the response is recorded step by step, with who did each part.

    Fictional advisory · Example patient monitor model

    1. Advisory matched to 64 devicesHub
    2. Match confirmed, finding createdDevice security analyst
    3. Manufacturer guidance attached: patch pending validationClinical engineering
    4. Monitors confirmed on segmented networkDevice security analyst
    5. Interim risk acceptance approvedSecurity leader and ICU director
    6. Validated patch scheduledClinical engineering
    From the moment an advisory is matched, the response is recorded step by step, with who did each part.

  6. Step 6

    Reviewing a purchase

    Before a new device model is bought, its security documentation and the manufacturer's answers are reviewed and decided.

    Example ultrasound system (fictional) · Requested by Radiology

    MDS2
    Received
    SBOM
    Received
    Supported OS until
    Stated by manufacturer
    Remote service access
    Always-on by default
    Patch process
    Manufacturer-validated, quarterly

    Open issues

    • Remote access must be configurable to on-demand
    • Confirm components with known vulnerabilities in the SBOM
    Before a new device model is bought, its security documentation and the manufacturer's answers are reviewed and decided.

Workflows

The principal workflows

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

    • Asset records arrive from the clinical engineering system by scheduled file or API
    • Network discovery data arrives from the tools you already run
    • Records are matched on asset tag, serial number, MAC address and model
    • Unmatched devices and conflicting details are queued for review
    • Each device is assigned an owning department and a clinical criticality

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

    • Vulnerability and advisory feeds are checked against models and versions in the inventory
    • Matches are listed with the affected devices and their locations
    • Analyst confirms or rejects each match and records the reason
    • Risk scored from severity, known exploitation, network exposure and clinical criticality
    • Confirmed findings are routed to the device owner and clinical engineering

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

    • Manufacturer guidance and validated patch availability recorded on the finding
    • Patch or upgrade scheduled with the owning department to fit clinical use
    • Compensating controls such as network segmentation recorded where no patch is available
    • Completion verified against the next inventory or discovery update
    • Finding closed with evidence, or sent for risk acceptance

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

    • Risk acceptance requested with the reason, controls in place and proposed review date
    • Security leader and device owner approve or return the request
    • Accepted risks reviewed before their expiry
    • New device purchases reviewed against the manufacturer's MDS2 and SBOM
    • Device risk reported to the risk or security committee

Roles and permissions

Who does what in the product

Each role below is a starting point. During implementation we set them up to match your teams, and every action anyone takes is recorded in the audit trail.

Device security analyst

Medical device security analyst, IoMT security engineer, information security analyst

Keeps the fleet's vulnerability picture accurate and makes sure every confirmed finding is moving toward a patch, a control or an approved acceptance.

Sees

  • The full device inventory with network and software details
  • Vulnerability and advisory matches waiting for confirmation
  • Open findings with their risk factors, owners and status
  • Compensating controls and risk acceptances across the fleet

Does

  • Confirms or rejects vulnerability matches with a recorded reason
  • Adjusts the risk score on a finding with a written justification
  • Assigns findings to clinical engineering and the owning department
  • Records and verifies compensating controls
  • Drafts risk acceptance requests for devices that cannot be remediated
  • Leads the response to a new manufacturer advisory

Cannot

  • Approve a risk acceptance, including one they drafted
  • Change the scoring model or risk policy
  • Mark a patch as applied on a device; that is recorded by clinical engineering
Approvals
Risk acceptances they draft go to the security leader and the device owner; their score adjustments are visible in the audit trail and reporting.
Notified about
New advisory matches, findings past the target dates your policy sets, controls due for re-verification and risk acceptances returned with comments.

Clinical engineering technician

Biomedical equipment technician, clinical engineer, HTM specialist

Keeps device records correct and carries out the patches and upgrades the manufacturer has validated.

Sees

  • Devices in their sites or teams, with maintenance and software details
  • Findings assigned to them and the manufacturer guidance on each
  • The reconciliation queue for their sites

Does

  • Resolves unmatched or conflicting device records
  • Records manufacturer patch validation and the version installed
  • Schedules and records patch and upgrade work with the owning department
  • Marks devices retired, relocated or replaced
  • Attaches service reports and manufacturer correspondence

Cannot

  • Close a finding without evidence that the fix was applied
  • Approve risk acceptances
  • Change risk scores
Approvals
Patch work that needs clinical downtime is agreed with the device owner; completion is verified against the next inventory update.
Notified about
Findings assigned to them, new manufacturer patches for their devices, and reconciliation items at their sites.

Security leader

CISO, deputy CISO, director of information security, IT risk officer

Owns medical device cyber risk for the organization: sets policy, approves risk acceptances and reports to leadership.

Sees

  • Every device, finding, control and risk acceptance
  • Program reporting by site, department and risk level
  • Scoring settings and their change history
  • The full audit trail

Does

  • Approves or returns risk acceptance requests
  • Sets risk scoring factors and target dates by risk level
  • Decides how advisory responses are prioritized
  • Approves exceptions to pre-purchase review outcomes
  • Prepares committee and board reporting

Cannot

  • Approve a risk acceptance without the device owner's approval
  • Edit or delete entries in the audit trail
  • Approve a request they drafted themselves
Approvals
Approves risk acceptances together with the device owner, and approves changes to scoring and policy.
Notified about
Risk acceptances waiting for approval, acceptances nearing expiry, high-risk findings past target date, and new advisories affecting critical devices.

Device owner

Department director, nurse manager, imaging or laboratory manager

Represents the clinical side: knows how the devices are used, agrees downtime for fixes and shares responsibility for accepted risk.

Sees

  • Devices assigned to their department and where they are
  • Open findings and planned work on those devices
  • Risk acceptances that involve their department

Does

  • Confirms the clinical criticality of their devices
  • Agrees maintenance windows for patches and upgrades
  • Co-approves or returns risk acceptances for their devices
  • Flags devices that have moved, been replaced or are no longer used

Cannot

  • See devices or findings belonging to other departments
  • Change findings, scores or controls
  • Approve a risk acceptance without the security leader
Approvals
Risk acceptances on their devices need both their approval and the security leader's.
Notified about
Findings on their devices, downtime requests, and risk acceptances waiting for them or coming up for review.

Procurement reviewer

Supply chain analyst, value analysis coordinator, third-party risk analyst

Makes sure device security is reviewed before a purchase is committed.

Sees

  • Pre-purchase reviews assigned to them
  • MDS2 forms and SBOMs held for the models under review
  • Past reviews and the current fleet of the same model

Does

  • Opens a security review for a proposed device purchase
  • Requests and attaches the manufacturer's MDS2 and SBOM
  • Records the manufacturer's answers to security questions
  • Submits the review for a decision

Cannot

  • Make the final decision on a review that raises open security issues
  • See vulnerability findings on installed devices beyond the model under review
  • Change device records
Approvals
Reviews with open security issues are decided by the security leader.
Notified about
New review requests, manufacturer documents received and decisions on submitted reviews.

Auditor (read-only)

Internal auditor, compliance officer, external assessor (under temporary access)

Reviews the device security program and its evidence without being able to change anything.

Sees

  • Devices, findings and controls within the scope granted
  • Risk acceptances with their approvals and reviews
  • Program reports
  • The audit trail

Does

  • Searches and reads records within their scope
  • Exports records and reports they have access to, with each export logged
  • Leaves review notes where the organization enables them

Cannot

  • Change, approve, close or delete anything
  • See records outside the scope and dates granted
  • Keep access after it expires
Approvals
Their access is approved by the security leader or an administrator, with a scope and an end date.
Notified about
Nothing by default; access granted and expiring is confirmed to the person who approved it.

Administrator

Application administrator, IT systems administrator

Manages users, roles, sites and integrations without taking part in risk decisions.

Sees

  • Users, roles, sites and department mappings
  • Integration settings and import results
  • The record of permission changes

Does

  • Adds and removes users, or maps them from single sign-on groups
  • Assigns roles, sites and departments
  • Maintains integration schedules and field mappings
  • Runs access review reports

Cannot

  • Approve risk acceptances or change findings
  • Grant themselves the security leader role without a second approver
  • Change scoring or policy settings
Approvals
Role changes that grant approval rights are approved by the security leader.
Notified about
Failed imports, access reviews coming due and accounts not used for a period your policy sets.

Permissions at a glance

ActionAnalystClin. eng.Sec. leaderDevice ownerProcurementAuditorAdmin
View device inventoryFullOwn work onlyFullOwn work onlyView onlyView onlyNo access
Edit and reconcile device recordsFullOwn work onlyFullNo accessNo accessNo accessNo access
Confirm or reject vulnerability matchesFullNo accessFullNo accessNo accessNo accessNo access
Adjust a finding's risk scoreFullNo accessFullNo accessNo accessNo accessNo access
Record patch appliedNo accessOwn work onlyFullNo accessNo accessNo accessNo access
Record compensating controlsFullOwn work onlyFullNo accessNo accessNo accessNo access
Agree maintenance downtimeNo accessView onlyView onlyOwn work onlyNo accessNo accessNo access
Request a risk acceptanceFullOwn work onlyFullNo accessNo accessNo accessNo access
Approve a risk acceptanceNo accessNo accessApprovesApprovesNo accessView onlyNo access
Run a pre-purchase reviewView onlyNo accessApprovesNo accessOwn work onlyView onlyNo access
View audit trailView onlyNo accessView onlyNo accessNo accessView onlyView only
Manage users and rolesNo accessNo accessApprovesNo accessNo accessNo accessFull
  • Full
  • Own work only
  • Approves
  • View only
  • No access

How access is controlled

  • Risk acceptance always needs two approvals, the security leader and the owning department, and nobody approves a request they drafted themselves.
  • Roles are configured with you during implementation. You can rename them, create custom roles, and limit them by hospital, site or department, so a department sees only its own devices.
  • Every permission change is recorded in the audit trail with who made it and when, and access review reports list each person's roles for periodic certification.
  • Staff sign in through your identity provider, and roles can follow its groups. Auditors and external assessors get temporary read-only access with a defined scope and an end date, rather than shared accounts.

Features

What it does

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

How it connects to your systems

Connects toHowWhat flows
Clinical engineering system (CMMS)Asset records, models, locations and maintenance history from your computerized maintenance management system, by scheduled file or API.In: asset tags, models, serial numbers, locations and owning departments. Out: patch and finding status, where your CMMS accepts it.
Network discovery toolsDevice data from the passive network monitoring or medical device discovery tools you already run, mapped during implementation.In: IP and MAC addresses, observed software versions, network segment and communication patterns.
Vulnerability and advisory feedsThe National Vulnerability Database, the CISA Known Exploited Vulnerabilities catalog, CISA medical advisories and manufacturer security bulletins.In: vulnerability identifiers, affected products and versions, severity and exploitation status.
IT service managementRemediation tasks raised as tickets in your service desk, with status flowing back to the finding.Out: remediation tasks. In: ticket status and closure notes.
Network access controlSegmentation and access policies recorded as compensating controls, including from Moraph's Network Access Control managed service.In: device segment and policy assignments.
Single sign-onStaff sign in through your identity provider (SAML or OpenID Connect).In: user identity and group membership for role assignment.
Work APIDevice, finding and risk data available to your data warehouse and reporting tools through the Moraph Work API.Out: devices, findings, controls, risk acceptances and status.

Each integration is confirmed in discovery and specified in the design. See how an engagement progresses.

Security and privacy

How your data is protected

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.

Company-wide controls, independent audits (SOC 2 Type II and ISO/IEC 27001) and data residency are described in our Trust Center, where you can request the evidence pack.

Reporting

What you can report on

11 standard reports, grouped by who uses them. Each shows who it is for, how it can be broken down, how it is delivered and what it is used for. The data behind them is also available to your own reporting tools.

Operational

Open findings by risk

For device security analysts and the security leader

Every open finding with its risk score, affected devices, owner, status and age, highest risk first.

Break down by
Risk level, Site, Department, Manufacturer, Status
Delivered as
Live dashboard; CSV export
Used for
Deciding what to work on next and making sure nothing high-risk sits unassigned.

Advisory response tracker

For device security analysts, clinical engineering, security leader

For a selected advisory or vulnerability, every affected device, where it is, who owns it and how far the response has got.

Break down by
Advisory, Site, Department, Response status
Delivered as
Live dashboard; scheduled email
Used for
Answering leadership's question of which devices are affected and what has been done.

Reconciliation backlog

For clinical engineering and device security analysts

Devices seen on the network but not in clinical engineering records, and records with conflicting details, with how long each has been open.

Break down by
Site, Issue type, Device category, Age band
Delivered as
Live dashboard; CSV export
Used for
Keeping the inventory complete enough to trust.

Patch status by model

For clinical engineering

For each model, the installed software versions, whether a manufacturer-validated patch exists, and how many devices still need it.

Break down by
Manufacturer, Model, Software version, Site
Delivered as
Live dashboard; CSV export
Used for
Planning patch rounds and maintenance windows.

Management and committee

Device risk summary

For security leader, risk committee and board

A periodic summary of inventory coverage, open findings by risk level, findings past target date, accepted risks and end-of-support devices.

Break down by
Period, Hospital or site, Risk level
Delivered as
PDF; scheduled email
Used for
Giving leadership the information to oversee medical device cyber risk.

End-of-support devices

For security leader, clinical engineering, capital planning

Devices running software or operating systems the manufacturer no longer supports, with their controls and any replacement plan.

Break down by
Department, Device category, Operating system, Replacement status
Delivered as
Live dashboard; PDF and CSV export
Used for
Informing capital replacement decisions and showing that unsupported devices are protected in the meantime.

Department device risk

For device owners and department leaders

Each department's devices, their open findings, planned work and accepted risks.

Break down by
Department, Device category, Risk level, Planned work
Delivered as
Live dashboard; scheduled email
Used for
Keeping department leaders informed about the devices they own.

Risk and audit

Risk acceptance register

For security leader, compliance, auditors

Every risk acceptance with the reason, controls in place, approvers, conditions, expiry date and review history.

Break down by
Status, Department, Expiry window, Approver
Delivered as
Live view; PDF and CSV export
Used for
Showing that unremediated risk was accepted by the right people and is reviewed.

Compensating control verification

For device security analysts, auditors

Each recorded control, the devices it protects, who verified it and when it is next due for verification.

Break down by
Control type, Site, Verification status, Due date
Delivered as
Live view; CSV export
Used for
Evidencing that controls on unpatched devices are in place and checked.

Audit trail extract

For internal audit and compliance

Who did what, when and why for a selected device, finding, risk acceptance or period, including notes, decisions and approvals.

Break down by
Record, User, Action, Date range
Delivered as
On request in the product; CSV and PDF export
Used for
Answering auditor and risk analysis requests for evidence without assembling it by hand.

Procurement

Pre-purchase review log

For supply chain, security leader

Each pre-purchase security review, the documents received, open issues and the decision.

Break down by
Manufacturer, Decision, Requesting department, Period
Delivered as
Live view; CSV export
Used for
Showing that device security is considered before purchase, and following up on conditions.

Exports, access and evidence

  • Every report can be exported to CSV, and summary and evidence reports to PDF. Reports can be scheduled to arrive by email for the people entitled to see them.
  • Each report can be filtered and the filters saved, so an analyst, a clinical engineering lead or a department director can keep their own views.
  • Device, finding and risk data is available through the Moraph Work API, and can be delivered to your data warehouse or business intelligence tool alongside other security and asset data.
  • Reports respect each viewer's role: a department director sees their own devices, the security leader sees the whole program, and auditors can be given read-only access.
  • Risk and audit reports can be run as of a past date and give the same result each time. Running and exporting a report is itself recorded in the audit trail.

Deployment

Where and how it runs

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 controls, independent audits and data residency are set out in our Trust Center. Engagement models and what drives a quotation are on Working with Moraph.

Implementation

What a rollout involves

The general phases are on Working with Moraph. For this product, they involve the following.

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.

Limitations

What it does not do

Worth knowing before you evaluate it.

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

Evaluation checklist

What to test in a demonstration or pilot

Questions worth putting to us, and to any other vendor you are considering.

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

Questions

Frequently asked questions

Does the Hub replace our network discovery tool?

No. It takes device data from the discovery tools you already run and combines it with your clinical engineering records. It does not scan devices itself.

Who owns the data in the Hub?

Your organization does. How it is returned to you and deleted at the end of the agreement is set out in the contract.

Will Moraph sign a business associate agreement?

Yes, where your use of the Hub could involve PHI. The Hub is designed to hold device data rather than patient records.

Can we change how findings are scored?

Yes. Scoring factors, clinical criticality categories and target dates are set with your security leader during implementation and can be changed later, with each change recorded.

How is it priced?

As a subscription, usually measured by the number of devices or sites covered, with implementation charged separately. See Working with Moraph for what drives a quotation.

Is there an accessibility conformance report?

Ask for one through the procurement request form at /how-to-buy/request, naming the version you are evaluating.

Next steps

Evaluate Medical Device Cybersecurity Hub

Book a demonstration

See the product working with sample data, focused on your workflows.

Request a demonstration

Request a technical briefing

Architecture, integrations, security and hosting, with our engineers and your technical team.

Request a briefing

Factsheet

This page on two sides, to share with colleagues or add to your evaluation file.

Open the factsheet

Buying through a formal procurement? See How to buy for purchasing routes, accessibility conformance reports and company information. Documentation: Medical Device Cybersecurity Hub guides on docs.moraph.com (getting started and security guides are public; setup, administration and integration guides are for client accounts). Support: Medical Device Cybersecurity Hub support guide.

Related products