Terminology

CRA glossary

The Cyber Resilience Act comes with a lot of vocabulary. Here is every term you keep meeting, defined in a sentence or two, in plain language.

Back to all articles

Actively exploited vulnerability

A vulnerability being used in a real attack, which triggers CRA reporting.

An actively exploited vulnerability is one that is being used in an attack, not merely one that exists or was reported to you. Under Article 14, an actively exploited vulnerability in your product triggers the reporting clock: a 24-hour early warning, a 72-hour notification, and a final report no later than 14 days after a corrective or mitigating measure is available.

Annex III

The list of important product categories that face a stricter conformity route.

Annex III names the categories of important products with digital elements, split into two classes by risk. Products on this list face stricter conformity routes than the default. Examples named in the CRA's higher-risk classes include operating systems, password managers, certain network and security products, and industrial or safety-related components. If your product is not on the Annex III list, it is in the default category, the cheapest compliance path.

Authorised representative

An EU-based party a non-EU manufacturer appoints to hold documents and liaise with authorities.

A non-EU manufacturer may appoint an EU-established authorised representative to carry out specified tasks, such as keeping the technical documentation available and cooperating with authorities. An authorised representative holds documents and acts as a contact point; they do not create your technical file or take on your reporting duty.

CE marking

The mark that says a product meets the applicable EU requirements, including the CRA.

The CE mark is the manufacturer's declaration that a product meets the EU requirements that apply to it. From 11 December 2027, a product with digital elements needs to meet the CRA to carry the CE mark and be sold in the EU. No compliant technical file means no CE mark, which means no EU sales.

Conformity assessment

The process of checking and demonstrating that a product meets the requirements.

Conformity assessment is how you show a product meets the CRA's essential requirements. For most products this is a self-assessment the manufacturer carries out. For higher-risk categories it can require a third party. The route depends on how the product classifies under Annex III.

Coordinated vulnerability disclosure (CVD)

A policy for receiving and handling vulnerability reports and disclosing fixes in a coordinated way.

Coordinated vulnerability disclosure is the practice of receiving vulnerability reports from outsiders, fixing the issue, and disclosing it in a way that is coordinated with the reporter rather than dropped without warning. The CRA expects manufacturers to have a CVD policy. In practice you publish a policy, monitor a contact address, and agree a disclosure timeline with reporters.

Critical product

The highest-risk category, subject to the strictest conformity requirements.

Critical products with digital elements are the highest-risk categories the CRA identifies. They are subject to the strictest conformity requirements, which can include mandatory third-party assessment or European cybersecurity certification. Few products fall here, but if yours might, confirm it early.

CSIRT

The national Computer Security Incident Response Team you report to.

A Computer Security Incident Response Team is a national body that receives and coordinates cybersecurity incident reports. Under the CRA, you notify the CSIRT designated as coordinator in the Member State where your business has its main establishment in the Union. That CSIRT shares the report with other Member States where your product is available.

CVE

A public identifier for a specific known vulnerability.

A CVE (Common Vulnerabilities and Exposures) identifier is a unique reference for a publicly known vulnerability, such as CVE-2024-12345. Screening your SBOM against CVE and similar databases tells you whether your components carry known flaws, which matters for the requirement not to ship known exploitable vulnerabilities.

Cyber Resilience Act (CRA)

The EU regulation that sets cybersecurity rules for products with digital elements.

Regulation (EU) 2024/2847, the Cyber Resilience Act, sets mandatory cybersecurity requirements for products with digital elements sold in the EU. It covers hardware and software, puts most of the duties on the manufacturer, and applies whether or not the manufacturer is based in the EU. Reporting duties start on 11 September 2026 and the full regulation applies from 11 December 2027.

Declaration of Conformity

The manufacturer's signed statement that a product meets the CRA.

The EU Declaration of Conformity is the document in which the manufacturer states, on its own responsibility, that the product meets the applicable requirements. Signing it is what lets you affix the CE mark. The manufacturer remains responsible for it, which is why the technical file behind it has to be real.

Default category

Products not listed as important or critical; they can self-assess.

If your product is not named in Annex III (important) or as a critical product, it sits in the default category. Default-category products can be self-assessed by the manufacturer. This is where most products land, which is why the majority of manufacturers can comply without a notified body.

Distributor

