Security, data and compliance in Medical Device Cybersecurity Hub

How Medical Device Cybersecurity Hub protects data and supports your compliance obligations.

Security controls

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.

Requirements it supports

• HIPAA Security Rule (45 CFR Part 164, Subpart C)
• FDA guidance: Postmarket Management of Cybersecurity in Medical Devices
• Federal 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.

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

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.