Search CRA guidance

A CRA actively exploited vulnerability is a security flaw where threat actors currently use exploit code in real-world attacks. Under CRA Article 14, manufacturers must report actively exploited vulnerabilities to ENISA and the national CSIRT within 24 hours of becoming aware.

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.

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 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 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.

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.

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 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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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.

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 Weakness Enumeration (CWE) is a community-developed catalogue of software and hardware weakness types (CWEs) maintained by the MITRE Corporation. Unlike CVEs (which describe specific vulnerability instances), CWEs describe underlying software weakness categories.

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.

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.

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.

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.

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.

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.

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 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.

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 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.

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.

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.

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.

An exploit is code, payload, or technique that takes advantage of a vulnerability in software or hardware. The exploit rate measures the probability or velocity of real-world exploitation by threat actors (via EPSS and KEV feeds). Under the CRA, active exploitation triggers a 24-hour ENISA reporting deadline.

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.

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.

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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 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.

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 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 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.

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 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.

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.

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.

Secure by default means a product ships with protective security settings pre-configured. Features are disabled, ports are closed, and strong authentication is active without user action. Annex I of the EU Cyber Resilience Act makes this a mandatory requirement.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

Access control systems - including IP-connected door controllers, card readers, biometric access terminals, and integrated physical security management platforms - are products with digital elements that directly control physical access to facilities. Their compromise can enable physical security breaches with serious consequences. Most networked access control systems qualify as Annex III Class I; those securing critical infrastructure or government facilities may be Class II.

Assistive technologies and augmentative and alternative communication (AAC) devices serve users with disabilities and complex communication needs. Products not classified as medical devices under MDR fall fully within CRA scope. Given the vulnerable user population and the critical dependency of users on these devices, security and continuity requirements are especially important. Manufacturers must balance rigorous security with accessibility and usability needs.

Professional audio and video equipment - including networked broadcast systems, IP audio routing (Dante, AES67), live production switchers, IP video distribution, and broadcast management systems - are products with digital elements subject to the CRA. While most professional AV products are Default class, broadcast infrastructure for national broadcasters and critical live event systems may approach Class I given their public communication role.

Automotive electronics face a complex regulatory landscape. Vehicles and vehicle-integrated systems subject to UNECE WP.29 type approval (UN Regulations R155 and R156) may be excluded from CRA scope, as these regulations provide equivalent cybersecurity requirements. However, standalone aftermarket automotive electronics, diagnostic tools, and fleet telematics devices placed on the market independently are fully in CRA scope. Manufacturers must carefully map each product to determine applicable regulations.

Building automation systems (BAS/BMS) control HVAC, lighting, access, fire safety, and energy management across commercial and industrial buildings. Most BAS components are Default class under the CRA, but those deployed in hospitals, data centres, and other critical facilities may be treated as critical infrastructure components. The BACnet and Modbus protocols widely used in BAS were not designed with security in mind - CRA compliance requires significant attention to protocol security and access control.

CCTV and video surveillance systems - including IP cameras, network video recorders (NVRs), video management software (VMS), and integrated surveillance platforms - are products with digital elements with a significant history of security vulnerabilities. IP cameras have repeatedly been mass-compromised to form botnets (Mirai and successors). Professional surveillance systems used in critical infrastructure are Annex III Class I or II. Consumer cameras are Default. All must meet CRA security requirements.

Networked CNC machines and industrial 3D printers are safety-critical manufacturing systems increasingly connected to production networks and cloud-based management platforms. Their digital control systems - including G-code interpreters, machine controllers, and remote monitoring agents - fall under the CRA. Most networked industrial CNC systems are Annex III Class I due to their safety-critical nature; those integrated into critical manufacturing infrastructure may be Class II.

Consumer routers and modems are high-value targets for attackers and face specific CRA requirements around default credentials, remote management security, and firmware update integrity. Routers marketed for home use are Default class; those marketed for industrial or critical infrastructure use may be Annex III Class II.

Dental equipment falls into two CRA categories. Dental devices classified as medical devices under MDR (imaging systems, diagnostic sensors, implant-planning software as SaMD) are excluded from CRA if properly MDR-compliant. However, dental practice management software, appointment systems, patient record platforms, and non-MDR dental IT are fully in CRA scope. Manufacturers must carefully verify their product's regulatory classification.

Digital signage systems - including commercial displays, media players, content management systems (CMS), and interactive display platforms - are products with digital elements subject to the CRA. While classified as Default, digital signage systems in public spaces present risks including unauthorised content injection, privacy violations through connected cameras, and use as botnet infrastructure. Manufacturers must implement robust security practices.

Drones and unmanned aerial vehicles operate in a complex regulatory environment combining the CRA and EU Drone Regulation (EU) 2019/947. Higher-category drones (C2 and above) capable of BVLOS operations, remote identification, and integration with UTM systems are likely Annex III Class II under the CRA. Consumer toy drones in the lowest categories may be Default class. Manufacturers must map each product to both regulatory frameworks.

E-readers and consumer tablets are among the most widely deployed consumer products with digital elements. They run complex software stacks, connect to app stores and cloud services, and often store sensitive personal data. As Default-class products under the CRA, manufacturers must implement all Annex I security requirements, maintain vulnerability disclosure processes, and support timely security updates.

Edge computing devices and gateways - including industrial IoT gateways, edge AI inference nodes, fog computing appliances, and protocol converters - sit at the boundary between operational technology and IT networks. They often aggregate sensitive data from many downstream devices and may have elevated privileges in industrial environments. Most industrial edge gateways are Annex III Class I; those processing critical infrastructure data may be Class II.

Embedded Linux devices span a vast range - from network gateways and industrial HMIs to set-top boxes and smart displays. All are products with digital elements subject to the CRA. The open-source nature of Linux creates specific obligations around SBOM completeness and CVE monitoring. Classification ranges from Default for consumer devices to Annex III Class I or II for industrial or infrastructure applications.

Energy management systems (EMS) - including building energy management, industrial energy optimisation, and grid-connected demand response systems - are classified as critical products under the CRA. Those connected to energy infrastructure or capable of controlling significant energy loads fall under Annex III Class II, mandating third-party conformity assessment. Manufacturers must also address the intersection with the NIS2 Directive for operators in the energy sector.

Enterprise networking equipment - switches, firewalls, load balancers, and network management systems - spans multiple Annex III classifications. Hardware firewalls are Class II Important products; network management software and monitoring tools are Class I Important products. Both require third-party conformity assessment.

Environmental monitoring sensors - including air quality monitors, water quality sensors, weather stations, soil sensors, and flood detection systems - are products with digital elements subject to the CRA. Most are Default class, but sensors integrated into official environmental regulatory monitoring networks or emergency warning systems may be Annex III Class I. Compromise of environmental monitoring data could have public health, regulatory, and emergency response implications.

Compliance tips for EV chargers and Electric Vehicle Supply Equipment (EVSE) manufacturers under the EU Cyber Resilience Act. EV charging stations, Level 2 chargers, and DC fast chargers sit at the intersection of energy infrastructure, payment systems, and connected electric vehicles (EV). Residential chargers are typically Default class, while public charging network stations connected to grid management systems face Annex III Important Class I product classifications. Secure communication protocols (OCPP 2.0.1, ISO 15118) and vulnerability management are required compliance elements.

Networked fire detection and suppression systems are life safety infrastructure - their failure or compromise can result in loss of life. Networked fire alarm control panels, addressable fire detection systems, and remotely managed suppression systems are classified as Annex III Class II under the CRA, requiring third-party Notified Body conformity assessment. Manufacturers must also address the intersection with the Construction Products Regulation (CPR) and EN 54 standards.

Fleet management and telematics systems - including GPS trackers, OBD-connected devices, electronic logging devices (ELDs), tachograph systems, and fleet management platforms - are products with digital elements fully in scope for the CRA. They collect sensitive location and operational data at scale, often operate in remote or unattended environments, and some are legally mandated safety and compliance devices. Security is both a CRA obligation and a competitive differentiator.

Gaming consoles and connected peripherals are consumer products with digital elements fully in scope for the CRA. They involve complex software ecosystems, online multiplayer services, digital storefronts, and user account systems - each presenting distinct cybersecurity risks. While classified as Default, gaming platforms process significant personal and payment data, making robust security practices essential.

Health monitoring wearables - fitness trackers, smartwatches with health sensors, sleep monitors, and consumer ECG devices not classified as medical devices under MDR - are fully in scope for the CRA. Unlike regulated medical devices, these consumer health products cannot claim the MDR exclusion and must meet all CRA requirements. The combination of sensitive health data and consumer deployment makes security practices critical.

Hospital IT systems - including electronic health record (EHR) systems, clinical information systems, hospital information systems (HIS), and clinical decision support tools not classified as Software as a Medical Device (SaMD) - are not excluded from the CRA by the MDR carve-out. These systems are critical to patient care, process sensitive patient data at scale, and face sophisticated threat actors. They likely qualify as Annex III Class I products.

Hotel and hospitality technology - including electronic door locks, in-room automation systems, property management software (PMS), guest Wi-Fi platforms, and hotel IoT devices - are products with digital elements subject to the CRA. Hotels process sensitive guest personal and payment data, and their technology systems face threats including room access compromise, guest data theft, and payment fraud. Most hospitality products are Default class.

Industrial controllers, PLCs, and SCADA components are classified as Important Class II under Annex III of the CRA, requiring third-party conformity assessment. These products have long operational lifetimes (10–20+ years), network connectivity, and significant safety implications. CRA compliance must be planned well in advance of the September 2026 deadline.

Industrial robots and collaborative robots (cobots) are safety-critical connected systems deployed in manufacturing, logistics, and process automation. Their CRA classification depends on deployment context - standalone industrial robots are Annex III Class I, while those integrated into critical infrastructure control systems may be Class II. Safety and security are inseparable in robotics: a cyber attack that disables safety interlocks can cause physical harm.

Intruder alarm and security systems range from consumer burglar alarms to commercial grade monitored alarm systems protecting critical facilities. The CRA classification depends on deployment context: systems protecting critical infrastructure are Class II; commercial security systems are likely Class I; basic consumer alarm products may be Default. All networked alarm systems must meet CRA Annex I requirements regardless of classification.

IoT sensors - temperature, humidity, pressure, flow, and motion sensors - are the backbone of industrial and building automation. Most fall into the Default CRA class, but their constrained hardware often makes meeting Annex I security requirements challenging. Manufacturers must plan for secure update mechanisms even on resource-constrained devices.

Laboratory instruments and scientific equipment - including networked analysers, chromatography systems, mass spectrometers, laboratory information management systems (LIMS), and laboratory automation platforms - are products with digital elements subject to the CRA. In Vitro Diagnostic (IVD) instruments regulated under IVDR are excluded from CRA scope. General-purpose laboratory instruments with network connectivity and data management capabilities are fully in CRA scope.

Livestock monitoring systems - including connected ear tags, health monitoring wearables for animals, automated feeding and milking systems, and livestock management platforms - are products with digital elements in scope for the CRA. They collect sensitive farm data, often operate in remote or low-connectivity environments, and their compromise could affect animal welfare, food safety, and farm productivity. Most are Default class.

Marine electronics range from safety-critical navigation systems (ECDIS, AIS, GMDSS equipment) to consumer chartplotters and fish finders. Safety-critical navigation systems are Annex III Class I or higher due to their role in vessel safety. Consumer marine electronics are Default class. Manufacturers must also address the intersection with IMO maritime cybersecurity guidelines and flag state regulations for commercial vessels.

