Cyber Resilience Act

CRA Check for software, hardware and connected products

This interactive check helps companies, manufacturers, importers, distributors, software providers, component suppliers and open-source structures make an initial assessment of whether the Cyber Resilience Act may be relevant and which next steps for security, conformity, SBOM, vulnerability handling and product documentation are advisable.

Start the check

Products with digital elements
Secure by design
SBOM and OSS
VDP, PSIRT and reporting logic
CE and conformity file

What you get as a result

The CRA Check provides a preliminary risk level, a likely role and product classification, typical reasons, prioritised review points, documents to prepare and a copyable summary for a structured enquiry.

Covers manufacturer, importer, distributor, reseller, component and OSS constellations.
Classification of deadlines: reporting obligations under Art. 14 CRA have applied since 11.09.2026, the rules on conformity assessment bodies since 11.06.2026, and the main CRA obligations apply from 11.12.2027.
Interfaces with NIS2/BSIG, Data Act, GPSR, product liability, GDPR, open source and software contracts.

Interactive visualisation

CRA product security compass

The Cyber Resilience Act does not require an isolated checklist but a robust product security model. Click on a review module to see which evidence typically has to be built up in a CRA project.

Scope & role The starting point is defining the product with digital elements: manufacturer, importer, distributor, substantial modifier, component supplier or open-source steward. Without this classification, the CRA obligations path cannot be determined reliably.

Orientation in five steps

Define the product boundarySoftware, hardware, remote component, firmware, SDK, library, cloud function or purely internal service must be clearly delineated.

Determine the roleManufacturers, importers, distributors, substantial modifiers, component suppliers, open-source stewards and buyers have different obligations and evidence points.

Check category and conformityImportant or critical product categories can tighten the conformity procedure and the evidence requirements.

Build the security lifecycleThreat modelling, secure by design, SBOM, vulnerability handling, security updates, support period and technical documentation should be considered together.

Manage deadlines and interfacesReporting obligations since 11.09.2026, main obligations from 11.12.2027 as well as NIS2, Data Act, GPSR, product liability, GDPR and open source should be brought together in one roadmap.

What this check does

The CRA Check is a structured first orientation. It does not replace an individual assessment, but it helps you sort the subject matter, the likely relevant role, typical readiness gaps and the next documents for a legal or internal compliance review.

When is the CRA typically relevant?

The CRA is typically relevant when software, hardware, connected products, embedded systems, firmware, components or digital functions are made available on the EU market. Decisive factors are the product boundary, making available on the market, the company's role and possible exemptions.

Which obligations are at the centre?

At the centre are cybersecurity requirements across design, development, production, delivery and maintenance, vulnerability management, security updates, support period, technical documentation, EU declaration of conformity, CE and marking topics, and reporting processes for actively exploited vulnerabilities or severe security incidents.

What are the limits of the check?

The check cannot replace a binding product classification, a technical review or a final conformity assessment. Special legislation, special open-source rules, third-party assessment, harmonised standards, notifications via the ENISA Single Reporting Platform, the technical descriptions of the product categories (Implementing Regulation (EU) 2025/2392), the Commission guidelines C(2026) 5252 and specific product categories must be examined in each individual case.

Interactive questionnaire

Assess CRA applicability and readiness

Answer the following questions as specifically as possible. The result is calculated from role, product, category, readiness and urgency signals.

Step 1 of 6

1. What role does your company have?

Choose the role that best matches the product.

Manufacturer or provider under its own brandYou develop, commission, market or provide software, hardware or digital products under your own name. Importer into the EUYou place a product from a manufacturer outside the EU on the EU market for the first time. Distributor or resellerYou make products with digital elements available without substantially modifying them. Reseller, integrator or white-label provider with substantial modificationYou modify, brand, configure or integrate the product in a way that may make you a manufacturer. Software, hardware or component supplierYou supply libraries, SDKs, firmware, modules, hardware components or embedded software. Open-source steward or commercial OSS structureYou support free or open-source software on a sustained, structured basis or in a commercial setting. Buyer, user or integrator of third-party productsYou want to review suppliers, contracts, evidence, SBOMs, security advisories or update commitments. Internal development onlyThe tool is not provided externally and not offered as a product on the EU market.

2. Which product is concerned?

The CRA applies to products with digital elements. The product boundary is often the most important review point.

