Complete coverage from automation, depth from senior pentesters, and a record FDA can walk from every finding back to its test case.
You approve the test plan before anything runs, and findings arrive as they land.
Service type, start date and contacts, sent two weeks ahead to services@eltoncyber.com with the Platform Service Order Form.
Order form completed, scope reviewed, materials requested.
Materials, device and software provisioning, accounts and data, ELTON validation of access, and the test plan, which you approve before execution.
The twin, all four lanes, exploitation evidenced. Status updates on plan changes and on any high or critical finding.
Draft findings, your feedback, the final report, a walkthrough on request. Postmarket monitoring begins.
Each window is the minimum set for quality. A shorter one takes the hours out of review, never out of automation.
| What is tested | Postmarket or previously tested | New submission |
|---|---|---|
| Retest of prior findings | 1 to 2 days | 1 to 2 days |
| Application | 1.5 weeks | 2 weeks |
| Physical device | 2 weeks | 2.5 weeks |
| Platform or system | 2.5 weeks | 3 weeks |
The test plan is built from the digital twin and access is validated before a single case runs.
SAST, DAST, fuzzing and pentest-class test cases run across every interface in scope.
Every automated result reviewed, chaining and bypass on the key attack surfaces, exploitation, evidence and the report.
Postmarket and previously tested products receive platform findings or a vulnerabilities report. New submissions and significant updates receive the formal FDA-ready regulatory report. A shorter window shows in the record as fewer test cases run, fewer results reviewed, more findings left unverified, and a thinner traceability matrix for FDA. Ask for the full window and book it two weeks ahead.
Test cases are generated from the digital twin, so coverage is a list before testing starts.
| Lane | What it exercises | How |
|---|---|---|
| SAST | Source and binaries | Static tools built to read the product's own source and interrogate its compiled binaries, including bespoke firmware. |
| DAST | Running services | Dynamic tools generated for the target, reaching into the services the device actually exposes. |
| Fuzzing | Protocol listeners | Malformed traffic through DICOM, HL7, MQTT and proprietary listeners, on the real interface. |
| Pentest-class test cases | Human techniques, encoded | Authentication bypass, session abuse, privilege and trust-boundary crossing, chained access, written as repeatable test cases. |
The twin holds the release’s components, interfaces, data flows, assets, trust boundaries and countermeasures, built from the documentation your quality system already produces. TestLink carries the pipeline onto the physical device, so firmware, serial, radio and proprietary links get the same treatment as the web interface.
The order matters: the automated half covers the plan, then senior pentesters decide exploitability.
Every component, interface and data flow in scope is exercised. A manual engagement working interface by interface runs out of days long before the plan runs out of test cases.
Nothing a tool found is reported unreviewed. Then the hours go where devices fall: authentication and sessions, privilege and trust boundaries, chaining, bypass, proprietary interfaces, and off-plan leads.
A technique that worked against this release is written back as a test case and runs automatically on every release after it. The next test starts where the last one ended.
Every finding is rated first and keeps that rating; exploitability decides its status.
Exploitable on its own from a known entry vector, every precondition met by the product as shipped.
Reachable only while another root cause keeps producing the condition it needs. Fix the root and it closes.
In scope and rated, with no exploit path on this device today. Re-evaluated every time the product changes.
A path that existed, closed by a fix or control, and proven by rerunning the test case that found it.
| Verification tier | What is exercised | Closed as Not Affected |
|---|---|---|
| Level 1, digital twin | Architecture, SBOM, reachability and the security-profile overlay; exploitability reasoned from composition | About 30 to 40 percent, baseline confidence |
| Level 2, code and firmware | Custom harnesses from the real code; static analysis and emulation confirm which paths are reachable | About 50 to 65 percent, strong confidence |
| Level 3, real hardware runtime | Live exploit attempts on the actual device, through TestLink or in the lab | About 70 to 85 percent, highest confidence |
Ratings run through the MDDT-qualified rubric for CVSSv3 and ELTON’s FDA-aligned method for CVSSv4, and the rationale for every status is the dependency graph of entry vectors, conditions and findings on the twin. Not Affected rates describe ELTON’s delivery experience and are illustrative.
The first page still carries the handful to fix; everything after it is why a reviewer accepts that handful as complete.
| Output | When | What it contains |
|---|---|---|
| Findings in the platform | As they land, during execution | Every result on the twin and every finding with its verdict, evidence, rating and disposition, plus status updates on plan changes and on any high or critical finding. |
| Draft findings and recommendations | At test completion | The full record for your review and questions, with a walkthrough on request. |
| Vulnerabilities report | Compliance and milestone tests | Final findings and recommendations after your feedback, with the test case coverage behind them. |
| Formal regulatory report | New product or significant update | Submission-ready: test cases mapped to the architecture and threat model, findings traced to test cases, MDDT-qualified ratings, VEX dispositions, and the history of every test on the release. |
| Living report | On demand, through the term | The current report for a previously tested release, regenerated against today’s CVE set and timestamped. |
How long does an ELTON test take?
It depends on what is tested and why. A retest of prior findings takes one to two days; an application takes one and a half to two weeks, a physical device two to two and a half weeks, and a platform or system two and a half to three weeks, the longer figure for a new submission. Those durations are the floor the statement of work sets for quality.
Why not run the test faster?
A shorter window leaves the automation untouched and takes the hours out of pentester review, chaining and verification. The record shows it as fewer results reviewed, more findings left unverified and a thinner traceability matrix for FDA.
Do you report findings that are not exploitable?
Yes. Every finding is rated and recorded, and exploitability decides its status: directly exploitable, conditionally exploitable, unexploitable weakness or mitigated weakness. FDA asks for a justified disposition on everything found, and a failed test case with no finding attached reads as a missing finding.