Cybersecurity for cloud-connected medical devices: what FDA asks and what changes

Overall, healthcare providers are happy when a new medical device is connected to the cloud. It makes their life easier. Patients also benefit.

But for manufacturers, cloud-connected medical device cybersecurity can be a source of pure angst. There are simply more things that can go wrong.

Generally, we define a cloud-connected medical device as one that exchanges data with cloud-based systems for functions such as remote monitoring, data storage, analysis, or software updates. But manufacturers soon learn that securing the device itself is only part of the solution. They also need to evaluate the constant back-and-forth traffic between the device and the cloud and what could go wrong after the data arrives.

It goes without saying that according to FDA cybersecurity guidance, manufacturers are expected to address cybersecurity risks that could affect device safety and effectiveness. Network connections. Third-party software. Cloud services. All bring risks.

And yet there is one more opening for an attacker. Cloud environments change, often without the device manufacturer making any changes at all.

What we look at in this article:

• What makes cloud-connected medical devices different
• What FDA expects manufacturers to document and test
• How to manage cybersecurity when the cloud environment changes

What makes cloud-connected medical devices different?

Cloud connectivity gives medical devices capabilities they wouldn't otherwise have. A patient monitoring device, for example, can send readings to a healthcare provider without the patient leaving home. Clinicians can review the data remotely, and manufacturers may be able to deliver software updates without physically accessing the device.

Those are worthwhile benefits. But they come with a tradeoff. The more a device depends on outside systems, the more there is to protect.

A security problem in a cloud service could affect a medical device even when there's nothing wrong with the device itself. That's one reason medical device cloud security requires looking beyond the hardware.

More connections mean more places to look for risk

Think about everything involved in sending a patient's readings from a medical device to a doctor's computer. There's the device, the internet connection, the cloud platform, and possibly a mobile app or web dashboard.

Each connection introduces another potential point of attack.

An insecure API could expose patient data. Weak authentication might allow someone to access information they shouldn't see. And a cloud outage could interrupt the flow of information clinicians depend on.

For manufacturers, this means looking beyond the device when identifying cybersecurity risks. FDA expects them to consider how connected systems and external dependencies could affect device safety and effectiveness.

The cybersecurity threats cloud-connected medical devices face

Connecting a medical device to the cloud doesn't necessarily make it less secure. But it does give attackers more ways to find a weakness.

Some threats are familiar, such as stolen passwords and outdated software. Others involve the way devices communicate with cloud platforms, mobile apps, and hospital systems.

What makes cloud medical device security risks particularly concerning is their potential effect on patient care.

Let's look at some of the vulnerabilities manufacturers need to consider.

Unauthorized access and compromised credentials

A stolen password might not sound like a major cloud-connected medical device cybersecurity threat. But what if that password gives someone access to a cloud dashboard used to monitor patients?

Depending on the system's design, an attacker could view sensitive information, change settings, or interfere with data that healthcare providers rely on.

Weak passwords aren't the only concern. Shared accounts, excessive user permissions, and poorly managed authentication can also leave cloud-connected devices vulnerable.

Manufacturers need to consider who can access each part of the system, what they're allowed to do, and how that access is protected. Strong authentication, appropriate access controls, and monitoring for suspicious activity can help reduce these risks.

Insecure APIs and Data Transfers

Cloud-connected medical devices rely on application programming interfaces (APIs) to exchange information with other systems. Think of an API as the connection that lets a patient monitoring device send readings to a cloud platform or a clinician's dashboard.

The problem comes when those connections aren't properly secured.

An attacker might exploit a poorly protected API to access patient information, alter transmitted data, or interfere with communications between the device and the cloud.

Encryption helps protect data in transit, but it's only part of the solution. Manufacturers also need to verify that APIs authenticate users and systems, enforce access permissions, and reject unauthorized requests.

Cloud Service Outages and Availability Risks

What happens when a medical device depends on a cloud service that suddenly goes offline?

For some devices, an outage might delay a routine report. For others, it could prevent clinicians from receiving information they need to make timely treatment decisions.

And the problem doesn't always start with a cyberattack. A cloud provider might experience a technical failure, network disruption, or configuration error that interrupts service.

Manufacturers need to consider how their devices behave when cloud services become unavailable. Can the device continue operating safely? Is information stored locally until the connection returns? Will users know something is wrong?

These are cybersecurity availability questions that belong in the device's risk assessment.

Third-Party Software and Configuration Problems

Here's another complication for manufacturers: They don't necessarily control every piece of software their cloud-connected devices depend on.

Cloud providers, software vendors, and other third parties may supply components that support device operations. Those components can contain vulnerabilities, and updates or configuration changes can introduce new ones.

