Reporting a Security Vulnerability

Embedded Systems Academy (EmSA) welcomes reports of suspected security vulnerabilities in its products. This page is the single point of contact for such reports. It states how to reach us, what we do with your report, and what we ask of you in return.

How to report

Write to sec@em-sa.com, or use the contact form with "Security" as the subject. Both reach the same people. Please report in English or German.

If you have evidence that the vulnerability is already being exploited, put the word "exploited" in the subject line as well, and say so in your first sentence. That finding carries legal reporting deadlines for us, and it is the one thing we cannot afford to learn about late.

If exploitation is under way right now, telephone us rather than wait for a reply. The numbers for Europe and for North America are on the contact page. Say that you are calling about an actively exploited vulnerability and you will be put through. Between the two offices the telephone is answered from the European morning to the Californian evening on every business day.

If you consider the matter sensitive enough to warrant encryption, say so in a first message without technical detail and we will arrange a channel with you.

What this policy covers

This policy covers the PC software, embedded software, firmware and hardware products that EmSA places on the market, and the websites EmSA operates.

It does not cover the products of other manufacturers that embed an EmSA component. If you found the issue in such a product, please report it to that manufacturer as well. Where the cause lies in an EmSA component, we coordinate with them on the fix and on the timing of any public statement.

What a useful report contains

Whether you have any evidence that the vulnerability is already being exploited, and what that evidence is.
The affected product, and its version or firmware release.
A description of the suspected vulnerability and the impact you expect it to have.
Enough technical information for us to reproduce or verify the issue.
Where available: configuration details, the affected interfaces, logs, screenshots and proof-of-concept information.
Your contact details, so that we can come back to you with questions.

Please do not include data belonging to your customers or to third parties. A description of the data a flaw exposes is more useful to us than a sample of it.

An incomplete report is still worth sending. We would rather ask you for the missing piece than never hear about the problem.

What we do with your report

We acknowledge every report on the next business day after it reaches us. Reports are worked in the order they arrive, with one exception: anything indicating that a vulnerability is already being exploited goes to the front of the queue.

From the acknowledgment onward:

We determine whether the report describes a vulnerability in an EmSA product, and we tell you the outcome within ten business days.
We score confirmed vulnerabilities using CVSS v4.0 and establish which released versions are affected.
We prepare a fix or a documented mitigation, and we inform the customers and integrators whose products are affected.
Where we establish that a vulnerability in one of our products is being actively exploited, or that a severe incident has affected the security of one of them, we notify the competent CSIRT and ENISA as required by Regulation (EU) 2024/2847, the Cyber Resilience Act: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days of a corrective or mitigating measure becoming available.
We publish an advisory when the fix or the mitigation is available.

We keep you informed as this runs. If a fix is going to take longer than we first estimated, we tell you that rather than go quiet.

One limit, stated plainly. We read reports written by people. Bulk output from automated scanners, submissions that demonstrate no impact on an EmSA product, and repeated resubmissions of the same claim may be closed without an individual response, so that the queue stays open for reports describing a real problem. If your report is closed and you believe that was wrong, say so and we will look again.

Coordinated disclosure

We ask that you give us a reasonable opportunity to investigate and remediate before you disclose publicly. Our working assumption is 90 days from the day your report reaches us. If a fix needs longer, we will tell you why and propose a new date. Where a vulnerability is already being exploited, we act faster, and we will say so.

We do not ask for indefinite silence. If we decide not to fix an issue, or if we cannot, we will tell you that and explain the reasoning, so that you can make your own decision about publication.

Products of this kind reach end users through machine builders and system integrators, who need time of their own to roll a firmware update out to installed equipment. That is usually what governs the schedule, and we will be specific about it rather than ask you to wait without a reason.

Good-faith research

EmSA will not pursue legal action against anyone who reports a vulnerability to us in good faith and who, in the course of the research:

stays within the scope of this policy;
does not access, modify or delete data belonging to others;
does not degrade the availability of any system or service;
does not use the finding to extract payment from us or from anyone else; and
gives us the opportunity to respond before disclosing publicly.

Test against equipment you own or are authorized to test. We cannot grant you permission to test a system operated by one of our customers.

Credit and rewards

We name the reporter in the advisory that accompanies a fix, unless you ask us not to. Tell us the name or handle you want used.

EmSA does not operate a bug bounty program and offers no payment for reports.

Machine-readable contact

The same contact details are published as security.txt, in the format defined by RFC 9116.

Last updated: 11 September 2026.

EmSA