Glossary

CRA and embedded security glossary

Short definitions of terms that come up in CRA compliance and product security. Each term has its own link; our guides link here.

Legislation and roles

CRA (Cyber Resilience Act): Regulation (EU) 2024/2847. Sets common cybersecurity requirements for products with digital elements on the EU market. See the CRA guide.
Product with digital elements: A software or hardware product, and its remote data processing solutions, whose intended use includes a direct or indirect data connection to a device or network (Article 3(1)).
Manufacturer: A person or organisation that develops or has a product with digital elements developed and markets it under its own name or trademark. Most CRA obligations sit with the manufacturer.
Importer: A person or organisation established in the EU that places on the EU market a product from a manufacturer outside the EU (Article 19).
Authorised representative: A person or organisation established in the EU that carries out specified tasks on the manufacturer's behalf under a written mandate. Appointing one is optional under the CRA (Article 18).
Important product (Class I and II): Products listed in Annex III whose core functionality carries a higher cybersecurity risk. See product classes.
Critical product: Products listed in Annex IV: hardware devices with security boxes, smart meter gateways, smartcards and secure elements.
Notified body: A body notified to the Commission by a Member State and authorised to carry out third-party conformity assessment.
Harmonised standard: A European standard whose reference is published in the Official Journal of the EU. Applying it gives a presumption of conformity with the requirements it covers.
EU declaration of conformity: The document in which the manufacturer declares that the product meets the essential requirements (Article 28, Annex V).
CE marking: The marking showing that a product conforms to the applicable EU legislation. For CRA products it is affixed after the conformity assessment (Article 30).
Technical documentation: The file showing how the product meets the requirements (Annex VII): design, risk assessment, vulnerability handling processes, SBOM and test reports. Kept for 10 years or the support period.
Support period: The period during which the manufacturer commits to handling vulnerabilities effectively. It reflects the expected use time of the product and is generally at least five years (Article 13(8)).

Reporting and incident handling

Actively exploited vulnerability: A vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission (Article 3(42)). Reporting is mandatory; see Article 14.
Severe incident: An incident that affects the security of the product and negatively affects the protection of data or functions, or leads to malicious code being executed (Article 14(5)).
CSIRT (coordinator): Computer security incident response team. CRA reports go to the CSIRT a Member State designated as coordinator and to ENISA.
ENISA SRP: ENISA's Single Reporting Platform. The portal for Article 14 reports; it forwards each report to the coordinating CSIRT and to ENISA at the same time.
Coordinated vulnerability disclosure (CVD): A process in which the finder reports a vulnerability to the manufacturer and details are not shared until a fix is ready. The CRA requires manufacturers to have a CVD policy.
security.txt: A file that publishes a site's security contact details at a standard location (/.well-known/security.txt), defined in RFC 9116.

SBOM and vulnerability data

SBOM (software bill of materials): A machine-readable list of the components, versions and dependencies inside software or firmware. CRA Annex I Part II(1) requires an SBOM covering at least the top-level dependencies. See what is an SBOM.
CycloneDX: A security-focused SBOM format developed by OWASP. It can also carry vulnerability and VEX information.
SPDX: An SBOM format developed by the Linux Foundation and standardised as ISO/IEC 5962; strong on licence information.
VEX: Vulnerability Exploitability eXchange. A document stating whether a vulnerability is actually exploitable in a product (not affected, affected, fixed, under investigation).
CSAF: Common Security Advisory Framework. An OASIS standard for publishing security advisories and VEX information in machine-readable form.
OpenVEX: An open format that carries VEX information as minimal JSON.
CVE: A unique identifier for a publicly known vulnerability (for example CVE-2024-3094).
CPE: A standard naming scheme for products and software; NVD vulnerability records are matched through CPE.
PURL (package URL): An address format identifying a software package by ecosystem, name and version (for example pkg:npm/lodash@4.17.21).
OSV: An open-source vulnerability database and format that can be queried by package name and version.
NVD: The US National Vulnerability Database; adds CVSS scores and CPE matching to CVE records.
CVSS: A system scoring the technical severity of a vulnerability from 0 to 10.
EPSS: Exploit Prediction Scoring System. Estimates the probability that a vulnerability will be exploited in the next 30 days (FIRST).
CISA KEV: The US CISA catalogue of vulnerabilities known to be exploited. A strong prioritisation signal; under the CRA the manufacturer makes the "actively exploited" decision.

Device security

Secure boot: A mechanism that lets a device run only software whose signature has been verified.
OTA update: Updating firmware remotely over a network. The CRA requires security updates to be distributed securely and, where possible, automatically.
A/B partitions: A layout with two firmware slots. The update is written to the inactive slot; if the new version fails to boot, the device returns to the old one.
Anti-rollback: A counter mechanism that prevents a device from being returned to an older firmware version with known vulnerabilities.
Hardware root of trust: Immutable hardware and code where a device's chain of trust starts (for example the ROM bootloader and a key digest stored in eFuses).
Secure element: A separate security chip that protects keys and cryptographic operations against physical attacks.
PUF: Physically Unclonable Function. An identity or key derived from microscopic manufacturing differences of a chip that cannot be copied.