If your device runs software, the EU MDR already regulates its cybersecurity. Not as a recommendation, and not in a separate annex you can defer. The security requirements sit inside the General Safety and Performance Requirements that your conformity assessment is graded against.
This matters because of how many manufacturers structure the work. Security gets stood up as its own program: a penetration-test schedule, a threat-modeling workshop, a SOC 2 effort borrowed from the cloud team. It runs parallel to the regulatory file. The notified body reviews one stack, the security function maintains another, and nobody owns the seam between them.
The MDR does not give you that seam. It folds cybersecurity into the same obligations that govern electrical safety and biocompatibility. A device that is insecure is, in the language of the regulation, a device that does not meet its essential requirements. That is a conformity finding, not a security backlog item.
Here is where the text actually puts it, and what each obligation requires you to produce.
Where does the EU MDR actually require cybersecurity, and is it optional?
The EU MDR is Regulation (EU) 2017/745. Its General Safety and Performance Requirements live in Annex I. Every device placed on the EU market must demonstrate conformity with the applicable requirements there, and that demonstration is what the notified body assesses for class IIa and above.
Cybersecurity is not named as a standalone chapter. It is distributed across the requirements that deal with software, electronic programmable systems, the IT environment, and the information you supply to users. Three places carry most of the weight: Annex I Section 17 on electronic programmable systems and software, Section 14.2(d) on interaction with the IT environment, and Section 23.4(ab), which pushes specific security requirements into the instructions for use.
None of these are conditional on a separate "if you choose to address security" trigger. If your device incorporates software or an electronic programmable system, the requirements apply by virtue of that fact. There is no opt-out and no risk-acceptance path that lets you skip them. You either show conformity or you do not have a compliant device.
So the framing question answers itself. Cybersecurity under the MDR is not a bolt-on you add for maturity points. It is part of the conformity obligation that gates market access.
What does Annex I Section 17 require for software and electronic programmable systems?
Section 17 is the core software provision, and it reads as a lifecycle obligation rather than a feature checklist.
Section 17.1 requires that devices incorporating electronic programmable systems, including software, or software that is itself a device, be designed to ensure repeatability, reliability and performance in line with their intended use. It goes further on failure: in the event of a single fault condition, you must adopt appropriate means to eliminate or reduce as far as possible the consequent risks or impairment of performance. Single-fault tolerance is a design obligation, and a software defect or a security failure that degrades performance falls inside it.
Section 17.2 is the one that names the discipline directly. Software must be developed and manufactured in accordance with the state of the art, taking into account the principles of development life cycle, risk management including information security, and verification and validation. Read that clause carefully. Risk management is not separate from information security here. The text places information security inside risk management, inside the development life cycle, inside verification and validation. Your secure-development practice is not adjacent to your design controls. It is a named input to them.
That single sentence is why a parallel security program tends to fail an MDR audit. If your threat model, your security testing, and your vulnerability handling are not traceable back into the same design-history file the notified body reads, you have evidence in the wrong place. The state-of-the-art expectation also moves. What counts as adequate secure development in 2026 is not what counted in 2020, and the notified body will benchmark against current consensus standards.
What 'minimum IT security requirements' must you set under Annex I 17.4, and put in the IFU under 23.4(ab)?
This is the pair that catches manufacturers most often, because it converts a design obligation into a disclosure obligation.
Section 17.4 requires manufacturers to set out minimum requirements concerning hardware, IT network characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended. You have to define the operating envelope. What hardware does the device assume, what network conditions does it expect, and what security controls must be present for it to run safely. Protection against unauthorised access is called out by name.
Section 23.4(ab) then takes those same minimum requirements and requires them in the instructions for use. The exact obligation: for devices that incorporate electronic programmable systems, including software, or software that is a device in itself, the IFU must state the minimum requirements concerning hardware, IT network characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended.
The two sections use almost identical language on purpose. 17.4 makes you determine the security baseline. 23.4(ab) makes you publish it to the people deploying the device. A hospital integrating your infusion pump or your imaging workstation is entitled to read, in the IFU, what network segmentation, access controls, and hardware assumptions your device depends on.
This is a documented, auditable artifact. The notified body can open your instructions for use and check whether the minimum IT security requirements are actually stated. If 17.4 produced an internal security spec but 23.4(ab) was never satisfied in the IFU, that gap is visible on inspection. Both obligations trace to the same set of facts, which is exactly why they belong in one control rather than two disconnected ones.
How does Annex I 14.2(d) fold the IT environment into your essential safety requirements?
Section 14.2 is a general safety requirement: devices must be designed and manufactured to remove or reduce, as far as possible, a list of risks. Most of the list is physical, covering injury from physical features, external electromagnetic effects, contact with substances. Then comes point (d).
Section 14.2(d) requires you to remove or reduce as far as possible the risks associated with the possible negative interaction between software and the IT environment within which it operates and interacts. This is a safety-interaction requirement, and it is worth keeping distinct from the access-control language in 17.4 and 23.4(ab). Those sections are about controlling who and what can reach the device. 14.2(d) is about what happens when your software meets the messy reality of a hospital network: a misconfigured firewall, a noisy peer device, an OS patch that changes behavior, an integration that sends data your software did not expect.
The obligation treats the IT environment as a source of safety risk, not just a security boundary. A negative interaction that degrades device performance is a safety concern under 14.2(d) regardless of whether anyone attacked it. That framing should feed your risk-management file directly. The interaction failures you identify under 14.2(d) and the unauthorised-access threats you handle under 17.4 are different hazard classes, and conflating them in your documentation produces gaps a careful reviewer will find.
Why does cybersecurity belong inside your QMS and post-market surveillance system (Arts 83 to 86)?
Conformity at the point of CE marking is only the first half. The MDR makes safety, including the security dimension of safety, a lifetime obligation through post-market surveillance.
Article 83 requires that for each device, manufacturers plan, establish, document, implement, maintain and update a post-market surveillance system, in a manner proportionate to the risk class and appropriate for the type of device. The article is explicit that this system must be an integral part of the manufacturer's quality management system. It is not a separate function. It lives inside the QMS the notified body already audits. Article 83 also requires the system to actively and systematically gather, record and analyse relevant data on the quality, performance and safety of the device throughout its entire lifetime.
Read "throughout its entire lifetime" against a connected device with a published vulnerability surface. New CVEs in your dependencies, new attack techniques against your protocols, exploit activity reported in the field. All of that is post-market data on safety and performance, and Article 83 obliges you to gather and analyse it actively, not to wait for a complaint to arrive.
Article 86 adds the periodic safety update report. Manufacturers of class IIa, class IIb and class III devices must prepare a PSUR for each device, summarising the results and conclusions of the post-market surveillance data, with a rationale and description of any preventive and corrective actions taken. Class IIb and class III devices update the PSUR at least annually; class IIa at least every two years. Class I devices instead prepare the post-market surveillance report under Article 85. Whichever applies to your class, the security-relevant findings from your post-market monitoring belong in that report, alongside the benefit-risk conclusions.
The structural point is that the MDR has already decided where security operations live. They live inside the QMS and the post-market surveillance system. A security program that maintains its own incident log, its own vulnerability tracker, and its own metrics, none of which flow into the PSUR, is duplicating the regulated record instead of feeding it.
When do you have to report a cybersecurity-driven serious incident, and how fast (Art 87, trend reporting Art 88)?
This is where the cost of treating security as a side program becomes concrete, because the clock in Article 87 is short and it does not pause while your security team decides whether an event "counts."
Article 87 governs the reporting of serious incidents and field safety corrective actions. A cybersecurity event is reportable when it meets the definition of a serious incident, and a compromise that leads to a patient-safety consequence or a serious deterioration in health does. The deadlines are tiered by severity:
→ Any serious incident: report immediately after you establish a causal relationship, or that one is reasonably possible, and not later than 15 days after becoming aware of it.
→ A serious public health threat: report immediately, and not later than 2 days after becoming aware of the threat.
→ Death or an unanticipated serious deterioration in a person's state of health: report immediately after you establish or suspect a causal link, and not later than 10 days after becoming aware of the serious incident.
Article 87 also lets you file an incomplete initial report followed by a complete one where that is needed to report on time, and it tells you that when you are uncertain whether an incident is reportable, you report anyway within the applicable timeframe. The benefit of the doubt runs toward reporting.
Now picture the security-as-bolt-on failure mode against a 2-day clock. A SOC detects anomalous access to a fleet of connected devices. Is it a serious incident? Is there a public-health dimension? Who owns the regulatory clock, the CISO or the person responsible for vigilance? If those questions get asked for the first time during the event, you are already burning the 2-day or 10-day window on internal routing. The obligation belongs to the manufacturer's vigilance process, and your security monitoring has to feed it directly.
Article 88 covers the lower tier. Manufacturers must report any statistically significant increase in the frequency or severity of incidents that are not serious incidents, or of expected undesirable side-effects, that could have a significant impact on the benefit-risk analysis. You define the methodology and the observation period in your post-market surveillance plan. For a connected device, a rising rate of non-serious security events can be exactly the trend signal Article 88 is built to surface before it becomes a serious incident.
How do you map MDR cyber obligations to a single, auditable control set instead of a parallel security program?
Put the obligations next to each other and the pattern is obvious. 17.2 names information security inside your design risk management. 17.4 makes you define a security baseline; 23.4(ab) makes you publish it in the IFU. 14.2(d) treats IT-environment interaction as a safety risk. Article 83 puts security monitoring inside the QMS for the device's whole lifetime. Articles 86 and 87 turn the findings into reports on fixed clocks. These are not nine separate programs. They are one obligation set with one underlying record.
The practical move is to stop running security parallel to the regulatory file and start treating each MDR cyber requirement as a control that traces back to the source clause. That means your threat model resolves into 17.2 and 14.2(d). Your security baseline resolves into 17.4 and your IFU section under 23.4(ab). Your vulnerability monitoring resolves into Article 83 and feeds the PSUR under Article 86. Your incident process carries the Article 87 deadlines as hard timers. When a clause changes or a new guidance document shifts the state of the art, you want to see which controls move, not re-derive the whole map by hand.
This is the problem Aegis GRC was built to solve. We ingest the regulation so that every obligation traces to a verbatim quote from the legal text, then bind each obligation to the controls and evidence that satisfy it. One organizational profile maps to the MDR and to the other frameworks a medical-device manufacturer carries at the same time, with overlaps resolved instead of duplicated. The result is a posture you can defend in front of a notified body, an auditor, or a regulator, because every line traces back to the source. Source-grounded, with no AI hallucinations.
If you build connected or software devices and your security work still lives outside the regulatory file, map your MDR cyber obligations once at aegis-grc.com, and see them resolve against the conformity, lifecycle, and vigilance requirements that actually apply.
FAQ: EU MDR cybersecurity, IFU security requirements, PMS, and incident reporting
Does the EU MDR explicitly require cybersecurity? The MDR does not use a single "cybersecurity" chapter, but it requires it through Annex I. Section 17.2 places information security inside software risk management; Section 17.4 requires minimum IT security measures including protection against unauthorised access; Section 23.4(ab) requires those measures in the instructions for use; and Section 14.2(d) treats negative interaction with the IT environment as a safety risk. For a device with software, these requirements are mandatory parts of the conformity assessment.
What IT security information has to go into the instructions for use? Under Annex I Section 23.4(ab), the IFU for a device incorporating electronic programmable systems or software must state the minimum requirements concerning hardware, IT network characteristics and IT security measures, including protection against unauthorised access, that are necessary to run the software as intended. This is the same baseline you determine under Section 17.4, disclosed to the operator.
Is device cybersecurity part of post-market surveillance? Yes. Article 83 requires a post-market surveillance system, integral to the QMS, that actively and systematically gathers data on safety and performance throughout the device's entire lifetime. For connected devices, security findings such as new vulnerabilities and field exploit activity are post-market data, and they feed the PSUR under Article 86 for class IIa, IIb and III devices, or the post-market surveillance report under Article 85 for class I.
How fast must a cybersecurity-driven serious incident be reported under Article 87? Article 87 sets tiered deadlines: a serious incident must be reported no later than 15 days after you become aware of it; a serious public health threat no later than 2 days; and a death or unanticipated serious deterioration in health no later than 10 days. A security compromise that meets the serious-incident definition falls under these same timelines, and when you are uncertain whether an event is reportable, you report within the applicable timeframe anyway.
What is trend reporting under Article 88, and how does it relate to security? Article 88 requires reporting of any statistically significant increase in the frequency or severity of non-serious incidents or expected side-effects that could significantly affect the benefit-risk analysis. You define the methodology and observation period in your post-market surveillance plan. For a connected device, a rising rate of lower-severity security events can be the trend signal that surfaces a problem before it escalates to a reportable serious incident.
