Cyber Resilience Act: when Swiss manufacturers are in scope

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) has been in force since 10 Dec 2024. It requires manufacturers, importers and distributors of products with digital elements to implement security-by-design, vulnerability management across the product lifecycle and reporting processes. It does not apply directly in Switzerland. It affects every Swiss manufacturer whose products enter the EU market. A SOC is the operational foundation for the active reporting and vulnerability-management duties.

All

How this compares to neighbouring topics

This page frames the Cyber Resilience Act (CRA) from a Swiss-manufacturer angle: which products, which duties, which deadlines. For operating IT services (not products), see NIS2 Swiss subsidiaries. For financial-sector products, see DORA requirements for the SOC. For the domestic reporting duty, see SOC & ISG 24h reporting. For manufacturing operations, see SOC for manufacturing.

Which Swiss manufacturers are in scope?

  • Any product with digital elements (hardware or software) placed on the EU internal market, regardless of the manufacturer's country of establishment.
  • The CRA excludes products already covered by sector-specific regimes, such as medical devices, vehicles, and certain aviation and financial products. Manufacturers must check the narrow exemptions product by product.
  • Important and critical products under Annex III and IV require stricter conformity procedures with third-party assessment. Examples include password managers, network devices, firewalls and industrial control systems.
  • Importers and distributors share responsibility: they must check conformity, CE marking and documentation.
Important

The CRA is a regulation, not a directive: it applies directly and uniformly across the EU. Reporting duties apply from September 2026. Full application, including conformity requirements, starts on 11 December 2027. For EU market access, a non-EU manufacturer needs a responsible economic operator in the EU, usually the importer. It may appoint an authorised representative (Art. 22 CRA), but this is not mandatory.

What the CRA requires operationally

  • Security-by-design and -by-default per Annex I: secure default configurations, minimised attack surface, update capability, documented hardening.
  • Vulnerability handling across the whole product lifecycle, minimum five years after market entry or expected useful life: coordinated disclosure, timely patches, public advisories.
  • Manufacturers must notify the coordinating CSIRT and ENISA of actively exploited vulnerabilities with an early warning within 24 hours of awareness and full notification within 72 hours. They must submit a final report within 14 days after a remediation measure becomes available. The same 24h/72h deadlines apply to severe incidents with a security impact. For these incidents, manufacturers must submit the final report within one month.
  • Technical documentation and Software Bill of Materials (SBOM) for the components used, in machine-readable format and traceable.
  • Conformity assessment with CE marking: self-assessment for standard products, third-party assessment for important and critical products.
  • Fine range: up to EUR 15 million or 2.5 percent of worldwide annual turnover for breaches of the essential cybersecurity requirements.

What the SOC delivers in the CRA context

  • The SOC monitors product telemetry and the manufacturer's update infrastructure 24/7. Without this foundation, manufacturers cannot meet the 24-hour early warning deadline for the coordinating CSIRT and ENISA.
  • Detection content for active exploitation of the manufacturer's products: analysis of PSIRT reports, threat intelligence and customer signals with clear escalation paths.
  • Playbooks with an explicit CRA notification threshold and templates for the early warning, 72-hour notification and final report to the coordinating CSIRT and ENISA plus parallel customer communication.
  • Ticket and evidence trail for the vulnerability-handling chain: from intake through reproduction to fix and published advisory.
  • OT and product-network view: detection on build systems, signing infrastructure and update servers, which are prime targets for supply-chain attacks.
  • Reporting to executive management and oversight: notified cases, open vulnerabilities per product line, mean time to repair (MTTR), conformity status.
Bottom line

The CRA moves cybersecurity out of IT operations into the product lifecycle. A SOC that only covers corporate IT falls short. Anyone selling products into the EU needs detection coverage on the build pipeline, signing infrastructure, update channels and product telemetry.

Practice: what to do first

  1. Product inventory: which products with digital elements are placed on the EU market and in which CRA category (standard, important, critical) they fall.
  2. Build an SBOM and component inventory in machine-readable format, linked to vulnerability feeds.
  3. Set up or formalise a PSIRT process with coordinated disclosure, including a public reporting address and advisory channel.
  4. Align detection and reporting with the CRA deadlines: 24h for early warning and 72h for notification. Submit the final report within 14 days after a fix becomes available for actively exploited vulnerabilities, or within 1 month for severe incidents. Put ENISA templates and escalation chains in writing.
  5. Clarify the responsible economic operator in the EU, usually the importer; an authorised representative under Art. 22 CRA is optional.
  6. Choose the conformity assessment route and put a roadmap in place with milestones toward 11 Dec 2027.

