Most medical device manufacturers arrive at the conformity assessment process expecting a separate cybersecurity checklist, a standalone regulation, or a dedicated standard they can simply tick off. That expectation sets them up for friction. Cybersecurity under the EU Medical Device Regulation (MDR) is not a separate lane. It runs through your entire technical file, your risk management, your quality system, and your post-market obligations. Notified Bodies (NBs) assess it accordingly, and manufacturers who misunderstand this structure consistently encounter delays, nonconformities, and costly remediation cycles.

Table of Contents

• How Notified Bodies approach cybersecurity under EU MDR
• What Notified Bodies look for during conformity assessment
• Testing methodologies required for cybersecurity compliance
• Post-market activities and ongoing NB requirements
• The uncomfortable truth about NB cybersecurity: Why “good enough” isn’t
• How Testvox helps medical device makers meet cybersecurity requirements
• Frequently asked questions

Key Takeaways

How Notified Bodies approach cybersecurity under EU MDR

The first thing to internalize: there is no standalone EU cybersecurity regulation for medical devices. Cybersecurity requirements are embedded in Annex I of the MDR as General Safety and Performance Requirements (GSPRs), particularly GSPR 17.2, which mandates protection against unauthorized access. This architecture means that a cybersecurity gap is simultaneously a safety gap, a regulatory gap, and potentially a clinical risk. Notified Bodies treat it exactly that way.

The primary guidance document shaping NB expectations is MDCG 2019-16. This guidance structures both pre-market and post-market cybersecurity frameworks, and NBs reference it extensively when evaluating technical documentation. The guidance establishes minimum security features that manufacturers must demonstrate: authentication controls, encryption of data in transit and at rest, security logging with tamper resistance, and structured vulnerability monitoring after market launch. It also requires manufacturers to implement coordinated vulnerability disclosure processes, meaning there must be a defined way for external researchers or customers to report discovered vulnerabilities.

Understanding how the EU MDR approach compares to the FDA framework helps clarify what NBs are and are not looking for:

Manufacturers targeting both markets need to understand that the FDA cybersecurity requirements are considerably more prescriptive. The EU approach gives manufacturers more flexibility but also places more responsibility on them to interpret and apply the requirements appropriately within their risk management framework.

Several other standards feed directly into how NBs evaluate cybersecurity:

• ISO 14971: The risk management standard that ties cybersecurity vulnerabilities to clinical harm probability and severity
• IEC 62304: The software lifecycle standard requiring security considerations throughout design, coding, testing, and maintenance
• IEC 62443: The industrial cybersecurity standard increasingly referenced for networked medical devices
• Post-market surveillance (PMS) regulation: Ongoing obligations to monitor field data, complaint trends, and newly discovered vulnerabilities

“Notified Bodies do not evaluate cybersecurity as a separate checklist item. They look at how cybersecurity is woven into risk management decisions, software development practices, and post-market monitoring systems.”

The harmonization of NB cybersecurity requirements across European NBs is an active and evolving process. Manufacturers should not assume that what satisfied one NB in 2023 will satisfy the same or a different NB in 2026.

What Notified Bodies look for during conformity assessment

Having established the regulatory frameworks, let’s break down exactly what NBs scrutinize during the assessment process. This is where many manufacturers discover uncomfortable gaps between their internal assumptions and external expectations.

Conformity assessment for cybersecurity covers integration into risk management under ISO 14971, software lifecycle processes under IEC 62304, technical documentation completeness, QMS audit findings, and post-market surveillance. These are not separate boxes. They form an interconnected evaluation where a weakness in one area raises suspicion about the others.

Here is what a structured NB review typically covers, in approximate order of assessment:

1. Risk management file review: Does the manufacturer trace specific cybersecurity threats to clinical harm scenarios? A vulnerability in a patient monitor’s communication interface must connect to a harm analysis showing the probability and severity of a patient safety event. Vague or generic risk entries fail this test.
2. Software lifecycle documentation: Under IEC 62304, the NB checks whether security requirements were defined during software planning, whether they were tested, and whether the test evidence links back to specific requirements. Missing traceability is one of the most common findings.
3. Technical file completeness: The technical file must contain a security architecture overview, network diagrams showing data flows, interface specifications, and evidence of security testing. Incomplete files trigger information requests that delay certification timelines.
4. QMS audit for security processes: NBs verify that your quality management system includes defined security processes, not just product-level controls. This includes change control for security patches, supplier cybersecurity evaluation, and incident response procedures.
5. Post-market surveillance system review: The NB confirms that your PMS system captures security-related signals from the field, including adverse event reports, customer complaints, and public vulnerability databases.