Medical devices regulated under the EU Medical Device Regulation (MDR) or In Vitro Diagnostic Regulation (IVDR) are generally excluded from the CRA. However, software products used in healthcare that are not classified as medical devices under MDR may fall within CRA scope. Manufacturers should carefully verify their product's regulatory classification.

Network attached storage devices are high-value targets - they store critical personal, business, and infrastructure data and are frequently targeted by ransomware and data exfiltration actors. Consumer NAS is Default class; enterprise NAS marketed as critical data infrastructure may be Class I. NAS vendors have a poor historical track record on patching, making CRA obligations in this area particularly significant.

Open source hardware (OSH) projects occupy a unique position under the CRA. The regulation explicitly excludes hardware developed for non-commercial purposes, shared freely without monetisation. However, when open source hardware designs are manufactured and sold commercially - even by small businesses or community projects - the CRA's full scope applies. The CRA also introduces a 'steward' concept for open source projects that is relevant to OSH ecosystems. Understanding the commercial/non-commercial boundary is essential.

Payment terminals and ATMs are products with digital elements that sit at the intersection of the CRA, PCI DSS, PSD2, and EBA regulatory frameworks. They are Annex III Class I due to their financial infrastructure role. ATMs and unattended payment terminals in public spaces face significant physical and cybersecurity risks. While PCI DSS compliance does not provide a CRA exclusion, the two frameworks address overlapping security domains and compliance evidence from PCI assessments can support CRA technical documentation.

Perimeter security systems - including IP-connected vehicle barriers, automated gate systems, electric perimeter fencing with smart controllers, and ground radar detection systems - are safety-critical physical security products with digital elements. Systems protecting critical infrastructure sites are Annex III Class II. Commercial and industrial perimeter systems are likely Class I. Their compromise could enable physical security breaches at sensitive facilities.

Point of sale systems and payment terminals are products with digital elements that process financial transaction data and interact with payment card networks. They face specific CRA obligations and must also address the intersection with PCI DSS (Payment Card Industry Data Security Standard) and PSD2 Strong Customer Authentication requirements. While PCI DSS does not provide a CRA exclusion, compliance with it addresses many overlapping security requirements.

Precision agriculture systems - including connected tractors, autonomous field robots, variable rate applicators, soil and crop sensors, and farm management platforms - are products with digital elements subject to the CRA. Agriculture is increasingly recognised as critical infrastructure in the context of food security. Most precision agriculture systems are Default class, but systems integrated into large-scale food supply chain infrastructure may be Class I.

SCADA systems and industrial process controllers form the backbone of critical infrastructure - water treatment, energy generation, chemical processing, and manufacturing. CRA Annex III Class II applies to these systems given their potential for widespread societal harm if compromised. Third-party conformity assessment by an EU Notified Body is mandatory. Manufacturers must align with IEC 62443 and address the intersection with NIS2 Directive obligations for their customers.

Satellite and space technology presents unique CRA challenges. Satellite communication systems and ground segment infrastructure are Annex III Class II as critical telecommunications infrastructure. User terminal equipment (VSATs, satellite broadband modems, satellite navigation receivers used in critical applications) may be Class I or II depending on their role. The 2022 Viasat/KA-SAT cyberattack demonstrated the severe real-world impact of satellite cybersecurity failures.

Smart appliances - including connected washing machines, refrigerators, dishwashers, and ovens - are products with digital elements subject to the full CRA. They typically connect to home networks and cloud services, presenting risks including unauthorised access, data leakage, and as entry points for lateral movement. As consumer products they are Default class but must meet all Annex I security requirements.

Smart cameras and IP video surveillance systems are frequently compromised via default credentials and unpatched firmware - they were among the first device classes targeted by Mirai and similar botnets. The CRA's prohibition on default passwords and requirement for secure update mechanisms directly target these failure modes. Manufacturers must also consider GDPR obligations around video data and the NIS2 implications for critical infrastructure deployments.

Smart greenhouse automation systems - including climate control, automated irrigation, LED lighting control, CO2 enrichment systems, and integrated greenhouse management platforms - are products with digital elements in scope for the CRA. They control critical agricultural production environments and their compromise could affect crop yields, food supply, and energy consumption. Most systems are Default class, but large-scale controlled environment agriculture installations may approach Class I.

Smart grid systems - including advanced metering infrastructure (AMI), distribution automation systems, grid management software, and grid-connected energy storage controllers - are among the most critical products under the CRA. CRA Annex III Class II applies, requiring mandatory Notified Body assessment. The energy sector is NIS2-classified as essential infrastructure, creating overlapping obligations between CRA product requirements and NIS2 operator obligations.

Smart home devices - thermostats, smart speakers, lighting controllers, home security cameras - are among the most common products with digital elements in scope for the CRA. Most will fall into the Default class requiring self-assessment, but devices with gateway functionality may be classified as Important Class I.

Smart toys and connected children's products are among the most sensitive categories under the CRA. Toys intended for children that incorporate AI or collect personal data are explicitly listed in Annex III Class II, requiring mandatory third-party conformity assessment by an EU Notified Body. Manufacturers must also address the intersection with GDPR children's data protections and the Toy Safety Directive.

Telecommunications equipment ranges from consumer CPE (modems, set-top boxes) to core network infrastructure (base stations, routers, switching systems). Core network and 5G infrastructure equipment is Annex III Class II given its critical infrastructure role. End-user equipment is Default class. Manufacturers must also address the intersection with the European Electronic Communications Code (EECC) and 5G security requirements.

Connected vending machines and interactive kiosks - including self-service retail kiosks, bill payment terminals, information kiosks, and automated retail machines - are products with digital elements subject to the CRA. Those integrating payment processing overlap with PCI DSS requirements. Kiosks deployed in public spaces face specific risks including physical tampering, kiosk breakout attacks, and unauthorised data access. Most are Default class; payment kiosks may be Class I.

Warehouse automation systems - including autonomous guided vehicles (AGVs), conveyor control systems, warehouse management systems (WMS), and robotic picking systems - are networked products with safety-critical digital elements subject to the CRA. Their classification as Annex III Class I reflects their safety implications and importance to supply chains. Systems forming part of critical logistics infrastructure may be Class II.

Wearable devices - fitness trackers, smartwatches, and health monitors - collect sensitive biometric and health data and are in scope for the CRA as products with digital elements. Unlike medical devices regulated under MDR, general fitness wearables are not excluded from the CRA and must comply with all Annex I security requirements, including data minimisation, encrypted transmission, and secure update mechanisms.

Access control and physical security vendors manufacturing electronic door controllers, card readers, biometric terminals, visitor management systems, and integrated security platforms for the EU market face Important Class I classification under the CRA. Physical access control products that process biometric data, authenticate identities, or control entry to secured facilities present elevated cybersecurity risk - a compromise of these systems can directly enable physical security breaches.

Agricultural IoT and precision farming vendors placing connected soil sensors, irrigation controllers, crop monitoring systems, livestock tracking devices, and precision agriculture platforms on the EU market must comply with the EU Cyber Resilience Act by September 2026. While many basic agricultural sensors fall into Default Class, connected controllers managing irrigation, fertilisation, or livestock environmental systems - and platforms that aggregate farm operational data - face Class I classification.

Professional audio-visual equipment vendors manufacturing networked AV processors, digital signage players, conference room systems, streaming encoders, and broadcast infrastructure hardware for the EU market must comply with the EU Cyber Resilience Act by September 2026. AV equipment with IP networking, cloud management, and remote control capabilities is within CRA scope, and large format display systems and control processors used in critical facility infrastructure may be classified as Class I.

Automotive OEMs and Tier-1 suppliers placing connected electronic control units, telematics modules, or in-vehicle infotainment systems on the EU market must comply with the EU Cyber Resilience Act by September 2026. Products with safety-critical network interfaces typically fall under Class I, requiring third-party conformity assessment. CVD Portal provides the vulnerability disclosure infrastructure mandated by Article 13.

Avionics and aerospace systems manufacturers selling products to EU civil aviation operators are subject to the CRA for their commercially distributed digital products, creating a new regulatory layer alongside existing EASA certification requirements. While military-use products are generally excluded from CRA scope, commercial avionics - including flight management systems, communications equipment, and ground support software sold under commercial contracts - fall within the regulation. Manufacturers must determine scope carefully and establish CVD and incident reporting capabilities that complement EASA's safety reporting framework.

Chemical and process plant automation vendors supplying distributed control systems (DCS), safety instrumented systems (SIS), and process SCADA platforms to EU chemical manufacturers face the highest tier of CRA obligations, given the catastrophic potential consequences of automation system failure in chemical production environments. The intersection of CRA cybersecurity requirements with Seveso III Directive major accident prevention obligations creates a complex dual regulatory framework. CRA compliance for chemical automation vendors is not only a market access requirement but a fundamental component of major hazard risk management.

Vendors of connected vehicle telematics platforms, vehicle-to-everything (V2X) communication units, and fleet management systems sold into the EU market face CRA obligations as manufacturers of products with digital elements. The automotive sector's adoption of UNECE WP.29 Regulation 155 (vehicle cybersecurity) creates a parallel regulatory framework for type-approved vehicle systems, but aftermarket and fleet connectivity products outside the type approval scope are fully subject to the CRA. Vendors must navigate the boundary between type-approved vehicle systems and CRA-regulated aftermarket products carefully.

Consumer electronics brands placing connected products - including smart TVs, streaming devices, Bluetooth speakers, tablets, laptops, and networked peripherals - on the EU market must comply with the EU Cyber Resilience Act by September 2026. The CRA introduces mandatory security standards and vulnerability disclosure requirements that will materially change product development, launch timelines, and post-market support obligations for consumer electronics brands of all sizes.

Cybersecurity product vendors - including manufacturers of firewalls, intrusion detection systems, endpoint security platforms, SIEM appliances, and identity management products - face Important Class I or Critical Class II classification under the CRA. Security products are among the most closely scrutinised product categories given that vulnerabilities in defensive tools directly enable attacker access to protected environments. CRA compliance is therefore both a regulatory obligation and a market credibility requirement.

Digital signage and kiosk vendors manufacturing networked display systems, interactive self-service kiosks, wayfinding terminals, and digital menu board systems for EU retail, hospitality, and public venue operators must comply with the EU Cyber Resilience Act by September 2026. Kiosks and signage systems connected to corporate networks and content management platforms are products with digital elements that require CRA compliance, with interactive kiosks processing payment or personal data likely classified as Important Class I.

Drone and UAV manufacturers placing commercial and consumer unmanned aircraft systems on the EU market face CRA obligations that run in parallel with the EU UAS Regulation (EU 2019/945) and EASA airworthiness requirements. Connected drones with ground control interfaces, telemetry links, and over-the-air update capabilities are classified as Important Class I under the CRA, given the potential physical and safety consequences of compromised drone operation.

Electronic health record (EHR) and clinical IT vendors selling software to EU healthcare providers face obligations under both the CRA and the emerging European Health Data Space (EHDS) regulation. EHR systems are critical healthcare infrastructure - their compromise directly affects patient safety, treatment continuity, and the confidentiality of some of the most sensitive personal data categories under GDPR. Ransomware attacks on hospital EHR systems have repeatedly caused patient harm through care disruption, making CRA compliance an urgent clinical safety matter as well as a regulatory obligation.

Electronic lock and smart door manufacturers placing network-connected access control products on the EU market must comply with the CRA. Smart locks with Bluetooth, Wi-Fi, or Z-Wave connectivity, electronic door access controllers, and cloud-connected access management platforms are products with digital elements. These products control physical access to homes, offices, and facilities - meaning security failures can translate directly to physical security breaches. Manufacturers must implement robust cryptographic security, establish CVD programmes, and address the specific challenge of long-lifecycle physical security hardware.

