The Best Cloud Platforms for FDA 524B Cyber Devices

FDA 524B cybersecurity is now part of every premarket submission for a connected device, and the cloud a device talks to is inside the scope the FDA reviews. Short answer: Matrix Connect (formerly Galen Data) is the best cloud platform for a 524B cyber device in 2026, followed by BioT, CypherMed Cloud, Device Authority, Kaa IoT, BrightInsight, AWS IoT Core and Microsoft Azure. Matrix Connect is first because the cloud side of a 524B submission arrives with HITRUST CSF r2 certified controls, an ISO 13485:2016 certified quality system with IEC 62304 and ISO 14971 compliant processes, and audit logging and access control built in.

A disclosure before the detail. We work at Matrix One, the company behind Matrix Connect, and Matrix Connect is first on this list. The statute and guidance quoted here were read on congress.gov and fda.gov on 1 October 2026, and none of this is a substitute for your own cybersecurity risk assessment. Every competitor statement comes from that vendor's own website, read on 1 October 2026.

Matrix Connect is a compliant cloud connectivity platform for connected medical devices and AI health software. It is developed and operated under an ISO 13485:2016 certified quality management system and holds HITRUST CSF r2 certification.

Why can you trust this list?

• Matrix One builds regulated software for medical device companies, and Matrix Connect is our device cloud.

• We disclose our interest in the second paragraph, not in a footnote.

• Every regulatory statement is tied to a section of the FD&C Act, the Code of Federal Regulations or a named FDA or HHS guidance with its date.

• Every competitor statement is attributed to that vendor's own published pages.

• No invented pricing and no G2 data. Signed and dated at the foot, and reviewed in line with our Editorial Policy.

Which cloud platforms help most with a 524B submission, at a glance?

What does Section 524B require?

Section 524B of the FD&C Act, in force for submissions since 29 March 2023, applies to every 510(k), De Novo, PMA, product development protocol and humanitarian device exemption for a cyber device.

It sets four requirements in 524B(b): (1) a plan to monitor, identify and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure; (2) processes that provide a reasonable assurance that the device and related systems are cybersecure, including patches on a regular cycle and out of cycle for critical vulnerabilities; (3) a software bill of materials; and (4) any other requirement set by regulation.

Is your connected device a cyber device?

Almost certainly, if it talks to a cloud. Section 524B(c) defines a cyber device as one that includes software, has the ability to connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats. The FDA's premarket cybersecurity guidance reads the second condition broadly, covering devices that can connect intentionally or unintentionally through any means, and names cloud connections, Wi-Fi, Bluetooth and USB or ethernet ports among its examples.

Which FDA guidance applies now?

The current version is Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, final, issued 3 February 2026 under docket FDA-2021-D-1158. It replaced the June 2025 version, which had itself replaced the September 2023 version and absorbed the separate 524B select updates draft of March 2024. The 2026 version is aligned with the Quality Management System Regulation, which incorporates ISO 13485:2016 by reference.

For postmarket handling, the FDA's Postmarket Management of Cybersecurity in Medical Devices guidance of 28 December 2016 is still final. It treats most routine cybersecurity updates and patches as device enhancements and says the FDA does not intend to enforce part 806 reporting for them.

Why does the cloud fall inside 524B scope?

Because 524B(b)(2) covers the device and related systems, and the cloud a device reports to is a related system. The FDA's guidance expects the security architecture, threat model and risk assessment to include the connections between the device and the services it depends on, and lists new connectivity features, changes to authentication or encryption, and changes to the software update mechanism among the changes that may impact cybersecurity.

So choosing a cloud platform is choosing part of your 524B evidence. A platform that cannot tell you its components, its patch cadence or its vulnerability handling leaves a gap in your submission that you have to fill yourself.

What evidence does the cloud side of a 524B submission need?

The table maps each 524B duty to what the cloud vendor can usually supply and what stays with you.

What should the SBOM cover when part of the system is a cloud?

Every software component in the device and its related systems that you can identify, including commercial, open-source and off-the-shelf components, as 524B(b)(3) puts it. For the device itself that is your firmware and its libraries. For the cloud, the practical question is how deep the vendor's own component list goes and how it is kept current, because a static list goes out of date with the first platform release.

Agree three things with the vendor in writing: the format and scope of the component information they will give you, how often it is refreshed, and how they notify you when a component in their stack has a known vulnerability. Those three answers are what turn a vendor relationship into the 524B(b)(1) monitoring plan.

