Why is cybersecurity within an QMS important?

In recent years, cybersecurity has evolved from a purely technical issue into a critical success factor for companies—particularly in highly regulated sectors such as healthcare and the medical device industry. Increasing digitalisation, connected devices, and globally accessible software services continuously expand the potential attack surface.

The figures speak for themselves: the number of cyberattacks has been rising steadily for years, and the financial impact is significant. According to IBM’s Cost of a Data Breach Report, the average cost of a data breach in Germany is around €3.87 million per incident. These costs arise not only from immediate technical disruption, but also from production downtime, recovery efforts, reputational damage, and potential regulatory consequences.

From a regulatory perspective, clear signals are emerging: the proposed revision of the MDR aims to explicitly anchor cybersecurity within the General Safety and Performance Requirements (GSPRs). However, even under the current MDR framework, cybersecurity is already addressed indirectly—particularly in areas such as software, interoperability, risk management, and patch management processes (see figure).

However, cybersecurity is not merely a matter of software updates or network perimeter controls. It is inherently interdisciplinary: development processes, risk management, supplier controls, clinical evaluation, production environments, support structures, post-market surveillance, and training across the organisation all play a role. A holistic approach is therefore essential to ensure product security throughout the entire lifecycle. International authorities such as the FDA emphasise this concept, referring to the “Secure Total Product Life Cycle” (sTPLC). This denotes a comprehensive, continuous security approach that extends from design, development, and production through to use and maintenance. Security is therefore not a one-time project, but an ongoing process.

Regulatory requirements for cybersecurity

Cybersecurity is no longer merely a technical concern; it has become a regulated quality and safety attribute. Regulatory authorities worldwide are responding to the evolving threat landscape by establishing binding requirements that manufacturers must address throughout the entire product lifecycle. For companies—particularly in the medical technology and healthcare sectors—this means that cybersecurity is becoming an integral part of the compliance framework and, therefore, an essential element of the quality management system:

  • A key European regulatory framework is the Cyber Resilience Act (CRA). This regulation applies to products with digital elements, regardless of whether they are classified as medical devices. As a result, a wide range of consumer and industrial applications—such as apps, software tools, and connected devices—fall within its scope. The CRA aims to establish binding baseline security requirements, promote “security by design,” and ensure cybersecurity is maintained throughout the product lifecycle.
  • Within the MDR framework, MDCG 2019-16 provides important guidance. This document outlines how manufacturers can meet relevant requirements of Annex I of the MDR and IVDR with regard to cybersecurity. It effectively bridges general regulatory requirements and practical implementation within the QMS.
  • At the level of standardisation, several specialised standards and technical reports provide concrete processes for manufacturers. AAMI TIR57:2016 is particularly relevant, as it is structurally aligned with ISO 14971 and defines a dedicated process for managing cybersecurity risks. This close alignment facilitates the integration of safety and security within a unified risk management system.
  • For post-market activities, AAMI complements TIR57 by providing methods for assessing and managing cybersecurity risks in the field. Embedded within the established safety framework of ISO 14971, it highlights that cybersecurity does not end with market approval—it continues throughout the product’s operational lifetime.
  • Another key standard is ANSI/AAMI SW96:2023, which defines binding requirements for the cybersecurity risk management of medical devices and expands the content of TIR57 to include specific minimum requirements. This provides manufacturers with a clear framework that both fulfils regulatory requirements and facilitates practical implementation in the development process.
  • For software manufacturers, IEC 81001-5-1:2021 is of central importance. This standard defines requirements for secure software lifecycle processes and is in line with IEC 62443-4-1, but takes into account the specific needs of health software. It provides a standardised basis for processes, activities and tasks that are necessary to develop and maintain safe software in the long term.
  • The FDA has also set clear expectations. In its guidance “Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions,” it outlines cybersecurity expectations for the QMS and the content expected in premarket submissions. In addition, the guidance “Postmarket Management of Cybersecurity in Medical Devices” describes how manufacturers should monitor, assess, and address cybersecurity risks after market entry.

Overall, a clear consensus is emerging across authorities and regions: cybersecurity is not an optional add-on, but an integral component of design, risk management, quality management, and post-market activities. Manufacturers who integrate these aspects into their processes early not only reduce regulatory risk, but also enhance the safety and trustworthiness of their products.

Cybersecurity across all processes

In many companies, cybersecurity is still primarily seen as a task for software development or IT infrastructure. However, this narrow view can cause important security-relevant aspects to be overlooked. Modern threat scenarios and regulatory requirements make it clear that cybersecurity is an organisation-wide issue that extends far beyond the source code. It affects every department, every process, and every phase of the product lifecycle.

In the development process, cybersecurity begins with the initial product concept. Architectural decisions, technologies used, threat analyses, and risk assessments have a long-term impact on the security of the end product. The supply chain also plays a crucial role: even the procurement of components, software libraries, or cloud services can introduce risks that need to be carefully assessed and monitored. Manufacturers are increasingly required to systematically audit their suppliers and contractually commit them to security compliance.

Security-critical points of contact also arise in production: production lines, test benches, or automated test systems are often connected and therefore potential gateways. Manipulated test environments or compromised production data can lead to faulty or unsafe products going unnoticed. Cybersecurity must therefore also be integrated into production and quality assurance processes so that test benches, firmware tools, and configuration data remain protected against unauthorised access.