Energy management system vendors providing demand response platforms, building energy management systems (BEMS), grid-edge controllers, and energy optimisation software to EU markets face the highest CRA classification tiers due to the critical infrastructure context of energy systems. Products interacting with the electrical grid or managing energy consumption at scale are subject to Important Class I or Critical Class II requirements and face the most rigorous conformity assessment pathways under the regulation.

Enterprise networking equipment vendors - including manufacturers of switches, routers, firewalls, load balancers, and network management appliances - face Important Class I classification under the CRA for virtually all product lines. Network infrastructure products are explicitly named in Annex III as Important Class I by default due to their critical role in enabling network security and connectivity for organisations across the EU.

Manufacturers placing EV chargers and electric vehicle supply equipment (EVSE) on the EU market must comply with the EU Cyber Resilience Act by September 2026. Connected AC wallboxes, DC fast chargers, and the charging station management systems (CSMS) that control them are products with digital elements. Public DC fast chargers with payment handling, OCPP back-office connectivity, and smart-grid interaction typically face Important Class I classification, while basic home AC chargers are more often Default Class. Compliance for EV chargers runs in parallel with the Alternative Fuels Infrastructure Regulation (AFIR), which governs deployment and interoperability rather than cybersecurity.

Vendors of computer-aided facilities management (CAFM) software, integrated workplace management systems (IWMS), and IoT-connected building maintenance platforms sold to EU customers are manufacturers of products with digital elements under the CRA. CAFM systems increasingly integrate with building management systems, access control, energy management, and workplace sensor networks - creating complex connected architectures that must be secured under Annex I. Vendors must establish CVD programmes and incident notification capabilities by September 2026.

Firewall and network security appliances are explicitly listed as Important Products Class II in Annex III of the CRA, requiring mandatory third-party conformity assessment by an EU notified body. Manufacturers face the highest tier of CRA obligations, including stringent secure-by-design requirements under Annex I, mandatory CVD programmes, and 24-hour vulnerability exploitation reporting under Article 14. Given the frequent targeting of security appliances in nation-state and ransomware campaigns, robust vulnerability management is both a regulatory and reputational imperative.

Fleet management and telematics vendors placing OBD dongles, connected vehicle gateways, tachograph interface hardware, and fleet management software on the EU market must comply with the EU Cyber Resilience Act by September 2026. Telematics hardware that connects to vehicle CAN bus systems or transmits location and operational data via cellular networks is classified as Important Class I, given its direct interface with vehicle systems and the sensitivity of the operational data it processes.

Food and beverage automation vendors supplying SCADA systems, batch controllers, filling line automation, and quality control inspection systems to EU food manufacturers must comply with the CRA as manufacturers of products with digital elements. The food industry's increasing connectivity - driven by Industry 4.0 adoption and supply chain traceability requirements - significantly expands the attack surface that must be addressed under Annex I. Ransomware attacks on food processing plants have demonstrated the severe operational consequences of inadequate OT security.

Gaming hardware manufacturers producing gaming consoles, handheld gaming devices, gaming peripherals with network connectivity, and gaming-specific networking hardware for the EU market must comply with the EU Cyber Resilience Act by September 2026. Gaming consoles with online services, account management, and payment processing present a substantial attack surface - and the large, active user base makes vulnerabilities in gaming platforms high-value targets for both financial fraud and account compromise.

Healthcare IT and clinical software vendors providing electronic health record systems, clinical decision support software, hospital information systems, laboratory information management systems, and health data integration platforms to EU healthcare organisations must comply with the EU Cyber Resilience Act by September 2026. Software products that connect to clinical networks, process patient data, or integrate with medical devices are within CRA scope and typically classified as Important Class I.

Manufacturers of connected home health devices - including blood pressure monitors, pulse oximeters, blood glucose meters, and smart scales with network connectivity - must comply with the CRA in addition to any applicable Medical Device Regulation requirements. These devices collect sensitive physiological data in consumer home environments and must meet stringent security-by-design standards. The consumer deployment context means that usability and security must be engineered together, with automatic update mechanisms and clear end-of-support policies particularly important.

HVAC and climate control manufacturers placing networked heating, ventilation, air conditioning, and refrigeration systems on the EU market must comply with the EU Cyber Resilience Act by September 2026. Connected HVAC controllers, building management system (BMS) integration gateways, and smart thermostats are products with digital elements. Industrial HVAC systems integrated into building automation networks face Important Class I classification; residential smart thermostats are typically Default Class.

Industrial automation vendors placing programmable logic controllers, SCADA components, industrial gateways, and HMI systems on the EU market must comply with the EU Cyber Resilience Act by September 2026. OT products connecting to operational technology networks or managing industrial processes are broadly classified as Important Class I under Annex III. The CRA introduces mandatory CVD policies and incident reporting obligations that many OT vendors currently lack entirely.

Manufacturers of connected laboratory instruments - including mass spectrometers, chromatography systems, automated liquid handlers, and scientific imaging systems with network interfaces - must comply with the CRA for their EU-market products. Laboratory instruments increasingly integrate with LIMS platforms, cloud data repositories, and remote diagnostic services, creating network exposure that the CRA directly addresses. Manufacturers must establish vulnerability disclosure programmes, maintain SBOMs for complex instrument software stacks, and implement Article 14 notification procedures.

Precision livestock farming (PLF) technology vendors - supplying connected ear tags, activity monitors, automated milking systems, indoor climate sensors, and livestock health monitoring platforms to EU farmers - must comply with the CRA for their network-connected products. While agricultural technology has not traditionally been considered high-risk from a cybersecurity perspective, the increasing connectivity of livestock management systems and their role in food production and animal welfare creates obligations that vendors must address. The agricultural sector's CRA compliance journey is typically earlier-stage than industrial sectors, making now the critical time to establish foundations.

Managed service providers (MSPs) who develop and distribute their own on-premises software products - including remote monitoring and management (RMM) tools, professional services automation (PSA) software, backup agents, and security management platforms - are manufacturers under the CRA and must comply with all applicable obligations. MSP tooling occupies a privileged position in customer IT environments, making it a high-value target for supply chain attacks. The CRA's security requirements are particularly pertinent for MSP software given the cascading risk that a compromise of MSP tooling poses across the entire customer base.

Vendors of electronic chart display systems (ECDIS), AIS transponders, vessel management systems, and integrated bridge systems sold to EU-flagged vessels or EU ports are subject to the CRA as manufacturers of products with digital elements. Maritime systems face dual regulatory pressure from both the CRA and IMO MSC-FAL.1/Circ.3 cyber risk management guidelines, and vendors must reconcile these frameworks. The integration of navigation systems with satellite communications and shore-side networks significantly expands the attack surface that must be addressed under Annex I.

Medical device manufacturers placing connected devices on the EU market face overlapping obligations under both the EU Medical Device Regulation (MDR) and the EU Cyber Resilience Act. Software as a Medical Device (SaMD) and hardware devices with network interfaces are subject to CRA requirements that run in parallel with MDR cybersecurity guidance. Class I classification is likely for devices processing patient data or connected to clinical networks.

Oil and gas automation vendors supplying SCADA systems, RTUs, and PLCs to EU operators fall within the CRA's scope as manufacturers of products with digital elements used in critical infrastructure. The regulation imposes mandatory vulnerability disclosure policies, secure-by-design requirements, and 24-hour incident reporting obligations that significantly expand existing IEC 62443 compliance programmes. Vendors must align security documentation, conformity assessment, and post-market monitoring with CRA timelines by September 2026.

Smart parking management systems - including IoT-connected parking sensors, access barrier controllers, payment terminals with network connectivity, and cloud-based parking management platforms - are products with digital elements subject to the CRA. Vendors serving EU municipalities, airports, and commercial operators must implement Annex I security requirements, establish CVD policies, and prepare for CE marking by September 2026. Payment data processing in parking systems adds PCI-DSS obligations that run alongside CRA requirements.

Pharmaceutical manufacturing automation vendors - supplying SCADA systems, batch management software, process analytical technology (PAT) platforms, and manufacturing execution systems (MES) to EU pharmaceutical manufacturers - must comply with the CRA for their products. The intersection of CRA cybersecurity requirements and EU GMP computerised systems validation (CSV) obligations creates a dual compliance framework that demands careful coordination between security and validation activities. CRA non-compliance by automation vendors directly threatens their customers' GMP compliance status and product supply security.

Point-of-care diagnostic and in vitro diagnostic (IVD) manufacturers placing network-connected diagnostic instruments and software on the EU market face obligations under both the IVDR (2017/746) and the CRA. Connected blood analysers, point-of-care PCR systems, and laboratory information management interfaces that transmit test results electronically are products with digital elements. The interaction between IVDR conformity assessment and CRA requirements creates dual compliance obligations that must be carefully managed across product development and post-market activities.

Port and logistics automation vendors supplying terminal operating systems (TOS), automated container handling equipment, vessel traffic services software, and cargo tracking platforms to EU ports face CRA obligations as manufacturers of products with digital elements. EU ports are classified as critical infrastructure under multiple frameworks including the CER Directive and NIS2, making supply chain cybersecurity a regulatory obligation for port operators - and therefore a procurement requirement for their automation vendors. The CRA deadline of September 2026 coincides with accelerating port automation investment across EU member states.

Point-of-sale system and payment terminal vendors placing connected card readers, POS terminals, mobile payment devices, and integrated POS software on the EU market must comply with the EU Cyber Resilience Act by September 2026. Payment terminals that process cardholder data and connect to payment networks face Important Class I classification and must satisfy CRA obligations in parallel with PCI DSS and PCI PTS requirements already mandated by the payment industry.

Precision agriculture and AgTech vendors placing autonomous field robots, variable rate application systems, GPS-guided machinery controllers, drone-based crop monitoring systems, and farm data integration platforms on the EU market must comply with the EU Cyber Resilience Act by September 2026. Precision agriculture hardware with autonomous control capabilities, safety-critical functions adjacent to human workers, or integration into farm management information systems requires careful CRA classification - some products face Class I obligations.

Vendors of private 5G network equipment, industrial Wi-Fi infrastructure, and CBRS/NR-U industrial wireless systems deployed in EU manufacturing, logistics, and critical infrastructure environments face CRA obligations as manufacturers of products with digital elements. Private 5G gNBs, core network components, and network management platforms are likely Important Products under Annex III, given their role as foundational connectivity infrastructure. The intersection of CRA obligations and Radio Equipment Directive (RED) cybersecurity delegated act requirements creates a dual compliance framework for wireless equipment vendors.

Railway signalling and train control systems represent some of the highest-consequence digital products in EU critical infrastructure, and their manufacturers face both CRA obligations and stringent rail-specific safety certification requirements under the ERA framework. Vendors of ETCS, CBTC, interlocking systems, and level crossing controllers must navigate the intersection of functional safety requirements and the CRA's cybersecurity mandate. Classification as Important Products Class II is likely for most safety-critical signalling components, mandating third-party conformity assessment.

Robotics and collaborative robot (cobot) manufacturers placing industrial robots, autonomous mobile robots (AMRs), and cobot platforms on the EU market must address CRA obligations alongside existing Machinery Regulation requirements. Network-connected robotic systems with remote programming, monitoring, or update capabilities are classified as Important Class I under the CRA, given their direct role in manufacturing safety and production continuity.

Smart appliance manufacturers producing connected washing machines, dishwashers, refrigerators, ovens, and other networked household appliances for the EU market must comply with the EU Cyber Resilience Act by September 2026. While individual smart appliances are typically Default Class, manufacturers with large connected appliance portfolios must establish CVD programmes, maintain SBOMs, and declare support lifetimes that reflect the 10–15 year operational life consumers expect from major household appliances.

