13 yrs
Testing medical devices
Since 2013, nothing else
10,000+
Device tests run
Across 1,000+ devices
1,000+
FDA submissions
Behind the team and methodology
ISO 14971UL 2900AAMI TIR57AAMI TIR97IEC 62304ISO 13485ISO 27001IEC 81001-5-1IEC 62443-4-1
Point-in-time is the problem

Legacy pentesting fails
regulatory and product teams.

FDA wants traceability, teams want speed. Consultants deliver neither.

Late results, late surprises.

ELTON surfaces vulnerabilities faster than any consulting firm can start, runs on-demand, every build, no surprises.

ELTON 95% faster, 75% more efficient

TIME Legacy pentest4 weeks ELTON2 days · 95% less COST Legacy pentest100% one-time spend ELTON75% less · continuous fixed annual subscription · tests all year

A consultant sells you a snapshot. ELTON tests all year on one subscription. Same evidence FDA expects, at a quarter of the spend.

Pure findings, no fixes.

Consulting shops say something is wrong, not how to fix it. ELTON ships prescriptive remediation down to the code.

ELTON provides fixes at the code level

WeaknessTLS negotiation on mgmt portPRESCRIPTIVE FIX · EXACT LINE- ctx = ssl.PROTOCOL_TLS+ ctx.minimum_version =ssl.TLSVersion.TLSv1_3verified against the digital twin · runtimeTicketJira · Azure DevOpsELTON MCPclosed-loop CI/CD1% prioritized now · every weakness carries a fix

Prescriptive fixes for the exact line, delivered where your developers already work. Open a ticket, or run it closed-loop over ELTON MCP.

The vulnerability management problem

Every vulnerability you don't fix
is one you must explain to the FDA.

AI-native vulnerability testing is outgrowing management, and the FDA questions everything you didn't fix.

ELTON combines discovery with management, the future-proof strategy.
FDA Required

It’s the law, 524B

Premarket and postmarket regular testing and management of every vulnerability.

3x

CVE volume by 2028

AI vulnerability discovery is here. Your spreadsheets won’t keep up. ELTON finds and manages.

2+ FTEs

Per product, just for triage

Senior engineers burn quarters proving CVEs don't apply to your device. That work ships nothing.

99%

Of findings never need a fix

But every dismissal needs evidence. FDA reviewers probe the findings you didn't fix, not the ones you did.

THE VULNERABILITY AVALANCHEPublished CVEs a year (NVD), 2025 on projected40K80K120K20172018201920202021202220232024202520262027202814.7K40K72K125KAI ERA BEGINSDiscovery cost collapses,reports go to feed speedPRE-AIVolume creeps: 15K to 29K a yearPOST-AI · 10X BY 2028

Legacy spreadsheets fail audits.

Today an engineer re-rates every finding by hand, weeks of work, stale at release. Unscalable in the AI era.

POSTMARKET SPREADSHEET CVE-2025-21617 9.8re-rate by hand CVE-2024-6387 8.1re-rate by hand CVE-2025-0282 9.0re-rate by hand CVE-2023-44487 7.5re-rate by hand + 2,140 rowsmitigation: blank Every tool, every row, by hand. Weeks per release, then stale. ELTON AI ELTON · PER PRODUCT RELEASE Placed on the digital twin, exploitation conditions known Directly exploitable3 Conditionally exploitable1 Weakness2,140 Mitigation auto-associated where available Historical and new, tracked per release, portfolio-wide
The spreadsheet re-rated by hand versus the twin classifying every vulnerability with its mitigation attached.

Directly exploitable

Reachable and exploitable on the release as shipped. Rated against the product, not the worst case, and queued for a fix.

Conditionally exploitable

Real, but only once another exploit or an external condition opens the path. Tracked with the condition named, not guessed.

Weakness

No path from any entry vector on this release. Severity neutralized by design, with the rationale recorded for the audit.

Anatomy of a verdict

Every finding carries its own receipts.

A verified ELTON finding is not a row in a spreadsheet. It is a package a reviewer can replay: the test case that ran, the execution log it produced, the observed result, and the VEX status that follows. Dismissals carry the same package, because not affected is a claim that needs proof too.