How do patches work when the vendor runs the cloud?

On the vendor's release cycle, which is why the cycle matters. Section 524B(b)(2) expects patches on a reasonably justified regular cycle for known unacceptable vulnerabilities and as soon as possible out of cycle for critical ones. A cloud vendor that patches its platform continuously can satisfy the cloud half of that duty for you, provided you receive notice and can assess each change against your device under your design controls.

The 2017 software change guidance helps here: a change made solely to strengthen cybersecurity is not likely to require a new 510(k). Most cloud side security patches therefore stay inside your quality system rather than triggering a submission.

How do you run the vendor assessment for 524B?

1. Draw the system boundary: device, gateway or app, cloud, and every external service the cloud calls.

2. Ask each vendor for its security certifications with their scope, and confirm which product each covers.

3. Ask for the component information for the cloud side, its format and its refresh cadence.

4. Ask for the vendor's vulnerability disclosure and incident notification commitments, with timelines.

5. Ask for the patch and release cadence and the notice you receive before a change reaches production.

6. Ask for the access control, authentication and audit logging model, and test it in a trial.

7. Record the assessment as a supplier evaluation under ISO 13485:2016 clause 7.4.1 and reference it in your threat model.

What should the security architecture show about the cloud?

The device, the cloud and every connection between them, at the level a reviewer can follow. The FDA's premarket cybersecurity guidance expects security architecture views that show how the device and its related systems connect, where trust boundaries sit, how software updates reach the device, and how a compromise could affect many patients at once rather than one. A device that reports to a shared cloud has a multi patient dimension by design.

For the cloud side, that means diagrams and descriptions of the interfaces the device uses, how devices are authenticated to the cloud, how users are authenticated and authorised, how data is encrypted in transit and at rest, and how updates and configuration changes are controlled. A platform vendor should be able to supply the cloud half of those views for its own service.

Which logs should the cloud keep, and for how long?

Enough to investigate an incident long after it happens. Security monitoring under 524B(b)(1) and incident investigation both depend on logs of who accessed what, when, and what changed. A log kept for a few weeks cannot support an investigation into a vulnerability disclosed a year later.

Set a retention period in your requirements and match it in the contract. For reference, the Matrix Connect Commercial plan's published terms retain audit logs for 6 years, and the Development plan for 6 months, so check which plan a figure applies to before you rely on it.

Does 524B apply to software as a medical device in the cloud?

Yes, if it meets the three conditions. Software as a medical device that runs in a cloud includes software by definition and connects to the internet by design, so the only open question under 524B(c) is whether it has technological characteristics that could be vulnerable to cybersecurity threats, and almost every networked service does. A cloud hosted SaMD is therefore treated as a cyber device in its 510(k), De Novo or PMA.

For SaMD the cloud is not a related system, it is the device. That moves the platform's security controls, component list and patch cadence from supporting evidence to core device evidence, and makes the vendor's quality and lifecycle documentation part of the device file rather than a supplier record alone.

Which platforms are on the list?

Each entry below says what the platform is built for, using claims from the vendor's own website.

Matrix Connect (formerly Galen Data)

Matrix Connect gives a cyber device a cloud side that already carries its security controls. It holds HITRUST CSF r2 certification, whose scope covers controls drawn from ISO 27001, SOC 2 and HIPAA, and it is developed and operated under an ISO 13485:2016 certified quality management system with IEC 62304 and ISO 14971 compliant processes. Data transfer and storage are encrypted throughout.

The controls that map most directly to 524B(b)(2) are on our live pages: granular role based permissions, multi factor authentication and single sign on, automated session management, and real time audit logs of who accessed what data and when. Under our published terms, the Commercial plan carries a 99.9 percent uptime guarantee, backups every 4 hours retained for a year, audit logs retained for 6 years and a 4 hour response time for critical issues. Our access controls page sets out the model.

BioT

Built for device teams that want cybersecurity evidence packaged with the platform. BioT's compliance page says it maintains an IEC 62304 design history file and an SBOM updated every release, and that its documentation is mapped to the FDA eSTAR structure including a cybersecurity management plan, risk assessment and threat model. It holds HITRUST r2, SOC 2 Type II, ISO 27001 and ISO 27799.

CypherMed Cloud

Built for medical device manufacturers; CypherMed Cloud, from Promenade Software, says it is designed for their unique needs. Its site lists SOC 2 Type 2 security certification, IEC 62304 and 82304 lifecycle control, and FDA cybersecurity documentation included, and Promenade says its quality management system is ISO 13485 certified and that it provides the complete design history file for the software, compliant to FDA 510(k) and IEC 62304. No pricing is published.