Smart city infrastructure vendors supplying connected streetlighting, environmental sensors, waste management systems, urban mobility platforms, and city management software to EU municipalities must comply with the CRA. The public sector deployment context means that smart city products are subject to both CRA obligations and the procurement requirements of NIS2-regulated public authorities. CRA compliance is rapidly becoming a prerequisite for EU municipal and national government smart city contracts, and vendors must demonstrate conformity credibly before the September 2026 deadline.

Smart home device manufacturers producing connected doorbells, smart locks, home automation hubs, security cameras, smart plugs, and similar IoT products for the EU market must comply with the EU Cyber Resilience Act by September 2026. Smart home products present some of the most common cybersecurity vulnerabilities found in consumer IoT - default credentials, unencrypted cloud communications, and absent update mechanisms - which the CRA directly targets.

Smart meter and Advanced Metering Infrastructure (AMI) manufacturers placing electricity, gas, and water metering products on the EU market face Important Class I classification under the CRA. Smart meters are deployed at scale across EU households - over 225 million units projected by 2027 - making systematic vulnerabilities in metering hardware or the AMI communication network a critical infrastructure concern that regulators will scrutinise closely.

Smart traffic management systems - including adaptive traffic signal controllers, urban traffic control platforms, variable message signs, and connected intersection management systems - are likely Important Products Class I or Class II under the CRA due to their direct role in public safety and urban mobility. Vendors must implement robust security-by-design controls, establish mandatory CVD programmes, and prepare for notified body assessment where applicable. Traffic management systems in EU cities are increasingly targeted in demonstrations of disruptive cyberattack capability, making security programme maturity a reputational as well as regulatory imperative.

Solar inverter monitoring platforms, SCADA gateways for wind farms, and energy management systems sold into EU markets are products with digital elements under the CRA. Vendors in this sector must implement secure-by-design engineering, publish coordinated vulnerability disclosure policies, and meet Article 14 incident reporting timelines by September 2026. The rapid cloud-connectivity trend in renewable monitoring increases the attack surface and the regulatory stakes simultaneously.

Telecom equipment vendors manufacturing base station hardware, optical transport systems, CPE devices, SIM-based modules, and network management systems for the EU market face Important Class I or Critical Class II classification under the CRA. Telecommunications infrastructure is explicitly recognised as critical infrastructure under EU law, elevating the compliance burden for vendors whose products underpin mobile and fixed network operations across the bloc.

Telemedicine platforms and remote patient monitoring (RPM) devices face dual regulatory obligations under both the EU Medical Device Regulation (MDR 2017/745) and the CRA. Vendors must determine precisely which components qualify as medical devices under MDR and which are standalone software or connectivity products subject to the CRA independently. Security failures in RPM devices - which transmit real-time physiological data from patients' homes - carry both patient safety and data protection consequences, making robust security engineering a clinical as well as regulatory obligation.

Video surveillance and CCTV vendors placing IP cameras, network video recorders, video management systems, and cloud-based surveillance platforms on the EU market must comply with the EU Cyber Resilience Act by September 2026. IP cameras have been among the most heavily exploited connected devices globally - Mirai and its variants specifically targeted IP cameras with default credentials - making CRA compliance both a regulatory obligation and a fundamental product security baseline for this sector.

Water treatment and utilities automation vendors supplying SCADA systems, remote telemetry units, and control systems to EU water utilities are subject to the CRA as manufacturers of products critical to essential services. The water sector's classification as critical infrastructure under NIS2 means that automation product vendors face intense scrutiny from both CRA market surveillance authorities and water utility customers implementing their own NIS2 supply chain obligations. Demonstrated CRA compliance is rapidly becoming a mandatory procurement criterion for EU water utility contracts.

Wearable technology brands producing smartwatches, fitness trackers, health monitoring wearables, smart glasses, and connected hearables for the EU market must comply with the EU Cyber Resilience Act by September 2026. Wearables that process health data, integrate with smartphones, or include payment functions face Important Class I classification. The intimate personal data these devices collect - heart rate, sleep patterns, location - makes security failures particularly consequential for users.

A structured notification template for the CRA Article 14 24-hour early warning obligation. Designed to be submitted to ENISA (or the relevant national CSIRT) when a manufacturer discovers an actively exploited vulnerability or severe security incident.

A complete coordinated vulnerability disclosure policy following ISO/IEC 29147 best practice and CRA Article 13. Covers the full disclosure lifecycle: intake, triage, remediation, and coordinated publication.

A straightforward coordinated vulnerability disclosure policy aligned with ISO/IEC 29147. Covers the core commitments expected by security researchers and satisfies CRA Article 13 requirements.

A CVD policy template for contract manufacturers (Electronics Manufacturing Services / EMS companies and Original Design Manufacturers / ODMs) that build products on behalf of brand owners. Addresses how to manage vulnerability disclosures for products you manufacture but do not own or sell under your own name, including coordination with brand owners and their CRA compliance obligations.

A comprehensive CVD policy structured specifically for the EU Cyber Resilience Act. Addresses Articles 13 and 14 obligations including 24-hour early warning, 72-hour full notification, and coordinated disclosure timelines.

A CVD policy template for manufacturers of industrial control systems (ICS), SCADA components, PLCs, HMIs, and other operational technology (OT) products. Addresses the unique challenges of OT environments: operational continuity requirements, long deployment cycles, critical infrastructure obligations, and sector-specific regulatory coordination.

A CVD policy template tailored to the specific challenges of IoT and connected device manufacturers: long product lifespans, constrained firmware update mechanisms, heterogeneous fleets, and supply chain complexity. Structured for CRA compliance.

A CVD policy template for manufacturers of medical devices with digital elements. Navigates the intersection of the EU Cyber Resilience Act, the Medical Device Regulation (MDR), and international medical device cybersecurity guidance. Emphasises patient safety as the primary escalation trigger.

A CVD policy template for Original Equipment Manufacturers (OEMs) that supply components, modules, chipsets, firmware, or subsystems to downstream branded product manufacturers. Addresses the CRA's supply chain security obligations and the unique coordination challenges of operating in the middle of the product value chain.

A field-by-field EU Declaration of Conformity template structured on CRA Annex V. Each section covers one required element of the declaration, from product identification through to signature, with guidance on Article 28 obligations and the simplified Annex IX option.

A CVD policy template specifically written for EU manufacturers placing products on the European market. References EU-specific obligations (CRA, NIS2 intersection, ENISA), using terminology aligned with EU regulatory guidance.

A formal charter for establishing or formalising a Product Security Incident Response Team (PSIRT). Defines the team's mandate, authority, scope, membership, and operating procedures under the EU Cyber Resilience Act and ISO/IEC 30111.

A free responsible disclosure policy template for manufacturers, device builders, and software publishers. Provides clear guidelines for security researchers when they discover a vulnerability, establishes safe harbour protections, and meets CRA Article 13 coordinated vulnerability disclosure requirements.

A pre-filled Cyber Resilience Act risk assessment for a field gateway aggregating soil, weather and machinery sensors over LPWAN, with a cloud backhaul and a farm-management app. It covers the Annex III/IV classification and the conformity route that follows from it, a starter asset inventory, a STRIDE threat analysis mapped to Annex I Part I essential cybersecurity requirements, and the likelihood and impact scales those threats are scored against. Treat it as a first draft to challenge and replace with your own product's specifics before it becomes a technical file.

A pre-filled Cyber Resilience Act risk assessment for a connected-vehicle telematics service and its backend, covering the digital elements an OEM or supplier places on the market outside type approval. It covers the Annex III/IV classification and the conformity route that follows from it, a starter asset inventory, a STRIDE threat analysis mapped to Annex I Part I essential cybersecurity requirements, and the likelihood and impact scales those threats are scored against. Treat it as a first draft to challenge and replace with your own product's specifics before it becomes a technical file.

A pre-filled Cyber Resilience Act risk assessment for a centralised controller that discovers, configures and monitors switching, routing and wireless infrastructure. It covers the Annex III/IV classification and the conformity route that follows from it, a starter asset inventory, a STRIDE threat analysis mapped to Annex I Part I essential cybersecurity requirements, and the likelihood and impact scales those threats are scored against. Treat it as a first draft to challenge and replace with your own product's specifics before it becomes a technical file.

A pre-filled Cyber Resilience Act risk assessment for a next-generation firewall or intrusion detection and prevention appliance inspecting traffic at a network boundary. It covers the Annex III/IV classification and the conformity route that follows from it, a starter asset inventory, a STRIDE threat analysis mapped to Annex I Part I essential cybersecurity requirements, and the likelihood and impact scales those threats are scored against. Treat it as a first draft to challenge and replace with your own product's specifics before it becomes a technical file.

A pre-filled Cyber Resilience Act risk assessment for a programmable logic controller or edge automation controller driving plant equipment, engineered and maintained by an integrator. It covers the Annex III/IV classification and the conformity route that follows from it, a starter asset inventory, a STRIDE threat analysis mapped to Annex I Part I essential cybersecurity requirements, and the likelihood and impact scales those threats are scored against. Treat it as a first draft to challenge and replace with your own product's specifics before it becomes a technical file.

A pre-filled Cyber Resilience Act risk assessment for a autonomous mobile robot or cobot controller with fleet management, teleoperation and over-the-air updates. It covers the Annex III/IV classification and the conformity route that follows from it, a starter asset inventory, a STRIDE threat analysis mapped to Annex I Part I essential cybersecurity requirements, and the likelihood and impact scales those threats are scored against. Treat it as a first draft to challenge and replace with your own product's specifics before it becomes a technical file.

A pre-filled Cyber Resilience Act risk assessment for a consumer hub integrating smart locks, cameras and alarm sensors, paired to a mobile app and a vendor cloud. It covers the Annex III/IV classification and the conformity route that follows from it, a starter asset inventory, a STRIDE threat analysis mapped to Annex I Part I essential cybersecurity requirements, and the likelihood and impact scales those threats are scored against. Treat it as a first draft to challenge and replace with your own product's specifics before it becomes a technical file.

A pre-filled Cyber Resilience Act risk assessment for a smart metering gateway aggregating consumption data and mediating access between meters, grid operators and consumers. It covers the Annex III/IV classification and the conformity route that follows from it, a starter asset inventory, a STRIDE threat analysis mapped to Annex I Part I essential cybersecurity requirements, and the likelihood and impact scales those threats are scored against. Treat it as a first draft to challenge and replace with your own product's specifics before it becomes a technical file.

A pre-filled Cyber Resilience Act risk assessment for a customer-premises or carrier-grade routing equipment with a remote management plane and operator-pushed firmware. It covers the Annex III/IV classification and the conformity route that follows from it, a starter asset inventory, a STRIDE threat analysis mapped to Annex I Part I essential cybersecurity requirements, and the likelihood and impact scales those threats are scored against. Treat it as a first draft to challenge and replace with your own product's specifics before it becomes a technical file.

A pre-filled Cyber Resilience Act risk assessment for a iP camera and recorder combination with motion analytics, remote viewing and operator-managed retention. It covers the Annex III/IV classification and the conformity route that follows from it, a starter asset inventory, a STRIDE threat analysis mapped to Annex I Part I essential cybersecurity requirements, and the likelihood and impact scales those threats are scored against. Treat it as a first draft to challenge and replace with your own product's specifics before it becomes a technical file.

An internal security incident notification policy for manufacturers, covering escalation procedures, Article 14 regulatory notification, and user communication. Designed to sit alongside your CVD policy as an internal-facing document.

