Der Cyber Resilience Act verändert grundlegend, wie Hersteller digitale Produkte entwickeln, absichern, dokumentieren und über ihren gesamten Lebenszyklus betreiben. Die EU-Verordnung 2024/2847 vom 23.10.2024 macht Cybersecurity ab Dezember 2027 damit von einer freiwilligen Qualitätsleistung zu einer verbindlichen Voraussetzung für den europäischen Marktzugang. Betroffen sind viele Hardware- und Softwareprodukte, die direkt oder indirekt mit Geräten oder Netzwerken verbunden werden können. Unternehmen müssen deshalb technische Produktarchitektur, Schwachstellenmanagement, Lieferkettensteuerung und regulatorische Nachweisführung gemeinsam betrachten. Identity & Access Management, kurz IAM, wird dabei zum zentralen Kontrollmechanismus für privilegierte Zugriffe, Entwicklungssysteme, Signaturprozesse und belastbare Verantwortlichkeiten.
Cyber Resilience Act (CRA): Was Unternehmen jetzt wissen müssen
Was regelt der Cyber Resilience Act
Der Cyber Resilience Act, kurz CRA, definiert horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen, die im EU-Binnenmarkt bereitgestellt werden. Dazu zählen beispielsweise vernetzte Maschinen, industrielle Steuerungskomponenten, Betriebssysteme, Anwendungen, Firmware, IoT-Geräte und separat vermarktete Softwarekomponenten. Hersteller müssen angemessene Schutzmassnahmen bereits bei Planung, Design, Entwicklung und Produktion berücksichtigen und während der erwarteten Nutzungsdauer aufrechterhalten. Der CRA verbindet damit Secure by Design, Secure by Default und kontinuierliches Vulnerability Management zu einer durchgängigen Produktverantwortung. Neben Herstellern betrifft die Verordnung auch Importeure, Händler, Bevollmächtigte und weitere Akteure innerhalb der digitalen Lieferkette. Entscheidend ist nicht allein der Unternehmenssitz, sondern ob ein relevantes Produkt auf dem europäischen Markt angeboten wird. Auch Unternehmen ausserhalb der EU können deshalb unmittelbar betroffen sein, sobald sie digitale Produkte oder Komponenten in die Europäische Union exportieren. Cyber Resilience wird damit zu einer strategischen Fähigkeit, welche Produktmanagement, Engineering, Security, Compliance und Unternehmensführung miteinander verbindet.
Welche Produkte und Unternehmen fallen in den Anwendungsbereich
Der CRA gilt grundsätzlich für Hardware und Software, deren vorgesehene oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte Datenverbindung umfasst. Das Spektrum reicht von Consumer-IoT und Business-Software bis zu industriellen Produkten, Bibliotheken, Netzwerkkomponenten und eingebetteten Systemen. Ausnahmen bestehen unter anderem für bestimmte Produkte, die bereits sektorspezifischen europäischen Regelwerken unterliegen, weshalb eine belastbare Einzelfallprüfung erforderlich bleibt. Unternehmen sollten ihr Portfolio nicht nur nach Produktnamen, sondern nach Funktionen, Verbindungsmöglichkeiten, Vertriebsmodellen und Verantwortlichkeiten systematisch klassifizieren. Gerade bei Plattformen, White-Label-Lösungen, Open-Source-Bausteinen und gemeinsam entwickelten Produkten können Rollen und Pflichten entlang der Lieferkette unklar werden.
Die Europäische Kommission hat im 27. Juli 2026 ergänzende Leitlinien zur Unterstützung der Umsetzung des Cyberresilienzgesetzes durch Unternehmen veröffentlicht, die Unternehmen unter anderem bei der Einordnung des Anwendungsbereichs und weiterer praktischer Umsetzungsfragen unterstützen.
Welche Fristen müssen Unternehmen jetzt berücksichtigen
Der Cyber Resilience Act ist am 10. Dezember 2024, siehe Deutsche Fassung 2024/2847, in Kraft getreten, seine wesentlichen Anforderungen gelten jedoch gestaffelt:
- 11. Juni 2026: Die Vorschriften über die Notifizierung von Konformitätsbewertungsstellen nach Kapitel IV (Art. 35–51) gelten ab diesem Zeitpunkt (Art. 71 Abs. 2 CRA).
- 11. September 2026: Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle nach Art. 14 gelten ab diesem Zeitpunkt (Art. 71 Abs. 2 i. V. m. Art. 14 CRA).
- 11. Dezember 2027: Ab diesem Zeitpunkt gilt der Cyber Resilience Act grundsätzlich vollständig (Art. 71 Abs. 2 CRA).
Diese vorgezogenen Pflichten machen ein funktionsfähiges Detection-, Triage- und Eskalationsmodell schon deutlich vor der allgemeinen Anwendung erforderlich. Hersteller müssen bei relevanten Ereignissen eine Frühwarnung grundsätzlich innerhalb von 24 Stunden nach Kenntnis übermitteln. Eine vollständige Meldung ist grundsätzlich innerhalb von 72 Stunden (analog DSGVO) vorgesehen, ergänzt durch spätere Abschlussinformationen nach Behebung oder Untersuchung. Wer erst 2027 mit der Umsetzung beginnt, riskiert deshalb operative Lücken, unvollständige Evidenzen und nicht getestete Verantwortungswege.
Welche Pflichten entstehen über den Produktlebenszyklus
Der Cyber Resilience Act verpflichtet Hersteller, die Cybersicherheit ihrer Produkte mit digitalen Elementen über den gesamten Produktlebenszyklus hinweg zu berücksichtigen – von der Entwicklung und dem Inverkehrbringen bis zum Umgang mit Schwachstellen und Sicherheitsupdates während des Supportzeitraums:
Risiken vor der Markteinführung bewerten und geeignete Sicherheitsanforderungen in Produktarchitektur, Entwicklung und Tests verankern.
Produkte ohne bekannte ausnutzbare Schwachstellen bereitstellen und sichere Voreinstellungen sowie Schutzmechanismen gegen unbefugte Zugriffe vorsehen.
Schwachstellen während der Unterstützungsdauer identifizieren, dokumentieren, priorisieren, beheben und über geeignete Sicherheitsupdates adressieren.
Softwarekomponenten und Abhängigkeiten transparent verwalten, damit betroffene Versionen bei neuen Schwachstellen schnell ermittelt werden können.
· Sicherheitsrelevante Ereignisse, Korrekturmassnahmen und Entscheidungen so dokumentieren, dass Konformität und Verantwortlichkeit nachweisbar bleiben.
Damit entsteht eine Verbindung zwischen Product Security, Software Supply Chain Security, Qualitätsmanagement und regulatorischer Governance.
Welche technischen CRA-Anforderungen haben einen direkten IAM-Bezug
Der Cyber Resilience Act formuliert in Anhang I, Teil I konkrete Cybersicherheitsanforderungen, die unmittelbar Berührungspunkte mit Identity & Access Management (IAM) haben. Dazu gehören insbesondere:
- Zugriffsschutz und starke Authentifizierung: Produkte müssen durch geeignete Kontrollmechanismen vor unbefugtem Zugriff geschützt werden. Der CRA nennt ausdrücklich Authentifizierungs-, Identitäts- und Zugriffsmanagementsysteme (Anhang I, Teil I, Ziff. 3 a).
- Least Privilege: Der Zugriff natürlicher und juristischer Personen auf Funktionen und Daten muss auf das erforderliche Mass beschränkt werden (Anhang I, Teil I, Ziff. 3 e).
- Schutz von Vertraulichkeit und Integrität: Gespeicherte, übertragene oder anderweitig verarbeitete Daten müssen angemessen geschützt werden, gegebenenfalls durch Verschlüsselung sowie andere technische Verfahren (Anhang I, Teil I, Ziff. 3 c und d).
Warum ist Identity & Access Management (IAM) für die CRA-Umsetzung relevant
IAM adressiert zwar nicht sämtliche Anforderungen des Cyber Resilience Act, kontrolliert jedoch einen wesentlichen Teil der sicherheitskritischen Handlungen. Entwicklungsplattformen, Quellcode-Repositories, Build-Pipelines, Cloud-Umgebungen und Update-Infrastrukturen benötigen eindeutig zugeordnete Identitäten mit angemessenen Berechtigungen. Ohne geregelte Zugriffe können unautorisierte Änderungen, manipulierte Artefakte oder missbräuchlich verwendete Signaturschlüssel die Integrität digitaler Produkte gefährden. Ein belastbares IAM sorgt dafür, dass Personen, technische Konten, Services und externe Partner nur die tatsächlich erforderlichen Rechte erhalten. Identity Governance and Administration (IGA) unterstützt zusätzlich Genehmigungen, Rezertifizierungen, Funktionstrennung und revisionsfähige Nachweise. Privileged Access Management (PAM) schützt besonders mächtige Konten, protokolliert administrative Sitzungen und reduziert dauerhafte Hochprivilegierung. Machine Identities und Workload Identities - sprich alle Non-Human Identities (NHI) - müssen ebenfalls verwaltet werden, weil moderne Softwarelieferketten zunehmend automatisiert und servicebasiert funktionieren. Damit wird IAM zu einer tragenden Kontrollschicht zwischen CRA-Governance und technischer Produktentwicklung.
Wie unterstützt IAM Secure by Design und Secure by Default?
Secure by Design bedeutet, dass Sicherheitsanforderungen nicht nachträglich ergänzt, sondern als Architekturprinzip in Entwicklung und Betrieb verankert werden. IAM übersetzt dieses Prinzip in eindeutige Regeln für Authentisierung, Autorisierung, privilegierte Aktionen und die Trennung kritischer Aufgaben, wie in Anhang I, Teil I, Ziffer 2(d) ausgeführt.
Secure by Default verlangt zudem, dass Produkte und Plattformen bereits in der Ausgangskonfiguration ein angemessenes Sicherheitsniveau bieten. Dazu gehören deaktivierte Standardkonten, starke Authentisierung, minimale Berechtigungen und kontrollierte administrative Schnittstellen. Produktteams sollten diese Vorgaben als wiederverwendbare Security Patterns dokumentieren, und automatisiert in Entwicklungs- und Bereitstellungsprozesse integrieren.
Welche Rolle spielen Schwachstellenmanagement, SBOM und Meldeprozesse?
Ein CRA-konformes Vulnerability Management muss Schwachstellen nicht nur technisch erkennen, sondern betroffene Produkte, Verantwortliche und notwendige Entscheidungen schnell zusammenführen. Eine Software Bill of Materials, kurz SBOM, schafft Transparenz über Komponenten und Abhängigkeiten, ersetzt aber weder Risikobewertung noch belastbare Betriebsprozesse. Unternehmen benötigen ein Product Security Incident Response Team (PSIRT) oder eine vergleichbare Funktion mit definierten Übergaben zu Entwicklung, Recht, Kommunikation und Management. Aktiv ausgenutzte Schwachstellen erfordern besonders kurze Reaktionszeiten und eine verlässliche Beurteilung, ob gesetzliche Meldekriterien erfüllt sind. Die europäische Single Reporting Platform soll für verpflichtende Meldungen an die zuständigen Stellen genutzt werden. IAM stellt hierbei sicher, dass nur autorisierte Rollen Meldungen erstellen, freigeben oder ergänzen können und dass ihre Aktivitäten nachvollziehbar bleiben. Gleichzeitig müssen Bereitschaftsdienste, Stellvertretungen und externe Spezialisten rechtzeitig mit zeitlich begrenzten, kontrollierten Zugängen ausgestattet werden. Cyber Resilience entsteht deshalb erst, wenn technische Erkenntnisse, Identitäten, Prozesse und Governance ohne Medienbrüche zusammenwirken.
Wie sollten Unternehmen ihre CRA-Governance aufbauen?
Eine wirksame CRA-Governance braucht klare Entscheidungen, messbare Kontrollen und eine verbindliche Zuordnung von Produkt- und Prozessverantwortung. Unternehmen sollten mindestens folgende Rollen und Strukturen festlegen:
-
Einen CRA-Verantwortlichen oder ein bereichsübergreifendes Steuerungsgremium für Prioritäten, Risiken und Eskalationen.
-
Eindeutige Product Owner für Sicherheitsanforderungen, Unterstützungszeiträume, Updates und technische Dokumentation.
-
Ein Product Security Incident Response Team für Schwachstellen, Vorfälle, Meldeentscheidungen und koordinierte Offenlegung.
-
Kontrollverantwortliche für IAM, privilegierte Zugriffe, Softwarelieferketten, Konformitätsbewertung und Auditnachweise.
-
Einen regelmässigen Management-Review mit Kennzahlen zu Schwachstellen, Behebungszeiten, Ausnahmen, Zugriffsrisiken und Lieferanten.
Diese Struktur verhindert, dass CRA-Aufgaben zwischen Produktentwicklung, Informationssicherheit, Compliance und Rechtsabteilung liegen bleiben.
Was bedeutet der Cyber Resilience Act für Schweizer Unternehmen?
Schweizer Hersteller müssen den CRA berücksichtigen, wenn sie betroffene Produkte direkt oder über Partner auf dem EU-Markt bereitstellen. Dabei können auch Komponenten relevant sein, die in grössere Systeme integriert und separat kommerziell angeboten werden. Unternehmen sollten deshalb früh klären, welche Rolle sie je Produkt einnehmen und welche Pflichten vertraglich an Lieferanten oder Vertriebspartner übertragen werden können.
In einer Medienmitteilung vom 20. August 2025 kündigte der Bundesrat an, dass auch die Schweiz ihre gesetzlichen Grundlagen zur Cyberresilienz digitaler Produkte stärken will. Die geplante Gesetzgebung soll dabei auf den internationalen Kontext abgestimmt werden und ausdrücklich den europäischen Cyber Resilience Act berücksichtigen. Ziel ist unter anderem, international tätige Schweizer Unternehmen nicht durch voneinander abweichende Vorgaben zusätzlich zu belasten.
Eine rein juristische Betrachtung reicht nicht aus: Konformität hängt von realen Entwicklungs-, Betriebs- und Supportfähigkeiten ab. Nicht delegierbare Herstellerverantwortung, unklare Updatezusagen und fehlende Komponententransparenz können erhebliche Umsetzungsrisiken erzeugen.
Wie gelingt eine pragmatische CRA-Roadmap?
Eine belastbare Roadmap für «CRA READY» beginnt mit einem Scope Assessment, das Produkte, Märkte, wirtschaftliche Rollen und relevante Ausnahmen nachvollziehbar erfasst. Danach folgt eine Gap-Analyse gegen Sicherheitsanforderungen, Schwachstellenprozesse, technische Dokumentation, Konformitätsbewertung und Meldebereitschaft. Parallel sollte das Unternehmen seine IAM-Landschaft auf privilegierte Konten, technische Identitäten, externe Zugriffe und kritische Berechtigungskonflikte prüfen. Priorität erhalten Kontrollen, die sowohl das unmittelbare Sicherheitsrisiko als auch den späteren Nachweisaufwand reduzieren. Pilotprodukte helfen, Zielprozesse praktisch zu testen, bevor sie auf das gesamte Portfolio skaliert werden. Geeignete Kennzahlen sind beispielsweise die Zeit bis zur Schwachstellenbewertung, die Dauer bis zur Behebung und der Anteil rezertifizierter privilegierter Zugriffe. Ebenso wichtig sind dokumentierte Ausnahmen, klare Risikoakzeptanzen und regelmässige Übungen der Melde- und Eskalationswege. So wird der CRA nicht als isoliertes Compliance-Programm umgesetzt, sondern als nachhaltige Verbesserung der Product Security Governance.
Wie unterstützt IPG bei Cyber Resilience und CRA?
IPG verbindet regulatorische Anforderungen mit Identity & Access Management, Identity Governance und der Absicherung privilegierter sowie technischer Identitäten. Im ersten Schritt analysieren unsere Experten Geschäftsrollen, Produktprozesse, kritische Systeme und bestehende Zugriffskontrollen im CRA-relevanten Umfeld. Daraus entsteht ein priorisiertes Zielbild, das Governance, IAM-Architektur, Prozesse und messbare Kontrollen miteinander verbindet. IPG unterstützt anschliessend bei Konzeption, Implementierung und Optimierung geeigneter IAM-, IGA- und PAM-Fähigkeiten. Damit schaffen Unternehmen nachvollziehbare Verantwortlichkeiten, reduzieren Zugriffsrisiken und verbessern ihre Audit Readiness.
Fazit: Cyber Resilience wird zur unternehmerischen Kernfähigkeit
Der Cyber Resilience Act macht Produktsicherheit zu einer kontinuierlichen Verpflichtung, die weit über eine einmalige Konformitätsprüfung hinausgeht. Erfolgreiche Unternehmen verbinden regulatorische Interpretation deshalb früh mit Product Security, Softwareentwicklung, Lieferkettensteuerung und operativer Reaktionsfähigkeit. IAM liefert dabei die Identitäts-, Berechtigungs- und Nachweisebene, auf der kritische Prozesse kontrolliert und Verantwortlichkeiten belastbar zugeordnet werden. Besonders dringlich sind jetzt die ab September 2026 geltenden Meldepflichten sowie der Aufbau getesteter Eskalations- und Freigabeprozesse. Wer Scope, Governance und technische Kontrollen strukturiert priorisiert, reduziert nicht nur Compliance-Risiken, sondern erhöht zugleich die Widerstandsfähigkeit seiner digitalen Produkte. Eine belastbare Identity Governance macht darüber hinaus sichtbar, wer kritische Entscheidungen treffen, Produktänderungen freigeben oder Sicherheitsmeldungen übermitteln darf. Diese Transparenz verbessert die Nachweisfähigkeit gegenüber Prüfern und reduziert operative Abhängigkeiten von einzelnen Schlüsselpersonen. Cyber Resilience wird so vom regulatorischen Projekt zum Qualitätsmerkmal, das Vertrauen, Marktzugang und nachhaltige Wettbewerbsfähigkeit stärkt.
Dieser Bericht beruht auf Expertenwissen, für die Ausformulierung wurde Hilfe von KI in Anspruch genommen.