Two EU regimes now govern device cybersecurity. MDR treats security as part of the safety case, proven in the technical file and re-examined at recertification. The CRA layers on vulnerability-handling duties and a reporting countdown measured in hours. ELTON produces the evidence both demand, from one continuous practice.
The MDR and the CRA overlap but ask different questions. The MDR asks whether your device is safe, and now counts cybersecurity as part of that answer. The CRA asks whether you handle and report vulnerabilities on time. A single, evidenced practice satisfies both.
Annex I General Safety and Performance Requirements 17.2 require software developed to the state of the art with IT security measures. MDCG 2019-16 makes cybersecurity part of the GSPR, not an optional annex, and Notified Bodies now ask for technical evidence, traceability, and lifecycle management, including at recertification of legacy devices.
Products with digital elements carry vulnerability-handling duties across their support period, and an actively exploited vulnerability starts a reporting countdown: a 24-hour early warning and a 72-hour notification to ENISA and the national CSIRT. The CRA does not care how old the device is.
Under the MDR, manufacturers must demonstrate that software risks are identified, evaluated, and controlled across the lifecycle. MDCG guidance expects documented processes, and Notified Bodies expect the evidence behind them. The gap most files have is continuity, not a single pentest.
Proof that someone watched the SBOM between the last test and today, and triaged what appeared. ELTON's continuous discovery and finding lifecycle make that a running record, not a reconstruction.
A record of what was fixed and why the rest was accepted. ELTON's VEX-aligned statuses carry the reasoning for every decision, which is exactly the justification MDCG asks for.
SBOM evidence in the technical file and cybersecurity-specific postmarket surveillance. ELTON generates the CycloneDX SBOM and re-assesses findings as new vulnerabilities surface, per release.
The hard part of both regimes is the same: knowing, quickly and provably, whether a given vulnerability is exploitable on your product. That answer only comes from testing the device itself, and it feeds the MDR file and the CRA clock at once.
ELTON builds a digital twin from your quality system documentation and runs continuous discovery across firmware, software, web, mobile, and network. The continuity the MDR wants is how the platform operates, not a project you schedule.
When a CVE drops or an exploitation report arrives, AI verification attacks the question on the real device. You notify from evidence: exploitable here, or provably not, with the test record attached.
The same twin, findings, and VEX statuses populate the MDR technical file and the CRA reporting timeline. Evidence is a byproduct of the work, generated as you go.
The MDR asks for continuity across the whole lifecycle. The CRA compresses part of it into hours. ELTON runs continuously, so when the countdown starts the evidence already exists.
Start with one device. We build the twin, run continuous discovery, and keep the record both the Notified Body and the CRA clock expect, current and ready.