Software, app, desktop program, plugin or mobile appStand-alone software or application that is or will be provided externally. Cloud, SaaS, API or remote component as part of the productA remote digital function is required for the product or is the responsibility of the manufacturer. IoT, smart device, wearable or connected consumer productHardware with a digital element, data connection, app connection or update capability. Industrial, OT, machine, control or edge systemProduct with digital control, sensors, gateway, automation or operating functions. Cybersecurity productFirewall, VPN, IAM, password manager, EDR, SIEM, scanner, key management or a comparable security tool. Component, library, firmware, SDK or moduleA building block that is provided separately or integrated into other products. Open-source software or OSS componentCommunity project, commercially supported OSS, open-core model or OSS building block. No external market productPurely internal use without external provision, distribution or product-like offering.

3. How is the product made available?

Making available on the market, the EU connection and possible special rules strongly influence the classification.

Already on the EU marketThe product is already sold, offered for download, distributed or provided to customers in the EU. EU market launch or major release plannedA launch, release, rebranding, import or new sales channel is imminent. B2B supply chain or OEM/white-label provisionThe product or component is supplied to other companies, manufacturers, integrators or platforms. Possibly a specially regulated product areaMedical devices, automotive, aviation, radio equipment, maritime or other special legislation could be relevant. Non-commercial free open-source softwareCommunity project without commercial provision, systematic support or product marketing. UnclearProduct boundary, EU connection, making available on the market or allocation of roles are not yet properly documented.

4. Which CRA category could apply?

If the category has not yet been checked, choose “unclear”.

Standard product with digital elementsNo recognisable important or critical category, but software, hardware or a digital function with security relevance. Possibly an important product, Class IFor example identity and access management, browsers, password managers, antivirus, VPN, network management, SIEM, operating systems, routers, modems and switches (Annex III Class I CRA, technical descriptions in Implementing Regulation (EU) 2025/2392). Possibly an important product, Class IIFor example hypervisors and container runtime systems, firewalls, intrusion detection and prevention systems, and tamper-resistant microprocessors and microcontrollers (Annex III Class II CRA). Possibly a critical productHigh cybersecurity relevance, critical product category or possible need for a special conformity assessment. Possibly exempt or overriddenSpecial legislation, product law or sector-specific regulation could override or delimit the CRA. Unclear or not yet checkedThere is no reliable product categorisation, no review of standards and no conformity concept yet.

5. Which CRA readiness building blocks already exist?

Tick everything that is reliably documented or already implemented in practice.

Product-related cybersecurity risk assessmentThreats, operating environment, users, attack scenarios and safeguards are documented. Secure by design and secure by defaultSecure defaults, hardening, access protection, minimal attack surface and secure updates are planned or implemented. SBOM, OSS and component overviewComponents, versions, dependencies, OSS licences, CVEs and supply chain risks are traceable. Vulnerability handling, VDP or PSIRTVulnerability intake, assessment, remediation, disclosure, patch process and communication are defined. Technical documentation and product fileArchitecture, security requirements, tests, measures, residual risks and evidence are documented. Conformity assessment, CE and EU declaration of conformity plannedConformity procedure, standards strategy, marking, user information and manufacturer details are prepared. Support period and update policy definedSecurity updates, patch level, end of life, support duration and user information are set. Reporting process for actively exploited vulnerabilities and severe incidentsRoles, escalation, deadlines, preservation of evidence, ENISA/CSIRT logic and customer communication are prepared. No structured CRA readiness yetIndividual measures may exist, but there is no reliable overall CRA picture.

6. Is there pressure to act or are there interfaces?

Select all signals that are relevant for the product or the organisation.

Actively exploited vulnerability or critical vulnerabilityA CVE, exploit, security advisory, patch pressure, customer pressure or risk to users is known. Severe security incident related to the productAttack, compromise, misuse, outage, data leak or security impact on users. Launch, import, distribution or release is imminentThe product is to be newly made available, extended, rebranded or placed on the market in the EU. Customer, investor, insurer or auditor requires evidenceSecurity questionnaire, vendor assessment, due diligence, tender or cyber insurance. Third-party or special conformity assessment could be relevantImportant or critical category, harmonised standards, certification or notified body are unclear. Supply chain, OSS or component problemInsecure library, missing SBOM, unclear upstream responsibility, supplier gap or build risk. Interface with NIS2, Data Act, GPSR, product liability or GDPRCybersecurity, data access, product safety, liability or data protection obligations run in parallel. A roadmap up to 11.12.2027 is to be plannedReporting obligations, main obligations, legacy products, portfolio, release planning and support period are to be managed. Preventive review without an acute deadlineThere is no specific incident, but CRA applicability and a gap analysis are to be clarified.

Typical deadlines, risks and measures

