Glossary

A vulnerability that is already being used against products in the wild; triggers the 24-hour SRP early warning obligation under Article 14.

The CRA annex listing the categories of important products that fall into Class I and Class II.

The duty to notify ENISA and the relevant CSIRT of actively exploited vulnerabilities and severe incidents within strict deadlines (early warning within 24 hours).

A document or file stored against a dossier — such as an SBOM, test report or Declaration of Conformity — that supports compliance.

The sum of all points where an attacker could interact with a product — interfaces, APIs, updates, storage and dependencies. Minimising it is a core security goal.

The specific path or technique a threat actor uses to reach and exploit a target, for example a network interface or a malicious dependency.

An automatic, tamper-evident record of every create, update and delete action, supporting accountability and audit readiness.

The mark a manufacturer affixes to declare that a product complies with all applicable EU rules, including the CRA, allowing it on the EU market.

A single CRA requirement assessed for a specific dossier, with status and supporting evidence.

Important products listed in Annex III (e.g. password managers, VPNs, network management). Allow self-assessment only if a harmonised standard is applied, otherwise a third party is involved.

The most sensitive important products in Annex III (e.g. hypervisors, firewalls, tamper-resistant microcontrollers). Require third-party conformity assessment.

A 0–100 value automatically calculated from checklist completion to show how ready a dossier is.

The state of a requirement or dossier, such as Not Started, In Progress, Under Review, Compliant or Non-Compliant.

The procedure used to demonstrate that a product meets the CRA's essential requirements, ranging from self-assessment to full third-party evaluation.

A role that can create and edit compliance data such as products, dossiers and evidence, but cannot manage members or settings.

A documented process letting researchers report vulnerabilities responsibly so they can be fixed before public disclosure; required by the CRA.

Risk classification that determines how strict the conformity route is: Default, Class I (important) or Class II (critical).

A Computer Security Incident Response Team designated as coordinator that receives CRA vulnerability and incident reports for its member state.

A Common Vulnerabilities and Exposures identifier — a unique public ID assigned to a known security flaw, e.g. CVE-2024-12345.

EU regulation that sets mandatory cybersecurity requirements for products with digital elements placed on the EU market, across their whole lifecycle.

An open SBOM standard, widely used for security use cases; one of the two formats the platform accepts.

The lowest CRA risk tier, covering most products. Conformity can be demonstrated through self-assessment.

Layering multiple independent security controls so that the failure of one does not expose the whole system.

Making a product or service unavailable to legitimate users by exhausting its resources or crashing it.

An operator in the supply chain, other than the manufacturer or importer, that makes a product available; must check CE marking and required documents are present.

The digital compliance file the platform creates for each product, gathering its checklist, evidence, policies and documentation.

Gaining higher permissions than intended, allowing an attacker to perform restricted actions.

The European Union Agency for Cybersecurity, which operates the single reporting platform for CRA incident and vulnerability notifications.

The baseline security properties and vulnerability-handling duties set out in Annex I that every in-scope product must meet.

The manufacturer's signed statement that a product meets the CRA's essential requirements; it must accompany the product.

Documents, notes or artefacts attached to a checklist item to prove a requirement has been met.

An organisation-wide security policy (e.g. SDL, vulnerability disclosure, incident response) that can be inherited by product dossiers.

An EU-referenced technical standard; applying it grants a presumption of conformity with the corresponding CRA requirements.

An estimate of how damaging a threat would be if realised, combined with likelihood to form a risk score.

An operator placing a product from outside the EU onto the EU market; must verify the manufacturer carried out conformity assessment and documentation.

The organisation's planned process for detecting, handling and reporting security incidents, including CRA notification duties.

Exposure of confidential data to people who should not have access, for example through weak encryption or leaky logs.

A publicly documented flaw, typically tracked as a CVE. Annex I requires products to be delivered without known exploitable vulnerabilities.

Granting each user, process or component only the minimum permissions it needs, limiting the impact of a compromise.

