The Cyber Resilience Act: what Swiss SMEs should know now

The Cyber Resilience Act introduces new cybersecurity requirements for products with digital elements. Swiss SMEs can be affected too if they offer software, hardware or digital components on the EU market. Anyone who wants to be prepared needs one thing above all: clarity about risks, responsibilities, measures and evidence.

For many Swiss SMEs, the first question about the Cyber Resilience Act, or CRA, is a simple one: does this apply to us at all? The short answer: it depends.

What matters is not whether a company is based in the EU, but whether a product with digital elements covered by the CRA is made available on the EU market. Swiss companies that supply or sell software, hardware, connected products or digital components in the EU should therefore establish early on which requirements apply to them.

What is the Cyber Resilience Act?

The Cyber Resilience Act is an EU regulation that introduces binding cybersecurity requirements for products with digital elements. These include, for example, software and hardware products, connected devices and digital components, as well as certain remote data processing solutions that are necessary for a product to function.

The objective: products should not only be secure when they enter the market. Cybersecurity must be considered across the entire product lifecycle — from development and risk assessment through operation to vulnerability handling and security updates.

The CRA therefore shifts the perspective: security is no longer just a technical task that becomes relevant once a vulnerability is discovered or an attack becomes known. It becomes a structured part of development, product management and the way a company is organised.

Does the CRA also apply to Swiss SMEs?

Yes. Swiss SMEs can be directly affected by the CRA.

What matters is whether an affected product is made available on the EU market and what role the company plays in doing so. Depending on the business model, manufacturers, importers or distributors may have different obligations.

The CRA can be relevant, for example, for:

• Swiss software manufacturers with customers in the EU
• manufacturers of IoT devices and connected products
• machine builders with digital control or software components
• suppliers of software or hardware components to other manufacturers
• SMEs that sell their products in the EU through partners or distributors

But even companies that do not themselves have to fulfil all of the CRA’s manufacturer obligations may feel the effects.

Manufacturers, customers and larger clients will increasingly want to know how their suppliers deal with cybersecurity risks. As a result, requirements regarding documented development processes, security measures, vulnerability handling or evidence can be passed down the supply chain.

For Swiss SMEs it is therefore worth assessing the situation early, even when their own role under the CRA is not yet clear-cut.

What do affected companies need to do in practice?

The first step is to take stock: which products with digital elements do we offer? Which components do we use? In which markets are they offered? And what role do we play within the supply and distribution chain?

If the CRA is relevant, companies have to consider cybersecurity systematically across the entire product lifecycle. Five areas are particularly important.

1. Security by design and security by default

Cybersecurity must already be taken into account during design, development and manufacturing.

Products should be designed to provide a level of security appropriate to the risk. This includes secure default settings, protection against unauthorised access and limiting possible attack surfaces.

Security is therefore not added to a finished product afterwards, but built into its development from the outset.

2. Assessing cyber risks systematically

Manufacturers must assess the cybersecurity risks associated with their products and document that assessment.

This is not only about listing risks. Companies must derive appropriate security measures from them and update the risk assessment during the product lifecycle where necessary.

Being able to record, assess and prioritise risks in a structured way creates a central basis for implementing the CRA.

3. Handling vulnerabilities and providing security updates

Manufacturers must effectively handle known vulnerabilities in their products and in the components they contain.

This requires clear processes for detecting, assessing, prioritising and remediating vulnerabilities, as well as for providing security updates.

The CRA sets out a defined support period. In principle this is at least five years. If a product is expected to be in use for less than five years, the support period may be based on that expected lifetime.

For SMEs this means: responsibilities, processes and resources for security updates should not be defined only after an incident has occurred.

4. Knowing what is inside your own product

Companies must be able to trace which software components and dependencies are used in their products.

The software bill of materials (SBOM) plays an important role here. It documents the software components contained in a product and their dependencies. Among other things, the CRA requires manufacturers to identify and document vulnerabilities and components, and to draw up a software bill of materials in a common, machine-readable format.

This transparency is particularly important for open source components and third-party libraries. If a critical vulnerability becomes known in a component in use, a company must be able to determine as quickly as possible which of its own products are affected.

