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. ELTON is an exploitability management platform, delivered as a managed program. Our team runs the testing continuously. You get the platform, the evidence, and a TestLink™ appliance, with no new headcount.
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 product. 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.
The CRA starts a reporting countdown. An actively exploited vulnerability triggers a 24 hour early warning and a 72 hour notification to ENISA and the national CSIRT. Vulnerability handling duties run across the product's support period, and the CRA does not care how old the device is.
The MDR asks whether your device is safe and now counts cybersecurity as part of that answer, proven in the technical file and re-examined at recertification. The CRA asks whether you handle and report vulnerabilities on time. The two regimes overlap, so a single evidenced practice can satisfy both.
Annex I General Safety and Performance Requirements 17.2 require software developed to the state of the art with IT security measures, and MDCG 2019-16 makes cybersecurity part of the GSPR. Notified Bodies ask for the technical evidence behind that: vulnerability monitoring and triage, patch management with justification for unmitigated risk, SBOM, and cybersecurity specific postmarket surveillance.
CRA vulnerability handling duties apply to products with digital elements across their support period, and the regulation does not care how old the device is. A product certified years ago carries the same handling and reporting obligations as one launched this quarter, which is why legacy recertification and CRA reporting are usually the same evidence problem.
ELTON builds a digital twin from your quality system documentation and runs continuous discovery across firmware, software, web, mobile and network. The same twin, findings and VEX statuses populate the MDR technical file and the CRA reporting timeline, so the evidence is a byproduct of the work rather than a separate project.