When your SaMD fails audit because of a security patch

Written by HATEM RABEH, MD, MSc Ing

Your Clinical Evaluation Expert And Partner

in
S

This happens more often than most teams expect. Software as a Medical Device brings a regulatory reality that traditional hardware does not face: the clinical performance you validated last year might change next month because of a security patch, an OS update, or a vulnerability disclosure.

And when that happens, your clinical evaluation is no longer current.

The regulatory framework does not separate clinical and security

MDR Article 61 requires manufacturers to demonstrate safety and performance based on clinical evidence. MDCG 2020-1 reinforces that clinical evaluation must address all risks, including those related to cybersecurity, when they affect clinical safety or performance.

This is not a theoretical connection. If a security vulnerability can alter the output of your device, change the accuracy of a measurement, delay a critical alert, or expose patient data in a way that affects clinical decisions, then it is a clinical risk.

Your clinical evaluation report must reflect that.

But most manufacturers treat cybersecurity as an ISO 14971 topic handled by the risk management team. The clinical evaluation team rarely sees the cybersecurity documentation. The connection is not made until the Notified Body asks the question.

Why this matters more for SaMD than for hardware

A pacemaker changes slowly. Its design is locked. Its clinical performance is validated once and remains stable for years unless there is a field safety corrective action.

Software is different. It runs on platforms you do not control. It integrates with third-party libraries. It depends on operating systems that receive updates outside your release cycle. A Windows patch, an API change, a deprecated protocol can all affect functionality.

And if functionality changes, performance might change. If performance changes, clinical safety might change. If clinical safety changes, your clinical evaluation is no longer valid.

This is not hypothetical. I have seen devices where a browser update changed how data was displayed, affecting interpretation. I have seen diagnostic algorithms that performed differently after an OS security patch altered floating-point precision. I have seen notification systems that stopped working because a third-party authentication service changed its API.

None of these were caught during routine post-market surveillance because they were not classified as complaints. They were discovered during audits or field observations.

The clinical evaluation must anticipate change

Your CER cannot assume the software remains static. MDCG 2020-1 requires that the clinical evaluation addresses the entire lifecycle, including foreseeable changes. For SaMD, this includes cybersecurity updates.

Here is what that means in practice:

First, your clinical evaluation plan must define how cybersecurity risks are monitored and how changes to those risks trigger reassessment of clinical safety and performance. This cannot be vague. It must specify who reviews security bulletins, who assesses clinical impact, and what threshold triggers an update to the CER.

Second, your State of the Art analysis must include the evolving cybersecurity landscape. If your device processes sensitive health data, the current best practices for encryption, authentication, and access control are part of the State of the Art. If those practices change, your device might fall behind.

Third, your PMCF plan must include active monitoring of cybersecurity incidents and patches. This is not just about logging complaints. It is about tracking every security update, every vulnerability disclosure, and every patch applied to assess whether clinical performance was affected.

What Notified Bodies look for

When a Notified Body reviews a SaMD clinical evaluation, they check whether the manufacturer understands that software changes over time. They look for evidence that the clinical evaluation process accounts for this.

Here are the questions they ask:

Does the CER reference the cybersecurity risk analysis? Is there a clear link between identified vulnerabilities and potential clinical impact? If a vulnerability was found and patched, did the manufacturer reassess whether the patch affected performance?

Is the PMCF plan designed to capture security-related performance issues? Does it include monitoring of security bulletins, incident reports, and third-party dependency updates?

When a major update is applied, such as a migration to a new OS version or a switch to a new encryption standard, is there a process to reassess clinical equivalence and performance data?

Most manufacturers cannot answer these questions clearly. The cybersecurity team works in parallel to the clinical team. The risk file is updated. The CER is not.

The hidden risk of third-party dependencies

Many SaMD devices rely on third-party software components. Cloud platforms. AI frameworks. Database engines. Authentication services. These dependencies introduce a risk that most clinical evaluation reports ignore.

If a third-party library is updated and the manufacturer does not control the update schedule, the clinical performance of the device can change without a formal design change. The manufacturer might not even notice until a user reports unexpected behavior.

MDCG 2019-16 on cybersecurity emphasizes that manufacturers must maintain awareness of vulnerabilities in all software components, including third-party dependencies. But awareness is not enough. If a vulnerability or a patch affects clinical output, the clinical evaluation must be updated.

This is where the regulatory expectation becomes difficult to meet. You cannot freeze your software environment forever. You cannot ignore security patches. But every patch is a potential clinical change.

The only way to manage this is to build the reassessment process into your quality system. Every patch. Every update. Every dependency change gets reviewed for clinical impact. If impact is identified, the CER is updated. If not, the review is documented.

The practical challenge of maintaining current clinical evaluation

The regulatory expectation is clear. The practical execution is difficult. Most manufacturers do not have the resources to reassess clinical data after every security patch. Most clinical teams do not have visibility into the cybersecurity update schedule.

So what can you do?

Start by creating a formal link between your cybersecurity risk management process and your clinical evaluation process. When a vulnerability is identified or a patch is planned, the cybersecurity team must notify the clinical team. The clinical team reviews whether the change could affect safety or performance. If yes, reassessment is triggered. If no, the decision is documented.

This does not require a full CER update after every patch. It requires a documented assessment. Most of the time, the answer will be no impact. But when impact is identified, you need to act quickly.

Second, structure your PMCF plan to capture cybersecurity-related performance issues. This means defining specific data points related to security events, such as device downtime due to patches, performance degradation after updates, or user-reported issues following infrastructure changes.

Third, plan for major updates. When you migrate to a new platform, update a core dependency, or implement a significant security enhancement, treat it as a design change. Reassess clinical equivalence. Update the CER. Do not assume that clinical performance remains unchanged.

Why this matters now more than before

The regulatory pressure on cybersecurity is increasing. MDCG 2019-16 made cybersecurity a central part of the risk management process. The new EU Cyber Resilience Act will add further requirements. Notified Bodies are trained to look for gaps between cybersecurity documentation and clinical evaluation.

And as software becomes more complex, the risk of security-related clinical impact grows. AI-driven devices depend on data pipelines that can be disrupted by security measures. Cloud-based devices depend on infrastructure that changes regularly. Mobile apps depend on OS features that evolve rapidly.

If your clinical evaluation process does not account for this reality, you will face deficiencies. Not because your device is unsafe. But because your documentation does not demonstrate that you understand how cybersecurity affects clinical performance.

This is the unexpected intersection. Cybersecurity is not separate from clinical evaluation. It is part of it. And manufacturers who do not integrate the two will struggle to maintain compliance as software evolves.

Peace,
Hatem
Clinical Evaluation Expert for Medical Devices
Follow me for more insights and practical advice.