On 11 September 2026, the European Union’s Cyber Resilience Act (CRA) began applying its first operational reporting obligation. Manufacturers, importers and distributors of products with digital elements must report actively exploited vulnerabilities and severe incidents through ENISA’s Single Reporting Platform. For a Swiss company, the relevant question is not whether it has an EU legal entity. It is whether its connected product is placed on the EU market.
That distinction brings reporting into product engineering, customer support and executive risk management. A vendor can be headquartered in Zurich, develop in Vaud and sell through a German distributor, yet still need to meet the same 24-hour early-warning and 72-hour notification milestones as an EU manufacturer.
The reporting clock starts before certainty
The CRA is designed around speed. Once a manufacturer becomes aware that a vulnerability is being actively exploited, it must submit an early warning within 24 hours. A fuller notification follows within 72 hours, with subsequent information as the investigation develops. Severe incidents affecting the security of a product follow the same reporting logic. The first notice is therefore not a finished forensic report; it is a controlled statement of what is known, what is not known and what containment is under way.
This changes the internal threshold for escalation. Security teams should not wait for legal to decide whether an event is “material” in a financial sense. Product security, incident response and regulatory affairs need a shared trigger matrix that maps exploit evidence, affected versions, customer exposure and mitigation status to the CRA workflow.
The workflow should distinguish discovery from confirmation. A credible researcher report, exploit telemetry from a customer, or a vendor bulletin may be enough to open the clock while specialists validate scope. Assigning one person to coordinate the initial notice avoids the failure mode in which engineering, legal and communications each assume another team is preparing the submission.
◆ Key Takeaway
For Swiss vendors, CRA compliance is an evidence-and-timing problem. The organisation that can identify the affected product, preserve proof and approve a defensible first notification will outperform the organisation that simply has a policy.
Why Swiss vendors are directly in scope
The CRA follows market placement and product responsibility rather than nationality. Network equipment, industrial controllers, software appliances, connected medical devices and many embedded components can create obligations when offered to EU customers. Importers and distributors also carry duties, which means Swiss manufacturers cannot treat downstream partners as a substitute for their own vulnerability-management capability.
Contracts should make the reporting chain explicit. A distributor must know where to send a suspected exploit, which time zone controls the clock, and what minimum technical evidence is required. The manufacturer should retain authority over the product-level assessment while giving partners a safe channel for urgent signals. This is especially important where a Swiss group sells under several brands or uses an original-equipment manufacturer.
Sales and support teams also need a short escalation script. They should capture the product version, deployment context, indicators of compromise and customer impact without promising a fix or speculating about attribution. That information is often the difference between a report that can be actioned and a series of disconnected tickets.
Build one workflow around the product
The most resilient operating model connects a product inventory to a vulnerability disclosure process. Each product record should identify the responsible security owner, supported versions, update mechanism, EU economic operators, critical dependencies and customer communication route. Without that inventory, the first 24 hours will be spent answering basic questions rather than reducing harm.
Incident responders also need a decision log. Record when the exploit was first suspected, who confirmed it, which evidence was reviewed, when the report was approved and what changed afterward. This supports ENISA reporting and gives management a defensible audit trail. It also prevents teams from making contradictory statements to regulators, distributors and customers.
Reporting should be integrated with remediation, not treated as its endpoint. A temporary mitigation, configuration change or update advisory needs an owner and a verification method. When a later investigation changes the affected-version range, the same workflow should support an update to the original submission and consistent customer communication.
Actions for the next reporting cycle
- Map every connected product and software component placed on the EU market to a named accountable owner.
- Define the 24-hour and 72-hour CRA escalation triggers with security, legal, product and communications teams.
- Test the ENISA reporting path using a tabletop exercise based on a credible exploited vulnerability.
- Put vulnerability disclosure, evidence sharing and notification deadlines into distributor and supplier contracts.
- Maintain a signed decision log for triage, report submission, mitigation and customer notification.
- Measure time from initial signal to verified asset scope, executive approval and regulator submission.
The CRA will make product security visible outside the security department. Swiss vendors that treat reporting as a narrow compliance formality will struggle when a vulnerability crosses products, brands and borders. Those that connect engineering telemetry, incident response and accountable decision-making can turn the rule into a repeatable trust advantage in the European market.