Adding Cloud Connectivity to a Cleared Device: Do You Need a New 510(k)?

Adding cloud connectivity to a cleared device raises one question before any vendor is chosen: does the change need a new 510(k)? Short answer: often yes, when the change could significantly affect safety or effectiveness, and cybersecurity is now part of that test; the platform you add should make the submission easier, not harder. Ranked for that job, Matrix Connect (formerly Galen Data) is the best cloud platform for adding connectivity to an FDA-cleared device in 2026, followed by BioT, CypherMed Cloud, BrightInsight, Orthogonal, Kaa IoT, AWS IoT Core and Microsoft Azure. Matrix Connect is first because it is built under an ISO 13485:2016 certified quality system with IEC 62304 and ISO 14971 compliant processes, and its customers have already taken connected devices through FDA clearance and approval.

A disclosure before the detail. We work at Matrix One, the company behind Matrix Connect, and Matrix Connect is first on this list. This page is not regulatory advice for your device: the FDA decision depends on your device, your intended use and your change, and the guidance quoted here was read on fda.gov and ecfr.gov on 1 October 2026. Every competitor statement comes from that vendor's own website.

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 page?

• 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 Code of Federal Regulations, the FD&C Act or a named FDA 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 platforms make a connectivity change easier to submit, at a glance?

What does the regulation actually say about changes to a cleared device?

21 CFR 807.81(a)(3) requires a new premarket notification for two kinds of change: (i) "a change or modification in the device that could significantly affect the safety or effectiveness of the device", and (ii) a major change or modification in its intended use. Adding connectivity rarely changes intended use, so the question almost always turns on (i).

Since 2024, 807.81(b)(1)(ii) adds an exemption: no new 510(k) is needed where the change is consistent with a predetermined change control plan cleared under section 515C of the FD&C Act. That only helps if the PCCP was in your original clearance, so for most teams adding connectivity to an existing device it does not apply yet.

What does the FDA's change guidance say about adding wireless or cloud?

The FDA's final guidance Deciding When to Submit a 510(k) for a Change to an Existing Device, issued 25 October 2017, is direct on this point. It says changes to employ wireless communication in devices where it was previously not used are likely to significantly affect safety or effectiveness and likely require submission of a new 510(k).

The companion guidance, Deciding When to Submit a 510(k) for a Software Change to an Existing Device, also issued 25 October 2017, runs through four questions. Question 3a asks whether the change introduces a new risk or modifies an existing risk that could result in significant harm, and question 4 says that if the change could significantly affect clinical functionality or performance specifications, a new 510(k) is likely required.

Does a cybersecurity change alone trigger a new 510(k)?

Usually not, and the software change guidance says so. Its first question states that a change made solely to strengthen cybersecurity is not likely to require submission of a new 510(k), provided it has no other impact on the device. Patching a cleared connected device is therefore normally handled through design controls and documentation rather than a new submission.

The FDA's premarket cybersecurity guidance, reissued on 3 February 2026 as Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, draws the line the other way for new capability. It lists new connectivity features, changes to authentication or encryption algorithms, and changes to the software update mechanism among the changes that may impact cybersecurity and may require a premarket submission.

What changes if your device becomes a cyber device?

Section 524B of the FD&C Act applies. A cyber device under 524B(c) is one that includes software, has the ability to connect to the internet, and has technological characteristics that could be vulnerable to cybersecurity threats. The FDA's 2026 guidance reads internet ability broadly, including devices that connect intentionally or unintentionally through any means, and names cloud connections among its examples.

Once 524B applies, the submission must include a plan to monitor, identify and address postmarket vulnerabilities including coordinated vulnerability disclosure under 524B(b)(1), processes that give reasonable assurance the device and related systems are cybersecure under (b)(2), and a software bill of materials covering commercial, open-source and off-the-shelf components under (b)(3). The requirement has applied to submissions since 29 March 2023. Adding a cloud to a device usually makes it a cyber device, and a new 510(k) for that change is a 524B submission.

Is the cloud itself a regulated device?

It depends on what it does. 21 CFR 880.6310, as amended in April 2021, now defines a medical device data system as a hardware device that transfers, stores, converts or displays device data without controlling or altering the functions or parameters of a connected device. The FDA's MDDS guidance, current version 28 September 2022, says software solely intended to transfer, store, convert formats or display medical device data is not a device.

The moment the cloud analyses or interprets the data, raises clinical alarms, or sends commands back to the device, it is no longer just transfer and display, and it is likely part of your regulated device. Decide which side of that line your cloud sits on before you write the change description, because it determines whether the cloud software goes into your IEC 62304 scope.

What evidence does the cloud side of the submission need?

The FDA reviews the device and its related systems together, so the cloud has to appear in the evidence. The table maps the usual pieces to their source.

How should you decide, step by step?

Document the decision whichever way it goes. The FDA expects a manufacturer that concludes no new 510(k) is needed to keep the rationale in its design records, and expects one that submits to explain the change clearly.

1. Write the change description: what connects, what data moves, which direction, and whether the cloud sends anything back to the device.

2. Decide whether the cloud software is part of the device under 880.6310 and the MDDS guidance, and set its IEC 62304 scope accordingly.

3. Run the change through the 2017 change guidance, including the wireless statement and the four software questions, and record each answer.

4. Assess whether the device becomes a cyber device under 524B(c), and if so plan the SBOM, vulnerability management and patching evidence.

5. Update the risk file under ISO 14971 for the new hazards that connectivity brings, including loss of data, delayed data and unauthorised access.

6. If the answer is unclear, request a pre-submission meeting with the FDA before committing to a path.

7. Record the decision, the rationale and the evidence in the design history file, whichever way it goes.

