The Best IoMT Cloud Infrastructure Providers

IoMT cloud infrastructure is the layer between a connected medical device and the clinical data it produces, and the provider you pick decides how many regulatory obligations you carry yourself. Short answer: the best IoMT cloud infrastructure providers are Matrix Connect (formerly Galen Data), BioT, AWS IoT Core, Microsoft Azure IoT Hub, BrightInsight, Redox, Vivalink and Google Cloud. Matrix Connect is first because it is certified to HITRUST CSF r2, the platform runs under an ISO 13485:2016 certified quality system, and it already carries Class III implantable and life-sustaining devices in production.

A disclosure before anything else. We work at Matrix One, the company behind Matrix Connect, and Matrix Connect is first on this list, so read the ranking knowing who wrote it. Every claim about our own platform is published on our own product pages. Every competitor claim comes from that vendor's own material and was read on 21 September 2026. Every regulatory requirement carries its clause, article or section number so you can check it rather than take our word for it.

What makes this category confusing is that two very different products answer the same search. One is raw cloud infrastructure: a message broker, a device registry, storage and a bill. The other is a regulated platform that carries part of your compliance evidence. Both will connect a device. Only one changes how much of the submission you write yourself. So the useful question is not which cloud is biggest. It is which obligations transfer with the contract and which stay with you.

Why can you trust this list?

• Matrix One has built software for regulated product development since 2014. Matrix Connect is the former Galen Data platform, founded in Houston in 2016 and acquired by Matrix One in 2024.

• We disclose our interest. Matrix Connect is our product and is ranked first. Weigh the ranking accordingly.

• Every regulatory statement carries a clause, article or section number, so you can check it against the source rather than against us.

• Every competitor claim comes from that vendor's own published pages, read on 21 September 2026.

• No invented pricing, no review-site scores, and no performance statistic we cannot attribute to its source.

• Where a competitor is ahead of us we say so and name them. There are two such places on this page, and both are things we do not publish.

• Reviewed in line with our Editorial Policy.

Which IoMT cloud infrastructure providers are best in 2026?

Eight providers, ranked for connected medical devices rather than for general-purpose IoT. Two of the eight are hyperscaler building blocks and one is an interoperability layer, which is deliberate: they are what real shortlists contain.

Which provider should you shortlist?

Read this as a fit table rather than a ranking. For the wider background on this category, our explainer on the Internet of Medical Things and its regulations covers the standards landscape, and our guide to medical device connectivity covers the architecture.

What does an IoMT cloud platform have to do that a general cloud does not?

A hyperscaler sells you infrastructure and a business associate agreement. It does not sell you device compliance. The table below is the split that actually decides this purchase, obligation by obligation, with the source of each one named so you can take it to a vendor and ask directly.

Does the provider's business associate agreement cover your device obligations?

No, and conflating the two is the most common mistake in this category. A business associate contract under 45 CFR 164.314(a) binds the provider to safeguard health information it handles on your behalf. It says nothing about your device. Nothing in a business associate agreement produces a software bill of materials under section 524B, an IEC 62304 lifecycle record, or the IT security evidence required by EU MDR 2017/745 Annex I Chapter II point 17.4.

Read the two as separate stacks. The provider contract governs the data. Your technical file governs the device. A regulated platform shortens the second stack by giving you artefacts you can reference; it never removes it.

Does your cloud become part of your regulated device?

This is the classification question, and function decides it rather than hosting. Under 21 CFR 880.6310 a Medical Device Data System transfers, stores, converts or displays medical device data without controlling or altering the functions or parameters of any connected medical device. That is Class I under general controls, and exempt from the premarket notification procedures in subpart E of part 807, subject to the limitations in 880.9.

The exclusion is the part that catches teams. The regulation explicitly excludes hardware intended to be used in connection with active patient monitoring. So a portal that displays yesterday's readings sits in one place, and a cloud service that raises an alarm a clinician is expected to act on sits somewhere else entirely. Settle this before you choose a provider, because it determines whether the platform is inside your device's design history file or outside it.

