CRA Compliance Glossary

Key terms and definitions to help you navigate the Cyber Resilience Act with confidence.

Acceptable Risk

Risk that is deemed tolerable for the intended and reasonably foreseeable use of a Product with Digital Elements (PDE), considering the state of the art, health and safety of users, and broader security objectives. Acceptability is determined against defined risk acceptance criteria established during the risk assessment process.

Activity
A set of cohesive, interrelated tasks performed to achieve a specific goal within the product lifecycle, such as threat modeling, vulnerability triage, or update deployment. Activities form the basis of structured workflows in secure development and compliance management.
Advisory

A formal communication issued by a manufacturer, CSIRT (Computer Security Incident Reponse Team), or researcher to inform stakeholders of a known vulnerability, including its potential impact, recommended mitigation, and guidance on remediation. Advisories are central to coordinated vulnerability disclosure (CVD) and must be publicly accessible.

Architecture Review
A security-focused evaluation of the product’s technical design, used to verify that critical components (e.g., authentication, data flow, cryptography) and their interactions are implemented securely. Often related to early-stage threat modeling and required to support the technical documentation for the CRA.
Asset
Any resource that has value to an individual, an organization or a government. In cybersecurity, assets include software, hardware, data, credentials and infrastructure.
Authenticity
The property ensuring that an entity (user, system, or device) is who or what it claims to be. Authenticated identity is essential for access control and secure communication.
Availability
The property that ensures a system, service, or data is accessible and usable upon demand by authorized users, under agreed conditions. Availability is a core component of the CIA triad and a key security objective under the CRA.
CRA (Cyber Resilience Act)
An EU regulation (Regulation (EU) 2024/2847) that introduces mandatory cybersecurity requirements for products with digital elements placed on the EU market. he CRA mandates secure-by-design and secure-by-default principles, robust vulnerability management, and long-term security maintenance.
CE Marking
A mandatory conformity marking indicating that a product complies with applicable EU legislation, including the CRA. The CE mark may be self-declared (for Class I) or issued following assessment by a Notified Body (for Class II and Critical). It is required prior to placing a product on the EU market.
CI/CD (Continuous Integration / Continuous Delivery)
Automated software development pipelines that integrate code changes, run tests, and deploy updates continuously. Under CRA, security tools such as SAST, DAST, SBOM generation, and dependency scanning must be embedded within CI/CD processes to support secure software development and continuous compliance.
Confidentiality
The property that ensures information is accessible only to authorized individuals, entities, or processes. Confidentiality is maintained through encryption, access controls, and data protection mechanisms.
Conformity Assessment

The process used to demonstrate that a product meets specific requirements. Who can do this, depends on the product class:

  • Class I: Self-assessment by the manufacturer.
  • Class II / Critical: Involves a Notified Body (external review)
CVD (Coordinated Vulnerability Disclosure)
A formal, collaborative process for reporting, validating, and resolving cybersecurity vulnerabilities. CVD involves the manufacturer, external researchers, and a Computer Security Incident Response Team (CSIRT). CRA mandates CVD procedures to ensure timely and responsible handling of vulnerabilities.
CVE (Common Vulnerabilities and Exposures)
A standardized system for identifying, cataloging, and naming publicly known cybersecurity vulnerabilities. CVE identifiers enable consistent communication across organizations and tools, supporting vulnerability tracking and remediation.
DAST (Dynamic Application Security Testing)
A testing methodology that analyzes an application while it is running. DAST identifies runtime vulnerabilities such as injection flaws, broken authentication, insecure configurations, and business logic errors. Typically performed in staging or pre-production environments.
(Software) Dependency
A relationship in which one software component relies on another (e.g., libraries, frameworks, SDKs). Dependencies must be accurately documented in the SBOM to enable supply chain transparency and vulnerability tracking.
DoC (Declaration of Conformity)
A legally binding document signed by the manufacturer, declaring that the PDE complies with all applicable EU legislation, including the CRA and other relevant directives. The DoC is required prior to affixing the CE mark. It must be available upon request and accompany the product or its packaging.
EOL (End of Life)

The point at which a manufacturer ceases to provide updates, support, or security patches for a product. Under the CRA:

  • EOL must be clearly communicated in user documentation.
  • Technical documentation (including final SBOM, risk assessment, and change logs) must be archived and retained for 10 years after the product’s last placement on the market.
ESO (European Standardisation Organisation)

One of the three EU-recognized bodies responsible for developing harmonized standards to support EU legislation. ESOs provide technical specifications that, when cited in the Official Journal of the EU, grant a presumption of conformity with CRA requirements.

The three ESOs are:

  • CEN – European Committee for Standardization
  • CENELEC – European Committee for Electrotechnical Standardization
  • ETSI – European Telecommunications Standards Institute
Essential Requirements (CRA Annex I)

The mandatory cybersecurity requirements that all PDEs must meet under the CRA. These include:

  • Secure design and development
  • Secure update mechanisms
  • Vulnerability handling and disclosure
  • Supply chain risk management
  • Resilience to cyber threats

All CRA compliance activities, including risk assessments, technical documentation, and conformity assessment, are evaluated against these requirements.

Harmonised Standards

European standards developed by ESOs (e.g., CEN, CENELEC, ETSI) that provide a presumption of conformity with the CRA. Adherence to an applicable harmonized standard simplifies the conformity assessment process and reduces the burden of proof.

