For manufacturers and developers
The Cyber Resilience Act is coming. Most companies still treat it as an IT problem.
The CRA is a market-access rule for digital products, not only a security topic. Who is in scope, why 2027 is late and where companies should start.
Why CRA will affect product strategy, suppliers, software vendors, development partners, and the next generation of secure-by-design products.
There is a regulation coming in Europe that many companies still underestimate. Not because they have never heard of it, but because they put it in the wrong box.
The Cyber Resilience Act, or CRA, is often discussed as a cybersecurity topic: something for CISOs, security engineers, compliance teams and product certification specialists. That is partly true, but it is too small. In my view, the CRA is not just a cybersecurity regulation. It is a market-access regulation for digital products.
That changes the conversation completely. The moment cybersecurity becomes connected to CE marking, technical documentation, vulnerability handling, support periods, conformity assessment and product lifecycle responsibility, it stops being only a technical issue. It becomes a business issue, a product issue, a supply-chain issue and, ultimately, a question of whether a product can be placed on the European market at all.
The scope is wider than many companies think.
The CRA applies to “products with digital elements.” That may sound abstract, but in practice it covers hardware and software products, including components, that are made available on the EU market and whose use involves a direct or indirect connection to a device or network.
This can include connected devices, embedded systems, industrial software, applications, operating systems, chips, software components, remote data processing related to the product and many other parts of modern digital products. That is why I think many companies will discover the CRA too late. They will not see themselves as “cybersecurity companies.” They will see themselves as machine builders, device manufacturers, industrial equipment suppliers, software vendors, platform companies, electronics suppliers, IoT product companies, automotive suppliers or engineering service providers.
But the regulation will not care what they call themselves. It will ask a simpler question: do you place a product with digital elements on the EU market? If the answer is yes, the CRA may become relevant.
This is the part many companies still miss.
Security is becoming part of product conformity
For years, cybersecurity was often treated as something added around the product. The product was developed first. Then someone checked the software. Then someone added access control. Then someone created documentation. Then someone patched known issues if there was time, budget or customer pressure.
CRA pushes the logic in the opposite direction. Security needs to be considered from planning and design through development, production, market placement and maintenance. Manufacturers will need to think about risk assessment, secure-by-default configurations, vulnerability handling, security updates, technical documentation, support periods and reporting obligations.
This is not just about writing a security policy. It is about building a product organization that can prove what it did. That proof matters because a product that cannot show conformity may become a commercial problem, not just a security problem.
The first big deadline is closer than 2027.
Many people look at the full CRA application date, December 2027, and assume there is still time. That is risky. The reporting obligations start earlier. From September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.
That means companies need more than a policy on paper. They need to know what is inside their products, which software components they use, how vulnerabilities are monitored, who owns the process, how impact is assessed, how fixes are coordinated, how reporting works and how customers are informed. They need these capabilities before the full market-access pressure arrives.
2027 is not the starting line. It is the point where companies that started late may discover they are already behind.
The real cost is not the fine
Yes, the fines matter. The CRA penalty framework includes administrative fines of up to EUR 15 million or 2.5 percent of global annual turnover for serious non-compliance with essential cybersecurity requirements and manufacturer or reporting obligations.
But I do not think the fine is the real business risk. The real risk is slower product launches, delayed certification, emergency redesign, supplier uncertainty, unsupported components, products that cannot be updated, customers asking for evidence you cannot produce, tenders you cannot enter, distributors that do not want to touch your product and market surveillance authorities asking questions your organization cannot answer.
In product businesses, time-to-market is often worth more than the fine. CRA can become a time-to-market problem. That is why it should be discussed by CEOs, product leaders, CTOs, procurement teams and business development teams, not only by security departments.
A new ecosystem will form around CRA
The CRA will not be solved by one type of company. It will create a new division of responsibility across the product ecosystem.
Product manufacturers will carry the main responsibility. They will need to define support periods, manage vulnerabilities, document conformity, handle security updates and make sure their products remain secure throughout the lifecycle. Chip vendors and silicon suppliers will need to provide stronger security capabilities, secure elements, roots of trust, crypto support, lifecycle documentation and long-term vulnerability information.
Operating system and middleware vendors will become more important because their update policies, vulnerability handling, SBOMs and long-term support will directly affect product compliance. Tool vendors will sell SBOM generation, firmware analysis, vulnerability monitoring, traceability, requirements management, testing and compliance automation. Certification bodies and notified bodies may become bottlenecks for certain categories of important and critical products.
Open source communities and foundations will play a very sensitive role because open source is everywhere inside products, but responsibility will depend on how it is commercialized, maintained and integrated.
Development companies like Promwad will sit in the middle of this ecosystem. Not as lawyers and not as certification bodies, but as teams that help product companies turn regulation into engineering reality. This is where the work becomes practical: secure architecture, threat modeling, component selection, firmware and software updates, SBOM readiness, vulnerability handling processes, security documentation, product lifecycle planning, integration of secure hardware and software, and evidence that the product was built with security in mind.
The CRA will not only ask whether a product is secure today. It will ask whether the company has a system to keep it secure tomorrow.
Why post-quantum matters
There is another layer that is easy to ignore because it still feels far away: quantum. Post-quantum cryptography is not a simple CRA checkbox today, but it will influence how long-lifecycle products are designed.
NIST has already finalized its first post-quantum cryptography standards. The EU has also published a coordinated roadmap for the transition to post-quantum cryptography. The strategic message is clear: companies should not wait until quantum risk becomes urgent.
For digital products with long support periods, this matters. A connected industrial controller, a smart energy device, a telecom product, a gateway, a medical-adjacent system, a machine with remote update capability or an automotive and industrial subsystem may stay in the field for years, sometimes decades.
If cryptography is hardcoded, difficult to update, poorly documented or dependent on unsupported components, the problem is not only today’s cybersecurity. It is future resilience. That is why crypto-agility should become part of the CRA conversation. Not because every product needs post-quantum algorithms tomorrow, but because every serious product company should know where it uses cryptography, which algorithms and libraries are involved, which certificates and dependencies exist, which update paths are available and how fast the security foundation can be changed if standards, threat models or customer requirements change.
If a product is designed with no path to change its security foundation, it is not resilient. It is only temporarily secure.
Europe’s opportunity
The CRA will create friction. It will slow down some teams, expose weak documentation, make suppliers uncomfortable, increase pressure on manufacturers and probably create confusion before it creates clarity.
But I do not think it should be seen only as a regulatory burden. It can also become an opportunity.
Europe has a strong industrial base. It has product companies that understand quality, safety, certification and long lifecycle support. It has engineering service companies, embedded specialists, cybersecurity experts, semiconductor vendors, industrial automation players and certification ecosystems. If these players move early, CRA can become more than a compliance exercise.
It can become a way to build better products: more transparent, more maintainable, more updateable, more trusted and more competitive in regulated markets. But this will not happen automatically. Companies that treat CRA as paperwork will turn it into paperwork. Companies that treat it as product strategy may turn it into an advantage.
What companies should do now
I would not start with a legal memo. I would start with a product map.
Companies should identify which products they sell in the EU, which of them have digital elements, which include remote access, updates, connectivity, cloud dependencies or embedded software, which components come from suppliers, which open-source components are inside, which products can be updated, which products are difficult to update, which products have long support obligations, which teams own vulnerability handling, which customers will ask for evidence, which products may need third-party conformity assessment and which future requirements, including post-quantum readiness, could change the security design.
This is not a one-week exercise. But it is the right place to start.
The biggest CRA risk is not that companies know exactly what to do and simply lack time. The bigger risk is that many companies still do not know that they are in scope. Or they know they are in scope but still treat the problem as “security will handle it.”
That will not be enough.
The Cyber Resilience Act is coming for the product organization, not only for the security team. And the companies that understand this early will have a very different 2027 from the companies that wait.
Sources
-
European Commission, CRA overview: Scope, timeline and summary of Regulation (EU) 2024/2847.
-
European Commission, CRA for manufacturers: Manufacturer obligations, secure lifecycle and product responsibilities.
-
European Commission, CRA reporting obligations: Reporting obligations starting September 2026.
-
European Commission, CRA conformity assessment: Self-assessment and stricter conformity assessment for important/critical products.
-
European Commission, CRA open source: Treatment of free and open-source software and open-source stewards.
-
European Commission, CRA standardisation: Standardisation request and harmonised standards context.
-
CRA Article 64, penalties: Penalty framework including up to EUR 15 million or 2.5 percent global turnover.
-
NIST, first finalized post-quantum cryptography standards: PQC standardisation signal and migration urgency.
-
European Commission, coordinated PQC roadmap: EU roadmap for transition to post-quantum cryptography.
-
Qt, Cyber Resilience Act: Vendor positioning around CRA and product lifecycle security.
-
Canonical, CRA and Ubuntu Pro for Devices: Long-term security maintenance and vulnerability management positioning.
-
Wind River, EU Cyber Resilience Act FAQ: Embedded/edge software vendor perspective.
-
Siemens Polarion, CRA compliance: Requirements, traceability and lifecycle compliance tooling perspective.
-
OpenSSF, EU CRA resource hub: Open source ecosystem resources and CRA context.
-
ONEKEY, SBOM and vulnerability management for CRA: Productized CRA readiness around firmware analysis, SBOM and vulnerability management.