The Cyber Resilience Act is not a product regulation. It is a leadership test.

Over the past two years, a recurring pattern has emerged in incidents across Europe. Vulnerabilities in widely used software components are discovered late, patched unevenly, and communicated poorly. When exploitation follows, the damage spreads across entire ecosystems, not just single organisations.

Regulators responded accordingly. The EU Cyber Resilience Act, adopted in 2024 and entering application from 2027, shifts attention to the security of digital products placed on the market. Not operators. Not users. Products.

What is CRA?

The Cyber Resilience Act is often described as “the NIS2 for products”. That comparison is pausible, but falls a bit short.

NIS2 focuses on organisational resilience in critical infrastructure. DORA focuses on operational continuity in financial services. The CRA focuses on accountability for software and hardware security over the entire product lifecycle.

Even Switzerland is not an EU member, it applies for Swiss companies in the same way as GDPR or DORA for IT service providers. If product or services are available to EU customers, including hardware, software, inclduing cloud delivered software, or it integrates 3rd party digital components into products sold in the EU under its own brand. Physical presence in the EU is not required. Market availability is sufficient.

What is commonly underestimated is not the technical burden, but the organisational consequence.

Under the CRA, manufacturers are responsible for secure by design development, vulnerability handling, coordinated disclosure, and timely patching for years after a product is shipped. This includes products with digital elements embedded deep in supply chains, from industrial controllers to consumer IoT and enterprise software.

In practice, this cuts across silos that rarely meet. Product management owns release cycles. Engineering owns code. Legal owns liability. Security often owns.. none of the above.

In organisations today weakness shows up repeatedly: when a vulnerability affects a product already in shipped and in place with customers, who decides severity? Who communicates? Who pays for remediation? Who owns the customer impact?

This is why the CRA is less about certificates and more about decision rights.

IMPLICATIONS FOR LEADERS & GOVERNANCE

For executives and boards, the CRA introduces several practical consequences:

• Product security becomes a standing governance topic. Not an engineering detail, but a recurring agenda item touching risk, liability, and reputation.

• Accountability must be explicit. Someone must own vulnerability handling end to end, including disclosure timelines and customer communication, not just technical fixes.

• Supply chain assumptions will be tested. “We rely on third party components” is no longer an explanation. It is a risk statement that needs oversight.

• Incident response expands beyond operations. Legal, compliance, communications, and product leadership are now part of the first response, not the follow up.

• Differences between frameworks matter. NIS2 asks whether your organisation can withstand attacks. DORA asks whether financial services remain operational. The CRA asks whether the products you sell should have been designed differently in the first place.

None of these are solved by a tool. All of them require clarity at leadership level in the first place.

The Cyber Resilience Act shifts the question from “Are we secure?” to “Are we accountable for the security we ship?”

That is an uncomfortable shift for many organisations. It forces conversations across functions that rarely align under pressure. But it also creates an opportunity to remove ambiguity before the next vulnerability forces the issue.