Pro Tip: Treat every cybersecurity risk management entry as a mini-narrative. Each entry should read: “This specific threat, exploited via this specific interface, leads to this specific clinical consequence with this estimated probability.” Generic entries like “unauthorized access may cause harm” will not satisfy an experienced NB reviewer.

One of the most common sources of nonconformities we see involves the failure to maintain living documents. The NB does not expect a perfect document frozen in time. It expects evidence that cybersecurity documentation is updated when new vulnerabilities emerge, when software is changed, and when PMS data reveals new threat patterns. To spot and fix cyber gaps before the NB does, manufacturers need internal processes that treat documentation as an ongoing responsibility, not a one-time deliverable.

For reference, here is a simplified view of what documentation each assessment area typically requires:

Understanding the regulatory compliance expectations that apply across complex technical products reinforces why manufacturers need to treat cybersecurity compliance as a system-level discipline rather than a product-level feature.

Testing methodologies required for cybersecurity compliance

Once the assessment criteria are clear, manufacturers need to know what practical testing methods are required and how to execute them in a way that satisfies NBs. This is where abstract regulatory language meets engineering reality.

Penetration testing by qualified experts covering all device interfaces and communication protocols is the standard expectation for connected devices. That means physical ports (USB, serial, JTAG), wireless interfaces (Bluetooth, Wi-Fi, Zigbee), network protocols, and any cloud-connected backend systems. Leaving even one interface untested creates a finding.

The expected testing program typically includes:

• Penetration testing: Simulated attack scenarios targeting known entry points and realistic threat actor behaviors. Must be performed by testers independent from the development team.
• Fuzz testing: Automated delivery of malformed or unexpected inputs to interfaces to identify crash conditions, memory corruption, or unexpected behaviors that could affect device function.
• Vulnerability scanning: Automated scanning of software components, libraries, and network services to identify known Common Vulnerabilities and Exposures (CVEs).
• Threat model validation: Testing must be scoped by the threat model. If your threat model identifies hospital network attackers as a primary threat actor, your penetration testing scenarios must reflect that.
• Static and dynamic code analysis: Especially important under IEC 62304, where code-level security reviews demonstrate that security requirements were implemented correctly.

“Testing is not a pass or fail event. It is an evidence-generating process. Every finding, even minor ones, must link to a documented mitigation decision and a residual risk assessment connected to clinical harm.”

This linkage is critical. An NB reviewer does not just want to see a penetration test report. They want to see how each finding was categorized by severity, what mitigation was implemented, and how the residual risk was accepted within the risk management framework under ISO 14971. A clean test report with no findings can actually raise suspicion if the test scope was narrow or the methodology was not rigorous.

For manufacturers building out their testing programs, the penetration testing guide covers scope definition, methodology selection, and documentation requirements in practical detail. Real-world examples of compliant testing execution are also visible in published VAPT testing case studies that show how findings translate into regulatory evidence.

Pro Tip: When selecting a penetration testing provider for regulatory purposes, confirm that they can produce structured test reports that map findings to CVSS scores, affected interfaces, and recommended mitigations. An informal report suitable for IT security will not satisfy an NB reviewer looking for documented evidence.

Choosing testing partners with medical device experience matters more than choosing partners with generic security credentials. The complete security testing guide for patient monitoring devices illustrates how testing evidence must be structured to support both FDA and EU MDR submissions. The mobile security considerations that manufacturers face in connected device environments further reinforce why interface-specific expertise is non-negotiable.

Post-market activities and ongoing NB requirements

Testing is only part of the process. Maintaining and improving cybersecurity after your device reaches the market is equally weighted in the NB’s ongoing surveillance activities. This is where many manufacturers underinvest, and where NB surveillance visits most often surface nonconformities.

The harmonized NB approach to post-market cybersecurity, reinforced by Team-NB’s formal position on the issue, establishes that manufacturers must actively maintain cybersecurity throughout the device lifecycle, not just at the time of initial conformity assessment. Team-NB issued a formal letter in 2026 supporting enhanced cybersecurity efforts and signaling that NBs are increasingly aligned in their post-market expectations.

Ongoing post-market cybersecurity obligations include:

• Continuous vulnerability monitoring: Manufacturers must monitor public sources including the National Vulnerability Database (NVD), vendor security bulletins, and sector-specific advisories (such as those from CISA or ENISA) for vulnerabilities affecting software components used in their device.
• Coordinated vulnerability disclosure: A public or semi-public process for external reporters to submit discovered vulnerabilities, with defined response timelines and update commitments.
• PMS data integration: Security-relevant field data, including adverse event reports, complaint trends, and software error reports, must be analyzed and integrated into the cybersecurity risk management file.
• Periodic security reviews: The cybersecurity risk assessment must be reviewed at defined intervals and whenever significant changes occur in the threat landscape, the software, or the clinical environment.
• Patch management documentation: Every security patch must be documented with a change control record, a risk assessment for the change, and evidence that testing was repeated for affected interfaces.

