Every major vulnerability needs a disclosure like this; ELTON builds it automatically for its customers, and this is that disclosure as a template you can complete by hand.
Enter your details and the blank template and the ELTON completed example open right here, both free, as raw DOCX.
Every major vulnerability a manufacturer discloses needs a statement like this, and for ELTON customers the platform produces it for every affected product from data it already holds.
The moment a major vulnerability lands, the platform reads your product data, tests exploitability on the real device, and fills the statement with evidence, for every affected product. The completed example here was built that way.
This is the same statement as a blank template. Download it, complete it by hand, and see exactly what a defensible disclosure contains. It is the work ELTON does for you, written out so you can do it yourself.
ELTON fills each part of this statement from platform data automatically, with the eMudhra forever vulnerability as the worked example.
The digital twin already holds every TLS implementation and its trust source for each onboarded product, so ELTON enumerates which products carry the affected element across the portfolio, with no new scan.
The twin shows the components, interfaces, dataflows and trust stores for each product, and which connections depend on the affected CA, down to the TLS stack.
The agentic pipeline presents a forged chain for the device's real hostname through TestLink, on the physical product, and records whether each client accepts it, checks revocation, and enforces a pin.
Each connection resolves to Directly exploitable, Conditionally exploitable, Unexploitable weakness, or Mitigated weakness, through the dependency graph, with the evidence attached.
The disposition, the data at risk, the fix and its status, and the two test cases are written into the disclosure and the VEX. The completed example is that output.
Once the update is built, the pipeline runs the attack again against the entire physical product in the lab and confirms the fix, then reruns the same test case.
The components, interfaces, dataflows, trust stores and the controls already in place, so the reader sees exactly what is affected and what is not.
Entry vectors, preconditions and postconditions for each affected connection, not a single blanket severity for the whole device.
Directly exploitable, Conditionally exploitable, Unexploitable weakness, or Mitigated weakness, stated the same way for every connection.
What each affected connection carries and its CIA impact, so a customer can weigh their own deployment rather than guess.
Affected or not affected, written so a customer's tooling can read the verdict straight out of the document.
The remediation and its status, with the two test cases: the one that found the exposure and the one that verifies the fix on the device.
No. For ELTON customers the platform builds the disclosure automatically, for every affected product, the moment a major vulnerability lands. It reads the product data it already holds, tests exploitability on the real device, and fills the statement with evidence. The blank template is the manual version of that same work, for any manufacturer to complete by hand.
Yes, both are free. The blank manufacturer-neutral template is the full structure for your own process, and the ELTON example is a finished statement, generated automatically from platform data for a fictional infusion system. Download either or both as raw DOCX.
FDA expects manufacturers to monitor fielded devices for new cybersecurity vulnerabilities after clearance and to communicate risk to users as part of postmarket management under Section 524B. A disclosure that shows how you located the exposure, what it affects, and your remediation status is what that communication looks like.
Under the EU Cyber Resilience Act, a manufacturer that becomes aware of an actively exploited vulnerability in its product files an early warning with its CSIRT and ENISA within 24 hours, then follows up as the picture firms up. A disclosure structured in advance is what lets you file inside that clock. The CRA page walks through the reporting timeline.
A VEX is a Vulnerability Exploitability eXchange statement: a machine-readable record of whether a given product is affected by a vulnerability, and why. Including one lets a customer's own tooling read your verdict instead of reading a PDF by hand, and it is the difference between a claim and an auditable statement.