Date / trigger	Relevance	Typical measure	Risk signal
10.12.2024	Cyber Resilience Act enters into force.	Start product and role mapping, check the product portfolio against the CRA scope.	No responsibility for the CRA defined within the company.
11.06.2026	Rules on the notification of conformity assessment bodies (Chapter IV CRA) apply.	For important Class II products and critical products, clarify the availability of notified bodies and the time needed for third-party assessment early.	Third-party assessment required, but no appointment with a notified body scheduled.
11.09.2026	Since this date, the reporting obligations under Art. 14 CRA have applied to actively exploited vulnerabilities and severe security incidents, including for existing products (Art. 69(3) CRA). Reports are made via the ENISA Single Reporting Platform to the coordinating CSIRT, in Germany CERT-Bund at the BSI: early warning within 24 hours, notification within 72 hours, final report after 14 days or one month.	Prepare VDP, PSIRT, incident runbook, preservation of evidence, escalation and reporting channels.	No process for vulnerability intake, CVE assessment or customer communication.
12.09.2026	Since this date, the Data Act design obligations (Art. 3(1) Data Act) have applied to connected products and related services placed on the market thereafter.	Plan product data, interfaces, trade secrets and GDPR gates together with the CRA architecture.	Connected product without a data access and security-by-design concept.
09.12.2026	New product liability law under Directive (EU) 2024/2853 applies to products placed on the market from this date, expressly including software and updates; the German act modernising product liability law has been passed by the Bundestag and Bundesrat.	Structure release notes, security patches, technical documentation and the liability file.	Security decisions exist technically but are not documented in a way that would stand up in court.
11.12.2027	Main CRA obligations become applicable.	Establish secure by design, technical documentation, SBOM, CE/conformity file, support period and update policy.	Product continues to be sold without a conformity strategy and evidence.
Event-driven	Actively exploited vulnerability, severe security incident, recall, customer or authority request.	Coordinate incident response, legal reporting assessment, customer communication, patch plan and preservation of evidence.	Public exploit, critical CVE, compromised component or missing SBOM.

Sensible next steps

Related ITMR checkers and follow-up reviews

NIS2 CheckChecks whether cybersecurity, management, risk management and reporting obligations are relevant for the organisation in parallel. Open Source / SBOM CheckHelps structure components, OSS licences, CVEs, supply chain risks and SBOM evidence in a CRA-ready way. Data Act CheckClassifies data access, connected products, related services and cloud switching as an interface with the CRA. Interactive risk matrix / Risk CockpitPrioritises CRA, security, product, data protection and supply chain risks by impact and urgency. Regulatory timelineShows relevant deadlines for the CRA, Data Act, product liability, NIS2, AI Act and further digital regulation at a glance. Document Dossier BuilderStructures product file, technical documentation, evidence, security policies, contracts and audit documents.

In-depth articles on the ITMR blog (in German)

The check gives a classification; the articles explain the legal position in detail, with references to the law and its current status.

Reporting obligation · Art. 14 CRA CRA reporting obligation since 11.09.2026 Early warning, 72-hour notification, final report and reporting platform: what manufacturers must now do in the event of actively exploited vulnerabilities and severe incidents. Read the article One incident, several reporting channels Reporting a cyber incident under NIS2, CRA, GDPR and DORA When your company is a manufacturer, an entity and a controller at the same time: the four reporting regimes, their deadlines and starting points compared. Read the article Open source · Art. 24 CRA The CRA and open source Manufacturer, steward or outside the scope: due diligence when integrating OSS components and the role of the open-source software steward. Read the article

Have your CRA applicability reviewed in a structured way

For software, connected products, IoT, embedded devices, security products, components or open-source structures, the CRA review should be built into the product roadmap, security engineering, contract drafting and evidence documentation early on.

Get in touch Have software contracts reviewed

Legal notice

This CRA Check is intended as an initial orientation and does not replace legal advice in an individual case. Whether the Cyber Resilience Act actually applies, which role your company has, whether an important or critical product category is affected and which conformity, reporting or documentation obligations exist must be examined on the basis of the specific product, the supply chain, the technical architecture, the making available on the market and the current position of authorities and standards. Legal status: 24.10.2026. Harmonised standards for the CRA have not yet been published in the Official Journal; the German CRA implementation act (BSI as market surveillance authority) has been passed by the Bundestag but not yet promulgated; a single reporting point for several legal acts has only been proposed in the Digital Omnibus. To learn how we support manufacturers and software providers with implementation, see our section on Cybersecurity; liability questions are covered on our page on product liability law.