The EU Cyber Resilience Act: The End of “Ship and Forget”
Navigating the shift from voluntary standards to strict liability for connected devices.
Command Palette
Search for a command to run...
Search for a command to run...
Navigating the shift from voluntary standards to strict liability for connected devices.
The era of voluntary security is over.
For years, device manufacturers treated firmware like packaging: ship the hardware, maybe push one update, then move on to the next product line. That model has been dying for a while. The European Union just put a legal bullet in its head.
The EU Cyber Resilience Act (CRA) is not a guideline, a “best practice,” or a suggestion. It is a market access requirement. If your connected product does not meet its requirements, you do not sell in the EU. Full stop.
If your product is “directly or indirectly connectable,” it is in scope. If it has a chip and can talk to anything else, i.e., cloud, phone, local network, or field bus, you are on the hook. Hobby projects are largely out of scope, and some domains (like medical and automotive) are handled under their own regimes (think R155), but if you are selling a commercial connected product, you are in the blast radius.
This is where many manufacturers underestimate the impact: they assume CRA is for “security products.” It is not. It is for security of products - everything from smart toasters to industrial sensors to children’s “smart” toys.
“No more admin/admin.”
If someone like me can extract your firmware and find hardcoded secrets, debug backdoors, or unauthenticated management interfaces, you are non‑compliant before the product ever hits a shelf. You will be expected to show your homework: how you assessed the components you integrated, your threat model, and your secure development practices.
“Vendor said the chip was secure” is no longer a defense. Blind trust in a component supplier is now a liability, not a shield.
Not every product is treated equally under the CRA.
General-purpose connected products can typically go through a self-assessment.
“Important” and “Critical” products (for example, certain firewalls, microcontrollers, or industrial control components) must go through a third-party conformity assessment.
That distinction matters because it creates a bottleneck. Third-party assessment capacity will not magically scale overnight. If you wait until 2027 to look for an auditor, you will be standing in line behind every other unprepared manufacturer with a hard deadline and finished hardware.
Security support is no longer “nice to have” or “we’ll do it until the next model ships.” You are now legally required to provide vulnerability fixes for the expected product lifetime, often five years or more.
Here is the part that catches people off guard: substantial modifications reset the compliance clock. If you push a major firmware update that changes the risk profile, the law treats that as a “new” product. The support timer starts over. You cannot simply declare a product “End of Life” to dodge your obligations and walk away.
The CRA is not a distant, hypothetical future. The clock has started.
Entry into force: the law is already on the books.
21 months after entry into force, mandatory vulnerability and incident reporting obligations activate — you no longer get to quietly bury security incidents.
By the end of 2027, full compliance is required. If you are not ready, your devices can be effectively “bricked at the border,” stuck in warehouses while compliant competitors ship.
The companies that treat this as a three-year runway will be fine. The ones that treat it as a three-year grace period will not.
The CRA effectively asks a simple question: do you actually know what is in your binaries?
You will need a Software Bill of Materials (SBOM) that enumerates the open-source components and third-party code inside your firmware. If a vulnerable library like Log4j (or its spiritual successor) is buried three levels deep in your dependency tree, that risk is now explicitly yours to own and manage.
Even open-source “stewards” and maintainers have obligations under the CRA, though lighter than those of commercial manufacturers. The era of “we just published the code, whatever happens happens” is ending as well.
Non-compliance penalties can go up to €15 million or 2.5% of global annual turnover, whichever is higher. That is not a slap on the wrist; it could ben existential risk for many product lines as well as a board-level concern for anyone selling at scale.
And fines are only part of the story. Lost market access, forced recalls, and reputational damage are often more expensive than the regulatory penalty itself.
This is where most organizations underestimate the challenge: you cannot “PowerPoint your way” into CRA compliance. Someone has to actually pull your firmware apart, inventory the components, and map what you are shipping today against what the law now requires.
At Product Cybersecurity Group, that is what we do. We don’t just read the law; we read the code. Our hybrid legal‑technical audits:
Extract and analyze your firmware instead of relying on aspirational design documents.
Build an SBOM tied to what you actually ship, not what you think you ship.
Map your current technical reality against your legal and regulatory obligations under the CRA.
If you are building or shipping connected products into the EU and want to know whether you are actually ready - not just “we think we’re fine” ready - this is the time to find out, while there is still room in the calendar and before regulators, auditors, or customers force the issue.
Don’t wait for someone else to brick your product for you.