For example, a cloud service update could affect an API connection. An improperly configured database might expose patient information. And an outdated software library could give attackers an opening.

Manufacturers can't assume a third-party provider has addressed every risk. They need to understand which external components their devices depend on, monitor relevant vulnerabilities, and evaluate changes that could affect device safety or effectiveness.

What does FDA expect for cloud-connected medical devices?

You might expect FDA (in accordance to FDA cybersecurity guidance) to have a separate set of cybersecurity rules for medical devices that connect to the cloud. It doesn't quite work that way.

FDA's February 2026 cybersecurity guidance explains the agency's recommendations for medical device security, including devices that connect to the cloud. Manufacturers need to consider the risks associated with their devices, including the cloud services, software, and network connections those devices depend on.

There's also Section 524B of the Federal Food, Drug, and Cosmetic Act. It establishes cybersecurity requirements for devices that meet the law's definition of a cyber device. Not every cloud-connected product automatically falls into that category.

The distinction matters. Section 524B establishes legal requirements for covered devices, while FDA's guidance provides recommendations for demonstrating how manufacturers address cybersecurity risks.

Here's how FDA cybersecurity requirements for cloud-connected medical devices affect manufacturers.

Security architecture and threat modeling

FDA recommends documenting how a device's systems connect and where cybersecurity threats could enter.

For cloud-connected medical devices, that means looking beyond the hardware. Manufacturers need to understand how information moves between the device, cloud platform, mobile applications, and other connected systems.

Threat modeling helps identify what could go wrong along those paths. Could someone intercept patient data? Gain unauthorized access to a cloud service? Change information before it reaches a clinician?

The security architecture should show the relevant components, connections, and security controls. The threat model then helps explain which risks those controls are intended to address.

Cybersecurity risk assessment

Finding a vulnerability is one thing. Figuring out what it could mean for a patient is another.

FDA recommends evaluating cybersecurity risks based on exploitability and the potential severity of harm. A weakness that exposes information may have different consequences from one that allows an attacker to interfere with treatment.

Consider a cloud-connected monitoring device. If an attacker changes a patient's readings, could a clinician make the wrong treatment decision?

Manufacturers need to assess these possibilities, determine whether existing security controls adequately address the risks, and document their conclusions. That's an important part of cloud-connected medical device cybersecurity.

Software bill of materials (SBOM)

An SBOM is essentially an inventory of software components used in a medical device.

Why does FDA care? Because manufacturers need to know which software components could be affected when a new vulnerability is discovered.

Section 524B requires an SBOM for covered cyber devices, including commercial, open-source, and off-the-shelf software components.

Cloud-connected devices add another consideration. Manufacturers also need to understand relevant external software and cloud dependencies, even when those services aren't components that belong in the device's SBOM.

That distinction helps manufacturers track vulnerabilities without confusing the device's software inventory with every service it communicates with.

Security verification and validation

It's not enough to describe how a device is supposed to resist cyberattacks. Manufacturers also need evidence that their security controls work.

FDA's guidance recommends cybersecurity verification and validation activities, including security requirements testing, vulnerability testing, and penetration testing.

For cloud-connected devices, the appropriate testing scope may include authentication, APIs, encrypted communications, software updates, and interfaces with cloud services.

Testing should also consider what happens when connections fail or services become unavailable.

The goal is to show that cybersecurity risks have been addressed through documented controls and supporting evidence, not simply that the device passed a security scan.

How cloud connectivity changes cybersecurity testing

Testing a medical device's software is one thing. Testing everything that happens when the device connects to the cloud is another.

A device might pass its internal security tests and still have vulnerabilities in the systems it communicates with. An insecure API, weak authentication, or poorly configured cloud service could give attackers access to information or functions that should be protected.

For cloud-connected devices, cybersecurity testing should consider several areas:

• Authentication and access controls: Can unauthorized users access patient information or device functions?
• API security: Can attackers manipulate requests or retrieve information they shouldn't see?
• Data transmission: Is sensitive information protected as it moves between the device and the cloud?
• Cloud configuration: Could incorrect security settings expose data or services?
• Software updates: Can the device verify that updates are authentic and haven't been altered?
• Service interruptions: What happens when the cloud connection fails? Can the device continue operating safely?

The testing scope depends on the device's architecture and how it is used. Medical device penetration testing can help manufacturers find exploitable weaknesses across the device and its connected systems before those weaknesses affect patients.

What cybersecurity documentation does FDA expect?

Finding and fixing cybersecurity weaknesses is important, but FDA also wants to see the evidence behind that work. That's where medical device cybersecurity documentation becomes involved.