The delivery and deployment of a product also require special attention. Whether installation packages, configurations, or update mechanisms, if these are not designed securely they can provide attackers with an easy path to introduce malware or compromise systems. “Secure deployment” therefore includes technical measures such as signatures and validation, as well as organisational controls to ensure the secure handling of software and hardware.

Post-market surveillance and vigilance come into focus after market entry. Attacks, vulnerabilities, and incidents must be monitored, analysed, and prioritised. The interaction between PMS, incident management, and security risk management forms the basis for continuous improvement.

Change management plays a key role: any change to the product—from software updates to process adjustments—should be assessed from a security perspective to identify and address new risks early.

The end of the product lifecycle—decommissioning—is also security-relevant. Devices that are not properly wiped, reset, or documented may retain sensitive data or provide exploitable access points. A controlled decommissioning process helps prevent data leakage and reduces the risk of misuse.

This makes it clear that cybersecurity is not an isolated activity, but a common thread that runs through the entire organisation. Security awareness, clear responsibilities, and integrated processes are crucial to meet growing regulatory and technical expectations and to ensure a secure product lifecycle.

Practical example 1: Change management

A practical example from day-to-day operations illustrates particularly clearly how closely cybersecurity is linked to, for example, change management. The process typically starts inconspicuously: a customer complaint is received. Customers often describe only functional issues, such as a device responding slowly, crashing intermittently, or behaving unusually. However, such symptoms may indicate more serious underlying causes—for example, malware, a denial-of-service attack, or another security-relevant incident. A trained and sensitised service team is essential for early detection.

The service department performs the initial assessment and must be able to correctly interpret indications of potential security incidents. If such a risk is suspected, software and, where relevant, hardware teams should be involved to conduct a technical analysis. If the suspicion of a cybersecurity incident is confirmed, the incident response plan must be activated without delay. This ensures that all required steps are coordinated and documented, and that the risk of further impact is minimised.

Depending on the severity of the issue, it may be necessary to initiate a CAPA process. It is crucial that criteria for assessing security-relevant criticality are considered systematically. Cybersecurity should therefore be firmly embedded in the CAPA process so that root cause analysis, action planning, and effectiveness verification address not only functional aspects, but also security-relevant aspects.

The issue is resolved through close collaboration between the involved teams. Any technical changes must be developed, implemented, and appropriately verified and validated. For security-critical modifications, it may be necessary to repeat penetration testing for the affected system components to ensure that changes do not introduce new vulnerabilities and that the intended security level is maintained over time.

Once an effective solution is available, transparent communication with customers is essential. At this stage, affected users must be informed and provided with the necessary updates, mitigations, or instructions. Clear, timely communication supports effective risk reduction in the field.

However, the process does not end with the rollout of the corrective measure. The effectiveness of the implementation must be monitored under real operating conditions to identify any unforeseen effects and to support sustained effectiveness over time.

Practical example 2: Firmware update in production

A firmware update in production may initially appear to be a routine step. However, particularly in early-series production—such as the 0 series—it becomes evident how critical secure production processes are for a product’s cybersecurity. In this practical example, production comes to a complete standstill when the first firmware is to be installed on the devices. The root cause was not the firmware itself, but a combination of organisational and technical deficiencies.

The production environment was not adequately protected against unauthorised access, allowing an attacker to gain access to the systems—a risk that may be underestimated in many production settings. In addition, access control was insufficient: the production computers did not require user authentication. As a result, anyone with physical access could directly access and potentially manipulate production-critical systems.

This was compounded by insecure work practices. The USB stick containing the firmware was left openly on the workbench. Without traceability or physical safeguards, it could have been replaced with a manipulated device. Such scenarios are observed in practice and illustrate the importance of secure handling procedures.

A further contributing factor was the update execution system, which lacked input validation. It accepted any file provided to it, regardless of content, format, or integrity. This enabled an attacker to introduce malware, which was executed unnoticed and subsequently disrupted the production line. In this way, a single compromised data path was sufficient to turn a simple firmware update into a serious security incident.

This example illustrates that cybersecurity in production involves more than protecting individual components. It requires a combination of technical controls (e.g., signatures, validation, and access rights) and organisational measures (e.g., secure workflows, clear responsibilities, and staff awareness).

Conclusion

Cybersecurity has long been a central component of modern quality management systems. Increasing connectivity, stricter regulatory requirements, and an evolving threat landscape make it clear that security can no longer be treated as an isolated IT or software topic. Instead, it must be understood as a holistic organisational responsibility that spans all processes—from development and production to service and monitoring in the field.

The practical examples show how differently security risks can manifest and how important it is for teams to be trained and prepared across departments. Whether analysing a customer complaint or handling firmware updates in production, any weakness in the process can become a critical gateway if cybersecurity is not consistently considered.

Regulatory requirements such as the CRA, MDR guidance, and FDA guidance reinforce this trend. They require not only technical protective measures, but also documented and traceable processes that support a secure product lifecycle. Although this creates additional effort for companies, it is also an opportunity: organisations that systematically and proactively embed cybersecurity in their QMS not only increase the security of their products, but also strengthen trust among users, authorities, and partners over the long term.

A holistically understood and practised approach to cybersecurity is therefore a key success factor for the future—technologically, organisationally, and regulatorily.