5. Preparing reporting processes

The CRA’s reporting obligations are a particularly topical point. From 11 September 2026, the reporting obligations for actively exploited vulnerabilities and severe security incidents apply.

Tight deadlines apply:

• an early warning is due within 24 hours
• a more detailed notification follows within 72 hours
• for actively exploited vulnerabilities, the final report is due no later than 14 days after a corrective or mitigating measure becomes available
• for severe security incidents, the final report follows within one month of the 72-hour notification

Reports are submitted through the CRA Single Reporting Platform provided by ENISA.

For companies this means above all: in an emergency there is little time left to clarify responsibilities and procedures. It should therefore already be clear beforehand how a vulnerability or incident is detected and assessed, who has to be informed internally, who decides on a report, and where the required information is documented.

The key CRA deadlines at a glance

Depending on the product and its risk category, different conformity assessment procedures may apply. For certain important or critical products, more extensive requirements may be in place.

How an ISMS supports implementation

The Cyber Resilience Act contains numerous product-specific and technical requirements. At the same time, it shows that cybersecurity can hardly be managed effectively without clear organisational structures. This is exactly where a well-designed information security management system — an ISMS — comes in.

An ISMS replaces neither technical product testing nor any conformity assessment that may be required. But it creates the organisational basis for managing risks, responsibilities, measures and evidence in a structured way.

These are precisely the areas that also play an important role in implementing the CRA:

• Risk management: cyber risks can be recorded, assessed, prioritised and documented in a structured way.
• Measure management: measures derived from risks and requirements can be assigned to owners, scheduled and tracked.
• Responsibilities: it becomes transparent who is responsible for which security tasks and which escalation paths apply.
• Documentation and evidence: assessments, decisions, controls and implemented measures remain centrally documented and traceable.
• Incident response: processes and responsibilities for security incidents can be organised so that it is clear who does what in an emergency.
• Controls and frameworks: requirements from different standards and regulations can be linked to one another instead of building separate structures for every topic.

How fortControl can help

For SMEs in particular, the challenge is often not to produce even more documents. What matters is organising the relevant information so that risks, measures and responsibilities can actually be managed.

fortControl starts where cybersecurity requirements become manageable within a company: with risks, measures, responsibilities and evidence.

With fortControl, companies can build and develop their ISMS in a structured way. Risks are recorded and assessed, measures are assigned to owners, and their implementation is documented in a traceable way.

Requirements from standards and frameworks such as ISO 27001, the NIST CSF or the Swiss ICT minimum standard can also be mapped in a structured way and linked to existing controls and measures. This creates a central basis on which companies can also address requirements from new regulations more efficiently.

One important point: an ISMS or a software solution alone does not automatically make a product CRA-compliant. The CRA sets out specific requirements for products, development, vulnerability handling, technical documentation and conformity assessment. A structured ISMS does, however, ensure that the organisational prerequisites for this do not have to be created from scratch every time.

Why an ISMS makes sense regardless of the CRA

The Cyber Resilience Act reflects a development that goes far beyond this single EU regulation: cybersecurity is becoming more systematic, more verifiable and more subject to evidence requirements. This also affects companies that do not currently fall directly under the CRA.

Customers, business partners, insurers and industry requirements increasingly demand transparency about how companies organise their information security. Individual technical measures are rarely sufficient on their own.

An ISMS provides an overarching framework. It shows:

• Which risks exist?
• Which measures have been decided?
• Who is responsible for them?
• What has already been implemented?
• And where is action still needed?

Companies that can answer these questions at any time not only create better conditions for regulatory requirements. They also improve their own ability to steer the organisation.

Structure creates security

The Cyber Resilience Act can also affect Swiss SMEs — particularly when they offer products with digital elements on the EU market.

Companies should therefore clarify early on whether and in what role they fall under the CRA, which of their products are affected, and which processes and evidence will be required.

This is not about producing as many new documents as possible. What matters is making cybersecurity manageable in the long term: clear risks, clear responsibilities, clear measures, traceable evidence.

With fortControl, SMEs create a structured basis for a practical ISMS and can integrate new requirements into existing processes instead of starting from scratch with every regulatory change.