Compliance & Regulation

EU-MDR recertification: what MDCG expects on cybersecurity

The hardest part of EU-MDR recertification isn't the new products. It's the installed base: devices CE marked years ago, under rules that never asked a cybersecurity question, now being re-examined by Notified Bodies that ask plenty of them.

The Medical Device Coordination Group made the shift explicit. MDCG 2019-16 and the updates that followed treat cybersecurity as part of the General Safety and Performance Requirements, not an optional annex. And Notified Bodies have adjusted what they look for accordingly. This isn't a documentation exercise anymore. It requires technical evidence, traceability, and lifecycle management of software risks that used to sit outside the scope of CE marking entirely.

What the technical file now has to show

Under EU-MDR, manufacturers must demonstrate that software risks have been identified, evaluated, and controlled across the product lifecycle. In practice, MDCG guidance expects documented processes for four things:

  • Vulnerability monitoring and triage
  • Security patch management
  • Justification of unmitigated risks
  • Postmarket surveillance activities specific to cybersecurity

For recertification, that means updating Technical Documentation to include a cybersecurity risk assessment, SBOM evidence, and an established vulnerability management process. Even for devices that have shipped for a decade. The regulation doesn't grandfather your evidence.

The gap is continuity, not testing

Most manufacturers I talk to can produce a penetration test report. What they can't produce is continuity: proof that someone watched the SBOM between that test and today, triaged what appeared, patched what mattered, and recorded why the rest didn't. That's the actual bar now.

A recertification file is a snapshot of a process. If the process doesn't exist, the snapshot shows it.

Notified Bodies aren't asking for perfection on legacy devices. They're asking whether you know your device's software risk today and can show how you keep knowing it. Age is forgivable. Blindness isn't.

The volume makes improvised approaches unworkable too. Thousands of devices need EU-MDR recertification by 2027, and each file has to stand on its own when a reviewer opens it. Spreadsheets and siloed test reports don't scale across a portfolio, and Notified Bodies are increasingly comfortable saying so.

Recertification exposes the evidence gap Legacy technical file (MDD era) xNo SBOM on file xOne pentest, from launch year xNo vulnerability triage process xUnmitigated risks undocumented xNo cyber postmarket surveillance EU-MDR file (MDCG expectations) Cybersecurity risk assessment SBOM evidence for every release Monitoring, triage, patch process Justified unmitigated risks Cyber postmarket surveillance recertify by 2027
MDCG guidance makes cybersecurity part of the GSPRs. Legacy files rarely survive contact unchanged.

How we close legacy files

ELTON treats recertification as a lifecycle problem rather than a documentation sprint. It starts with a digital twin of the device: embedded systems, software layers, interfaces, and network connections in one structured model. A Notified Body reviewer gets a clear view of how cybersecurity is actually addressed in the system, which beats prose every time.

For legacy products this matters more than it sounds. Much of what a reviewer now wants was never written down at design time, and the engineers who carried it in their heads have often moved on. Rebuilding the model from the QMS documentation and the software itself is the only honest way to close that file.

From there, ELTON monitors SBOM components across every release and flags new CVEs as they land. Each finding is evaluated for exploitability in the actual system context, and that context is what lets you justify why something does or doesn't require remediation. The justification requirement is written directly into MDCG expectations, and it's the piece generic scanning can't produce.

Postmarket, the platform maintains a living view of each product's vulnerability state: historical tracking, triage decisions, remediation actions, and risk-based justifications, all mapped to specific device releases and software updates. Every decision is logged, time-stamped, and traceable. That's the shape of evidence CAPA and postmarket surveillance reviews want to see.

Recertification pressure is unwelcome, but it's forcing something that should have happened anyway. A CE mark was never meant to be a one-time event for software-driven devices. Manufacturers treating 2027 as a deadline to survive will end up doing this work twice. The ones treating it as the moment vulnerability management becomes a standing process won't have to scramble for a technical file again.

← All intelligence
Get started

See your device through ELTON.

Start with one device. We build the twin from documentation your quality system already produces, run AI discovery remotely, and show you the graph: the handful to fix, and the evidence for everything else.

Automate medical device vulnerability discovery and verification. FDA §524B methodologyExploitability proven on-device95% faster than legacy testing Book a Demo
Platform
Platform OverviewDigital TwinAutonomous TestingExploitability VerificationVulnerability GraphRemediation OptimizationELTON TestLink™Lifecycle & MetricsCVSSv4 Migration
Solutions
FDA §524BEU MDR/CRAEU REDNIS2IMDRF N60 / N73Postmarket SurveillanceIncident Response
Why ELTON
Why ELTONPricing
Resources
Intelligence & BlogRegulatory GuidesWebinarsWhitepapers
Company
AboutLeadershipCareersContact Book a Demo