A ready-to-use security.txt file template following RFC 9116. The security.txt standard provides a standardised machine-readable location for vulnerability disclosure contact information, satisfying part of the CRA Article 13 requirement for a publicly accessible single point of contact for security researchers.

A structured template for the technical file required by Article 31 and Annex VII of the EU Cyber Resilience Act. Covers the required content areas, from product description and cybersecurity risk assessment through support period justification, standards applied, test reports, and the EU Declaration of Conformity.

A fill-in template for the user information and instructions required by Annex II of the Cyber Resilience Act. It covers all eight Annex II items, from manufacturer identity and the vulnerability reporting contact through to the support period end date and secure decommissioning instructions.

An internal-facing vulnerability reporting process that documents how your security team handles incoming reports from intake through resolution. Complements your public CVD policy with operational procedures aligned to CRA Article 13 and 14.

The Cyber Resilience Act introduces product liability consequences and regulatory penalties that flow up to the manufacturer level - and ultimately to its leadership. Board directors and executive leaders must understand their personal accountability, ensure adequate governance structures are in place, and make resource allocation decisions that enable the organisation to achieve and maintain conformity by December 2027. Delegating CRA compliance to engineering or legal teams without board-level oversight is itself a governance failure.

The CISO is the operational heart of CRA compliance: responsible for the coordinated vulnerability disclosure policy, PSIRT leadership, and the Article 14 obligation to notify ENISA and relevant CSIRTs within 24 hours of discovering an actively exploited vulnerability. Unlike the CTO's programme ownership, the CISO's role is continuous - monitoring, responding, and reporting throughout the product's entire support lifetime.

Cloud and Backend Engineers build the server-side infrastructure that products with digital elements rely on for connectivity, updates, and data processing. The CRA treats the entire connected product - including its backend - as a single regulated entity. This guide explains which CRA obligations fall on engineers building APIs, update delivery pipelines, and cloud-hosted services that are integral to a product's function, and how to produce the technical evidence required for market access.

The Compliance Officer is the operational backbone of CRA conformity: managing the conformity assessment process, assembling and maintaining Annex IV technical documentation, coordinating CE marking, and ensuring the organisation is audit-ready at all times. Where Legal interprets what the CRA requires, the Compliance Officer builds and maintains the evidence that proves the organisation meets it.

The Chief Operating Officer bears operational responsibility for ensuring that the organisation's internal processes, supply chain relationships, and cross-functional teams are structured to meet CRA obligations before and after market placement. While the CTO and CISO own technical and security programme decisions, the COO ensures the operational machinery - programme governance, vendor contracts, incident response readiness, and resource allocation - is in place to execute them. This guide outlines the COO's specific CRA obligations and how to discharge them.

The CTO holds ultimate technical accountability for CRA compliance across the product portfolio. From architecting secure-by-default systems to maintaining the update infrastructure that Article 13 demands, the CTO's decisions shape whether the organisation can credibly affix the CE mark. Effective CRA governance requires the CTO to act as programme owner - setting standards, allocating engineering resource, and signing the Declaration of Conformity.

Customer Success Managers are the primary relationship owners between the manufacturer and the customers who depend on their products. The CRA creates new obligations around transparency - manufacturers must communicate security vulnerabilities, end-of-support periods, and compliance information to customers in a timely and clear manner. Customer Success Managers must understand these obligations, lead sensitive customer conversations about vulnerabilities and EOL, and field the growing volume of CRA due diligence requests from enterprise customers and procurement teams.

DevOps and platform engineers are the architects of the build, test, and delivery infrastructure that underpins CRA compliance. The CRA requires manufacturers to maintain accurate SBOMs, deliver authenticated firmware updates, and respond rapidly to vulnerabilities - all of which depend on the pipelines and tooling that DevOps engineers own. Getting the pipeline right makes compliance sustainable; leaving it manual makes it fragile and audit-hostile.

Embedded systems engineers sit at the intersection of hardware and software, making them responsible for many of the CRA's most technically demanding security requirements. From secure boot chains and hardware security modules to memory-safe firmware and communication protocol hardening, the CRA translates into concrete design constraints at the silicon and firmware level. Understanding which Annex I obligations land directly on your implementation choices is essential for any engineer shipping connected products to the EU market.

Firmware and embedded software sit at the lowest trust boundary of connected products. The Cyber Resilience Act's Annex I technical requirements apply fully to firmware, including secure coding practices, signed update delivery, and maintaining an accurate Software Bill of Materials for embedded components. Developers who understand these obligations early can embed compliance into the build process rather than retrofitting it under time pressure.

General Counsel carries ultimate legal accountability for the organisation's CRA compliance posture. The CRA creates legal obligations that span product design, documentation, market authorisation, ongoing vulnerability management, and mandatory reporting. Failures can result in administrative penalties, product withdrawal, reputational damage, and civil liability under the updated EU Product Liability Directive. Understanding the full scope of exposure - and the legal instruments available to manage it - is essential for effective GC oversight.

Hardware and PCB Design Engineers are responsible for the physical and electronic foundations of products with digital elements. The CRA's Annex I requirements extend into hardware: secure boot roots of trust, cryptographic key storage, tamper-resistance, and the ability to deliver firmware updates securely are all hardware design decisions that affect CRA conformity. This guide explains how hardware engineers translate Annex I requirements into board-level design choices and produce the hardware documentation required for the technical file.

IT Managers responsible for internal tools and infrastructure occupy a supporting but operationally critical role in the CRA compliance programme. Whilst the CRA's obligations fall on the manufacturer of products sold to customers, the internal tooling, infrastructure, and operational processes that the IT Manager owns - vulnerability tracking platforms, SBOM repositories, patch delivery infrastructure, and logging systems - are the machinery that enables the security and compliance teams to meet the CRA's ongoing obligations. This guide explains the IT Manager's specific contributions to a CRA programme.

Legal Counsel carries the interpretive and contractual weight of CRA compliance. From determining which products fall under the regulation to drafting Declaration of Conformity language and embedding security obligations in supplier contracts, Legal is the function that translates regulatory text into binding commitments. Where the CISO executes operational obligations, Legal Counsel defines the legal framework within which those operations must occur.

The Cyber Resilience Act generated significant concern in the open-source community during its legislative development. The final text includes a stewardship exemption designed to protect volunteer maintainers who develop software outside of commercial activity. However, open-source projects that are commercialised - through corporate sponsorship, paid support, or SaaS offerings - may fall within scope. All maintainers who contribute components to commercial products benefit from understanding the CRA's open-source provisions and how to operate a CVD policy that meets modern security expectations.

Penetration Testing and Red Team Leads are a critical source of independent assurance that products with digital elements satisfy Annex I cybersecurity requirements. The CRA does not mandate specific testing frequency or methodology, but it requires manufacturers to demonstrate that products are free from exploitable vulnerabilities before market placement - a standard that is most credibly met with documented penetration testing evidence. This guide explains how pen testers produce, structure, and feed findings into the compliance and incident response programmes.

The Cyber Resilience Act extends compliance obligations into the supply chain. Manufacturers cannot achieve CRA conformity using components or integrated software that is itself non-conformant. Procurement and supply chain managers must translate CRA requirements into vendor selection criteria, contractual obligations, and ongoing governance processes. The SBOM - a machine-readable record of every component in a product - starts in the supply chain, and its accuracy depends on what suppliers provide.

Product Managers sit at the intersection of CRA compliance and product delivery. They must translate legal obligations into roadmap items, define support lifecycles that satisfy the CRA's minimum support period requirements, and ensure users receive timely and clear communications when vulnerabilities are discovered. The PM is often the person who must say 'this security requirement is not optional' to stakeholders prioritising features over compliance.

The Product Security Incident Response Team is the organisational function most directly impacted by the CRA's mandatory reporting obligations. Article 14 requires manufacturers to notify ENISA and national CSIRTs of actively exploited vulnerabilities within strict deadlines, and to operate an accessible coordinated vulnerability disclosure policy. PSIRT managers must design processes that meet these obligations without disrupting engineering velocity or creating unnecessary legal exposure.

Quality assurance teams are instrumental in demonstrating CRA conformity. The technical file that underpins a product's Declaration of Conformity must contain evidence that the product has been tested against the Annex I security requirements. QA engineers design, execute, and document that testing. They also own regression test coverage for security vulnerabilities, ensuring that patched issues do not recur in subsequent releases. This guide explains how QA practices must adapt to the CRA's evidential requirements.

Regulatory affairs professionals occupy the interface between legal obligation and technical implementation. Under the Cyber Resilience Act, they are responsible for selecting and executing the correct conformity assessment route, maintaining the technical file, managing the Declaration of Conformity, and engaging with national competent authorities when required. They must also track how CRA obligations interact with NIS2, the Medical Device Regulation, the Radio Equipment Directive, and other concurrent obligations.

The Cyber Resilience Act is reshaping enterprise procurement. Customers subject to NIS2 are demanding CRA conformity evidence from their technology suppliers as a condition of purchase. Sales engineers and pre-sales consultants are often the first point of contact when these demands arrive - and must be capable of answering accurately, sourcing the right documentation, and positioning the product's compliance status as a competitive advantage. This guide equips sales engineers with the knowledge to handle CRA-related customer conversations confidently.

Security Analysts and SOC Analysts are the operational front line of the CRA's ongoing vulnerability management obligations. The Regulation requires manufacturers to actively monitor, triage, and respond to cybersecurity threats across the product fleet on a continuous basis. Security Analysts own the threat intelligence monitoring, CVE triage, and escalation functions that feed into the PSIRT's Article 14 notification workflow - making their work directly connected to some of the CRA's strictest legal obligations. This guide explains the Security Analyst's specific role in a CRA-compliant programme.

Security Architects sit at the centre of CRA compliance. The Regulation mandates that products with digital elements are designed and built to be secure from the outset, making architectural decisions the single highest-leverage intervention point. This guide explains how Security Architects translate Annex I requirements into concrete design patterns, lead threat modelling programmes, and produce the architecture artefacts that populate the technical file required for market access.

The Cyber Resilience Act places concrete technical obligations on the teams who build and maintain secure products. Security engineers are responsible for implementing the Annex I security controls, operating vulnerability management processes, and providing the evidence that underpins a product's Declaration of Conformity. This guide translates each obligation into engineering practice.

Software Architects make the structural decisions that determine how easy or difficult it will be for engineering teams to satisfy the CRA's ongoing security obligations across a product's entire support period. Decisions about language choice, framework selection, component architecture, update mechanisms, and data handling patterns all have direct Annex I implications. This guide explains how Software Architects translate the CRA's requirements into durable architectural patterns and produce the documentation required for conformity assessment.

The Cyber Resilience Act applies to startups that manufacture products with digital elements sold in the EU market, regardless of company size. There are no SME exemptions from the core obligations, though the regulation includes some proportionality provisions around compliance cost assessments. For first-time founders navigating CRA compliance, the challenge is achieving conformity efficiently - without over-engineering the process - while meeting the key obligations around vulnerability management, SBOM, and CVD policy. This guide provides a practical starting point.

Supply Chain and Vendor Risk Managers are responsible for ensuring that the components, software libraries, and services sourced from third parties do not introduce cybersecurity risk that the manufacturer cannot manage - and cannot adequately disclose in the technical file. Annex I §10 of the CRA explicitly requires manufacturers to address the security of the software and hardware supply chain. This guide explains how Supply Chain Managers operationalise that requirement across vendor assessment, contractual controls, SBOM collection, and open-source governance.

Technical writers play an underappreciated but structurally important role in CRA compliance. Several CRA obligations are fundamentally documentation obligations - the CVD policy must be written clearly enough that researchers can follow it, security advisories must be comprehensible to a technical audience, and the technical file must be structured to satisfy a market surveillance authority review. Technical writers bring the communication discipline to turn legal and engineering inputs into compliant, auditable outputs.