For cloud-connected medical devices, that means documenting more than what's happening inside the device. Manufacturers need to account for relevant cloud services, network connections, and third-party software that could affect device safety or effectiveness.

FDA's February 2026 cybersecurity guidance recommends several types of documentation. These include security architecture views, threat models, cybersecurity risk assessments, and security testing results. Section 524B also establishes requirements for covered cyber devices, including an SBOM and plans for monitoring and addressing vulnerabilities.

Connecting security evidence to the actual device

Here's where manufacturers can run into trouble. Their threat model identifies a potential attack through a cloud API, but their testing report only covers the device's embedded software.

That leaves a question FDA reviewers may ask: What happened to the API risk?

The documentation needs to tell a consistent story. If a threat model identifies a vulnerability, the risk assessment should explain its potential consequences. The security architecture should identify relevant controls, and testing evidence should show whether those controls work.

Manufacturers should also document important cloud dependencies and explain how they'll manage vulnerabilities after the device reaches the market.

The goal isn't to produce more paperwork. It's to make sure reviewers can follow the engineering decisions from the identified risk through its mitigation and verification.

CyberMed's FDA cybersecurity documentation services help manufacturers organize this evidence, identify gaps, and prepare cybersecurity documentation for regulatory submissions.

What happens when the cloud environment changes?

Here's something manufacturers can't overlook: The cloud environment they tested before an FDA submission may not be the same one their device uses six months later.

Cloud providers regularly update software, change configurations, and introduce new features. Sometimes those changes happen without the medical device manufacturer initiating them.

Most changes won't create a problem. But some could affect how the device communicates, stores information, or protects patient data.

A cloud update might change an API connection, for example. Or a new software vulnerability could expose information that was previously protected.

That's why manufacturers need to think about medical device cloud security as an ongoing responsibility, not just something to address before submitting a device to FDA.

Managing cloud changes after market release

Once a device is on the market, manufacturers need a process for keeping track of changes that could affect its security.

That includes monitoring newly discovered vulnerabilities, evaluating cloud software updates, and communicating with third-party providers when changes affect connected systems.

Manufacturers should also determine whether a change requires additional testing or updates to their cybersecurity documentation.

Not every cloud update requires a new FDA submission. The answer depends on what changed and whether the modification triggers applicable regulatory requirements.

The important thing is to evaluate the change, document the decision, and make sure the device continues operating safely.

How CyberMed helps manufacturers secure cloud-connected devices

Cloud-connected medical devices present a challenge for manufacturers. They need to secure the device, understand the systems it depends on, and produce cybersecurity evidence that supports FDA review.

CyberMed helps manufacturers address these responsibilities through several services:

• Security architecture and threat modeling: Identifying cloud connections, potential attack paths, and security controls that protect device functions and patient information.
• Cybersecurity risk assessment: Evaluating vulnerabilities and determining how they could affect device safety and effectiveness.
• Penetration testing: Looking for exploitable weaknesses in the device and the connected systems included in the testing scope.
• FDA cybersecurity documentation: Preparing security architecture views, risk assessments, testing evidence, and other documentation needed to support regulatory submissions.
• Postmarket cybersecurity planning: Helping manufacturers establish processes for monitoring vulnerabilities, evaluating changes, and maintaining security after release.

Whether a manufacturer is preparing its first FDA submission or reviewing an existing cloud-connected product, CyberMed can help identify gaps in its cybersecurity work and determine what needs attention.

Conclusion: cloud security is part of medical device security

Connecting a medical device to the cloud offers real benefits, but it also introduces cybersecurity risks that manufacturers can't ignore.

FDA expects manufacturers to address risks that could affect device safety and effectiveness, including those involving relevant cloud services and external connections.

That means understanding the device's architecture, testing its security controls, documenting the results, and keeping up with changes after release.

The cloud may be outside the manufacturer's building, but the cybersecurity responsibilities don't stop there.

Need help building the software or cybersecurity package? See our FDA cybersecurity documentation service, our software DHF service, or email us at info@cybermed.ai.

Sources

• FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. February 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-management-system-considerations-and-content-premarket
• FDA. Cybersecurity in Medical Devices: Frequently Asked Questions. https://www.fda.gov/medical-devices/digital-health-center-excellence/cybersecurity-medical-devices-frequently-asked-questions-faqs
• FDA. Off-The-Shelf Software Use in Medical Devices. August 2023. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/shelf-software-use-medical-devices
• FDA. Cybersecurity. https://www.fda.gov/medical-devices/digital-health-center-excellence/cybersecurity