Glossary, the words of the file
20 terms, each with its reference and the page that explains it. The words of the regulation are those of the Official Journal; euvex's own words say what the product does.
The software and its sources
- SBOMCRA, Annex I, Part II, point 1 · applicable from 11.12.2027
A product's software bill of materials: the list of its components, with their version and identifier. The CRA requires one to be drawn up, “in a commonly used and machine-readable format”.
- CycloneDXCycloneDX 1.5 on export · 1.2 to 1.6 on import
The SBOM format maintained by OWASP. euvex exports it in version 1.5, deterministically: the same inventory always gives the same file. It imports versions 1.2 to 1.6, in JSON.
- purlpkg:type/name@version
Package URL, the identifier of a package, ecosystem included:
pkg:npm/lodash@4.17.21. OSV is queried with it, without confusing two packages of the same name.- CPEcpe:2.3:a:vendor:product
The other component identifier, the one that can name software that is not a package in any ecosystem. The NVD is queried with it; when your SBOM declares one, yours is the one queried.
- OSVapi.osv.dev
Open Source Vulnerabilities, the open database of vulnerabilities in open source components, maintained by Google and fed by the ecosystems themselves. euvex queries it by purl, on upload and at each recheck.
- NVDNIST, United States
National Vulnerability Database, the vulnerability database of NIST, the US standards institute. euvex only queries it for components OSV cannot resolve, by CPE, during scheduled monitoring.
- EUVDEUVD-2021-34768
The vulnerability database of ENISA, the European Union Agency for Cybersecurity. euvex cites its European identifier next to the CVE identifier; it does not use it to find a component's flaws.
- KEVCISA · copy refreshed every six hours
Known Exploited Vulnerabilities, CISA's catalogue of vulnerabilities whose actual exploitation has been observed. It is this catalogue, not severity, that opens an Article 14 case in euvex: the text says “actively exploited”, not “serious”.
- CoverageN out of M
The share of components a source was able to query, shown as “N out of M”. As long as a single component could not be queried, euvex does not conclude that there are no vulnerabilities.
- Not analysedpkg:generic
A component no source could query: a
pkg:genericwith no CPE or exact version, for example. It is never counted as healthy.
The product and its file
- Product lineTerms of use, Art. 8
The product as you place it on the market, the one that carries the CE marking and a declaration. It is recognised by its name: two versions with the same name form a single product line. It is the billing unit, not the version.
- RevisionCRA, Art. 31 and 13(13)
A dated check of a scan: its inventory and the vulnerabilities known that day. Revisions are added without ever being rewritten, and can be exported together as a standalone file, each in CycloneDX.
- Technical documentationCRA, Art. 31 and Art. 13(13)
The file that demonstrates compliance: the description of the product, how each applicable essential requirement is met, and the evidence. It is not published; it is kept at the disposal of the authorities and continuously updated, where appropriate, at least during the support period.
- EU declaration of conformityRegulation (EU) 2023/1230, Annex V · CRA, Art. 28(3)
The short document in which the manufacturer states that the product complies, and lists the texts it complies with. A single one for all the texts that require one. It is drawn up under the sole responsibility of the manufacturer: euvex assembles it, you sign it.
- Support periodCRA, Art. 13(13)
The period during which the manufacturer handles the vulnerabilities of its product. It also counts for retention: the technical documentation and the declaration stay available for at least ten years after the product is placed on the market, or for the support period if it is longer.
- Notified bodyCRA, Chapter IV (Art. 35 to 51)
A conformity assessment body, notified by a Member State, that steps in when the text requires it, depending on the product's category and the standards applied. euvex is not one, and does not replace its involvement.
- EN 18031EN 18031-1, -2, -3:2024 · Implementing Decision (EU) 2025/138
The three harmonised standards for the cyber requirements of the RED: network, privacy, fraud. Applying them gives a presumption of conformity, except on the points their publication in the Official Journal has restricted. They are paid for; euvex's questionnaires follow their structure, not their text.
The three Article 14 deadlines
- Early warningCRA, Art. 14(2)(a) and 14(4)(a) · 24 hours
The first of the three Article 14 CRA notifications: within twenty-four hours of becoming aware of an actively exploited vulnerability or a severe incident.
- NotificationCRA, Art. 14(2)(b) and 14(4)(b) · 72 hours
The second Article 14 notification: within seventy-two hours of becoming aware.
- Final reportCRA, Art. 14(2)(c) · 14 days; Art. 14(4)(c) · 1 month
The third. For a vulnerability, no later than fourteen days after a corrective or mitigating measure is available; for an incident, within one month after the submission of the notification. Never counted from becoming aware.
Frequently asked questions · Getting started · The deadlines, read from the text