The VP of Engineering is the executive accountable for translating CRA requirements into engineering practice across the entire product organisation. Where the CTO sets direction, the VP of Engineering ensures teams are resourced, processes are adopted, and delivery against security obligations is measurable. The CRA imposes ongoing obligations - not just a one-time certification exercise - which means the engineering org must be structured to sustain compliance through product iterations and team changes.

Austria's national cybersecurity authority for CRA purposes centres on the Federal Ministry of the Interior (BMI) and its GovCERT Austria function, supported by CERT.at operated by nic.at for the private sector. Austria has a significant precision engineering and industrial automation manufacturing sector with considerable CRA exposure. The country's comprehensive NIS2 transposition through the NISG 2024 provides a solid legislative foundation for CRA implementation.

Belgium's Centre for Cybersecurity Belgium (CCB) is a lean but capable national cybersecurity authority that serves as the CRA national competent authority and coordinates CERT.be as the national CSIRT. Belgium hosts numerous EU institutions and multinational headquarters, creating a unique regulatory environment where CCB must balance domestic manufacturer needs with its role as a host-country authority for pan-European entities. Belgian manufacturers in the chemical, pharmaceutical, and industrial sectors have significant CRA obligations.

Bulgaria's national cybersecurity authority structure is coordinated through the State e-Government Agency (SEGA) and CERT Bulgaria, which serves as the national CSIRT. Bulgaria is developing its cybersecurity governance in line with NIS2 requirements, and CRA enforcement capacity is expected to build progressively ahead of the 2027 application date. Bulgarian manufacturers in IT outsourcing, electronics assembly, and growing industrial sectors face CRA obligations as their products incorporate digital elements.

Croatia's national regulatory authority for electronic communications and cybersecurity, HAKOM (Hrvatska regulatorna agencija za mrežne djelatnosti), serves as the national competent authority for the CRA, with CERT.hr operating as the national CSIRT. Croatia joined the EU in 2013 and has progressively aligned its regulatory frameworks with EU requirements. Croatian manufacturers - particularly in the growing technology, maritime equipment, and defence sectors - face increasing CRA obligations as their products incorporate digital elements.

The Czech Republic's NUKIB (Národní úřad pro kybernetickou a informační bezpečnost) is one of Central Europe's most technically capable national cybersecurity agencies, serving as the designated CRA national competent authority. Czech manufacturers are heavily integrated into EU automotive and industrial supply chains - Škoda, Bosch, and numerous tier-2 suppliers have significant Czech manufacturing operations. NUKIB's CSIRT.CZ and GovCERT.CZ provide operational incident coordination for private and public sector entities respectively.

Denmark's national cybersecurity authority, Styrelsen for Samfundssikkerhed (SAMSIK — the Danish Agency for Societal Security), is expected to serve as the national competent authority for the CRA. SAMSIK was formed from a reorganisation of the former Centre for Cyber Security (CFCS) and has absorbed its cybersecurity mandate. Danish manufacturers in the maritime, pharmaceutical, and energy sectors are well-represented in the CRA's scope. The Danish Business Authority (Erhvervsstyrelsen) coordinates on market surveillance for consumer-facing products, while SAMSIK leads technical enforcement.

Estonia's Information System Authority (RIA - Riigi Infosüsteemi Amet) is one of Europe's most technically capable national cybersecurity authorities, with a strong track record in both digital governance and incident response. CERT-EE, operated within RIA, is Estonia's national CSIRT and the Article 14 notification point for the CRA. Estonia's exceptional e-government infrastructure and digital-first economy make it a natural leader in CRA implementation, and its manufacturers - including a growing technology hardware and software export sector - benefit from one of the EU's most mature cybersecurity regulatory environments.

Finland's Transport and Communications Agency Traficom, through its National Cyber Security Centre Finland (NCSC-FI), serves as the national competent authority and CSIRT for the CRA. Finland is a significant exporter of telecommunications equipment, industrial systems, and connected devices, making CRA compliance central to market access for many Finnish manufacturers. Finland's early and comprehensive NIS2 transposition provides a strong regulatory foundation on which CRA obligations are built.

France operates one of Europe's most capable national cybersecurity authorities in ANSSI, which will serve as the national competent authority for CRA enforcement. French manufacturers - particularly in aerospace, automotive, and industrial sectors - face a mature regulatory environment shaped by the Loi de Programmation Militaire (LPM), which already mandates incident reporting for operators of vital importance. The CRA extends comparable obligations across a far broader population of product manufacturers, and ANSSI is expected to play an active role in both guidance and enforcement.

Germany is home to Europe's largest manufacturing sector and one of its most mature national cybersecurity authorities. The BSI (Bundesamt für Sicherheit in der Informationstechnik) has been designated as the national competent authority for CRA enforcement, bringing decades of product security expertise to the role. German manufacturers face a well-established regulatory environment, with the BSI-Gesetz (BSI Act) already mandating incident reporting for critical infrastructure - the CRA extends comparable obligations to a far broader range of product manufacturers.

Greece's Ministry of Digital Governance and its cybersecurity directorate coordinate CRA national competent authority functions, with GR-CSIRT serving as the national CSIRT. Greece has been building national cybersecurity capacity rapidly since 2019, supported by EU funding and coordination with ENISA, which is headquartered in Athens. Greek manufacturers in shipping technology, energy equipment, and industrial systems have CRA obligations as these sectors digitalise. ENISA's presence in Athens creates a uniquely close relationship between Greece and the EU cybersecurity agency.

Hungary's Szabályozási Hatóság (Supervisory Authority for Regulatory Affairs, SZTFH) serves as the national competent authority for the CRA, reflecting Hungary's approach of embedding cybersecurity regulation within its electronic communications regulator. GovCERT Hungary operates as the national CSIRT. Hungary has significant automotive and electronics manufacturing operations - particularly in the Győr industrial corridor - creating substantial CRA compliance obligations for manufacturers integrated into European automotive supply chains.

Ireland's National Cyber Security Centre (NCSC Ireland) serves as the national competent authority for the CRA, despite Ireland's relatively small domestic manufacturing base. Ireland is significant in the EU context as the European headquarters for many global technology companies - including major hardware and software manufacturers - making it a key jurisdiction for CRA compliance decisions. CSIRT-IE, operated within NCSC Ireland, provides operational incident coordination. Ireland's EU membership means full CRA applicability, and the NCSC's expanding capacity reflects the government's commitment to meeting these obligations.

Italy established the Agenzia per la Cybersicurezza Nazionale (ACN) in 2021, creating a dedicated national cybersecurity authority that serves as the country's CRA national competent authority and hosts CSIRT Italia. Italian manufacturers - particularly in the industrial automation, aerospace, and fashion-tech sectors - must navigate CRA requirements alongside Italy's Perimetro di Sicurezza Nazionale Cibernetica, which imposes overlapping security obligations on supply chains for critical national infrastructure. Italy has one of the EU's largest manufacturing sectors, making CRA compliance a significant national economic issue.

Latvia's CERT.LV, operated by the Information Technology Security Incident Response Institution, serves as both the national competent authority and national CSIRT for the CRA. Latvia has developed a capable national cybersecurity agency that combines regulatory and operational incident response functions. Latvian manufacturers in electronics, ICT products, and industrial equipment face CRA obligations as they expand into EU and international markets. Latvia's close coordination with Estonia and Lithuania in Baltic cybersecurity cooperation provides a regional support framework.

Lithuania's National Cyber Security Centre (NKSC - Nacionalinis kibernetinio saugumo centras), operating under the Ministry of National Defence, serves as both the national competent authority and coordinates CERT-LT as the national CSIRT for the CRA. Lithuania has one of the fastest-growing technology manufacturing and fintech sectors in Central and Eastern Europe, and NKSC has built significant regulatory capacity to match. Lithuanian manufacturers benefit from a proactive authority that publishes detailed guidance and engages industry constructively.

Luxembourg's CRA national competent authority is ILNAS (Institut Luxembourgeois de la Normalisation, de l'Accréditation, de la Sécurité et qualité des produits et services), which coordinates with CIRCL (Computer Incident Response Center Luxembourg) as the national CSIRT. Luxembourg is a significant European financial and technology hub, hosting major cloud service providers, telecommunications companies, and satellite operators - all of which have significant CRA exposure. Luxembourg's proactive cybersecurity policy, led by CIRCL's internationally recognised work, provides a strong foundation for CRA implementation.

Malta's national cybersecurity authority for CRA purposes is expected to be the Malta Digital Innovation Authority (MDIA), with the Cybersecurity and Information Protection Directorate (CIPD) serving as the national CSIRT per ENISA's register. Malta has a growing technology and gaming sector, with manufacturers of connected devices and digital services products increasingly subject to CRA requirements. Malta's small market size means that many manufacturers are SMEs, for whom the CRA's proportionate requirements and ENISA's SME guidance are particularly relevant.

The Netherlands has positioned itself as a European leader in coordinated vulnerability disclosure, having published one of the world's first national CVD policies as early as 2013. NCSC-NL serves as both the national competent authority and national CSIRT for CRA purposes, bringing considerable operational maturity to enforcement and incident coordination. Dutch manufacturers benefit from a rich support ecosystem, with NCSC-NL publishing detailed technical guidance and the Dutch government actively engaging industry through the Digital Trust Center (DTC).

Norway participates in the EU single market through the European Economic Area (EEA) agreement, and the EU Cyber Resilience Act will be incorporated into the EEA Agreement following its adoption, making it applicable to Norwegian manufacturers. The Nasjonal sikkerhetsmyndighet (NSM) - Norway's national security authority - leads cybersecurity policy and operates NorCERT as the national CSIRT. Norwegian manufacturers in maritime, oil and gas, and defence sectors face significant CRA exposure given Norway's export-oriented manufacturing profile.

Poland's cybersecurity authority landscape centres on CERT Polska, operated by the research institute NASK under the Ministry of Digital Affairs, which serves as the national competent authority and CSIRT for the CRA. Poland has one of the EU's fastest-growing technology manufacturing sectors, with significant production in electronics, industrial automation, and automotive components. Poland's Ustawa o Krajowym Systemie Cyberbezpieczeństwa (KSC Act) has already created an incident reporting framework that the CRA will complement.

Portugal's Centro Nacional de Cibersegurança (CNCS) serves as the national competent authority for the CRA, building on its mandate under Portugal's Estratégia Nacional de Segurança do Ciberespaço. CERT.PT, operated within CNCS, provides incident coordination. Portugal's manufacturing sector - including electronics, automotive components, and industrial equipment - has growing CRA obligations as digitalisation increases. Portugal's early NIS2 transposition through Lei n.º 65/2021 provides a legislative foundation for CRA implementation.

Romania's Directoratul Național de Securitate Cibernetică (DNSC) was established in 2021 as a dedicated national cybersecurity directorate, taking over functions previously handled by CERT-RO. DNSC serves as both the CRA national competent authority and national CSIRT. Romania has a growing IT manufacturing and services sector, and its manufacturers face CRA obligations as digital components proliferate across industrial and consumer product lines. Romania's active participation in NATO and EU cybersecurity frameworks provides a strong foundation for CRA implementation.

Slovakia's National Security Authority (NBU - Národný bezpečnostný úrad) serves as both the national cybersecurity authority and the CRA national competent authority, with SK-CERT operating as the national CSIRT. Slovakia has a significant automotive manufacturing sector - it produces more cars per capita than any other country in the world - creating substantial CRA obligations for automotive component and system manufacturers. NBU's technical capacity and active ENISA engagement position it as a capable CRA enforcement authority.

