Plain-English definitions of every term you need to understand the EU Cyber Resilience Act, coordinate vulnerability disclosure, and meet your September 2026 deadline.
Annex I of the EU Cyber Resilience Act sets out the mandatory cybersecurity requirements that all products with digital elements must meet. It is divided into two parts: Part I covers secure product properties, and Part II covers manufacturer vulnerability handling obligations.
Annex III of the EU Cyber Resilience Act lists product categories classified as 'Important' (Class I or Class II) or 'Critical', which are subject to stricter conformity assessment requirements than the Default class. Most products not listed in Annex III fall into the Default class and can self-certify.
The CE mark is the mandatory conformity marking that manufacturers must affix to products with digital elements before placing them on the EU market under the CRA. It indicates that the product meets the CRA's essential cybersecurity requirements and has passed the applicable conformity assessment procedure.
Conformity assessment is the process by which a manufacturer demonstrates that its product meets the CRA's essential cybersecurity requirements. The process required depends on the product's classification: Default and Class I products can self-assess; Class II and Critical products require third-party assessment by a notified body.
Default Class products are the baseline category under the EU Cyber Resilience Act - products with digital elements that do not fall into the Important Class I or Class II elevated risk classifications. The vast majority of consumer and commercial connected products are Default Class. Manufacturers may self-certify conformity through an internal control procedure.
Economic operators are the legal entities in the supply chain - manufacturers, authorised representatives, importers, and distributors - upon whom the EU Cyber Resilience Act places specific obligations. The manufacturer bears the primary and most extensive obligations, but importers and distributors have supplementary duties that can result in them inheriting manufacturer obligations if the original manufacturer is non-compliant.
An end-of-life (EOL) policy defines the date on which a manufacturer will cease providing security updates, technical support, and vulnerability fixes for a product. Under the EU Cyber Resilience Act, manufacturers must clearly communicate EOL dates and ensure they meet the minimum support period requirements before they can terminate update obligations.
ENISA (the European Union Agency for Cybersecurity) is the EU's dedicated cybersecurity agency, headquartered in Athens with offices in Brussels. Under the CRA, ENISA operates the central EU vulnerability registry, receives Article 14 notifications of actively exploited vulnerabilities, and publishes guidance supporting manufacturer compliance.
The essential cybersecurity requirements are the mandatory security properties and vulnerability handling obligations set out in Annex I of the CRA that all products with digital elements must satisfy before being placed on the EU market. They are the substantive compliance test at the heart of the CRA.
The EU Cyber Resilience Act (Regulation (EU) 2024/2847) is a horizontal EU regulation that establishes mandatory cybersecurity requirements for products with digital elements placed on the EU market. It entered into force on 10 December 2024, with most obligations applying from 11 December 2027.
The EU Declaration of Conformity is a formal document signed by the manufacturer (or authorised representative) declaring that a product meets the essential requirements of all applicable EU regulations, including the CRA. It must be drawn up before the CE mark is affixed and kept available for market surveillance authorities for at least 10 years.
Important Product Class I is the lower tier of the CRA's two-tier classification for products with digital elements that present a significant cybersecurity risk. Class I products face an elevated conformity assessment pathway compared to Default Class products, but less stringent than Class II. Examples include identity management software and general-purpose browsers.
Important Product Class II is the highest risk tier under the EU Cyber Resilience Act's product classification system, covering products with digital elements whose compromise could have severe or widespread impact. Class II products - including industrial control systems, medical devices, and critical infrastructure components - face mandatory third-party conformity assessment.
Manufacturer obligations under the EU Cyber Resilience Act are the comprehensive set of cybersecurity duties that apply to any entity that designs, develops, or produces a product with digital elements for the EU market. These obligations span product design, vulnerability handling, market surveillance cooperation, and post-market security support.
A 'product with digital elements' (PDE) is the CRA's term for any hardware or software product that has the ability to process, store, or transmit data and that connects, directly or indirectly, to another device or network. This definition determines whether the CRA applies to a given product.
Secure by default means that a product ships with security settings pre-configured to the most protective state - disabled features, closed ports, strong authentication - without requiring users to take action to enable security. It is an explicit essential requirement under Annex I of the EU Cyber Resilience Act.
Secure by design means that security is built into a product's architecture and development process from the earliest design stage, rather than added as an afterthought after development is complete. The EU Cyber Resilience Act's essential requirements in Annex I mandate a secure-by-design approach for all products with digital elements.
The support period is the duration for which a manufacturer commits to providing security updates, vulnerability remediations, and related security support for a product. Under the EU Cyber Resilience Act, the support period reflects the time the product is expected to be in use, is floored at five years, and must be communicated to users before purchase.
Technical documentation under the CRA is the comprehensive set of records a manufacturer must compile and maintain to demonstrate that a product with digital elements meets the Annex I essential cybersecurity requirements. It must be retained for at least 10 years and made available to market surveillance authorities on request.
An actively exploited vulnerability is a security flaw for which evidence exists that threat actors are currently using exploit code in real-world attacks. Under the CRA, manufacturers must notify ENISA within 24 hours of becoming aware that a vulnerability in their product is being actively exploited.
An advisory embargo is an agreed period during which a vulnerability disclosure is held private among the researcher, manufacturer, and any coordinating parties - allowing time for patch development and coordinated release before the vulnerability details become public. Embargoes are a core mechanism of coordinated vulnerability disclosure.
A bug bounty programme is a formal scheme in which a manufacturer or organisation offers financial rewards to external security researchers who discover and responsibly disclose security vulnerabilities in their products or systems. Bug bounty programmes are a supplementary CVD mechanism - they add financial incentive to an underlying CVD policy - but are not themselves a substitute for the CRA's mandatory vulnerability disclosure requirements.
The Common Weakness Enumeration (CWE) is a community-developed catalogue of software and hardware weakness types maintained by MITRE. Unlike CVEs (which describe specific vulnerabilities in specific products), CWEs describe the underlying weakness categories - such as buffer overflow or improper input validation - that give rise to vulnerabilities.
CVD is the process by which a security researcher privately reports a vulnerability to the affected vendor, who then develops and releases a fix before the vulnerability is made public. Under the EU Cyber Resilience Act, manufacturers of products with digital elements are legally required to establish a CVD process.
A Coordinating CSIRT is a national computer security incident response team that takes the lead role in facilitating multi-party vulnerability disclosures affecting multiple organisations or products. Under the CRA, EU member state CSIRTs have a defined role in coordinating vulnerability disclosures and supporting the European Vulnerability Database.
A critical vulnerability is a security flaw assigned a CVSS base score of 9.0 or higher, indicating the highest potential for harm - typically enabling remote code execution or full system compromise without authentication. Critical vulnerabilities require accelerated remediation and immediate advisory publication under CRA-compliant vulnerability handling processes.
A CSIRT is a team that coordinates responses to cybersecurity incidents, typically operating at a national or sector level. Under the CRA, manufacturers must notify the relevant national CSIRT within 24 hours of discovering an actively exploited vulnerability in their product, alongside simultaneous notification to ENISA.
A CVD Coordinator is a neutral third party - typically a CSIRT, CERT, or specialised organisation - that facilitates the coordinated disclosure process between security researchers and manufacturers, particularly in multi-vendor or complex vulnerability scenarios. Under the CRA, ENISA plays a CVD coordination role for the EU.
A CVD policy is a publicly published document that defines how a manufacturer receives, processes, and responds to vulnerability reports. The EU Cyber Resilience Act requires manufacturers to publish a CVD policy as part of their vulnerability handling obligations.
CVSS v4.0 is the fourth major version of the Common Vulnerability Scoring System, published by FIRST in November 2023. It introduces significant changes to the scoring model including more granular base metrics, new supplemental score groups, and improved handling of OT/ICS and IoT vulnerability contexts - areas directly relevant to CRA-covered products.
A disclosure timeline is the agreed or stated period between a security researcher privately reporting a vulnerability to a manufacturer and the point at which either the fix is released or the vulnerability is publicly disclosed. The standard industry timeline is 90 days, though the CRA does not prescribe a specific period.
The European Vulnerability Database (EUVDB) is an EU-level vulnerability repository operated by ENISA under the Cyber Resilience Act. It aggregates vulnerability notifications from manufacturers, national CSIRTs, and security researchers, providing a centralised European counterpart to the US National Vulnerability Database.
The Exploit Prediction Scoring System (EPSS) is a data-driven model maintained by FIRST that estimates the probability that a given CVE will be exploited in the wild within the next 30 days. EPSS complements CVSS by adding exploitation likelihood to severity, enabling more effective vulnerability prioritisation.
Incident response is the organised process for detecting, containing, investigating, and recovering from cybersecurity incidents - events where a product's security has been or may have been compromised. The EU Cyber Resilience Act requires manufacturers to have incident response capabilities and to notify authorities within strict timeframes when security incidents occur.
A PSIRT is a dedicated organisational function responsible for receiving, investigating, and coordinating responses to security vulnerabilities and incidents in a manufacturer's products. The EU Cyber Resilience Act's vulnerability handling obligations effectively require manufacturers to have PSIRT-equivalent capabilities.
A remediation timeline defines the expected period between a vulnerability being identified (or reported) and a fix being developed, tested, and released to users. The CRA requires manufacturers to address vulnerabilities 'without undue delay' - remediation timelines operationalise what this means for different severity levels.
Responsible disclosure is the practice of privately notifying a vendor of a security vulnerability before making it public, giving the vendor time to develop and release a fix. It is an older term that is largely synonymous with coordinated vulnerability disclosure (CVD), which is now the preferred terminology in EU regulatory frameworks.
A security advisory is a public document published by a manufacturer to inform users of a security vulnerability in a product, the severity of the issue, and how to remediate it. Annex I Part II of the CRA requires manufacturers to publish security advisories when releasing vulnerability fixes.
A security researcher is an individual or organisation that investigates security vulnerabilities in products, systems, or software - often independently of the affected manufacturer - and reports findings to enable remediation. The EU Cyber Resilience Act recognises the role of security researchers as essential contributors to the vulnerability discovery ecosystem and requires manufacturers to establish accessible disclosure channels for them.
security.txt is a standardised plain-text file placed at `/.well-known/security.txt` on a web domain that tells security researchers how to report vulnerabilities. Defined in RFC 9116, it is the recommended machine-readable disclosure of a manufacturer's CVD contact and policy.
Threat intelligence is evidence-based information about existing or emerging cybersecurity threats - including attacker TTPs, indicators of compromise, and exploitation trends - that enables organisations to make informed decisions about their security posture. For CRA manufacturers, threat intelligence feeds the threat modelling and active exploitation monitoring processes.
A Vulnerability Disclosure Policy (VDP) is a published document that defines how an organisation receives, handles, and responds to vulnerability reports from external security researchers. Under the CRA, maintaining a VDP is a legal requirement for all manufacturers of products with digital elements.
Vulnerability handling is the complete lifecycle process through which a manufacturer identifies, evaluates, remediates, and discloses security vulnerabilities in its products. Annex I Part II of the CRA makes robust vulnerability handling a mandatory ongoing obligation for all manufacturers of products with digital elements.
Vulnerability triage is the process of evaluating incoming vulnerability reports or newly disclosed CVEs to determine their validity, severity, applicability to specific products, and remediation priority. Effective triage is essential for CRA compliance, ensuring that critical vulnerabilities are addressed within required timeframes.
The CISA Known Exploited Vulnerabilities (KEV) catalogue is a curated list maintained by the US Cybersecurity and Infrastructure Security Agency that identifies CVEs for which there is credible evidence of active exploitation in the wild. For EU manufacturers, the KEV catalogue is the highest-priority vulnerability intelligence source - any KEV entry affecting a shipped product triggers the CRA's 24-hour ENISA notification obligation.
CSAF is an OASIS open standard for machine-readable security advisory documents, replacing the older CVRF format. ENISA recommends CSAF as the preferred format for security advisories published by manufacturers under the EU Cyber Resilience Act.
CVE is a public catalogue of known cybersecurity vulnerabilities, each assigned a unique identifier (e.g. CVE-2024-12345) maintained by MITRE. Under the CRA, manufacturers are expected to track CVEs affecting their products and report actively exploited vulnerabilities to ENISA.
CVSS is an open framework for communicating the characteristics and severity of software vulnerabilities, producing a numerical score from 0 to 10. Manufacturers use CVSS scores to prioritise remediation and to communicate risk in security advisories required under the CRA.
The Common Vulnerability Scoring System (CVSS) is the industry-standard framework for assessing and communicating the severity of software vulnerabilities using a numerical score from 0 to 10. CVSS scores are referenced throughout the CRA compliance ecosystem - in vulnerability advisories, SBOM tooling, CSAF documents, and PSIRT triage processes - and are the primary language for communicating vulnerability severity under the regulation.
The National Vulnerability Database (NVD) is the US government's comprehensive repository of CVE records enriched with CVSS severity scores, CWE classifications, and CPE product identifiers, maintained by NIST. It is the primary machine-readable vulnerability intelligence source used by SCA tools and vulnerability scanners globally, including by EU manufacturers complying with the CRA.
VEX (Vulnerability Exploitability eXchange) is a machine-readable security advisory format that allows manufacturers to communicate the exploitability status of known CVEs in their products - specifically whether a CVE that appears in a component is actually exploitable in the context of how the component is used. VEX is essential for managing the false-positive burden of SBOM-based vulnerability scanning.
The attack surface of a product is the totality of different points - interfaces, APIs, protocols, hardware ports, and user inputs - through which an attacker could attempt to enter or extract data from a system. Reducing attack surface is a core principle of the CRA's essential cybersecurity requirements.
A cybersecurity risk assessment is a systematic process of identifying, analysing, and evaluating security threats and vulnerabilities that could affect a product or system, then determining appropriate mitigations. The EU Cyber Resilience Act requires manufacturers to conduct and document a cybersecurity risk assessment as a precondition for market placement.
An exploit is code, data, or a sequence of commands that takes advantage of a vulnerability to cause unintended behaviour in software or hardware. Under the EU Cyber Resilience Act, manufacturers must actively track and remediate vulnerabilities before exploits are developed and weaponised.
A firmware update delivers new software to a device's embedded systems - microcontrollers, bootloaders, and operating environments - to fix vulnerabilities, add features, or address hardware behaviour. Over-the-air (OTA) updates deliver firmware remotely. The CRA requires manufacturers to implement and maintain a secure update mechanism throughout a product's support period.
Patch management is the process of identifying, testing, approving, and deploying software updates that fix security vulnerabilities and bugs. The EU Cyber Resilience Act requires manufacturers to provide security patches for their products throughout the defined support period and to deliver them without undue delay.
Penetration testing is a structured, authorised security assessment in which testers simulate real-world attack techniques to identify exploitable vulnerabilities in a product, system, or network before malicious actors discover them. The EU Cyber Resilience Act implicitly requires manufacturers to test their products' security prior to market placement.
A proof-of-concept (PoC) exploit is working code or a detailed technical demonstration that shows a security vulnerability is real and exploitable. The existence of a public PoC significantly increases the urgency of a manufacturer's patch release and may affect CRA notification timelines.
An SBOM is a formal, machine-readable inventory of all software components - including open-source libraries, third-party dependencies, and firmware packages - that make up a product. The EU Cyber Resilience Act requires manufacturers to maintain an SBOM as part of their technical documentation.
Software Composition Analysis (SCA) is the automated process of identifying open-source and third-party components in a codebase and checking them against known vulnerability databases to detect security risks. SCA is the primary technical mechanism for meeting the CRA's requirement that manufacturers identify and manage vulnerabilities in their products' components.
Software supply chain security encompasses the practices and controls that ensure the integrity, authenticity, and security of all software components - open-source libraries, commercial off-the-shelf modules, and development toolchains - that are integrated into a product. The CRA places explicit obligations on manufacturers to manage supply chain security throughout the product lifecycle.
Threat modeling is a structured technique for identifying, prioritising, and mitigating security threats to a system during its design phase by systematically analysing what could go wrong, who might cause it, and what the impact would be. It is the foundational practice that enables manufacturers to meet the CRA's requirement for risk-informed, secure-by-design product development.
Vulnerability scanning is the automated process of probing systems, networks, or applications to identify known security weaknesses by comparing observed configurations and software versions against databases of known vulnerabilities. It provides continuous visibility into a product's security posture and supports the CRA's requirement that manufacturers monitor and address vulnerabilities throughout a product's lifecycle.
A zero-day vulnerability is a security flaw that is unknown to the vendor and for which no patch exists at the time of discovery or exploitation. Zero-day vulnerabilities are particularly significant under the CRA because their active exploitation triggers immediate notification obligations to ENISA within 24 hours.
Annex II of the EU Cyber Resilience Act specifies the information that manufacturers must provide to users alongside their products. This includes security-relevant details such as the product's unique identifier, known vulnerabilities, the support period, and contact details for reporting security issues.
Annex VII of the EU Cyber Resilience Act specifies the contents of the technical documentation that manufacturers must compile and maintain to demonstrate CRA compliance. This file must be available to market surveillance authorities on request and retained for ten years after the product is placed on the market.
A Conformity Assessment Procedure is the formal process by which a manufacturer demonstrates that a product meets applicable EU essential requirements before affixing the CE mark and placing it on the market. Under the Cyber Resilience Act, the required procedure depends on the product's risk classification.
EU Type-Examination is a conformity assessment procedure in which a Notified Body examines a representative sample (the 'type') of a product and issues a certificate confirming it meets the applicable EU essential requirements. It is one of the mandatory routes for Important Class II products under the Cyber Resilience Act.
A Harmonised Standard is a European standard developed by a recognised standards body (CEN, CENELEC, or ETSI) under a mandate from the European Commission that confers a presumption of conformity with specific EU legislation. Once its reference is published in the Official Journal, manufacturers whose products comply with it are presumed to satisfy the corresponding CRA essential requirements without further proof. No CRA harmonised standard has been published in the Official Journal yet, so that presumption is currently unavailable for every product category.
A Market Surveillance Authority is a national regulatory body responsible for enforcing product safety and compliance legislation within an EU member state. Under the Cyber Resilience Act, MSAs investigate non-compliant products with digital elements, order corrective actions, and can impose fines or market bans.
The NIS2 Directive (EU 2022/2555) is the EU's updated network and information security law, establishing cybersecurity obligations for operators of essential and important services. While the CRA governs product manufacturers, NIS2 governs service operators - but the two frameworks overlap significantly for organisations that both manufacture products and operate digital services.
A Notified Body is an independent third-party organisation accredited by an EU member state to conduct conformity assessments on behalf of manufacturers. Under the Cyber Resilience Act, Notified Bodies are required for Class II and certain Class I products that cannot self-certify compliance.
An Open Source Steward is a legal entity that systematically provides non-commercial support for open source software components used in products with digital elements. The CRA introduces a specific, lighter regulatory category for Open Source Stewards - they are not treated as manufacturers but have limited obligations to support coordinated vulnerability disclosure.
The Product Liability Directive (EU 2024/2853, replacing the 1985 original) establishes the EU framework under which manufacturers are liable for damage caused by defective products, including software and digital services. The revised directive makes cybersecurity defects - including exploited vulnerabilities - a basis for product liability claims.
The Radio Equipment Directive (EU 2014/53/EU) governs the placing on the market of radio equipment in the EU, setting essential requirements for safety, electromagnetic compatibility, and efficient use of radio spectrum. A 2022 delegated regulation (EU 2022/30) adds cybersecurity requirements to RED that overlap with the CRA for connected devices.
A safe harbour clause in a vulnerability disclosure policy is a written commitment by a manufacturer that it will not pursue legal action against security researchers who discover and report vulnerabilities in good faith, within defined scope and conduct parameters. The CRA's mandatory CVD policy requirement implicitly demands meaningful safe harbour protection.
An Indicator of Compromise (IoC) is a piece of forensic evidence - such as a malicious IP address, file hash, domain name, or registry key - that suggests a system has been compromised. IoCs are used in incident response and threat intelligence to detect and investigate security incidents, including the exploitation of product vulnerabilities.
Mean Time to Remediate (MTTR) is a security operations metric that measures the average time elapsed between a vulnerability being identified (or reported) and a fix being deployed to affected systems. For CRA manufacturers, MTTR is a key performance indicator for demonstrating that vulnerabilities are addressed 'without undue delay' as required by Annex I.
SIEM (Security Information and Event Management) is a platform that aggregates, correlates, and analyses security log data from across an organisation's infrastructure to detect threats, support incident investigation, and provide audit evidence. SIEM is a core technology in SOC operations and supports CRA-related monitoring and incident detection.
A Security Operations Centre (SOC) is a centralised function staffed by security analysts who monitor, detect, analyse, and respond to cybersecurity incidents and threats in real time. For manufacturers of CRA-covered products, internal SOC capabilities or managed SOC services support the continuous monitoring and incident response obligations required by the CRA.
Security triage is the process of rapidly assessing incoming security reports, alerts, or vulnerability findings to determine their validity, severity, and priority for response. Effective triage is essential for CRA-compliant vulnerability handling - it enables manufacturers to identify which issues require urgent response and which can be addressed in routine release cycles.
A security war room (or incident bridge) is a coordinated, real-time response environment - physical or virtual - where cross-functional teams converge to manage a major cybersecurity incident. For CRA manufacturers facing an actively exploited vulnerability, the war room coordinates the technical response, regulatory notifications, and communications functions simultaneously.
Cryptographic agility is the design property of a system that allows its cryptographic algorithms to be updated or replaced without requiring complete redesign of the product. It is a CRA essential requirement that products support algorithm updates throughout their lifecycle, particularly as quantum computing advances threaten current cryptographic standards.
Defence in depth is a security strategy that employs multiple overlapping layers of security controls so that if one layer fails, others continue to protect the system. It is a core principle behind the CRA's essential requirements, which take a holistic view of product security rather than relying on any single mechanism.
DevSecOps is the practice of integrating security tools, testing, and responsibilities throughout the software development and operations pipeline - making security a shared responsibility of development, security, and operations teams rather than a final-stage gate. DevSecOps operationalises the CRA's SDLC requirements in modern continuous delivery environments.
A Hardware Security Module (HSM) is a dedicated hardware device that securely generates, stores, and manages cryptographic keys in a tamper-resistant environment. HSMs are used in CRA-compliant products to protect root keys for Secure Boot, firmware signing, and device identity - ensuring keys cannot be extracted even if other system components are compromised.
Network segmentation is the practice of dividing a network into isolated segments or zones to limit the blast radius of a security incident. For CRA-covered products operating in enterprise or industrial environments, built-in network isolation capabilities are a key security design requirement.
An Over-the-Air (OTA) update is a mechanism by which software or firmware is delivered and installed on a device remotely over a network connection, without physical access. The CRA requires manufacturers to provide security updates throughout a product's support period - OTA capability is essential for meeting this obligation for connected devices.
The Principle of Least Privilege states that every component, process, or user should operate with the minimum permissions necessary to perform its function. It is a fundamental secure design principle required by the CRA's Annex I essential requirements and limits the damage an attacker can cause if any component is compromised.
Secure Boot is a firmware security mechanism that verifies the cryptographic signature of each software component in the boot sequence before executing it, ensuring that only authorised, unmodified firmware and bootloaders are loaded. It is a key CRA essential requirement for products where firmware integrity is critical.
A Secure Development Lifecycle (SDLC) is a software and product development process that integrates security activities - threat modelling, security requirements, code review, security testing - at every stage of development. CRA Annex I requires manufacturers to address security throughout the product development lifecycle.
A threat actor is an entity - individual, group, or organisation - that poses a cybersecurity threat by intentionally or unintentionally conducting activities that can harm systems, data, or users. Understanding relevant threat actors is a required input to the risk assessments and threat models mandated by the CRA.
CycloneDX is an open-standard SBOM format maintained by OWASP that represents software components, their relationships, and associated metadata in a machine-readable structure. It is one of the two dominant SBOM formats alongside SPDX and is widely used for CRA compliance documentation.
Dependency-Track is an open-source Software Composition Analysis (SCA) platform maintained by OWASP that continuously monitors SBOM component inventories for known vulnerabilities. It is widely used by CRA manufacturers to operationalise their SBOM-driven vulnerability management obligations.
An open source component is software made available under an open source licence that is incorporated into a product. CRA manufacturers are fully responsible for the security of open source components in their products - the open source origin does not transfer liability to the component's maintainers.
OSV (Open Source Vulnerability) is a standardised vulnerability data format and database maintained by Google, designed for precise matching of vulnerabilities against specific package versions in open source ecosystems. It provides a PURL-based alternative to NVD for open source vulnerability correlation in SBOMs.
A Package URL (PURL) is a standardised string format for uniquely identifying software packages across different package ecosystems. PURLs enable precise component identification in SBOMs, allowing vulnerability databases and security tools to reliably correlate SBOM entries with CVE records.
A software identifier is a standardised string or code that uniquely identifies a specific software package, component, or product version. Common software identifiers include PURL, CPE, and SWID tags. Accurate software identifiers are essential for reliable SBOM-based CVE correlation and CRA technical documentation.
SPDX (Software Package Data Exchange) is an ISO-standardised SBOM format (ISO/IEC 5962:2021) that describes software components, their versions, licences, and provenance in a machine-readable structure. SPDX is one of the two dominant SBOM formats alongside CycloneDX and is accepted for CRA technical documentation purposes.
A transitive dependency is a software component that a product depends on indirectly - through another component that directly depends on it. Transitive dependencies are often numerous, poorly monitored, and the source of critical vulnerabilities in CRA-covered products.
CVD Portal gives manufacturers placing products on the EU market a complete Article 14 compliance programme. Receiving and tracking reports is free, and Article 14 filing with the SRP-ready package is on Reporting.
Set up your free portal