A party in the supply chain that makes a product available, other than the manufacturer or importer.

A distributor makes a product available on the market without being the manufacturer or the importer. Distributors must check that the CE mark and documentation are present before selling. Like importers, they cannot take on the manufacturer's core CRA obligations.

ENISA

The EU Agency for Cybersecurity, which operates the reporting platform.

ENISA is the European Union Agency for Cybersecurity. Under the CRA it operates the Single Reporting Platform and receives the notifications manufacturers submit, alongside the coordinator CSIRT. ENISA has also published onboarding guidance for the platform.

Essential requirements (Annex I)

The security properties and processes every in-scope product must meet.

Annex I of the CRA lists the essential cybersecurity requirements. Part I covers product properties, such as being secure by default, protecting data, and being free of known exploitable vulnerabilities at release. Part II covers vulnerability-handling processes the manufacturer must run, such as coordinated vulnerability disclosure and timely security updates. Your assessment works through these requirements.

Harmonised standard

A standard that, once cited, gives a presumption of conformity with the CRA.

A harmonised standard is a European standard that, once its reference is published in the Official Journal, lets a manufacturer that applies it presume conformity with the corresponding CRA requirements. Until such standards are cited for the CRA, assessment runs against the regulation's Annex I requirements directly.

Important product

A product in Annex III, in either Class I or the higher-risk class, facing a stricter route.

Important products are the Annex III categories. They are split into two classes by risk. The lower class may self-assess when harmonised standards are applied, and otherwise leans toward a notified body. The higher class involves a third party. Vandorisk's classifier tells you which class your product falls in.

Importer

The EU-established party that places a non-EU product on the EU market.

An importer places a product from a non-EU manufacturer on the EU market. Importers have their own CRA duties, and the main one is to check that the manufacturer did their job: that the CE mark and the required documentation exist before the product is sold. If they do not, the compliant action for the importer is to stop selling the product.

Manufacturer

The party that develops or makes a product, and carries most CRA duties.

Under the CRA the manufacturer is the party that develops or manufactures a product with digital elements, or has it developed and markets it under their own name. The technical file, the Declaration of Conformity, the security-by-design evidence, and the incident and vulnerability reporting all sit on the manufacturer. These duties cannot be handed to an EU importer or distributor.

Market surveillance authority

The national authority that enforces the CRA and can act against non-compliant products.

Each Member State designates market surveillance authorities that enforce the CRA. They can request your documentation, require corrective action, and ultimately restrict or withdraw a non-compliant product from the market. They are one reason the technical file has to actually exist and be available.

Notified body

An accredited third party that performs conformity assessment for higher-risk products.

A notified body is an independent organisation designated to assess conformity for the product categories that cannot be fully self-assessed. Under the CRA this applies mainly to important products in the higher class and to critical products. Engaging one costs money and time, which is why knowing your classification early matters.

Product with digital elements

Any hardware or software product that can connect or process data, as defined by the CRA.

The CRA's term for what it covers: a software or hardware product, and its remote data-processing solutions, placed on the market. This is broad. A connected device, a piece of firmware, a mobile app, an operating system, a password manager, a VPN client, and a library sold commercially can all be products with digital elements. Pure online services with nothing to download or install are generally outside scope, unless the cloud service is the remote backend a covered product depends on to work.

See also: Cyber Resilience Act (CRA), Remote data processing

Reporting obligations (Article 14)

The 24-hour, 72-hour, and 14-day or one-month CRA reporting clocks.

Article 14 requires manufacturers to report actively exploited vulnerabilities and severe incidents on a fixed timeline: an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report (no later than 14 days after a corrective measure is available for a vulnerability, or within one month of the notification for an incident). Reports go through the ENISA Single Reporting Platform to your coordinator CSIRT and are available to ENISA. These duties start on 11 September 2026.

Risk assessment (Article 13)

The mandatory analysis that drives which requirements apply to your product.

The CRA requires a cybersecurity risk assessment for the product, and it must be documented in the technical file. It considers the product's intended purpose, reasonably foreseeable misuse, the environment it runs in, the assets it protects, and the threats it faces. The outcome drives which essential requirements apply and how, with a written justification for anything you treat as not applicable.

SBOM (Software Bill of Materials)

A machine-readable inventory of the software components in your product.