Slovenia's national cybersecurity authority structure combines SI-CERT (the national CSIRT operated by ARNES, the academic and research network) with AKOS (Agency for Communication Networks and Services), which has regulatory authority over electronic communications and serves as CRA co-authority. Slovenia has a technically sophisticated manufacturing sector with significant operations in industrial automation, medical devices, and automotive components. SI-CERT is one of the longer-established national CSIRTs in Central Europe, providing operational maturity for CRA incident coordination.

Spain operates a dual-authority cybersecurity structure: the Centro Criptológico Nacional (CCN) under the CNI intelligence service handles government and critical infrastructure, while INCIBE (Instituto Nacional de Ciberseguridad) focuses on private sector and SME cybersecurity. For CRA purposes, INCIBE acts as the primary NCA for private-sector manufacturers, with CCN covering public sector supply chains. Spanish manufacturers in automotive, telecommunications, and industrial sectors have a significant CRA compliance footprint.

Sweden has designated its National Cyber Security Centre (NCSC-SE) - a collaborative body involving SÄPO, FRA, MSB, and Försvarets materielverk - as the national competent authority for the CRA. Swedish manufacturers in the telecoms, automotive, and defence supply chain sectors face both CRA obligations and overlapping requirements under Sweden's national cybersecurity strategy. CERT-SE, operated by the Swedish Civil Contingencies Agency (MSB) as the national Computer Security Incident Response Team (CSIRT), serves as the notification endpoint for Article 14 filings.

Enter the date and time you became aware of an actively exploited vulnerability or severe security incident. Get your exact Article 14 notification deadlines for ENISA reporting.

A 20-question check of your readiness to handle and report vulnerabilities under CRA Articles 13 and 14. Focused on coordinated disclosure, 48-hour acknowledgment, ENISA reporting and advisories. For a whole-programme view across all five CRA domains, use the CRA Maturity Assessment.

Paste your CSAF 2.0 JSON advisory and instantly validate the structure against the OASIS CSAF 2.0 schema. Identifies missing mandatory fields, invalid values, and flags common issues that would cause rejection by automated consumers and ENISA tooling.

Build a complete, publication-ready CVD policy document using a guided five-step wizard. Configure your response timelines, CRA Article 13 and 14 obligations, and product scope, then export a finished Markdown policy you can publish immediately.

Score a vulnerability with CVSS v4.0. Base, Threat and Environmental metrics are all supported, and the MacroVector equivalence class the score derives from is displayed alongside the vector so the result can be verified against the specification. A vector can be supplied in the URL to share or re-check a score.

Calculate CVSS 3.1 base scores for vulnerability severity assessment. Includes guidance on whether the score triggers Article 14 notification obligations under the EU Cyber Resilience Act.

Enter a vulnerability report date and instantly see every critical deadline: Article 14 early warning, full notification, final report to ENISA, researcher 90-day embargo, and your internal acknowledgment SLA. Colour-coded status keeps you on track.

Build a complete Article 14 early-warning notification based on the fields required by CRA Article 14(2). Fill in your product details, exploitation status, and mitigation actions, then copy the finished notification text ready for submission to ENISA or your national CSIRT.

A free open source tool and SBOM vulnerability scanner for engineering and security teams. Paste a list of software components (package@version, one per line) or SBOM file entries to instantly generate NVD CVE Database search links for each component. Quickly scan your SBOM tooling output, detect vulnerable transitive dependencies in container and Docker image stacks, and triage open source license and security issues.

Upload or paste a CycloneDX, SPDX JSON document or dependency manifest to scan all declared components against the OSV.dev open vulnerability database. The scanner identifies known CVEs and security advisories with precise version matching, returning an immediate severity breakdown across Critical, High, Medium, and Low vulnerabilities alongside top exposed components. The live interactive scanner is available at /sbom-exposure with no registration required. The tool operates in-request and does not store your SBOM data on our servers. For continuous vulnerability monitoring and full CRA Annex I Part II(1) due diligence, CVD Portal integrates SBOM ingestion with automated alerting and CSAF 2.0 advisory generation.

Upload or paste a CycloneDX or SPDX JSON SBOM and check it against BSI TR-03183-2 v2.1.0, the German federal guideline that concretises the CRA SBOM requirement. The validator verifies the minimum specification version (CycloneDX 1.6 or SPDX 3.0.1) and every required data field for the SBOM itself and for each component, including creator, timestamp, dependencies, licences and hashes. Validation runs entirely in your browser. The same document is also assessed against the 2026 Minimum Elements for a Software Bill of Materials, version 2.1, published by CISA with seventeen partner agencies including seven EU national cybersecurity authorities. That document replaced the 2021 NTIA minimum elements and expanded the field count from seven to seventeen. It is not EU law and creates no CRA obligation, but it is increasingly what procurement asks for. The two verdicts are reported separately and never blended, because the frameworks genuinely disagree: TR-03183-2 sets minimum format versions that the 2026 elements do not, and the 2026 elements require transitive dependency coverage that CRA Annex I Part II(1) does not.

Generate a standards-compliant security.txt file (RFC 9116) for your product or website. Required by the EU Cyber Resilience Act to make your vulnerability reporting contact discoverable.

Article 14(7) requires mandatory CRA notifications to go through the platform, using your coordinating CSIRT's end-point. How your Member State is determined, and what happens after you file.

No part of the EN 40000 series is cited in the Official Journal, so the Article 27 presumption of conformity is unavailable. What that costs under Article 32, and which standards carry weight now. Cited to EUR-Lex and CEN-CENELEC.

One event can trigger all three regimes. The CRA Article 14, NIS2 Article 23 and GDPR Article 33 triggers, clocks and recipients compared, with the reasons no single filing discharges the others. Cited to EUR-Lex.

The Cyber Resilience Act covers open source software only when supplied in the course of commercial activity. Explains CRA open source steward duties under Article 24, Recital 18, and fine exemptions.

A web app accessed only through a browser is not a product with digital elements. Commission guidance C(2026) 5252 point 21 draws the line, and a downloadable client crosses it.

Article 71(2) sets three dates, not one. Chapter IV from 11 June 2026, Article 14 from 11 September 2026, everything else from 11 December 2027. The preparation sequence that follows from them.

Commission guidance C(2026) 5252 point 110 gives a four-factor test. Scale is irrelevant, and security updates are only exempt while they leave intended purpose and dependencies alone.

Every Annex III category has a vertical standard being drafted, mostly ETSI's EN 304 6xx series, and none is cited in the Official Journal. Which body drafts yours, and what that means for Article 32. Cited to EUR-Lex and ETSI.

The CRA manufacturer obligations as an ordered sequence: scope, classification, risk assessment, Annex I, technical documentation, conformity assessment, CE marking, reporting and support period. Every step cited to EUR-Lex.

Every artefact the Cyber Resilience Act requires: technical documentation (Annex VII), EU declaration of conformity (Annex V), SBOM, CVD policy, Annex II user information and the Article 14 filings, with who receives each and how long it is kept. Cited to EUR-Lex.

Article 13(2) to (4) of the Cyber Resilience Act sets the risk assessment duty. What it must contain, how it decides which Annex I requirements apply, where it is documented, and which products it reaches. Cited to EUR-Lex.

The 24-hour deadline runs from when you become aware. Commission guidance C(2026) 5252 defines that as reasonable certainty after an initial assessment. Cited to EUR-Lex.

Default, Annex III class I, class II or Annex IV critical. How the core functionality test decides, what each class changes about conformity assessment, and why integration does not move you up a tier.

Article 14(7) picks your coordinating CSIRT by main establishment, with a four-step fallback for manufacturers outside the EU. How the ENISA single reporting platform routes it, what you file at 24 and 72 hours, and when dissemination can be delayed.

Article 2 excludes medical devices, motor vehicles, certified aviation products, marine equipment, spare parts and defence products. The full exclusion list with pinpoint citations to EUR-Lex.

Annex I of the EU Cyber Resilience Act lists the essential cybersecurity requirements every product with digital elements must satisfy for CE marking and EU market access from 11 December 2027. It covers two sets of requirements: Part I covers product security properties (design and development), and Part II covers vulnerability handling processes (post-market obligations).

Annex II defines the minimum information and instructions that manufacturers must provide to users of products with digital elements. This user-facing information package is a legally required element of CRA compliance - it enables users to assess the security properties of a product before purchase and to take appropriate action throughout the product's lifetime. Failure to provide the required information is a CRA violation subject to penalties under Article 64.

Annex III of the EU Cyber Resilience Act lists the 'important' product categories that face stricter conformity assessment before CE marking, split into Class I (lower-risk important) and Class II (higher-risk important). Class I products can keep self-assessment only by fully applying harmonised standards, while Class II products need third-party involvement.

Annex IV of the EU Cyber Resilience Act identifies Critical Products - those whose compromise would have the most severe societal or infrastructure impact. Products in Annex IV take the most rigorous conformity route: a European cybersecurity certification scheme where the Commission has mandated one, and otherwise the third-party routes that apply to Annex III Class II. These products cannot self-certify under any circumstance.

Annex V provides the model structure for the EU Declaration of Conformity required under Article 28. It specifies every element that must appear, from product identification through to the conformity assessment procedure used and the signatory's details. Manufacturers preparing a declaration should use Annex V as the checklist that ensures no required element is missing, and Annex VI where the short form pointing to it is supplied with the product instead.

Annex VI gives the model structure for the simplified EU Declaration of Conformity. Instead of reproducing the full Annex V declaration with every unit, the manufacturer supplies a short statement identifying itself and the product, declaring conformity with Regulation (EU) 2024/2847, and pointing to an internet address where the full declaration can be obtained. The simplified form is a delivery mechanism, not a lighter obligation: the full Annex V declaration must still exist, be signed and be kept available.

Annex VII specifies the content of the technical documentation that manufacturers must prepare and maintain to support CRA compliance. The technical file is the complete evidence base demonstrating that a product meets the essential requirements - it includes product design documentation, cybersecurity risk assessments, software bills of materials, test results, and references to the CVD policy. This documentation must be available to market surveillance authorities on request and must be maintained for 10 years after the last product is placed on the market.

Annex VIII contains the conformity assessment procedures a manufacturer follows to demonstrate that a product with digital elements meets the essential requirements in Annex I. It describes internal control (Module A), EU type-examination (Module B), conformity to type based on internal production control (Module C) and conformity based on full quality assurance (Module H). Article 32 decides which of these are open to a given product, based on whether it is a default, important or critical product.

Article 1 establishes the overarching purpose of the EU Cyber Resilience Act: to ensure that products with digital elements placed on the EU market meet baseline cybersecurity requirements throughout their lifecycle. It sets the foundation for all subsequent obligations by defining what the regulation aims to achieve and why. Manufacturers, importers, and distributors operating in the EU single market must understand Article 1 as the lens through which all other provisions are interpreted.

Article 13 of the EU Cyber Resilience Act is the master obligations article for manufacturers, and it applies in full to products placed on the EU market from 11 December 2027. It is one of the longest and most operationally significant provisions in the regulation, covering the full lifecycle of a product's security: initial design and risk assessment (paragraphs 1–5), SBOM and component due diligence (paragraphs 6–8), security updates and support periods (paragraphs 9–11), post-market monitoring and vulnerability handling (paragraphs 12–14), coordinated vulnerability disclosure (paragraphs 15–17), and cooperation with market surveillance authorities and users (paragraphs 18–20).