An estimate of how probable a threat is to occur, typically rated on a scale and combined with impact to form a risk score.

The core duties under Article 13: secure design, vulnerability handling, documentation, conformity assessment and reporting throughout the support period.

The national body that monitors products on the market and can require corrective action, withdrawal or recall of non-compliant products.

An independent organisation designated by an EU member state to carry out third-party conformity assessments, required for Class II products.

Automatic propagation of global policies to product dossiers, with the option to override them per product.

The legal assumption that a product meets CRA requirements when it conforms to a relevant harmonised standard.

Any software or hardware product, and its remote data-processing solutions, whose intended use includes a direct or indirect data connection. The CRA applies to PDEs.

The official legal reference for the Cyber Resilience Act, in force since December 2024 with main obligations applying from December 2027.

A user or system denying that an action took place because it was not reliably logged; countered by strong audit trails.

The platform's catalogue of CRA requirements with descriptions and guidance, used to build dossier checklists.

A derived value combining likelihood and impact to rank threats and prioritise mitigation.

Granting permissions based on a user's role. The platform defines four roles: Super Admin, Tenant Admin, Contributor and Viewer.

A database mechanism that filters every query so users can only access rows belonging to their own tenant; the platform's core isolation layer.

Shipping a product in its most secure state out of the box, for example without default passwords and with unnecessary features disabled.

A defined process that embeds security activities into every phase of development, from design through release and maintenance.

Building security into a product from the start rather than adding it later — a core principle of Annex I Part I.

A patch that fixes a vulnerability, which manufacturers must provide free of charge and in a timely manner throughout the support period.

A security incident with a significant impact on a product's security or on user data; triggers the 24-hour SRP early warning obligation under Article 14.

The seriousness of a vulnerability, usually rated Critical, High, Medium or Low, used to prioritise remediation.

ENISA's central portal that manufacturers use to file all CRA vulnerability and incident reports; live for Article 14 reporting from 11 September 2026.

Marking a record as deleted (with a timestamp) instead of removing it, so history is preserved and the audit trail stays intact.

A machine-readable inventory of all software components and dependencies in a product, required by the CRA to track vulnerabilities.

An open SBOM standard originally focused on licensing; one of the two formats the platform accepts.

Pretending to be another user, device or service to gain unauthorised access — the identity-related threat in STRIDE.

First stage of the Article 14 reporting cadence: notify ENISA within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, indicating affected Member States and — for an incident — whether it is suspected to be malicious.

Third stage of the Article 14 cadence: submit the root cause, applied mitigations and cross-border effects — within 14 days of a fix being available for a vulnerability (Art. 14(2)(c)), or within one month of the notification for a severe incident (Art. 14(4)(c)).

Second stage of the Article 14 cadence: within 72 hours, submit general information on the nature, severity and any indicators of compromise for the event.

A threat-classification framework covering six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege.

The time a manufacturer must provide security updates, normally at least five years or the product's expected lifetime if shorter.

Unauthorised modification of data, code or configuration, for example altering firmware or messages in transit.

A trackable work item with status, priority and due date, used to manage the activities needed to reach compliance.

The evidence file described in Annex VII (design, risk assessment, SBOM, test results) that proves CRA conformity and must be kept for at least ten years.

An isolated customer workspace. The platform is multi-tenant: each organisation's data is separated and never visible to others.

The administrator of a single workspace, who manages members, settings and all compliance data within their tenant.

The type of adversary considered in a threat model, such as a remote external attacker, an opportunistic mass scanner, an insider or a supply-chain actor.

A structured analysis of how a product could be attacked, used to derive concrete security requirements. The platform uses a STRIDE-light approach.

A read-only role that can view compliance data but cannot make changes.

A weakness in a product that can be exploited to compromise its security; the CRA requires products to ship without known exploitable vulnerabilities.

An automated check of a product's SBOM against vulnerability databases to find components affected by known CVEs.