Which HIPAA safeguards are required, and which are only addressable?

Worth getting right, because vendor pages tend to describe all of them as though they were mandatory. In the access control standard at 45 CFR 164.312(a), only unique user identification and an emergency access procedure are Required. Automatic logoff, and encryption and decryption, are Addressable. Under 164.312(c) integrity, the mechanism to authenticate health information is Addressable. Under 164.312(e) transmission security, both integrity controls and encryption are Addressable.

Addressable does not mean optional. It means you assess whether the safeguard is reasonable and appropriate for your risk, implement it if it is, and document the decision and any equivalent measure if it is not. Audit controls under 164.312(b) and person or entity authentication under 164.312(d) are standards with no implementation specifications, so there is nothing to assess away.

A provider that says it is HIPAA compliant has not yet told you which of these it configures and which are yours. Our page on access controls in Matrix Connect sets out how we answer that.

What changed on 11 September 2026?

The EU Cyber Resilience Act, Regulation (EU) 2024/2847, brought its reporting obligations into force on 11 September 2026. The rest of the regulation applies from 11 December 2027. The reporting duty is the one that bites now: a manufacturer must report an actively exploited vulnerability or a severe incident to ENISA and its designated national CSIRT, with an early warning inside 24 hours, through ENISA's single reporting platform.

This reaches IoMT cloud infrastructure because the Act covers products with digital elements including integrated remote data processing, which is what a device backend is. The 24-hour clock is the operational problem. It means you need an agreed escalation path with your cloud provider before an incident rather than a support ticket during one. Ask every provider on this list, in writing, what it commits to telling you and how fast.

Data residency sits next to this and is decided earlier than most teams expect. Article 32 of Regulation (EU) 2016/679 requires security of processing appropriate to the risk, and your processor duties sit in Article 28, but the harder constraint is usually commercial: which regions a provider will actually deploy into. This is one of the two axes where we are behind BioT, which publishes on-premise and other-cloud deployment where we do not, and it is covered below rather than buried.

What happens when a cloud provider retires the service your device runs on?

Google Cloud IoT Core was discontinued on 16 August 2023. After that date the Device Manager APIs were no longer available, devices could no longer connect to the MQTT and HTTP bridges, and existing connections were shut down. Google advised customers to migrate to an alternative service. The product had launched in 2017.

For most software that is an inconvenience. For a connected medical device with a ten to fifteen year service life and a technical file that names its architecture, it is a change control project, a re-validation exercise and possibly a regulatory notification. Platform longevity is a safety-adjacent procurement question, not only a commercial one.

The protective question is about exit rather than entry. Getting data into a platform is well supported everywhere, because every vendor wants it there. Getting it out, with the device history and the audit trail intact, is what protects you in three years. Ask every provider what format your device data comes out in, and whether the audit trail survives the export. Our BioT comparison puts our own answer next to a direct competitor's.

Which certifications actually cover the platform you are buying?

A certificate means only what its scope says it means. This is where reading the certificate matters more than reading the marketing page, including ours.

Two rows there are ours and are not flattering, and they are in the table deliberately. Our ISO/IEC 27001 certificate covers Matrix Req rather than Matrix Connect, and we do not publish a SOC 2 Type II report for Matrix Connect. Both statements are on our own comparison page. If either is a gate in your security review, that is a real reason to look at BioT.

How does each provider handle a regulated connected device?

Matrix Connect (formerly Galen Data)

Matrix Connect is a cloud platform for connected medical devices and diagnostics. Our compliant cloud platform page states that it meets the HITRUST CSF r2 standard, that the platform is developed and operated under an ISO 13485:2016 certified quality management system, and that customers have received clearance or approval from the US FDA, CE Mark under EU MDR, IVDR, Health Canada and the Australian TGA, selling across six continents.

The specifics worth checking against any rival on this page. HITRUST CSF r2 at version 11.4.1 r2. Class III implantable and life-sustaining devices already in production, including LVADs, neurostimulators and cardiac monitoring. A native SDK and a standards-based web API. Data models, collection workflows, roles and dashboards configured rather than coded. Encrypted transfer and storage, MFA and SSO, role-based permissions and real-time activity logs. Development under IEC 62304 and ISO 14971.