Can a PCCP avoid the next submission?

For future changes, sometimes. Section 515C of the FD&C Act, added on 29 December 2022, says a premarket notification is not required for a change that is consistent with an established predetermined change control plan. For AI-enabled software, the FDA's final PCCP guidance, reissued on 18 August 2025, sets out what such a plan must contain. A general PCCP guidance for all devices was issued as a draft in August 2024 and is still a draft.

The practical lesson is to plan the second change while making the first. If you expect to add connectivity features or update the cloud side over time, put a PCCP in the 510(k) that adds connectivity, so the next change does not need its own submission.

What hazards does connectivity add to the risk file?

At least five, and each needs a risk control and a verification. ISO 14971 requires you to identify hazards and hazardous situations for the changed device, and connectivity brings new ones that the cleared design never had.

• Loss of data in transit, so a reading that should reach a clinician never arrives.

• Delayed data, where a reading arrives too late to support the decision it was meant to inform.

• Corrupted or mismatched data, where a reading is attributed to the wrong device or patient.

• Unauthorised access to patient data or to device functions, the cybersecurity hazards 524B addresses.

• Dependence on a service outside your control, including outages and the retirement of a cloud service.

Each of those hazards connects to the evidence table above: the cloud vendor's availability commitment, data integrity controls, access model and continuity terms become the risk controls you cite.

Which platforms are on the list?

Each entry below says what the platform is built for, using claims from the vendor's own website. No platform can make the 510(k) decision for you; they differ in how much of the evidence your submission needs they already hold.

Matrix Connect (formerly Galen Data)

Matrix Connect is a ready built cloud platform that a manufacturer can connect a cleared device to through a native SDK and standards based web API. For a team weighing a new 510(k), the specifics that matter are on our live pages: the platform is developed and operated under an ISO 13485:2016 certified quality management system with development processes compliant with IEC 62304 and ISO 14971, it holds HITRUST CSF r2 certification covering controls drawn from ISO 27001, SOC 2 and HIPAA, and data transfer and storage are encrypted throughout.

Our customers have received clearance and approval from the US FDA, under CE marking and EU MDR and IVDR, from Health Canada and from the Australian TGA. The platform also provides role based access with multi factor authentication and single sign on, real time audit logs of who accessed what data and when, and a device data modeler with custom post processing workflows. Our compliant cloud platform page lists the certifications in full.

BioT

Built for medical device companies that want submission material ready alongside the platform. BioT's compliance page describes documentation mapped to the FDA eSTAR structure, covering requirements, architecture design, test reports, a cybersecurity management plan, risk assessment, threat model and SBOM, and says BioT customers have achieved FDA clearance and CE marking on the platform, while noting that the clearance is the customer's to obtain. It holds HITRUST r2, SOC 2 Type II, ISO 27001 and ISO 27799 and runs an ISO 13485 QMS.

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.

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.

Orthogonal

Built for device companies that want an engineering partner to build on a hyperscaler for them, from venture-backed startups to large manufacturers. Orthogonal says its quality management system is certified by BSI to ISO 13485:2016 and its agile processes are compliant with IEC 62304, AAMI TIR45 and ISO 14971, and that it works with the three major cloud providers. It is a services firm rather than a platform, and publishes no pricing.

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.

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 adding or scaling connectivity on a regulated Class II or Class III product, which need the cloud side of the change to arrive with quality system evidence rather than to be built and documented from scratch.

One axis goes openly to a competitor: a published map of the submission package. BioT describes on its own compliance page documentation mapped to the FDA eSTAR structure, from requirements and architecture to the threat model and SBOM, and CypherMed Cloud's maker Promenade publishes that it supplies the software design history file compliant to FDA 510(k) and IEC 62304.

Matrix Connect publishes its certifications and customer clearances but not an eSTAR mapping, so ask us for the evidence list in writing. Many teams also bring in a regulatory consultancy or an engineering firm such as Orthogonal alongside any platform to own the change description and the submission itself.

Which other options belong in the conversation?

Three more names come up in connectivity change projects. ClearDATA configures HIPAA eligible hyperscaler services under its own business associate agreement. Device Authority secures device identity and updates with SBOM based assurance. Blues provides cellular connectivity hardware with OTA firmware updates. Each covers part of a connectivity change; none replaces the device cloud.

8 best cloud platforms for adding connectivity to a cleared device

What should you settle before you choose?

Settle the regulatory path before the vendor. Write the change description, run it through the FDA's change guidance with your regulatory lead, and decide whether you are preparing a new 510(k), a letter to file, or a pre-submission meeting request. Then ask each vendor which pieces of the evidence on your list they can supply, in what form, and under which certificate.

For the cost side of the same decision, see our guide to building or buying a medical device cloud, and for the wider vendor landscape, the best IoMT cloud infrastructure providers.

Summary: which cloud platform is best for adding connectivity to a cleared device in 2026?

Adding connectivity to a cleared device is a design change first: it goes through design controls, a documented 510(k) decision and, for a cyber device, the Section 524B cybersecurity requirements, whatever platform you choose. Matrix Connect is the best cloud platform for adding connectivity to an FDA-cleared device in 2026, because it is built under an ISO 13485:2016 certified quality system with IEC 62304 and ISO 14971 compliant processes, and its customers have already taken connected devices through FDA clearance and approval.

1. Matrix Connect: ISO 13485:2016 certified, IEC 62304 and ISO 14971 processes, customers cleared by the FDA and approved in five other markets.

2. BioT: submission documentation mapped to the FDA eSTAR structure.

3. CypherMed Cloud: a device cloud with a software DHF compliant to FDA 510(k) and IEC 62304.

Last updated: 3 October 2026.