A Software Bill of Materials lists the components, including open-source dependencies, that make up your software. The CRA expects manufacturers to identify and document the components in their products, and an SBOM is how that is done in practice. It also lets you screen those components against known vulnerabilities, which becomes evidence in your technical file. Common formats are SPDX and CycloneDX.

Secure by default

The product ships in a secure configuration out of the box.

Secure by default means a product's out-of-the-box settings are the safe ones, so a user who changes nothing is still protected. No default passwords, unused features off, and safe options preselected are typical examples. It is one of the essential product requirements in Annex I.

Secure by design

Building security into a product from the start, not bolting it on later.

Secure by design means the product is developed so that security is a property of how it is built, not an afterthought. Under the CRA this shows up as essential requirements like shipping with a secure default configuration, minimising attack surface, protecting data, and not releasing with known exploitable vulnerabilities. The technical file documents how you did this.

security.txt

A standard text file that tells researchers where to report security issues.

security.txt is a small text file published at /.well-known/security.txt on your domain. It lists your security contact, a link to your policy, and an expiry date, so researchers and automated tools know where to send a report. It is the cheapest credibility signal you can publish and supports the single-point-of-contact expectation.

Self-assessment

The manufacturer assesses its own product against the requirements, without a lab.

For most products, the CRA lets the manufacturer perform the conformity assessment itself and sign its own Declaration of Conformity. The regulation expects this for the majority of products. Self-assessment is documentation work: you show your product meets the essential requirements and you keep the evidence. It is not a lighter obligation, but it does not require a notified body.

Severe incident

A security event serious enough to trigger CRA reporting.

Under Article 14, an incident affecting the security of your product counts as severe when it negatively affects, or could negatively affect, the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions, or it has led, or could lead, to the execution of malicious code. A severe incident triggers a 24-hour early warning, a 72-hour notification, and a final report within one month of the notification.

Single point of contact (SPOC)

The contact a manufacturer publishes for vulnerability reports.

The CRA expects manufacturers to provide a single point of contact for reporting vulnerabilities, and to make it easy to find (see Article 13). In practice this is a monitored address, such as a security email, referenced from your disclosure policy and your security.txt file.

Single Reporting Platform (SRP)

The ENISA platform through which CRA reports are filed.

The Single Reporting Platform, established under Article 16 of the CRA and operated by ENISA, is the electronic channel through which manufacturers submit their Article 14 reports. Registering for it in advance, before an incident, is part of being ready for the 24-hour clock.

Substantial modification

A change to a product significant enough to trigger a fresh conformity assessment.

A substantial modification is a change to a product after it is on the market that affects its compliance or changes its intended function in a way the original assessment did not cover. When one happens, the product is treated as newly placed on the market, so the conformity assessment and the technical file need to be revisited. A routine security update to fix a vulnerability is generally not a substantial modification.

Support period

The time a manufacturer must provide security updates for a product.

The CRA requires manufacturers to handle vulnerabilities and provide security updates for a defined support period, which reflects how long the product is reasonably expected to be in use and is at least five years for many products (see Article 13). The support period is stated to users and recorded in the technical file.

Technical file (Annex VII)

The documentation package that proves your product meets the CRA.

The technical documentation described in Annex VII is the evidence pack behind your Declaration of Conformity. It describes the product, the risk assessment, how the product meets the essential requirements, the vulnerability-handling process, and the support period. You keep it and make it available to authorities. It cannot be backfilled at the last minute because it documents how you actually built and maintained the product.

See also: Declaration of Conformity, Risk assessment, Support period

Vulnerability disclosure program (VDP)

The public policy plus internal process that lets outsiders report security flaws to you.

A vulnerability disclosure program is the practical implementation of coordinated disclosure. It is a public promise (where to report, what you will do, and safe harbour for good-faith researchers) plus a private process (who reads reports, how you triage and fix, and how you coordinate disclosure). A VDP is not a bug bounty; it does not pay for findings.

Vulnerability handling

The processes a manufacturer runs to find, fix, and disclose security flaws.

Annex I Part II sets out the vulnerability-handling processes a manufacturer must run: identifying and documenting vulnerabilities and components, addressing them without delay through updates, applying a coordinated vulnerability disclosure policy, and providing a contact address for reporting. This is the process side of the CRA, separate from the product properties.