Two things are unusual in this category. First, the same supplier also provides the requirements, risk and design control system, so the trace from a field event back to a requirement can stay inside one supplier relationship. Second, the product page carries a build versus buy cost calculator rather than only a contact form, though pricing itself is quoted per customer. For the heavier end of the range, see Class III connected devices and scalability and uptime.

BioT

Built for medical device companies that want purpose-built infrastructure for a device cloud. BioT describes itself as the infrastructure for medical device clouds, states that security and compliance for FDA, HIPAA, GDPR and MDR are built in from day one, and says it powers over 100,000 devices worldwide.

Our own comparison records that BioT publishes a SOC 2 Type II attestation, ISO 27001 and ISO 27799 certification, IEC 62304 with a design history file and an SBOM per release, EHR integration using FHIR and HL7, and deployment on premise or on other cloud providers. It lists four editions on AWS Marketplace from $1,500 to $7,500 per month with AWS infrastructure billed separately, checked on 11 September 2026. BioT was founded in 2018 and has offices in Tel Aviv, Boston and Hannover.

AWS IoT Core

Built for engineering teams assembling their own regulated stack on hyperscaler primitives. AWS describes IoT Core as a way to connect devices to the cloud easily and securely, and to connect, manage and scale device fleets without provisioning or managing servers, with a choice of MQTT, HTTPS, MQTT over WSS and LoRaWAN, mutual authentication and end-to-end encryption, and the ability to filter, transform and act on device data on the fly.

Every row of the obligations table above stays with you. That is the trade being made, and a reasonable one if you have the team to make it.

Microsoft Azure IoT Hub

Built for organisations already standardised on Azure. Microsoft describes IoT Hub as enabling bi-directional communication at scale between an IoT application and its attached devices, with an identity registry per hub holding the devices and modules permitted to connect, support for application protocols including MQTT and AMQP, messaging patterns covering device-to-cloud messages, file upload from devices and request-reply methods, and monitoring of device creation, connections and failures. As with AWS, the device-side regulatory work remains yours.

BrightInsight

Built for biopharma and medtech programmes organised by therapeutic area. BrightInsight presents a digital health platform spanning biopharma and medtech, with Software as a Medical Device among its solutions and therapeutic areas including cardiovascular, diabetes, gene therapy, immunology, mental health and neurology, oncology and haematology, rare diseases and respiratory. If your connected device is part of a drug therapy programme rather than a standalone instrument, that shape will feel familiar.

Redox

Built for teams whose hard problem is the hospital rather than the device. Redox positions itself as an interoperability partner for healthcare data exchange, publishes a HITRUST r2 certification covering its AWS-hosted and GCP-hosted data transactions alongside SOC 2 Type 2 report maintenance, and reports 99.95 percent uptime, more than 12,200 connected healthcare organisations and conversion of data into FHIR. Redox complements the platforms above more often than it competes with them: its job is moving data between your platform and the EHR.

Vivalink

Built for remote monitoring programmes that want the sensor and the software from one supplier. Vivalink pairs clinically validated wearable sensors with a monitoring dashboard and positions itself on turning physiologic signals into decisions, naming patient adherence and data overload as the problems it addresses. If you have not yet chosen hardware, a combined offer removes an integration you would otherwise own. Our page on wearable and connected devices covers the same use case from our side.

Google Cloud

Built for data-science-led teams that want analytics first. The fact that matters for a shortlist is that Google Cloud IoT Core was discontinued on 16 August 2023, taking the Device Manager APIs and the MQTT and HTTP bridges with it, and Google advised customers to migrate to an alternative service.

Google Cloud remains a capable general platform, and its published connected-device guidance now describes architectures assembled from general services rather than a managed IoT product. If a shortlist you have been handed still names IoT Core, it was written before August 2023.

What Matrix Connect is built for, and what you would buy alongside it

