What impact will the new EU law have on medical devices, accompanying apps and cloud services?

Introduction

Digitalization in the healthcare sector is growing rapidly. More and more processes, devices and applications are being networked or moved to the cloud. At the same time, data protection and cyber security requirements are increasing. Not only patient data is particularly worth protecting – attacks on medical systems can also cause life-threatening situations.

Until now, medical devices in the EU have primarily been subject to the Medical Device Regulation (MDR) and (where relevant) other standards, such as IEC 81001-5-1, which specifically regulates cyber security requirements for medical software. With the new Cyber Resilience Act (CRA), the EU is now creating a further, far-reaching level of regulation. Interestingly, although medical devices themselves are exempt from the CRA because they are already regulated by the MDR and IVDR, the CRA applies to digital components, services and applications that are not medical devices as defined by the MDR/IVDR – and this increasingly affects the healthcare sector.

In this blog post, we take a look at what the Cyber Resilience Act regulates, why it has a significant impact on manufacturers in the healthcare market despite the exclusion of medical devices and how it interacts with other directives such as NIS2 or US requirements. In addition, we provide a compact checklist that shows what companies should pay attention to now.

What is the Cyber Resilience Act?

The Cyber Resilience Act (CRA) is a planned EU law that aims to drastically increase the cyber security of products with digital elements. These include:

  • Software (e.g. apps, operating systems, communication applications)
  • IoT devices (e.g. smart wearables, networked household appliances)
  • Industrial controllers that have direct or indirect Internet connections

The aim of the CRA is to define uniform minimum standards for IT security throughout the entire product life cycle: from development (“security by design”) to market launch and operation through to patch and update management. In concrete terms, this means for manufacturers:

Commitment to safety measures

Products with digital elements must comply with certain basic standards, such as secure communication, encrypted data transmission and mechanisms to defend against typical threats (e.g. SQL- injectionsDDoS attacks).

Transparency about security gaps

Processes must be established to promptly rectify identified vulnerabilities. Security vulnerabilities must be disclosed, e.g. to authorities and users.

Uniform CE marking for networked products

Compliance with the CRA requirements is integrated into the CE marking. Anyone who places their products on the market in the EU without meeting the CRA requirements risks severe penalties.

Life cycle approach

The manufacturer’s responsibility does not end with the sale, but includes a defined period during which security updates must be provided. The transition phase after the CRA comes into force is expected to last several years. It is currently expected to come into force in 2024 and last around 36 months, which could mean full compliance from around 2027.

The CRA is thus responding to the high number of cyberattacks associated with the increased use of digital technologies and networked devices. For manufacturers in all sectors – but especially in the healthcare sector – the law creates a binding framework for greater cyber security.

BAYOOMED-Cyber_Resilience_Act

Significance for the healthcare sector

Although medical devices (e.g. certified surgical robots, implants, insulin pumps) are excluded per se from the scope of the CRA because they are already comprehensively regulated by the MDR, IVDR and standards such as IEC 81001-5-1, the new law nevertheless has a considerable pull effect on the healthcare sector. Why?

Companion apps and cloud services

Many medical devices use additional apps or cloud components that are not themselves medical devices. It is precisely these parts that fall under the CRA because they are “products with digital elements” and are not already covered by the MDR within the meaning of the law.

  • Example: Insulin pumps are classified as medical devices and must comply with MDR/IVDR. However, the associated app for dosage control or evaluation of measured values may not be a medical device. It is therefore subject to the CRA.

Devices used in the hospital environment

Networked devices (e.g. telemedicine platforms, patient apps) can be covered by the CRA obligation if they are essential for operation but do not legally comply with medical device status.

Link with NIS2

The revised NIS2 Directive forces operators of critical infrastructures (including the healthcare sector and hospitals) to meet higher security standards. Anyone supplying devices or software (under CRA) to such institutions must provide the required standards and documentation. This is the only way for hospitals to ensure their own NIS2 compliance.

Data security and patient well-being

In view of the sensitive nature of healthcare data and the high risk of cyberattacks, it is essential for manufacturers and operators to work closely together and exchange information on cybersecurity measures – regardless of whether the respective application is “only” covered by the CRA or “also” by the MDR.

Medical devices (as defined by the MDR/IVDR) already have strict requirements for cyber security. IEC 81001-5-1 specifies these requirements for software by providing a standardized framework for risk management and technical protective measures. Manufacturers must therefore prove that their medical devices are secure and can be protected against tampering or data leaks, for example.