PROBABILITYopinions about likelihoodCVSS 9.8worst-case deployment, not your deviceEPSS 0.94population statistics, not your buildReachability estimatea static guess that never ranTHE LADDEReach tier must earn the next, upward is harderL1 · DIGITAL TWINNo path on this architecture? Dismissed with the reasoning.L2 · CODE & FIRMWAREPresent in the shipped build? Confirmed at the source.L3 · REAL DEVICEThe exploit executes, on the bench over TestLink™ or in our lab.a score enters at the bottom, only evidence leaves the topExecuted proof of conceptthis is what earns the word vulnerabilityFailed exploit, with whya weakness, dismissed on evidenceVEX your customers ingestmachine readable, replayable, current
The ladder from a number in a database to a result a reviewer can replay.

Each verdict also answers the questions SSVC actually asks. Is the attack automatable? Does it end in total compromise of the device? Which vectors reach the flaw? Is there a working proof of concept? Grounded in an executed test, those four answers turn a score into a decision you can defend.

Proof is the foundation the rest of the platform stands on. It is how ELTON can find the 1% that matter, why an FDA-qualified rating methodology holds up in review, and what separates the pipeline from a prompt. The mechanics live on the verification page.

How ratings are made

From submission evidence to a defensible score, in six moves.

Every CVSS 4.0 decision is computed from the device’s documented architecture. Same inputs, same score, every run. This is the full path a rating takes, and every stop on it is traceable.

01

Ingest the submission evidence

ELTON starts from documentation you already produce for FDA review: architecture views and data flow diagrams, SBOM, threat model, risk management report, security controls, and cybersecurity testing reports. No new paperwork, no questionnaires.

Architecture viewsDFDsSBOMThreat modelRisk mgmt reportSecurity controlsPentest reports
02

Build the property graph, the digital twin

The documentation becomes a machine-readable graph. Components become nodes carrying trust level, assets with CIA sensitivity, countermeasures, and deployment configurability. Data flows become directed edges typed Network, Adjacent, Local, or Physical. Every element is tagged to the document it came from, and every manual edit is logged.

Trust zonesAssets + CIACountermeasuresInterface typesSource tagsEdit log
03

Bind the vulnerability to a component

Each finding attaches to the exact component it lives on, whether it arrives from a pentest report, an SBOM scan, the public CVE feed, or a user entry. The vulnerability carries SSVC context and an on-component exposure indicator before any path analysis begins. The unit of analysis is always one vulnerability on one component in one device design.

Pentest findingSBOM scanCVE feedUser-addedSSVCExposure indicator
04

Trace attack paths from every entry point

For each initial access point in the threat model (Wi-Fi, Bluetooth, USB, the user interface, a debug port), ELTON derives the feasible paths an attacker can take to reach the component and the propagation paths after compromise. Traversal respects trust boundaries and directionality, so infeasible paths never inflate a score. Each entry point is scored as its own scenario.

Wi-FiBluetoothUSBUIDebug portPre-compromise corridorPost-compromise spread
05

Apply deterministic CVSS 4.0 rules

Each metric is computed by rules that extend the FDA-qualified rubric (Q171974) to v4.0. Exploitability metrics read the entry interface, trust levels traversed, countermeasures, configurability, and user interaction. Impact metrics read asset sensitivity on the vulnerable component and everything downstream. If no feasible path exists, the scenario is marked non-exploitable. No questionnaires, no judgment calls.

AVACATPRUIVC / VI / VASC / SI / SA
06

Emit the score with its evidence

Every entry point gets a complete vector, score, and metric-level justification naming the components, interfaces, trust levels, and assets that drove it, cited back to your submission documents. The canonical score is the highest-severity feasible scenario; the others are retained as context. Change the architecture and the score changes with it. Nothing else moves it.

Vector per entry pointCanonical scoreMetric citationsDoc referencesAudit trail
The mapping

From v3.1 vectors to v4 answers.

