For manufacturers and developers
The CRA is a product business issue, not just a security team issue
Why the Cyber Resilience Act is more than a cybersecurity rule: it affects market access, product strategy, the supply chain and time to market.
The Cyber Resilience Act (CRA) is often discussed as cybersecurity regulation. That view is too narrow. The CRA is not aimed first of all at the security team. It is aimed at a company’s product business. I still see this mistake far too often.
Why is the security view not enough?
Because the CRA ties cybersecurity to several topics that reach far beyond IT security: CE marking, technical documentation, handling of vulnerabilities, support periods, conformity assessment and responsibility across the whole life of a product.
Once these points come together, it is no longer only a technical question. It becomes a question of market access. It becomes a question of product strategy. It becomes a question of the supply chain. And for many companies it can become a question of time to market.
Who is affected, specifically?
Affected most are manufacturers, companies with embedded products, IoT providers, suppliers in industrial automation, software vendors and engineering teams that work with products with digital elements. The circle is wide: it runs from the maker of connected devices to the software vendor, and it includes the teams that develop these products.
Is 2027 the real starting point?
No. 2027 is not the real starting line. The reporting obligations under Article 14 have applied since September 11, 2026. That is the uncomfortable part, because it means preparation had to begin before the year many people have in mind.
What companies need to be able to do by then comes down to five questions:
- What is in our products?
- Which components do we use?
- How do we handle vulnerabilities?
- Who is responsible for this process?
- How is the evidence for it produced?
All five questions concern the product as a whole, not just individual security features. Answering them requires knowing how a product is built, how it is maintained and who stands behind it.
What does this mean for the organization?
The CRA should not be treated as paperwork. It should also not be treated as something the security team will take care of. It becomes a task for the whole product organization, because the answers to the five questions do not sit in one place.
My view: companies that understand this early will have a very different 2027 from companies that wait. The difference lies in whether the questions about components, vulnerabilities, responsibility and evidence were asked early.
Why do I talk about the product business?
Because that is where the consequences show up. If CE marking is tied to cybersecurity, whether a product can be sold depends on how cleanly these topics were handled in the product process. A product whose documentation, vulnerability handling and support planning are not in place can change the timeline of a market launch. That is why I see the CRA as a topic for management and product owners, not only for the security department.
Anyone who starts from this view asks about components, process and responsibility first. The question about tools comes after.
What is the short version?
The CRA is not a question that a security team answers alone. It connects technology with market access, documentation, the supply chain and the life cycle of a product. That is why it belongs where decisions about the product are made.