CRA: “Expansion” of the regulatory spectrum

The Cyber Resilience Act comes into play when digital functions or systems do not fall within the scope of the MDR. Instead, the uniform requirements of the CRA now apply. In certain aspects, the CRA can even go beyond the MDR requirements, for example when it comes to reporting security vulnerabilities to authorities or regular patch management.

Practical example:

Companion app for data evaluation on the smartphone:

Subject to the CRA as it is not a medical device itself.

Cloud backend for medical software

Rather CRA-relevant if no medical device status exists.

 

NIS2 for operators and manufacturers

The NIS2 Directive, updated in 2023, strengthens cybersecurity in critical infrastructures (including the healthcare sector). Hospitals and other “operators of essential services” must now meet increased requirements for risk analysis, incident management and reporting obligations. To ensure that this works smoothly, manufacturers are required to design their products (whether medical devices or not) to be secure and to provide their customers with sufficient technical information.

A look at the USA: FDA and Co.

In the USA, the FDA (Food and Drug Administration) is a leader in the regulation of cyber Security in the medical device sector. However, there is no direct counterpart to the Cyber Resilience Act. The “U.S. Cyber Trust Mark Act” relies more on voluntary measures and is more focused on the consumer market. International manufacturers must therefore comply with EU requirements (CRA, MDR, IVDR) and US standards (FDA Guidances), provided they operate in both markets.

BAYOOMED-Richtlinien

Consequences for manufacturers of healthcare software

Separate consideration of medical device software and other components

It is crucial to clarify at an early stage which parts of the product (e.g. firmware, app, cloud components) fall under the MDR and which must meet the CRA requirements.

Documentation and reporting obligation

Similar to MDR/IVDR, the CRA requires conscientious documentation of all safety measures. In addition includes regular patch management and reporting relevant security vulnerabilities to authorities and customers.

Risk analysis and “security by design”

Both MDR and CRA require holistic risk assessments: What are the potential vulnerabilities? How can attacks be minimized? Manufacturers must proactively integrate security measures into the development process (“Security by Design”) and configure products securely by default (“Security by default”).

Checklist:
Cyber Security for manufacturers

Threat and risk analysis

Use standardized methods such as STRIDE (to identify different risk types) and CVSS (Common Vulnerability Scoring System) to prioritize vulnerabilities.

Security by Design

Integrate protective measures as early as the design and development phase.

Software Bill of Materials (SBOM)

Keep an inventory of all software components used (open source and proprietary).

CVE Analysis

Check known security gaps at least once a year (preferably monthly) using your SBOM.

Independent penetration tests

Carry out regular pentests by external experts to detect potential weaknesses at an early stage.

Additional meaningful activities

GDPR compliance

Pay attention to the protection of personal data. Cybersecurity and data protection go hand in hand here.

Privacy by Design

Only use the data that you really need and delete superfluous data records early on.

Optimized security concepts

Reduce attack surfaces by minimizing authorizations and interfaces.

Improved management of vulnerabilities

Set up structured update and patch processes in order to be able to react promptly to new threats.

Conclusion and outlook

Although the Cyber Resilience Act formally excludes medical devices that are already regulated by the MDR and IVDR, it is clear that networked software components in the healthcare sector can still fall within the scope of the CRA. Apps, cloud services and peripheral systems in particular, which are used in addition to medical devices, are subject to the strict requirements of the CRA.

This creates an extended regulatory framework that takes account of the increasing cyber threats and promotes a holistic approach to security in the healthcare sector. Companies operating in the healthcare sector should therefore take the following steps at an early stage:

  • Identifywhich parts of their products fall under the CRA and which under MDR/IVDR.
  • Merging requirements into a common compliance and security concept.
  • Exchange with clinics and other operators who have to comply with NIS2 obligations.

With the CRA, the EU is sending a clear signal for more security in networked systems. In view of the transitional period, which is expected to last until 2027, there is still some time – but given the dynamic threat situation, it is worth starting implementation immediately. Only those who think “security by design” today and establish seamless processes will be able to survive in the long term in an environment characterized by an increasing number of guidelines and gain the trust of patients, users and institutions in the long term.

The experts at BAYOOMED and BAYOOCARE support you in the development of your digital health application – from regulatory consulting to post-market surveillance (PMS). Arrange an appointment for an initial consultation.