Article 14 of the EU Cyber Resilience Act requires manufacturers to report actively exploited vulnerabilities and severe incidents to ENISA and their coordinator CSIRT from 11 September 2026, with an early warning within 24 hours, a full notification within 72 hours, and a final report within 14 days. It is the first CRA obligation to apply, fifteen months ahead of the rest of the regulation.

Article 15 of the EU Cyber Resilience Act creates a voluntary reporting pathway alongside the mandatory Article 14 deadlines, letting manufacturers and other parties notify a national CSIRT of vulnerabilities that are not yet actively exploited, near-misses, and security-relevant information that could benefit the broader cybersecurity community. Voluntary notifications are encouraged and acknowledge reporters' good-faith cooperation with EU cybersecurity objectives.

Article 16 of the EU Cyber Resilience Act mandates ENISA to create and operate the single reporting platform that receives Article 14 vulnerability and incident notifications when reporting begins on 11 September 2026. It also covers ENISA's role in establishing the European Vulnerability Database (EVDB) as the EU's authoritative registry for vulnerabilities in CRA-regulated products, and ENISA's coordination function across national CSIRTs for cross-border vulnerability disclosure.

Article 17 wraps up the CRA's reporting chapter. It lets ENISA share notification information with EU-CyCLONe for large-scale incident coordination, empowers the coordinating CSIRT to inform the public about a severe incident (or require the manufacturer to do so), provides that notifying does not by itself increase the notifier's liability, has ENISA add fixed, publicly known vulnerabilities to the European vulnerability database, gives manufacturers, especially SMEs, helpdesk support from the coordinating CSIRTs, and sets up ENISA's 24-month technical report on emerging cybersecurity risk trends.

Article 18 requires manufacturers established outside the European Union who place products with digital elements on the EU market to appoint an authorised representative established within the EU. The authorised representative is the legal point of contact for national market surveillance authorities, ENISA, and other competent bodies. This provision ensures that there is always an EU-based entity accountable for CRA compliance, regardless of where the manufacturer is located.

Article 19 places specific obligations on importers - entities that bring products with digital elements manufactured outside the EU into the EU market for the first time. Importers must verify that manufacturers have met their CRA obligations before placing products on the market, and they bear personal liability for non-compliant products they import. This provision creates a compliance gateway role for importers within the EU supply chain.

Article 2 defines the scope of the CRA - which products and economic operators are covered - and sets out important exclusions for sectors already regulated under other EU frameworks. Understanding the scope boundaries is critical for manufacturers who operate across multiple product categories or who supply products to regulated industries such as medical devices, aviation, or automotive. Where exclusions apply, the CRA does not impose additional obligations, but the underlying sector regulation typically has its own cybersecurity requirements.

Article 20 addresses distributors - entities in the supply chain that make products with digital elements available on the EU market but who are not the manufacturer or importer. Distributors have lighter obligations than manufacturers and importers, but they still have a duty to verify that products are compliant before making them available and to cooperate with authorities when issues arise. Distributors who modify products or sell them under their own name take on manufacturer-level obligations.

Article 21 closes a potential compliance gap by treating importers and distributors as manufacturers - with the full weight of manufacturer obligations - in two key scenarios: when they place a product on the market under their own name or brand, and when they modify a product in a way that could affect its compliance with CRA requirements. This provision prevents companies from avoiding CRA obligations by acting as intermediaries while substantively behaving as manufacturers.

Article 23 complements Article 14 by specifying reporting obligations to market surveillance authorities (MSAs) in addition to ENISA. It also addresses how reports are shared between national authorities and what information manufacturers must provide to users affected by security incidents.

Article 24 introduces the concept of 'open-source software steward' — an entity that provides a platform or support for the ongoing development of open-source software used in products with digital elements, without placing a product on the market itself. Open-source stewards are not manufacturers and are not subject to CE marking or EU Declaration of Conformity obligations. However, they must put a cybersecurity policy in place, publish a vulnerability disclosure process, and cooperate with market surveillance authorities — recognising their structural role in the supply chain.

Article 25 establishes a voluntary security attestation programme for free and open-source software (FOSS). ENISA runs the programme, which enables open-source components to undergo a structured security assessment and receive an attestation certificate. Manufacturers integrating attested FOSS components into their products can reference the attestation as evidence of component due diligence under Article 13. The programme bridges the gap between the CRA's manufacturer obligations and the open-source ecosystem's development model.

Article 27 governs how harmonised European standards and common specifications create a legal presumption of conformity with the CRA's essential cybersecurity requirements. When a manufacturer applies a harmonised standard published in the EU Official Journal, their product is presumed to meet the essential requirements that standard covers. Article 27 also governs the Commission's power to object to harmonised standards that do not adequately cover the essential requirements.

Article 28 requires manufacturers to draw up an EU Declaration of Conformity (DoC) before placing a product with digital elements on the EU market. The DoC is the formal document in which the manufacturer declares that the product meets all applicable CRA essential requirements. Article 28 specifies exactly what information the DoC must contain, making it a legally binding compliance statement that supports the CE marking.

Article 3 contains the statutory definitions that underpin the entire Cyber Resilience Act. The most consequential definition is 'product with digital elements' — any hardware or software product capable of connecting, directly or indirectly, to a device or network. Other defined terms establish who bears obligations (manufacturer, importer, distributor, authorised representative) and what types of activity are regulated (placing on the market, making available, substantial modification). Correctly applying these definitions is the essential first step in CRA compliance planning.

Article 30 is the technical 'how-to' provision for the CE marking under the Cyber Resilience Act. It tells manufacturers where the CE marking must physically appear (on the product, packaging, EU Declaration of Conformity, or accompanying website for software), how visible and legible it must be, when it must be affixed (before the product is placed on the market), and what must follow it (a pictogram, a notified body identification number for Module H assessments, or markings from other applicable Union harmonisation legislation). It also empowers the Commission to specify additional technical labelling rules through implementing acts and obliges Member States to act against improper CE marking use.

Article 32 decides which conformity assessment procedure applies to a product with digital elements. Default products may use internal control (Module A). Annex III Class I products may use it only where the relevant harmonised standards, common specifications or a qualifying European cybersecurity certification scheme are fully applied; otherwise a third-party route applies. Class II products always require a third party, and Annex IV critical products follow a certification scheme where the Commission has required one. The procedures themselves are set out in Annex VIII.

Article 33 requires member states and the European Commission to support microenterprises and small and medium-sized enterprises in meeting their Cyber Resilience Act obligations. The support covers awareness raising, training, testing assistance, dedicated communication channels, and a simplified technical documentation format. It reduces the cost of complying. It does not reduce the obligations themselves.

Article 35 establishes the process by which member states notify the European Commission of conformity assessment bodies authorised to perform third-party CRA assessments. Notified bodies are the organisations that conduct mandatory third-party conformity assessments for Class I and Class II products listed in Annex III. Understanding the notified body framework is essential for manufacturers of higher-risk products who require third-party certification rather than self-declaration.

Article 39 specifies the requirements that conformity assessment bodies must meet before a member state can notify them to the European Commission for CRA purposes. It establishes the competence, independence, and impartiality criteria that notified bodies must demonstrate, and the ongoing obligations they bear once notified. For manufacturers, understanding Article 39 helps in evaluating whether a potential assessment body genuinely qualifies to conduct CRA conformity assessments.

Article 4 is the market access provision at the heart of the CRA's regulatory logic: products that satisfy the essential cybersecurity requirements and bear the CE marking are entitled to free movement throughout the EU single market. Member states cannot impose additional national cybersecurity requirements on CE-marked products without specific EU authorisation. This provision benefits manufacturers by creating a single compliance pathway for the entire EU market rather than requiring country-by-country certification.

Article 5 addresses the obligations of organisations that procure or professionally deploy products with digital elements — particularly public sector bodies and operators of critical infrastructure. While most CRA obligations fall on manufacturers, Article 5 ensures that buyers and users of CRA-regulated products also play a role in maintaining cybersecurity, including applying security updates, considering cybersecurity in procurement decisions, and cooperating with manufacturers on security issues.

Article 52 establishes the framework for coordinating market surveillance activities across EU member states. Because the EU single market means products flow freely across borders, a non-compliant product identified in one member state may be on sale in 26 others. Article 52 ensures national surveillance authorities share information, coordinate investigations, and apply consistent enforcement standards so that manufacturers cannot exploit differences in national enforcement capacity.

Article 59 establishes the legal framework for national market surveillance authorities (MSAs) to carry out joint activities — principally joint investigations and coordinated enforcement actions — when addressing CRA non-compliance that has cross-border implications. Joint activities allow multiple national authorities to pool investigative resources, share evidence, and issue coordinated corrective measures against manufacturers whose products are sold across more than one EU member state. ENISA can participate in a technical advisory capacity and the Commission can support coordination. Joint activities under Article 59 are a significant escalation tool because their cross-border reach makes them much harder for manufacturers to outmanoeuvre than unilateral national enforcement.

Article 6 is the pivotal compliance provision of the CRA: it requires manufacturers to ensure their products with digital elements satisfy the essential requirements set out in Annex I. Annex I is divided into two parts - Part I covers the security properties products must have at the point of design and manufacture, and Part II covers the vulnerability handling processes manufacturers must maintain after placing products on the market. Compliance with Article 6 is the condition for bearing the CE marking and accessing the EU single market.

Article 64 sets out the administrative fine regime for CRA violations. It creates a graduated penalty structure calibrated to the seriousness of the infringement: the most severe fines apply to products that fail the essential cybersecurity requirements or lack vulnerability handling processes; lower tiers apply to other obligation breaches; and a separate tier covers the provision of incorrect or misleading information to authorities. Member state market surveillance authorities apply these fines, subject to national procedural law.

Article 7 designates certain products with digital elements as 'important' because their cybersecurity properties are critical to other systems or pose elevated risks. Products listed in Annex III fall into two classes: Class I (significant cybersecurity functions) and Class II (higher-risk products performing critical security roles). Important products face stricter conformity assessment — self-certification alone is not sufficient; Class I requires third-party documentation review and Class II requires full EU-type examination or quality assurance assessment.

Article 8 designates a narrow category of products with digital elements as 'critical' — those whose compromise could have the most severe systemic impact on cybersecurity. Products listed in Annex IV must use an EU cybersecurity certification scheme under the EUCS (EU Cybersecurity Certification Scheme) for their conformity assessment, rather than the notified body routes available to Annex III products. This makes critical products the only CRA product category linked directly to ENISA's certification framework.

The Commission's worked examples on core functionality, product classification and presumption of conformity, reproduced word for word. Operating systems, SIEM and SOAR, bundled suites, routers with firewalls.

The Commission's worked examples on the Article 13(2) cybersecurity risk assessment, reproduced word for word. Legacy protocols, pre-CRA components and designs, limiting intended purpose, and relying on operating system cryptography.

The Commission's worked examples on Article 13(8) support periods, reproduced word for word. Why five years is a floor and not a default, the Article 13(10) relief for iterative software, and when a substantial modification changes the period.

The Commission's five remote data processing use cases, reproduced word for word. Mobile banking, smart thermostat, e-Reader, industrial robot and cellular network, with what each means for your technical documentation.

The Commission's worked examples on the Article 2(6) spare parts exemption and physical repairs, reproduced word for word. What identical means, and when a replacement part becomes a product in its own right.

The Commission's twelve worked examples on software updates as substantial modifications, reproduced word for word. Persistent login, diagnostics logging, security updates, crypto changes and integration.

The Commission's nine worked examples on CRA scope, reproduced word for word. Mobile apps, browser-only web apps, source code, printers and their drivers, wearables and their companion apps.

The Commission's twenty-two worked examples on free and open-source software under the Cyber Resilience Act, reproduced word for word. Donations, support services, funded features, stewards and contributors.