Integrity
The property that ensures data and systems remain accurate, complete, and unaltered by unauthorized parties. Integrity is protected through cryptographic hashing, digital signatures, and access controls.
Lifecycle Security
The principle that cybersecurity must be maintained from the initial design phase through development, post-market support, and decommissioning. The CRA enforces lifecycle thinking through its documentation and update obligations.
Likelihood
The probability or ease with which a threat scenario may result in a security incident. Likelihood is assessed during risk analysis and combined with impact to determine overall risk level.
Notified Body
An independent, third-party organization designated by an EU Member State to assess the conformity of high-risk PDEs (Class II and Critical) under the CRA and other EU directives. Notified Bodies conduct audits, reviews, and assessments to ensure compliance.
Online Hosting Location
Infrastructure that stores and serves the resources for a website, application, or online service.
Patch Management
The process of developing, releasing, and applying updates to fix vulnerabilities. CRA requires a defined patch management process and timely application of security fixes, including clear documentation and update instructions for users.
PDE (Product with Digital Elements)
Any physical or virtual product that includes software, firmware, or programmable components. This includes connected devices, embedded systems, software applications, and cloud services. PDEs are subject to CRA requirements based on their risk class.
Presumption of Conformity
A legal presumption that a product complies with the CRA if it conforms to an applicable harmonized standard cited in the Official Journal of the EU. This presumption reduces the burden of proof during conformity assessment.
Product Control
A measure implemented within a product to reduce or manage cybersecurity risk. Controls may be technical (e.g., encryption, access controls) or organizational (e.g., policies, training). All controls must be documented and validated.
Remediation
A corrective action taken to eliminate or mitigate a vulnerability in a product or service. Remediation may involve patching, configuration changes, or architectural redesign. Actions must be documented and verified.
Reporter
Individual or organization that notifies a vendor or coordinator of a potential vulnerability. Reporters play a key role in coordinated disclosure and are protected under responsible disclosure policies.
Residual Cybersecurity Risk/Residual Risk
The level of risk that remains after mitigation strategies have been applied. Residual risk must be evaluated and accepted based on documented risk acceptance criteria.
Risk Assessment
A formal, documented process to identify, analyze, and prioritize cybersecurity risks associated with a PDE. It considers threats from connectivity, supply chain, usage scenarios, and environmental factors. Required as part of technical documentation under the CRA.
Risk Register
A structured record that tracks identified security risks throughout a product’s lifecycle. Each entry typically includes the risk description, likelihood, impact, mitigation strategy, responsible owner, and status. Under the CRA, maintaining a risk register helps demonstrate that risks have been systematically identified, evaluated, and addressed as part of the technical documentation. It also supports traceability between the risk assessment, mitigation measures, and the evidence provided during the conformity assessment.
SAST (Static Application Security Testing)
A testing method that analyzes source code or binaries without running the software, to detect vulnerabilities such as hardcoded credentials, buffer overflows, or unsafe function calls. SAST tools are typically integrated into the CI pipeline and help catch issues early in development.
SBOM (Software Bill of Materials)
A machine-readable list of all components (libraries, dependencies, firmware modules, etc.) used in a software product. Required under CRA to support vulnerability tracking and supply chain transparency.
Secure-by-Default
A product design principle that ensures the most secure configuration is enabled out of the box – without requiring the user to tweak settings. Features like automatic updates, disabled debug ports, unique secure default passwords, and restricted access modes are examples of security-by-default behavior.
Secure-by-Design
A development principle that ensures security is built into the product from the earliest design stages. This means thinking about threats, risks, and controls at the architecture level — not patching them in later. CRA expects manufacturers to plan for security from the ground up.
Security Control
A safeguard or countermeasure (technical or organizational) implemented to reduce risk. CRA compliance requires documenting security controls — including their design, implementation, and testing.
Security Objective
A specific, measurable outcome related to the protection of a system or data from cyber threats. Examples include confidentiality, integrity, availability, and non-repudiation.
Security Posture
The overall strength of an organization or product’s cybersecurity controls, based on design choices, processes, and technical measures. CRA requires products to have a demonstrably strong security posture through documentation and testing.
Shift-left
Refers to the practice of moving key activities – like security, testing, and documentation — earlier in the development lifecycle. By addressing these elements during the design and planning phases, rather than after implementation, you catch issues sooner, reduce rework, and create a more resilient product from the start.
Software Package
A bundled collection of software, data, libraries, and configuration files delivered as a single unit. Must be traceable and documented in SBOMs and technical documentation.
Supply Chain Risk
The risk introduced by third-party software, hardware, or service providers. CRA requires manufacturers to identify and manage these risks – SBOMs, contractual controls, and update mechanisms are all tools to mitigate them.
STRIDE

A lightweight threat modeling framework used in code reviews and architecture analysis:

  • Spoofing
  • Tampering
  • Repudiation
  • Information disclosure
  • Denial of service
  • Elevation of privilege
Technical Documentation

All the internal documentation needed to demonstrate compliance with CRA, including:

  • Risk assessments
  • Security architecture
  • SBOM
  • Test reports
  • Change logs

Must be maintained and updated throughout the product lifecycle and kept for 10 years after end-of-life.

Threat Modeling

A structured process for identifying potential security threats and vulnerabilities in a system – ideally done early in the design phase. It helps teams think through how attackers might exploit the system and what defenses are needed. Lightweight approaches like STRIDE are often used in CRA-aligned workflows.

Triage
The process of analyzing and prioritizing vulnerabilities based on severity, exploitability, and business impact. Triage decisions – including whether to patch, mitigate, or defer – should be documented as part of CRA compliance.
Vulnerability Management
A lifecycle process for identifying, assessing, remediating, and disclosing security vulnerabilities in a product – including monitoring advisories, patching, and reporting exploited issues.
VDP (Vulnerability Disclosure Policy)
A formal policy that tells external researchers and users how to report vulnerabilities in your product. The CRA requires manufacturers to provide a public reporting channel and to act on disclosures according to defined timelines.