For the differences between CRA and NIS2, see NIS2 Swiss subsidiaries. For the economics, see SOC cost Switzerland. For 24/7 operations, see SOC 24/7 operations.

Legal basis and sources

Frequently asked questions

Does the CRA apply to purely internal software?

The CRA does not apply to purely internal software. It covers products placed on the EU market or put into service. Purely internal tools without market access fall outside its scope. SaaS offerings delivered to EU customers as products with digital elements fall within its scope.

Is a NIS2 process enough for CRA reporting?

A NIS2 process alone does not meet CRA reporting requirements. NIS2 targets the operation of services, while the CRA targets products. Recipients, thresholds and content differ. Under the CRA, manufacturers report actively exploited vulnerabilities and severe product incidents to ENISA. A well-run SOC uses the same playbook structure with different recipients and templates.

What is an SBOM and why does the CRA require one?

A Software Bill of Materials is a machine-readable inventory of all components and dependencies of a product. The CRA requires it because it is the prerequisite for timely patching and advisory communication on component-level vulnerabilities. Without an SBOM, manufacturers cannot demonstrate the required vulnerability-handling chain in practice.

When do the duties apply?

The regulation has been in force since 10 Dec 2024. Reporting duties for actively exploited vulnerabilities and severe incidents apply from September 2026. Full conformity requirements including CE marking apply from 11 December 2027. Manufacturers must implement the requirements progressively before then.

Do we need an EU representative?

For EU market access, a non-EU manufacturer needs a responsible economic operator in the EU, usually the importer. It may appoint an authorised representative (Art. 22 CRA), but this is not mandatory. Importers and distributors must check that the manufacturer has met its obligations.

Continue reading in this cluster
NIS2 for Swiss subsidiaries: when the EU directive lands in Switzerland
The EU NIS2 directive (transposition deadline was 17 Oct 2024, implemented nationally by member states) does not apply directly in Switzerland. It bites through two channels: first, EU subsidiaries of Swiss groups fall directly under national NIS2 implementations. Second, Swiss providers of essential services to regulated EU customers inherit obligations contractually. A SOC is the operational building block for detection, notification and evidence in both cases.
DORA requirements for the SOC: what the Digital Operational Resilience Act means in operations
The Digital Operational Resilience Act (Regulation (EU) 2022/2554) requires EU financial entities to maintain a continuous ICT risk and resilience framework. It has applied since 17 January 2025. For Swiss groups, DORA applies directly through EU subsidiaries and indirectly through contracts with EU financial customers. These subsidiaries include banks, insurers, payment institutions, crypto-asset service providers, CSDs, CCPs and trading venues. A SOC delivers four DORA cornerstones. It provides continuous ICT detection and classified incident notification to the competent authority under the 24-hour / 72-hour / 1-month cascade. It also provides the evidence trail for supervisory review and the operational foundation for threat-led penetration testing (TLPT).
SOC & ISG: The 24-hour cyber-incident reporting duty in Switzerland
Since 1 April 2025, the Swiss Information Security Act (ISG, SR 128, Art. 74a-74f) imposes a cyberattack reporting duty on critical infrastructure operators. Operators must report cyberattacks to the National Cyber Security Centre (NCSC) within 24 hours of detection. Operators need 24/7 detection and documented response processes to meet this deadline reliably. A SOC delivers these two building blocks.
SOC for manufacturing: monitoring IT and OT together
During an incident, manufacturers lose production, not data. A SOC for manufacturing monitors the IT network and OT environment (PLC, HMI, legacy systems). It stops ransomware before the production line goes down. The core risk is not encryption; it is downtime.
SOC as a Service in Switzerland: The Complete Guide
SOC as a Service is an externally operated Security Operations Center that monitors your environment around the clock, detects attacks and triggers the response. According to Mandiant M-Trends 2026, attackers went undetected for a median of 14 days in 2025. With a SOC that detects and assesses around the clock, typical detection time becomes much shorter.
Look up short definitions in the glossary

Related terms