If you build embedded devices, IoT products, or software that ships with connected hardware, you’ve probably asked the same question your peers are asking right now: “Does the EU Cyber Resilience Act applies to your product and what exactly counts as ‘in scope’?”
The CRA introduces mandatory cybersecurity requirements for products with digital elements placed on the EU market, and it becomes fully applicable on 11 December 2027. Some obligations start earlier (notably reporting obligations from 11 September 2026).
We have explained in detail a practical, engineer-friendly way to assess, EU Cyber Resilience Act Applies to Your Product without drowning in legal jargon.
The CRA “Applicability Test”
Think of CRA scope like a gate with four checks:
- Are you placing the product on the EU market?
- Is it a “product with digital elements” (PDE)?
- Can it connect (directly or indirectly) to a device or network?
- Is it excluded because another EU regime already governs it?
If the answer is “yes” to the first three, and “no” to the fourth, you’re likely in scope and your next step becomes product classification (Default vs Important vs Critical), because that affects conformity assessment and whether you may need a Notified Body.
Step 1: Will Your Product Be Made Available on the EU Market?
CRA applies when a product is made available in the EU as part of a commercial activity; even if it’s free of charge.
So yes, CRA can still apply if you:
- bundle firmware tools with a device “for free,”
- provide a companion app to EU users,
- ship evaluation units into the EU,
- distribute software downloads to EU customers in a commercial context.
The key idea is the “marketplace principle”: if it’s supplied for distribution or use in the EU as part of commercial activity, CRA can apply regardless of whether your company is EU-based.
For example; a U.S. industrial OEM selling an edge gateway into Germany is in scope. A non-European start-up distributing a paid firmware tool to EU manufacturers can also be in scope.
Step 2: Is It a “Product with Digital Elements”?
The CRA uses a broad definition; a PDE is a software or hardware product and its remote data processing solutions, including components sold separately.
Hardware (broadly)
If it’s a physical electronic information system that processes digital data, it likely qualifies:
- routers, cameras, gateways, PLC-like controllers
- smart home devices
- industrial machinery/control systems
- many embedded systems used in energy, building automation, and manufacturing
Software (also broadly)
Any part of a system that is computer code tends to qualify:
- firmware, bootloaders, OS images
- mobile apps, desktop software
- software libraries and components sold separately (depending on context)
Remote Data Processing Solutions (the part people miss)
CRA also covers remote data processing solutions that are essential for the product’s operation and are provided by the manufacturer (or under the manufacturer’s responsibility).
For example; if your smart irrigation controller relies on your cloud backend to schedule watering, or a mobile app must connect to your service for setup, that remote processing can be part of the “product with digital elements.”
“Are cloud services in scope?”
This is where teams get confused.
A useful rule of thumb:
- Cloud features that are essential to the product’s function (e.g., remote control, provisioning, required device management) can be treated as remote data processing solutions tied to the PDE.
- Generic SaaS / PaaS / IaaS offerings are often treated differently and may be out of scope as “services,” but the boundary can be case-by-case depending on how integral it is to the product’s functionality.
If your “device doesn’t work without the cloud,” assume CRA relevance and evaluate carefully.
Step 3: Can It Connect to a Device or Network (Even Indirectly)?
CRA is meant to exclude truly offline products that can’t be an attack vector. Your product is generally in scope if its intended purpose or reasonably foreseeable use, includes a direct or indirect data connection to a device or network.
This can include:
- network sockets / APIs
- Wi-Fi, BLE, cellular, Zigbee
- wired interfaces like Ethernet, USB, UART bridges
- “offline” gear that’s routinely connected in real life (think: field service via laptop + cable)
If it can talk to something, attackers can often reach it, so CRA tends to treat it as in scope.
For example, a device shipped “offline” but commonly updated by USB or serviced through a laptop still has a connection pathway. That can be enough for CRA relevance.
Step 4: Is Your Product Exempt Because Another EU Regime Covers It?
CRA includes exclusions for certain products already governed by product-specific EU legislation (where cybersecurity requirements are addressed through sectoral rules).
Commonly referenced exclusions include:
- Medical devices and in-vitro diagnostic devices regulated under MDR/IVDR
- Motor vehicles governed under vehicle type-approval regimes
- Civil aviation and certain marine equipment under sectoral frameworks
- Products developed exclusively for national security/defence
There are also nuances around:
- Spare parts intended to replace identical components (details matter; “identical” is key).
- Open-source software: generally only covered when made available as part of a commercial activity (this was heavily debated and is still widely misunderstood).
Practical advice: don’t assume exemption. Many products are “near” excluded sectors but still in scope depending on how they’re placed on the market.
If You’re In Scope: What Happens Next?
Once you conclude your product is in scope, two tracks start immediately:
Product classification
CRA distinguishes product categories (often simplified as Default / Important / Critical). Classification influences how conformity assessment is handled and whether third-party assessment may be required.
Engineering evidence (not just policy)
CRA readiness isn’t “a PDF job.” It’s proving, with evidence, that you have:
- secure-by-design controls,
- vulnerability handling processes,
- lifecycle support and patchability,
- documentation that survives audit scrutiny.
This is where teams usually get stuck because the real workload is cross-functional: firmware + cloud + QA + compliance.
Where Epteck fits in practically: We help teams turn CRA into an engineering plan covering secure boot, secure OTA, SBOM automation, threat modeling, firmware security testing, and audit-ready documentation aligned with CE/GPSR/CRA.
FAQs
Does CRA apply if we give the software away for free?
It can, if it’s still supplied for distribution or use in the EU as part of a commercial activity (free doesn’t automatically mean “out of scope”).
Are firmware and bootloaders covered under CRA?
Yes. Firmware is generally considered software, and CRA covers software products and components that are part of products with digital elements.
Are mobile apps covered if they control an embedded device?
Often yes; especially if they’re part of the product ecosystem and essential to operation (and/or connect to remote services tied to the product).
Do cloud features fall under CRA?
Cloud capabilities that are essential for the product’s operation can be treated as “remote data processing solutions” tied to the PDE. Pure SaaS/PaaS/IaaS is often treated differently and may be out of scope, but this can be case-by-case.
When do CRA obligations actually start?
CRA entered into force on 10 December 2024. Full application is 11 December 2027, and certain obligations (like reporting) start earlier (notably 11 September 2026).