A v3.1 vector cannot be mechanically converted. The new metrics need information a score alone does not carry. The twin and the dependency graph supply it.

CVSS v3.1 TO v4.0: WHAT MOVES, WHAT IS NEW v3.1 v4.0 AV · Attack Vector AC · Attack Complexity PR · UI S · Scope C / I / A impact Temporal metrics AV · Attack Vector AC · Attack Complexity AT · Attack RequirementsNEW PR · UI VC/VI/VA · vulnerable system SC/SI/SA · subsequent system E · Exploit Maturity AC splits: complexity vs deployment conditions AT answered by the digital twin Scope becomes subsequent system impact, from the dependency graph
AT is answered from the twin’s deployment model. Subsequent system impact comes from the dependency graph.

AT from the twin

Network segmentation, required pairing, physical access assumptions: the digital twin already holds the deployment conditions AT asks about.

Chains from the graph

The dependency graph knows which findings produce the conditions others require, so subsequent system scores reflect real chains, not guesses.

v3.1 and v4, side by side

Every finding carries both scores during the transition. Submissions already in flight stay consistent while new work adopts v4. Nothing gets re-rated by hand on a deadline.

Go deeper

Where the proof gets used.

The same evidence carries the submission, the rating, and the postmarket record.

Get started

Watch a claim become proof.

Bring one device. We build the twin, run discovery, and hand you a verified finding with its executed test case, log, and VEX status. Then a dismissal with the same.

Questions

Common questions about FDA compliant ratings.

What does proof over probability actually mean in practice?

Proof over probability means a finding only counts once the exploit has executed on the real device and the evidence is attached to the verdict. The rule cuts both ways. Not exploitable means the executed test that failed and the reason it failed, so the evidence exists before the verdict does.

Why is a CVSS score not enough on its own?

A CVSS 9.8 describes the worst case deployment of a component, not your device. It predicts, it does not demonstrate. A number pulled from a national database cannot say whether the path is reachable on your build, which is the question both an engineer and a reviewer need answered before anyone spends a sprint on it.

How do you prove that a vulnerability does not apply?

Dismissals carry the same package as confirmed findings, because not affected is a claim that needs proof too. The record holds the test case that ran, the execution log it produced, the observed result, and the VEX status that follows. A reviewer can replay it rather than take the disposition on trust.

Do findings ship on an AI agent's opinion?

Nothing ships on an agent's opinion. Agents explore, chaining protocols and abusing assumptions the way a researcher would, and exploration is allowed to be wrong. A finding graduates only when deterministic logic executes the exploit against the real target and the result reproduces. Creativity proposes, determinism decides.

How does verified evidence connect to SSVC decisions?

A verified finding answers the questions SSVC actually asks. Is the attack automatable, does it end in total compromise of the device, which vectors reach the flaw, and does a working proof of concept exist. Grounded in an executed test, those four answers turn a score into a decision you can defend.

Exploitability management for medical devices. FDA §524B methodologyExploitability proven at runtime95% faster than legacy testing Book a Demo
Platform
OverviewAvoid FDA DeficienciesAvoid Consulting FeesDigital Twin TraceabilityAI PentestingExploitability VerificationVulnerability ChainingRemediation OptimizationRemote TestLink™Incident ResponseAutomated VEX & MetricsCVSSv4 Migration
Solutions
Postmarket SurveillanceIncident ResponseSecurity EngineeringRegulatory AffairsFDA §524BEU MDR/CRAEU REDNIS2IMDRF N60 / N73Japan MHLW
Why ELTON
Subscription TestingAI-NativeFDA ComplianceVerified ExploitabilityELTON vs. Legacy TestingThreat-Led AI PentestingMDDT MethodologyCredentialsDevice ModalitiesPricing
Resources
FDA Deficiency ListFDA Testing RequirementsFDA Cyber SOPs & TemplatesRemediation LibraryRegulatory GuidesWebinarsAI NewsletterThe End of Legacy TestingThe AI Vulnerability ExplosionSecurity AdvisoriesWhitepapersIntelligence & Blog
Company
AboutLeadershipCareersPartnershipsContact Meet ELTON