EU CRA Frequently Asked Questions (FAQs)
The European Cyber Resilience Act (EU CRA) casts a wide net across connected products, both software and hardware—and it addresses one of the most complex challenges facing product companies today: cybersecurity across the full product lifecycle. As a result, many organizations are asking the same practical questions: Which products are in scope? What documentation is required? How should legacy portfolios be handled? And what needs to happen before the December 2027 deadline?
Below are 10 of the most common EU CRA questions we hear from customers as they begin preparing for compliance. These answers are intended to complement—not repeat—the European Commission’s EU CRA FAQ materials, and to provide a practical starting point before diving into the full 66 pages of their FAQ.
Does the CRA apply only to companies located in the EU?
No. The CRA is not limited to companies that are physically located in the EU. The key question is whether their product is being placed on the EU market.
If a manufacturer, importer, or distributor places a product with digital elements, defined as software or hardware that has a direct or indirect logical or physical data connection, on the EU market, the CRA applies regardless of where the product was designed, developed, manufactured, or assembled.
In short, companies based in North America, Asia, or another non-EU region will need to comply if they sell products that contain digital elements into the EU.
A non-EU company cannot avoid CRA obligations simply because it has no office, employees, or headquarters in an EU Member State. If the product with digital elements is offered to EU customers, the company should assume that CRA scoping, categorization, conformity assessment, technical documentation, vulnerability handling, and support-period obligations need to be addressed.
For global manufacturers, this means CRA readiness should be treated as a market-access issue, not just a European legal department issue.
Is there a simple way to get an initial view of whether a product is in scope for the EU Cyber Resilience Act?
Yes. A practical screen is this: First check if the product is not already regulated under another EU product cybersecurity regime that excludes it from the CRA — for example, motor vehicles regulated under UNECE R.155 — and the product has a data interface, then it will not be in scope for the CRA.
Second, check if the products has a digital interface. The data interface does not need to be an obvious network interface such as Ethernet, Wi-Fi, Bluetooth, cellular, or USB. It can also be a lower-level hardware or software interface, such as SPI, I2C, an API, or another direct or indirect connection through which digital data is processed, transmitted, stored, or exchanged.
In simple terms: if the product contains hardware or software that has a direct or indirect data connection to another device or network, and no CRA exclusion applies, such as the product is already regulated, you can assume that the product will be in-scope and then confirm by check or using software such as BG Networks’ Aithra EU CRA conformity automation software.
We’ve created a product category table here that will also help with an initial assessment:
| Product Category | In Scope? | Notes |
|---|---|---|
| IoT devices (smart home cameras, thermostats, doorbells, etc.) | ✅ In Scope | Core target of the CRA; network connectivity is inherent |
| Consumer electronics (smart TVs, tablets, wearables, fitness trackers) | ✅ In Scope | Covered if capable of connecting to a device or network |
| Industrial control systems & OT devices (PLCs, SCADA, sensors with connectivity) | ✅ In Scope | Includes IIoT and connected factory equipment |
| Networking equipment (routers, switches, firewalls, modems) | ✅ In Scope | Often classified as Important or Critical under Annex III |
| Software products (desktop apps, mobile apps, operating systems) | ✅ In Scope | Applies to standalone software placed on the market commercially |
| Remote data processing solutions (manufacturer-operated cloud backends required for product function) | ✅ In Scope | In scope only when designed by the manufacturer and required for the product to function |
| Hardware components sold separately (microcontrollers, chipsets, modules) | ✅ In Scope | Components placed on the market independently are covered |
| Connected toys & children's products | ✅ In Scope | Explicitly cited by the European Commission as a primary use case |
| Payment terminals & devices handling financial data | ✅ In Scope | May fall into stricter Important or Critical classification tiers |
| Medical devices & in vitro diagnostic devices | ❌ Excluded | Governed by EU MDR (2017/745) and IVDR (2017/746), which already impose cybersecurity lifecycle requirements |
| Motor vehicles & automotive systems | ❌ Excluded | Covered by Regulation (EU) 2019/2144 and UNECE vehicle cybersecurity rules; note: components sold separately outside this regime may remain in scope |
| Civil aviation products | ❌ Excluded | Certified under Regulation (EU) 2018/1139 (EASA framework) |
| Marine equipment | ❌ Excluded | Falls under Marine Equipment Directive 2014/90/EU |
| National defense & national security products | ❌ Excluded | Must be developed or modified exclusively for defense/security purposes; dual-use products remain in scope |
| Non-commercial open-source software | ❌ Excluded | Software developed and distributed outside any commercial activity is out of scope; open-source integrated into a commercial product is covered under the manufacturer's obligations |
| Products not placed on the EU market (internal use, R&D prototypes) | ❌ Excluded | Products not supplied in the course of a commercial activity fall outside scope |
| Identical spare parts (replacing components to same specification) | ❌ Excluded | Narrow exclusion under Article 2(6); any deviation from identical specs removes this exemption |
| Pure SaaS / cloud services (not tied to a specific product's functionality) | ❌ Excluded | Standalone cloud services without a connected PDE fall outside scope; may be subject to NIS2 instead |
Are products in scope for the EU CRA that have digital elements that we have been shipping and manufacturing for years?
Individual units of a product with a digital element, sold before December 11, 2027, are not in scope. In other words, the regulation does NOT require units that are in the hands of customers to comply.
But a soon as the calendar changes from December 10 to December 11, 2027, units for that same product type are now in scope.
The key issue is whether the product was already placed on the EU market before December 11, 2027, or whether new units of that product will be placed on the EU market on or after December 11, 2027.
Also keep the EU CRA’s September 11, 2026 deadline in mind for exploited vulnerability reporting. This applies to all units shipped for product types that are in-scope, even if they had been sold before the December 2027 date.
So not only does the EU CRA cast a very wide net in terms of the types of software and hardware products that are in scope, it also applies to entire product portfolios including products that may have been designed many years ago. One of the challenges of the EU CRA is adding security to those older products that were designed before the need for product security was widely recognized.
How is the status of a product “being on the market” defined?
If a product is manufactured before the cutoff date, that is not enough to exempt it from CRA compliance. To be "placed on the market" before the December 2027 deadline, the product must have completely left the manufacturing process and been offered to the public, an importer, or a distributor in a ready-to-use state.
This determination applies to individual product units, not entire product lines or models. For example, if your factory produced 1,000 units of a smart device in July 2027, but only 500 were actually supplied to distributors in the EU before the December cutoff, the remaining 500 units that sit in a warehouse and are sold after the cutoff must be fully CRA-compliant.
What should a zero-based CRA readiness program do in its first 90 days?
A sensible approach is to determine where your company stands in terms of the EU CRA as opposed to writing new cybersecurity policies. Start by creating a list of all product types, versions, and which of those use cloud or remote data processing. Then determine which products are in scope, out of scope, and what EU CRA product category they fall into. Next consider the amount of work for each product to conform to the EU CRA. This includes creating a product-specific risk assessment, technical documentation, conformity assessment, support-period decisions, cybersecurity-related user instructions, vulnerability handling, and, in many cases, information about remote data processing dependencies. With this information, the size of the task to achieve EU CRA conformity can be scoped.
How large is the effort likely to be, and which functions need to be involved?
For most businesses, this is not a “security team project.” The CRA’s obligations span planning, design, development, production, delivery, maintenance, user information, support-period commitments, and reporting. That means the minimum working group usually includes product management, engineering, product security, regulatory/compliance, quality, procurement/supply-chain, support/operations, and the commercial team that controls packaging, purchase flows, and customer-facing assurances.
The overall amount of work is going to be dependent on the number of products a company plans to sell after December 11, 2027. Many companies will have thousands of products that will need to conform.
How much of our cloud backend, mobile app, or hosted control plane is actually inside CRA scope?
For mixed hardware-software-service offerings, the key concept is the CRA’s definition of a product with digital elements: it includes the product and its remote data processing solutions. “Remote data processing” covers data processing at a distance where the software is designed or developed by the manufacturer, or under the manufacturer’s responsibility, and where the absence of that remote processing would prevent the product from performing one of its functions. The recitals make that practical: a cloud function used to control a smart-home device remotely can fall in scope, and a mobile app that depends on a manufacturer-operated API or database can bring that into scope, too.
Can we reuse ISO 27001, IEC 62443, ETSI EN 303 645, Common Criteria, or existing secure development evidence?
Parts of the processes outlined in these standards can be used as well as the resulting security artifacts. But these standards cannot be a substitute for the EU CRA. The evidence that the EU CRA requires is unique and will require its own process to generate. So you can reuse what you already have for these security standards, but you’ll need to build specific EU CRA processes and comply with its specific security requirements.
What should we require from suppliers, OEMs, and component vendors now?
The CRA makes supplier governance a front-end issue. Technical documentation must cover the vulnerability-handling processes used by the manufacturer, including the SBOM, coordinated-vulnerability-disclosure policy, evidence of a vulnerability-reporting contact point, and the technical solution used for secure update distribution. A practical contract package should therefore cover SBOM data delivery, product/version traceability, EOL notice periods, vulnerability notification timelines, access to patches or mitigations, update-signing and distribution responsibilities, and retention of evidence needed for authorities.
What documentation and evidence are needed in a conformity file?
Authorities and notified bodies will care about product-specific evidence, not generic promises. Annex VII in the regulation outlines the documentation required. It includes, among other things, a general product description, the software versions affecting compliance, system architecture, vulnerability-handling process information, the SBOM, CVD policy, evidence of a reporting contact point, update-distribution controls, and the cybersecurity risk assessment. Annex I also requires effective and regular tests and reviews of product security.
Still have questions you still have about the EU CRA? Please reach out to us at [email protected].