A statistic worth internalizing: post-market surveillance failures are consistently among the top five reasons for NB nonconformity findings in EU MDR assessments. Cybersecurity-specific PMS failures are a growing subset of that category. Reviewing a security compliance management case demonstrates how structured post-market processes can both satisfy NBs and improve actual device security outcomes in parallel.

Understanding broader website security strategies used in other regulated industries also offers useful patterns for how vulnerability disclosure and patch communication can be structured professionally and transparently.

The uncomfortable truth about NB cybersecurity: Why “good enough” isn’t

We have worked with manufacturers across regulated markets, and the pattern that consistently leads to NB problems is not ignorance of the regulations. It is the quiet organizational assumption that meeting the minimum documented requirement is sufficient. It is not. Not in 2026, and certainly not going forward.

NBs are not static in their expectations. The harmonization effort led by Team-NB signals that reviewers are becoming more consistent, more knowledgeable about cybersecurity specifics, and more likely to push back on documentation that technically satisfies the letter of MDCG 2019-16 but lacks genuine substance. We have seen manufacturers produce technically compliant threat models that contain no realistic threats. We have seen penetration test reports that covered only one of six interfaces because the scope was deliberately narrowed to avoid findings. NBs are getting better at identifying these patterns.

The practical shift required is from compliance-as-documentation to compliance-as-practice. That means threat intelligence actually feeds your risk management process. It means PMS data is reviewed by someone with cybersecurity expertise, not just regulatory affairs staff. It means coordinated disclosure is a real program, not a generic email address in your instructions for use.

The MedSecurance critique of MDCG 2019-16 highlights exactly where the current guidance falls short of what the threat landscape demands. Manufacturers who read that critique and use it to get ahead of future guidance revisions will be in a fundamentally better position than those waiting for updated requirements to become mandatory. The compliance steps for medical device cybersecurity that distinguish leading manufacturers from struggling ones are not more documentation. They are better processes that generate documentation as a natural output.

How Testvox helps medical device makers meet cybersecurity requirements

Meeting NB cybersecurity expectations requires more than regulatory knowledge. It requires structured testing programs, compliant documentation, and a testing partner who understands both the security techniques and the regulatory evidence requirements.

Testvox specializes in medical device security testing aligned with EU MDR, MDCG 2019-16, ISO 14971, and IEC 62304 expectations. Our VAPT team conducts penetration testing, fuzz testing, and vulnerability scanning across all device interfaces, producing structured reports that map directly to risk management documentation requirements. We have supported manufacturers through initial conformity assessments and NB surveillance visits, with documented outcomes visible in our security testing case study for an FDA-ready patient monitoring device. Whether your device is approaching a first submission or preparing for a notified body surveillance audit, Testvox provides the testing evidence and documentation structure you need to move forward with confidence.

Frequently asked questions

Do Notified Bodies require specific cybersecurity testing for every medical device?

NBs expect penetration testing for higher-risk and connected devices, with test scope calibrated to the device’s risk classification and interface complexity. Lower-risk, non-connected devices may require less extensive testing but still need documented security risk assessments.

Is there a standalone cybersecurity regulation for medical devices in the EU?

No. Cybersecurity requirements are integrated directly into MDR GSPRs, risk management obligations, and post-market surveillance requirements rather than existing as a separate regulatory document.

What are the minimum cybersecurity features Notified Bodies expect?

MDCG 2019-16 guidance establishes expectations including authentication controls, encryption, security logging, post-market vulnerability monitoring, and coordinated disclosure processes as baseline requirements.

Do Notified Bodies require post-market cybersecurity surveillance?

Yes. Harmonized NB expectations require continuous vulnerability monitoring, integration of PMS data into cybersecurity risk files, and coordinated disclosure programs throughout the device’s commercial lifecycle.

How do EU cybersecurity requirements for medical devices differ from FDA?

EU MDR integrates cybersecurity within the broader safety and risk management framework, giving manufacturers interpretive flexibility; the FDA approach is more prescriptive, requiring specific deliverables such as a software bill of materials and defined patch management timelines.

Recommended

• FDA cybersecurity requirements: what startups must know
• Medical device cybersecurity: compliance steps to enter the market
• FDA cybersecurity compliance | Startup guide to avoid mistakes
• Avoid FDA cybersecurity mistakes: fintech & e-commerce
• DLL File Verification – Ensuring Windows Security – FixDlls Blog