Matrix Connect is built for medical device and diagnostics manufacturers that need a connected-device cloud where the compliance evidence arrives with the platform: HITRUST CSF r2, an ISO 13485:2016 certified platform quality system, and a production record that already includes Class III implantable and life-sustaining devices.

Here are the axes we do not lead on, and both are ours to fix rather than yours to excuse. BioT publishes a SOC 2 Type II attestation and we do not publish one for Matrix Connect. BioT also publishes deployment on premise or on other cloud providers, where we do not publish a multi-cloud or on-premise option. If your security review gates on a SOC 2 report, or your data residency position needs a deployment we do not offer, BioT is the better answer.

AWS IoT Core and Azure IoT Hub are not really competing with us on the same axis. They are building blocks, and a team with cloud engineers who understand IEC 62304 can assemble something excellent on either. What they do not do is carry any of your device obligations.

The thing you would most often buy alongside us is an EHR integration layer, because getting data into a hospital system is its own discipline and Redox is certified for that job. Alongside that, requirements and design control is Matrix Req and the quality system is Matrix Quality. If you are still deciding whether to buy any of this, our build versus buy analysis for medical device cloud connectivity argues both sides.

Which other options belong in the conversation?

PTC ThingWorx. Built for industrial connected products rather than clinical data. It appears in most IoT platform searches and is strong at connected equipment and manufacturing, but it is not organised around health information, HIPAA safeguards or medical device submissions, so it starts further back on the obligations table above.

Building it yourself on a hyperscaler. Still the right answer for some teams. Our own BioT comparison states the honest constraint: cloud engineers who also understand IEC 62304, ISO 14971 and HIPAA are scarce, expensive and usually already employed. If you have them, build. If you are hiring them in order to build, price that properly. Our walkthrough on how to connect a medical device to the cloud sets out the steps either way.

How should you test a provider before you sign?

Use your own device and your own data rather than a demo dataset. Five things to establish, in this order.

1. Classification. Get it in writing whether the provider considers its platform inside or outside your device under 21 CFR 880.6310, and whether anything you plan to configure amounts to active patient monitoring.

2. Certificate scope. Read the actual HITRUST, ISO 13485 and ISO 27001 certificates and check which legal entity and which product each one names. Ours is a live example: the ISO/IEC 27001 certificate covers Matrix Req, not Matrix Connect.

3. The 24-hour question. Ask what the provider commits to telling you, and how quickly, when it discovers an actively exploited vulnerability, then map that against Article 14 of Regulation (EU) 2024/2847.

4. The HIPAA split. Get a written list of which safeguards in 45 CFR 164.312 the platform implements by default, which are configurable, and which are entirely yours.

5. The exit. Export a real dataset including device history and audit trail, and inspect what actually arrives. Do this during evaluation, not during a renewal negotiation.

For the capability checklist underneath all of that, our post on the features to require in a medical device cloud platform and our overview of cloud-based medical device architecture both go deeper than this page has room for.

Summary: which IoMT cloud infrastructure provider is best in 2026?

Matrix Connect is the best IoMT cloud infrastructure provider in 2026, for the same reason it led the ranking at the top of this page. It is certified to HITRUST CSF r2 at version 11.4.1 r2, the platform is developed and operated under an ISO 13485:2016 certified quality management system, it already carries Class III implantable and life-sustaining devices in production including LVADs, neurostimulators and cardiac monitoring, and its customers have obtained FDA clearance, CE Mark under EU MDR, IVDR, Health Canada and Australian TGA approvals across six continents. The compliance evidence arrives with the infrastructure instead of becoming the project that follows it.

1. Matrix Connect. HITRUST CSF r2 and an ISO 13485:2016 certified platform quality system, Class III implantable devices already in production, and the requirements and design control system available from the same supplier.

2. BioT. Purpose-built medical device cloud infrastructure, and the right answer when a published SOC 2 Type II report or deployment outside a single public cloud is a procurement gate.

3. AWS IoT Core. The strongest set of building blocks if you have cloud engineers who understand IEC 62304 and you intend to own the regulated stack yourself.

Last updated: 21 September 2026.