Skip to Content

Connected Medical Devices and Public Cloud Services

November 17, 2022  •  Blog  •  Jennifer Moyer
Posted In Other News & Insights, Medical Device News & Insights – Biologics Consulting  •  Tagged cloud computing, validated state, quality system, software

Public cloud computing services are being increasingly used by medical device manufacturers to house components of medical device software. In this post, I am referring to a public cloud as defined by NIST SP 800-145:2011, The NIST Definition of Cloud Computing, and their “platform-as-a-service (PaaS)” model. The definitions of both are provided below.

Public cloud: The cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider.7

Platform as a Service (PaaS): The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosted environment.7

Today, there are a number of popular PaaS providers such as Amazon Web Services, Microsoft Azure, and Google Cloud. The advantages of using public cloud computing services are many: accessibility, scalability, security, reliability, and performance at manageable costs compared to hosting software in a company data center.

But what are the risks that manufacturers face when putting regulated software into a public cloud environment where the manufacturer has no control over the underlying cloud infrastructure?

For software used in a medical device, 21 CFR 820.30(g) Design Controls, states that “Design validation shall include software validation and risk analysis, where appropriate.”2

Further, the 2002 FDA guidance document, General Principles of Software Validation, outlines the traditional manner in which manufacturers can “ensure compliance with the Quality System regulation with regard to software validation.”5 As noted in section 3.1.2 of that guidance, FDA considers software validation to be “confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled.”5 This presumes, however, that the manufacturer is maintaining control over all aspects of the software system, even after it has been deployed.

In addition, the quality system regulation, 21 CFR 820.70(i), Automated processes, states that:

When computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol. All software changes shall be validated before approval and issuance. These validation activities and results shall be documented.1

So now we get to the question: how does a manufacturer maintain the validated state of their device software when it is hosted on computers that are not under their control? After all, there is a risk that the server host may alter their software to the point where a manufacturer’s hosted software no longer operates as intended; it can no longer be considered validated and falls out of compliance. A complicating factor is that in order to document validation activities for the quality management system, the manufacturer would – ideally – be able to obtain a detailed list of what has changed and conduct validation testing prior to the changes being deployed. But realistically, how often does that happen and what steps can a manufacturer take to proactively ensure the validated state of their software?

Fortunately, some basic guidance exists in the form of an industry-authored consensus report published by the Association for the Advancement of Medical Instrumentation (AAMI), AAMI CR510:2021, Appropriate Use of Public Cloud Computing For Quality Systems And Medical Devices. The report introduces the concept of “intermittently validated state” which means adding a layer of risk mitigations that would lower the risk that changes in the cloud server would impact the manufacturer’s device software in between validation activities.3

The report contains six recommended approaches to assessing and managing the risk associated with using a public cloud computing platform; a high-level summary is listed below.

  1. Start with the development of the requirements for the device, consider if those requirements might function differently in a cloud environment, and assess the risks based on the device software technical needs.
  2. Consider the following items: risks to safety, efficacy, availability, efficiency, effectiveness, security, and privacy should the device software get “broken” following a cloud service software update deployment; whether or not the manufacturer has any control on the updates deployed; and if the cloud service has external dependencies that might impact the manufacturer’s device software risk profile.
  3. Consider how often the cloud service issues software updates and whether or not the service provider will communicate those changes or if it is incumbent on the manufacturer to test periodically to find them. Establish a plan for revalidation frequency that is related to the possible risks introduced by the service provider updates.
  4. Consider whether or not the service provider processes might negatively impact the device software.
  5. Have a plan in place in the event that the service provider’s update does negatively impact the device software.
  6. Develop a means to detect service provider software updates and to assess the impact of those updates.

Readers interested in additional details should consult AAMI CR510 for more information.

FDA has also put out a draft guidance document that also sheds some light on software assurance: Draft Guidance: Computer Software Assurance for Production and Quality System Software: Draft Guidance for Food and Drug Administration Staff4. That draft document is intended to supplement the General Principles of Software Validation; it will also replace section 6 of that document. The draft guidance serves to provide manufacturers with clarity around the FDA expectations for computer software validation and automated data processing systems that are used as part of a quality or production system. Readers are cautioned that this guidance is not final and is subject to change.

Other concerns that we have seen raised by the FDA involve situations where a device relies on connectivity to the cloud service to perform aspects of the device’s intended use. FDA recommends that manufacturers implement device features that protect critical functionality in the event that, as an example, the cloud service provider is rendered inaccessible due to a hack or other online attack. In those instances where compromise of the data, software, or keys could impact the safety or effectiveness of the medical device, FDA has asked for:

  • Threat modeling and a risk assessment for the connection to the cloud service provider. A description regarding the extent to which the data is protected by the manufacturer. And a discussion of the service level agreement with the cloud service provider.
  • A description of the application programming interface (API) and manufacturer-developed software or services that reside in the cloud that are the responsibility of the manufacturer to design and secure. This includes a description of the API, and whether or not the system will use cloud provider services such as load balancing, key management services, etc. and if those services impact security in any way. Provide a description of the update process and controls for those aspects of the system.
  • A description of cybersecurity techniques that will maintain and improve the security posture of the software (e.g., using Amazon Virtual Private Clouds to segment into isolated components to reduce ransomware’s ability to spread).
  • All known vulnerabilities with the cloud-based API, software, and services used by the system, including an assessment of any applicable vulnerabilities that can be found in the NIST National Vulnerability Database.6

Obviously the above is not a comprehensive list of items that a manufacturer should be concerned about when designing a medical device system that will reside on a public cloud server; it can be considered a starting point, however.

Additional recommended reading:

Anselmo, C., Attili, M., Horton, R., Kappe, B., Schulman, J., Baird, P. (January 19, 2021). Hey You, Get On the Cloud: Safe and Compliant Use of Cloud Computing with Medical Devices. AAMI Biomedical Instrumentation & Technology. Vol. 55, Issue 1.

Maeder, T., and Horton, R., December 16, 2020. Connected Medical Devices & the Cloud: Delivering Validated States, Safety & Compliance on Continually-Evolving 3rd Party Platforms. MedTech Intelligence Webinar. Last accessed October 6, 2022 at

Miller, M., Zaccheddu, N. (2021). Light for a Potentially Cloudy Situation: Approach to Validating Cloud Computing Tools. AAMI Biomedical Instrumentation & Technology.


  1. 21 CFR 820.70, Production and Process Controls. (n.d.). Retrieved from U.S. Food and Drug Administration:
  2. 21 CRF 820.30, Design Controls. (n.d.). Retrieved from U.S. Food and Drug Administration:  
  3. AAMI CR510:2021, Appropriate Use Of Public Cloud Computing For Quality Systems And Medical Devices. (2021). Purchase from:  
  4. Computer Software Assurance for Production and Quality System Software: Draft Guidance for Industry and Food and Drug Administration Staff. (2022, September 13). Retrieved from U.S. Food and Drug Administration:
  5. General Principles of Software Validation: Final Guidance for Industry and FDA Staff. (2002, January 11). Retrieved from U.S. Food and Drug Administration:
  6. National Vulnerability Database. (n.d.). Retrieved from National Institute of Standards and Technology:
  7. NIST SP-800-145, The NIST Definition of Cloud Computing. (2011, September). Retrieved from National Institute of Standards and Technology: