Vulnerability Disclosure Policy

This policy describes how we report vulnerabilities in MicroEJ software, how we classify and handle them, and when we disclose them.

Devices built on MicroEJ software may remain in service for many years, and MicroEJ does not have a direct update channel to devices deployed in the field. When a vulnerability is identified, we publish a fix as part of a new software release. The integrator is responsible for delivering and deploying the fix to field devices through its own device update process.

Reporting a Vulnerability

Send security reports to security@microej.com.

Include as much of the following as you have:

The affected module(s).
The MICROEJ SDK version(s) used to build the affected Application.
The MicroEJ Architecture version(s) running the affected Application.
The type of flaw, and the security impact you believe it has.
Steps to reproduce it, the affected source locations, and the configuration needed to reach it.
Your assessment of severity, and whether you believe the flaw is being exploited.

Do not include customer data, credentials, or personal data. Describe what the data was rather than sending it.

Encrypting Your Report

Our PGP key is published on the keyserver of the Computer Incident Response Center Luxembourg (CIRCL), at pgp.circl.lu. It is an RSA 4096-bit key for MicroEJ Security <security@microej.com>.

Import our public key:

curl -sS 'https://pgp.circl.lu/pks/lookup?op=get&search=0x8B80A17E3EDDBDED93419EA705BDA6BD40549D4D' | gpg --import

Or download it from the link above and run gpg --import on the file you saved.

Check that the fingerprint matches. gpg --fingerprint security@microej.com must print:
```
8B80 A17E 3EDD BDED 9341  9EA7 05BD A6BD 4054 9D4D
```
Write your report in a file and encrypt it:
```
gpg --encrypt --armor -r security@microej.com report.txt
```
GnuPG will warn that there is no assurance the key belongs to the named user, because you have not certified it yourself. Having checked the fingerprint, answer yes; add --trust-model always if you are scripting this. Attach the resulting report.txt.asc, or paste it into the body, and send it to security@microej.com.
Keep the subject line generic. PGP never encrypts subject lines or headers.
Attach your own PGP public key if you want an encrypted reply.
A mail client with built-in OpenPGP support — Thunderbird, Proton Mail, Mailvelope — works equally well, with the same key.

As an alternative to email, you can file the report through the CVE Program, at cve.org/ReportRequest. A report filed there reaches us through the CVE Program’s routing, which is slower than writing to us directly.

Do not report a suspected vulnerability through the public forum, our open-source issue trackers, a pull request, or social media. Those channels are public from the moment you post, which removes the option of fixing the flaw before it is known. For anything that is not a suspected vulnerability, use the standard support channels.

Scope

This policy covers the software MicroEJ publishes, including:

MICROEJ VEE and the MicroEJ Architecture packages, including the MEJ32 secure container
MICROEJ SDK and its build tools, including the SOAR linker and the Binary Code Verifier
Libraries and add-on modules published in the MicroEJ Central Repository
MicroEJ-operated online services
The published documentation, where an error in it leads to an insecure configuration

Outside it, because MicroEJ does not control them: firmware, applications, and VEE Ports built by customers or third parties, even when they embed MicroEJ software; devices in the field, which are updated by the party that fielded them; and third-party open-source components not published in the MicroEJ Central Repository, where the flaw is in the upstream project rather than in our integration of it. Modules published in the developer repository are provided “as-is” and are also outside this policy.

If a report concerns a customer product that embeds MicroEJ software, send it to us anyway. We will confirm whether the flaw is ours and, when it is not, tell you who to approach.

What to Expect

Stage	Target
Acknowledgment that we received the report	72 hours
Triage: whether we confirm the flaw, and its severity	14 calendar days
Progress update, repeated until the report is closed	Every 30 days
Publication of the advisory and its CVE record	After the fix is available and integrators have had the opportunity to deploy it, on a date we set (see Coordinated Disclosure)

We treat as a vulnerability any weakness in MicroEJ software that a threat can exploit to defeat a security property the product is meant to hold. A functional defect with no security consequence goes to support instead, and we tell you when we make that call.

A report is received, then triaged once we confirm the flaw and assign a severity, then resolved, then published on a date we set. A report is resolved when a corrected version is published, or when we determine that a fix is neither possible nor desirable: in that case what we publish is the mitigation and the conditions under which the flaw is reachable, not a patch. We tell you at each change.

Until publication, the report is shared only with the people who need it to produce the fix: our security team, the maintainers of the affected component, the release manager for the affected versions, and you.

We do not run a paid bug bounty. We credit reporters who want to be credited, and withhold your name if you prefer.

Severity Classification

We score every confirmed vulnerability with CVSS version 4.0 and publish the vector alongside the score. A CVSS score alone tells an integrator little about embedded software, so we also classify each flaw by what it defeats in the MicroEJ security model. That classification sets the priority the fix is given.

Level	What it covers
Critical	Escape from the secure container into native or privileged execution. Ill-typed or unverified code accepted by the Binary Code Verifier. Defeat of install-time signature verification, or forgery of a valid signature. Compromise of the integrity of a MicroEJ release or of the tools that produce it.
High	Bypass of isolation between Applications, or elevation from an Application to Kernel privileges. Disclosure of Kernel secrets, or of another Application’s data. Code execution in an unprivileged managed context by an unauthenticated party.
Moderate	Denial of service that requires a device reset to recover. Disclosure of internal state that is not itself sensitive but assists another attack. A security control that fails only outside its documented configuration.
Low	A hardening measure that can be bypassed with no direct security consequence. A flaw reachable only by code that is already trusted, or under conditions the product documentation excludes.

A critical or high severity flaw is worked ahead of other engineering work, and its fix may ship as an out-of-cycle release; a moderate or low one is normally carried in a scheduled release. This policy sets no deadline for a fix, because how long one takes depends on the flaw. What we do commit to is a progress update every 30 days until the report is closed.

A flaw drops one level when reaching it requires privileges an untrusted party does not have, or a configuration the documentation already advises against. It rises one level when it is being actively exploited, or when it is reachable on every product built on the affected version rather than in a specific configuration. Because exposure varies so much between devices, the severity in your product may differ from ours, so each advisory states the conditions under which the flaw is reachable and you can classify it yourself.

Coordinated Disclosure

We ask reporters to hold details until the advisory is published. An embargo covers two pieces of work, and only the first is ours.

MicroEJ — confirm the flaw, produce and test the fix, and publish a corrected version.
Integrators — update the dependency, rebuild and re-verify firmware, and get it to devices before the flaw is public.

The second phase is usually the longer of the two. MicroEJ software has no update path of its own to a device, so an advisory published before integrators have shipped exposes a fleet with no fix available to it.

Ninety days from acknowledgment is a reasonable expectation for a straightforward flaw, and we are often well inside it, but it is not a commitment. Where a fix is shipped sooner, we publish sooner. Where the flaw is deep, or the fix needs coordination with silicon vendors, or integrators face a certification cycle before they can rebuild, we will ask you for more time, say precisely what we are waiting on, and continue the 30-day progress updates.

A request for an extension is decided above the level of the person handling your report. If you dispute our severity assessment, our timeline, or a request for an extension, raise it with us: your objection will be reviewed and answered at that level. We ask that you do not disclose the flaw until it has been resolved and the advisory published, and not without our agreement.

Three cases shorten the clock. A flaw that is already public, or about to be published by someone else, gets an advisory as soon as we can describe the impact and a mitigation, whether or not a fix is available. A flaw under active exploitation means we notify the authorities as required by law and warn affected integrators immediately. A legal requirement, or a direction from a competent authority, overrides any embargo we have agreed.

Receiving updates on your report does not require you to sign a non-disclosure agreement. We will not take legal action against a reporter who follows this policy.

Advance Notification for Integrators

Anyone shipping a product built on MicroEJ software can write to security@microej.com to be added to our advance-notification list. Recipients receive, under embargo, the affected versions, the severity level and CVSS vector, the CVE identifier, the fixed version and its expected date, and any interim mitigation. It arrives as soon as we have it, normally well before the public advisory. A request is reviewed rather than granted automatically, because embargoed information given to the wrong recipient is a disclosure, and recipients agree to hold it until the embargo lifts.

Being on the list is not required to receive fixes. Those are published to every customer within the support period. What it provides is lead time.

If you hold a MICROEJ SDK license, the address you register with us is your designated security contact. Keep it valid and monitored, and tell us when it changes. It is where we send written notice that a corrected version is available, and the license attaches two consequences to that notice: you have a set period in which to apply the update, and after it, responsibility for unpatched software is yours. Those terms are set out in the MICROEJ SDK EULA.

What we publish concerns MicroEJ software. An advisory does not identify you, your products, or your customers without your written agreement, unless the law requires it.

Security Advisories

Confirmed vulnerabilities are published as CVE records on the CVE Program portal, at cve.org.

Each advisory states the affected products and version ranges, the severity level and its CVSS vector, the impact, the fixed version, and the mitigation for anyone who cannot upgrade immediately. We request a CVE identifier for every confirmed vulnerability in a MicroEJ product. The identifier is reserved when we confirm the flaw and shared with affected integrators under embargo; the record is published on the date we set.

MicroEJ writes the description and sets the severity. Where a reporter disagrees with either, we acknowledge the disagreement in our reply; the wording and the classification remain ours.

Every confirmed vulnerability at moderate severity or above is published. What we decide is when, not whether: where we judge the risk of publishing to outweigh the benefit, typically because integrators have not yet had the opportunity to get the fix onto devices, we hold the advisory until they have. That hold is not open-ended: the MICROEJ SDK EULA sets the period within which an integrator is expected to apply a security update, and once it has passed we are free to publish, whether or not the fix has reached every device. Where integrators have shipped sooner, we publish sooner. A low severity finding with no security consequence, or a report we classified as a vulnerability and later found not to be one, may be closed without publication.

The portal is free to read: no account, no customer contract, no support agreement. Release notes and the module changelog record that a fix shipped; the advisory is where the security detail is published.

How Fixes Reach a Device

MicroEJ software is a component of a device, not a device. That shapes how a fix reaches the field.

MicroEJ — fix and test the flaw, then publish a corrected module version, with an integrity checksum and an updated software bill of materials. A security update is labeled as such, separately from functional updates, so that it can be deployed on its own and ahead of them.
MicroEJ — notify the integrators on the advance-notification list, under embargo.
Integrator — update the dependency version, rebuild and re-verify the firmware, and deliver it to devices through their own update channel.
MicroEJ — publish the advisory and the CVE record once the embargo lifts.

MicroEJ software contains no over-the-air update mechanism of its own. Step three is the integrator’s, and how long a fix takes to reach a device depends on their release process. Treating the MicroEJ version as a tracked dependency with a defined update route, rather than as a fixed part of the product, is what shortens it.

Supported Versions

Security fixes are provided free of charge within the support period MicroEJ declares for each version it publishes.

That period is the one set by the MICROEJ SDK EULA in force, which at the time of writing is five years. It runs from the first commercial availability of the version, not from the date a contract is signed.

MicroEJ notifies customers in writing at least twelve months before a version reaches the end of its support period. A fix is issued in the supported versions the flaw affects. It is not backported past the end of a support period, where the remedy is the documented upgrade path to a supported version, published before support ends rather than after.

Regulatory Reporting

MicroEJ is subject to the vulnerability reporting obligations of the EU Cyber Resilience Act. A vulnerability in one of our products that is being actively exploited, or a security incident affecting the security of one of our products, is reported to the designated national computer security incident response team and to the European Union Agency for Cybersecurity within the deadlines the regulation sets. Reporting to the authorities is separate from informing our customers: we do both, and a regulatory deadline does not delay a customer notification.

MicroEJ and CVE Program

MicroEJ is currently in the process of applying to become a CVE Numbering Authority (CNA) within the CVE Program. Once the application is approved, the intended scope will be MicroEJ technologies.

Until then, MicroEJ requests CVE IDs through the CVE Program’s designated CNA of Last Resort (MITRE), and coordinates disclosure with affected parties as described on this page.