Skip to main content
← BlogEU

MDCG 2019-16 — what a Notified Body actually checks

Cybersecurity is now reviewed properly in CE technical files. Notified Bodies assign reviewers to it, and they work from a structured questionnaire rather than reading the file and forming an impression. This post sets out what those reviewers ask for, which clauses the questions come from, and the findings that most often come back as non-conformities.

What MDCG 2019-16 is, and is not

MDCG 2019-16 is guidance, not law. The obligations live in the Regulations; the guidance explains what meeting them looks like. It is the joint guidance for both MDR (2017/745) and IVDR (2017/746) — an in-vitro diagnostic with software or connectivity carries the same cybersecurity obligations as a medical device. Only the clause numbers and the harm pathway differ.

Team-NB, the association of Notified Bodies, wrote in February 2026 that MDCG 2019-16 needs updating. It also confirmed the document remains the operative baseline in the meantime. Plan against it.

The clauses the questions come from

Four General Safety and Performance Requirements do most of the work:

  • GSPR 17.2 (IVDR 16.2) — software must be developed and manufactured in accordance with the state of the art, taking into account the development lifecycle, risk management including information security, verification and validation. This is the clause that pulls a secure development lifecycle into scope.
  • GSPR 17.4 (IVDR 16.4) — the manufacturer must set out minimum requirements for hardware, IT-network characteristics and IT-security measures, including protection against unauthorised access.
  • GSPR 23.4(ab) (IVDR 20.4.1(ah)) — those minimum requirements must appear in the Instructions for Use. A security section in the IFU is not optional polish.
  • GSPR 14.2(d) — reduce, as far as possible, risks from the device's interaction with its operating environment.

What the reviewer actually asks

The de-facto reference is the IG-NB questionnaire, Cybersecurity for Medical Devices — Technical Documentation, published by the German Notified Bodies Alliance and aligned to MDCG 2019-16 with IEC 81001-5-1, ISO 14971 and IEC 62304. Reduced to plain questions, a reviewer wants:

  • A system description and diagram showing the device, its data flows and its environment.
  • A threat model covering all interfaces, protocols, data types and trust boundaries. Not the main interface. All of them.
  • A named, systematic method for producing it — STRIDE, for example. "We considered the risks" is not a method.
  • Attack vectors identified in the context of the intended use and environment, not in the abstract.
  • Risk scoring by exploitability and severity, before and after mitigation.
  • Safety linkage: where a security risk can affect safety, it appears in the ISO 14971 safety risk assessment.
  • Risk controls in the right order — secure design first, then protective measures, then user information and training. A control implemented as a warning in the manual, where a design change was available, is a finding.
  • Verification that controls are appropriate and effective, not merely that they exist.
  • Confidentiality, integrity and availability addressed to the state of the art.
  • Responsibility boundaries stated between manufacturer, integrator and operator.
  • IFU security content: residual risks, installation and configuration, third-party software such as antivirus and firewall, minimum operating system and hardware, fail-safe behaviour, update and patch instructions, backup and restore, user roles and logging.
  • A software component inventory — every component with its manufacturer, version and unique identifier, which is what makes an SBOM usable rather than decorative.
  • Security testing by independent, skilled testers, covering all attack vectors, with a documented methodology.

The findings that come back

Seven recur:

  1. Security risks not carried into the ISO 14971 file. This is the most-cited conceptual failure. A separate security risk register, however good, does not satisfy it — safety-relevant security risks belong in the safety risk file.
  2. A threat model missing interfaces or trust boundaries, or with no method named.
  3. Scoring by probability instead of exploitability. Safety probability models an accident. An attacker is not an accident, and a reviewer will say so.
  4. Penetration testing that is not independent, does not cover all attack vectors, or has no documented methodology.
  5. No security section in the IFU.
  6. A component inventory without versions or unique identifiers, and no process for monitoring those components after release.
  7. No route for anyone to report a vulnerability to you. Post-market surveillance obligations under the MDR expect vulnerabilities to keep being found and handled after the device ships.

The pattern behind all seven is the same: cybersecurity documented once, as a checkbox, rather than run as a lifecycle. That is what a reviewer is trained to detect.

Where to start

If the technical file already exists, the fastest useful exercise is to take the list above and mark each item present, partial or absent, using only evidence someone else could find in the file. The gaps are usually in the same three places: the threat model's coverage, the link between security risk and the safety risk file, and the IFU.

If the device is still in development, the order that saves the most rework is threat model first, then the security risk file linked to ISO 14971, then controls and their verification, and the IFU security section written as the requirements settle rather than at the end.

Kaitara Security prepares the cybersecurity evidence for CE technical files — threat model, security risk file, SBOM, testing and the IFU security content. Conformity assessment remains with the Notified Body. Details: Medical Device Cybersecurity (CE).