The Cyber Resilience Act, or CRA, is becoming a practical product and market-access requirement. It covers relevant products with digital elements that are made available on the EU market, so a company based outside the EU can be affected when it sells a covered product to European customers. The European Commission CRA guidance explains the scope and gives examples for manufacturers, developers, and businesses.
For many companies, the difficult part is not hearing about the regulation. It is building repeatable ways to identify product components, assess vulnerabilities, collect technical evidence, manage security updates, involve suppliers, and make reporting decisions.
Readiness appears uneven in German industrial companies (heise online), among SMEs surveyed across Europe by ENISA, and in a global survey of the open-source ecosystem published through Linux Foundation Research. These studies do not use identical samples or questions, so they cannot support a country ranking. Together, they indicate that awareness often develops faster than operational preparation.
Why the CRA requires action before 2027
The reporting provisions of the CRA apply from 11 September 2026. The broader CRA requirements apply from 11 December 2027 to products placed on the EU market, subject to the regulation's scope and transitional arrangements.
The CRA is relevant to more than EU-headquartered businesses. A manufacturer may be within scope when it places an in-scope product on the EU market through direct sales, distributors, importers, marketplaces, or other commercial routes. Whether a specific product is covered depends on its characteristics, intended use, and the role of the company in the supply chain. Commission guidance discusses questions such as manufacturer status, remote data-processing solutions, substantial modifications, support periods, and open-source software.
A company preparing for the CRA usually needs clear answers to the following questions:
- Which products and product versions are made available in the EU?
- Which legal entity is the manufacturer for each product?
- Which software, firmware, and third-party components form part of the product?
- How are vulnerabilities identified, assessed, fixed, documented, and communicated?
- What security support period does the company offer for each product?
- Who can decide whether an incident requires escalation or reporting?
A Software Bill of Materials, or SBOM, is a structured record of the software components and dependencies used in a product. It can help teams establish whether a disclosed vulnerability affects a product version and can support faster remediation work.
German industry: reporting and supplier information create friction
A survey of 200 German industrial companies, reported by heise online, found that 45% of respondents were barely familiar or not familiar at all with CRA requirements. Around one-third said they were not prepared in internal processes, risk management, or security-update management.
The same reporting identified vulnerability and incident reporting as the most common implementation difficulty. Around 62% of respondents described the reporting duty as a challenge, while 30% identified it as a serious concern. In addition, 30% identified product-portfolio compliance assessment and the creation of SBOMs as obstacles.
Supplier information was another weak point. The report states that only 18% of suppliers provide the CRA-related information that manufacturers need, even though manufacturers remain responsible for supplied components included in their products.
These results show why CRA preparation is not only a legal task. A reporting decision depends on knowing which product versions are affected, whether a supplied component is involved, what mitigation is possible, and who has authority to approve external communication.
For example, a manufacturer may learn that a commonly used open-source library contains a serious flaw. The team needs to identify products that contain the library, confirm affected versions, assess exposure, decide on remediation, prepare customer communication, and determine whether the issue triggers CRA reporting. A company with reliable component inventories, product-version records, and escalation routes can usually complete these steps more quickly than one that must search repositories, spreadsheets, supplier emails, and support records during an incident.
European SMEs: practical capacity remains a constraint
ENISA's 2026 SME CRA survey included 194 respondents across 31 countries. It found that 66% had heard of the CRA, while also identifying a gap between general awareness and practical readiness.
ENISA identified incident response and product lifecycle management as the weakest maturity areas. These functions matter because the CRA requires manufacturers to address vulnerabilities and provide security updates throughout the relevant support period. The survey also reports that medium-sized businesses scored about one maturity point higher than micro-enterprises across its five assessed domains.
The request for implementation support was substantial. More than 70% of participants wanted practical templates for secure development and technical documentation. In addition, 142 of 194 respondents identified a need for financial support. Smaller companies often need workable processes and resources, not only high-level legal explanations.
In many small teams, people already perform security work such as code review, dependency updates, testing, and patching. The challenge is to assign responsibility, document evidence, link it to specific releases, and make it available when a customer, supplier, or authority needs an answer.
A SaaS company may, for example, resolve security tickets promptly but still have no agreed process for deciding whether an event is reportable, identifying the person responsible for customer notices, or recording the evidence behind its remediation decision. These omissions can slow down response even when technical capability is strong.
Non-EU vendors: CRA readiness affects EU market access
A company does not need to be established in the EU for the CRA to matter. The relevant question is whether it places an in-scope product with digital elements on the EU market. Commission guidance provides examples and flowcharts on scope, manufacturer obligations, open-source software, remote data-processing solutions, support periods, and reporting.
This creates additional planning work for companies that sell internationally. A non-EU vendor may need to map EU sales routes, identify the legal entity responsible for the product, determine what documentation is required, agree information flows with importers or distributors, and make sure product support commitments align with CRA-related obligations.
A 2026 CRA awareness and readiness study published by Linux Foundation Research found that 66% of all respondents were unfamiliar with the regulation. Among respondents in the United States and Canada, 72% were unfamiliar with it.
The study also reported that:
- Around 40% of CRA-aware respondents had not established whether the CRA applied to them
- 46% were unsure about the regulation's deadlines
- 41% of manufacturers expected to achieve full compliance by December 2027
- 39% were unsure whether they could meet that deadline
- 32% generated SBOMs for all products
- 51% relied passively on upstream projects for security fixes
These figures come from a global survey of the open-source ecosystem, not from a representative national sample of all companies in the United States, Canada, or other non-EU markets. They are nevertheless relevant to software and connected-product teams because many commercial products use open-source components.
The shared readiness problem: evidence and ownership
The German industrial survey, ENISA's European SME research, and the global open-source study examine different populations. Each nevertheless identifies practical barriers related to product information, vulnerability response, documentation, and organisational capacity.
| Common gap | Why it creates difficulty |
|---|---|
| Unclear product scope | Teams may not know which products, versions, services, or routes to market need CRA preparation |
| Limited component visibility | A vulnerability may be hard to trace to affected products and customer deployments |
| Incomplete SBOM practice | Dependencies can be difficult to track across releases and product variants |
| Weak incident escalation | Security, product, legal, support, and leadership teams may be unable to make decisions quickly |
| Limited supplier evidence | Manufacturers may lack information about third-party components, updates, and support commitments |
| Unclear ownership | Important responsibilities may fall between product, engineering, security, legal, procurement, and commercial teams |
| Documentation created late | Teams may need to reconstruct decisions and test evidence shortly before a release or market deadline |
The practical objective is not to build a separate compliance process that sits outside product development. Companies need ways to connect product-security work to specific products, releases, components, risks, decisions, and support commitments.
What to prioritise now
A proportionate programme normally starts with products that generate significant EU revenue, face higher cyber risk, have complex component dependencies, or rely on many suppliers.
-
Map EU-facing products and routes to market. Record products, versions, digital components, EU sales routes, and the legal entity responsible for placing each product on the market.
-
Assign product-level ownership. Name an accountable owner for each priority product or product family. Involve engineering, product, security, legal, support, procurement, and commercial teams where their decisions affect the product lifecycle.
-
Assess the current position. Review existing practices for risk assessment, secure development, technical documentation, vulnerability management, security updates, support periods, reporting, and supplier evidence.
-
Improve component and version visibility. Generate and maintain SBOMs, track dependencies, and connect components to product versions. Start with high-priority products rather than attempting to solve the full portfolio at once.
-
Test an incident scenario. Use a severe vulnerability in a shared dependency as a tabletop exercise. Check whether the company can identify affected products, assess impact, approve remediation, inform customers, and determine whether reporting is required.
-
Set supplier expectations. Update supplier questionnaires, contract terms, and escalation processes for critical software, hardware, cloud, and development suppliers. Ask for the information that product teams need to assess and address vulnerabilities.
These steps support CRA preparation, but they also improve day-to-day product operations. Clear component data and decision routes can make customer due diligence, vulnerability response, supplier management, and release planning easier to manage.
Conclusion
The available evidence points to a recurring problem: organisations may be aware of the CRA but still lack the product-level processes required to put its requirements into practice. German industry survey reporting, ENISA's Europe-wide SME research, and Linux Foundation Research's global survey all point to gaps in awareness, incident response, product lifecycle management, documentation, component visibility, supplier information, or implementation capacity.
The practical starting point is product reality rather than standalone paperwork. Map EU-facing products, establish clear ownership, improve component visibility, request supplier evidence, and test vulnerability escalation. Those actions give companies a workable foundation for the reporting obligations that begin in September 2026 and the broader CRA requirements that apply from December 2027.