Device Authority

Built for organisations securing device identity at fleet scale; Device Authority says it helps organisations discover, trust, govern and continuously validate machine identities. Its healthcare page describes continuous assurance and threat validation based on a device's SBOM to meet FDA requirements, and code signing and secure updates. It is a device security layer rather than a full device cloud.

Kaa IoT

Built for teams that want a validatable IoT backend; Kaa describes its medical offering as a validatable IoT backend for connected medical device software. It provides an SBOM for the platform components delivered in a project as part of its Validation Bundle, supports OTA workflows with firmware version tracking, and says plainly that it does not replace your regulatory team or QMS. Its generic IoT cloud plans start at 99 USD a month, with a free plan for up to 5 devices.

BrightInsight

Built for regulated digital health and software as a medical device programmes, and now positioned on its homepage around improving patient persistence for large pharma companies. BrightInsight's standards page lists IEC 62304, ISO 13485, ISO/IEC 27001, HITRUST CSF, HIPAA, IEC 82304-1, MDSAP, HDS and CE Mark under the MDR. It publishes no pricing.

AWS IoT Core

Built for teams with cloud engineering capacity that want to build their own platform on a hyperscaler. AWS IoT Core is on AWS's HIPAA eligible services list, last updated 3 September 2026, alongside IoT Device Management, IoT Greengrass and FreeRTOS, and AWS presents a standard business associate addendum for signature. AWS IoT Device Defender is not on that list. Everything above the infrastructure is yours to build, document and validate.

Microsoft Azure

Built for teams with cloud engineering capacity standardised on Microsoft. Microsoft includes the HIPAA business associate agreement in its Product Terms rather than as a separate contract. Note two platform changes: Microsoft stopped new Azure IoT Central application creation on 23 September 2026 and says IoT Central applications will no longer be available after 20 September 2029, and Defender for IoT plans to retire its micro agent on 1 June 2027.

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

Matrix Connect is built for medical device and diagnostics companies whose connected product is a cyber device under Section 524B, and which need the cloud side of the submission to arrive with certified controls, audit logging and an SLA rather than to be built and evidenced from scratch.

One axis goes openly to competitors: a published SBOM cadence and device side security. BioT says on its own compliance page that it updates its SBOM every release and packages a threat model and cybersecurity management plan, and Device Authority covers device identity, code signing and SBOM based continuous assurance on the device itself.

Matrix Connect does not publish an SBOM cadence, so agree the format and refresh in writing. Many teams run a device security layer such as Device Authority alongside a device cloud, because the firmware side of 524B is outside any cloud's scope.

Which other options belong in the conversation?

Three more names come up in 524B planning. Orthogonal is an ISO 13485 certified engineering firm that builds on the major clouds for device companies. ClearDATA configures HIPAA eligible hyperscaler services under its own business associate agreement. Blues provides connectivity hardware with OTA firmware updates, which is part of the update mechanism the FDA guidance names.

8 best cloud platforms for FDA 524B cyber devices

What should you settle before you choose?

Draw the system boundary first, then decide which party evidences each 524B duty inside it. A vendor that cannot answer the component, disclosure and patch questions in writing leaves you to build that evidence yourself. For the regulatory side of the connectivity change itself, see our guide to adding cloud connectivity to a cleared device, and for the cost side, building or buying a medical device cloud.

Summary: which cloud platform is best for an FDA 524B cyber device in 2026?

A device that talks to a cloud is a cyber device under Section 524B(c), and the cloud is one of the related systems its submission must show are cybersecure, with an SBOM and a postmarket vulnerability plan. Matrix Connect is the best cloud platform for a 524B cyber device in 2026, because the cloud side of the submission arrives with HITRUST CSF r2 certified controls, an ISO 13485:2016 certified quality system with IEC 62304 and ISO 14971 compliant processes, and audit logging and access control built in.

1. Matrix Connect: HITRUST CSF r2 and ISO 13485:2016, with audit logs kept 6 years and a 99.9 percent uptime guarantee on the Commercial plan.

2. BioT: an SBOM updated every release and a packaged cybersecurity management plan and threat model.

3. CypherMed Cloud: FDA cybersecurity documentation included, on SOC 2 Type 2 certified infrastructure.

Last updated: 4 October 2026.