Überblick
Der Cyber Resilience Act (CRA), die Verordnung (EU) 2024/2847, macht Cybersicherheit zu einer nachweisbaren Voraussetzung für den Marktzugang von Produkten mit digitalen Elementen. Er betrifft Hardware, Software und funktional zugehörige Remote-Dienste, sofern sie in den sachlichen Anwendungsbereich fallen.
Für die Geschäftsleitung ist der CRA kein isoliertes IT- oder Entwicklungsprojekt. Er verändert Produktstrategie, Entwicklungsmodell, Lieferantensteuerung, Supportkosten, Haftungsprofil, Konformitätsmanagement und langfristige Marktfähigkeit. Unternehmen müssen deshalb nicht nur technische Kontrollen einführen, sondern ein belastbares Product-Security-Operating-Model etablieren.
Die zentrale Managementaufgabe lautet: Welche Produkte fallen in den CRA, wer trägt je Produktfamilie die Herstellerrolle, wie lange wird Support finanziert, wie wird Schwachstellenbehandlung organisiert und wie wird die Konformität je Release nachgewiesen?
Ein technisch gutes Produkt ohne beherrschten Secure Lifecycle, belastbare Schwachstellenprozesse und nachvollziehbare Evidenz kann künftig seine Marktfähigkeit gefährden.
CRA in fünf Minuten
| Managementfrage | Belastbare Antwort |
|---|---|
| Warum jetzt handeln? | Die Meldepflichten gelten ab 11. September 2026; die Hauptpflichten ab 11. Dezember 2027. Produktänderungen, Toolchains und Konformitätswege benötigen lange Vorläufe. |
| Was ist betroffen? | Produkte mit digitalen Elementen, einschließlich relevanter Software, Hardware und erforderlicher Remote-Datenverarbeitung. |
| Wer trägt Verantwortung? | Die Herstellerrolle liegt häufig bei dem Unternehmen, das ein Produkt unter eigenem Namen oder eigener Marke vermarktet – nicht zwingend beim technischen Entwickler. |
| Was muss zuerst entstehen? | Produktregister, Rollenklärung, Reporting Readiness, repräsentativer Pilot und ein finanziertes Lifecycle-Modell. |
| Was ist der geschäftliche Kern? | Marktzugang, Produkthaftung, Kundenvertrauen, Supportfähigkeit und langfristige Margen. |
Executive Decision Guide
Der CRA verlangt miteinander verbundene Entscheidungen, die nicht an ein einzelnes Fachteam delegiert werden sollten.
| Entscheidung | Leitfrage | Erwartetes Ergebnis |
|---|---|---|
| Scope | Welche Produkte, Varianten, Marken und Gesellschaften fallen in den CRA? | Freigegebenes Produktregister mit Rolle, Markt, Version und Owner. |
| Portfolio | Welche Legacy-Produkte werden modernisiert, weitergeführt oder beendet? | Priorisierte Portfolioentscheidung mit Support- und Migrationsplan. |
| Support | Wie lange werden Schwachstellen behandelt und Updates bereitgestellt? | Finanzierter Supportzeitraum, EOL-Regeln und Kundenkommunikation. |
| Konformität | Welcher Bewertungsweg gilt je Produkt? | Klassifizierung, Verfahren, Standards, Zeitplan und Verantwortliche. |
| Operating Model | Wer entscheidet bei Release, Schwachstelle, Vorfall und Abweichung? | RACI, Gremien, Eskalation und Board Reporting. |
| Investition | Welche Fähigkeiten fehlen? | Roadmap für SSDLC, SBOM, PSIRT, Testing, Toolchain und Evidenz. |
Warum der CRA geschäftlich relevant ist
Produktsicherheit wird Bestandteil der Marktfähigkeit. Kunden, Versicherer, Investoren und Geschäftspartner werden stärker nach Supportzeiträumen, Updatefähigkeit, Schwachstellenprozessen und Nachweisen fragen. Gleichzeitig werden Lifecycle-Kosten transparenter, weil Security Engineering, Monitoring, Testing und Incident Readiness über Jahre finanziert werden müssen.
| Geschäftsdimension | Veränderung | CEO-Frage |
|---|---|---|
| Produktstrategie | Security beeinflusst Architektur, Plattformwahl und Varianten. | Welche Produkte bleiben langfristig wirtschaftlich und supportfähig? |
| Time-to-Market | Security Gates und Konformität werden Teil des Releaseprozesses. | Wie verhindern wir, dass fehlende Evidenz den Marktstart blockiert? |
| Marge | Support und Updates erzeugen Lifecycle-Kosten. | Sind diese Kosten in Preis, Vertrag und Business Case enthalten? |
| Lieferkette | Komponenten und externe Entwicklung müssen transparenter werden. | Welche Abhängigkeiten gefährden unsere Reaktionsfähigkeit? |
| Reputation | Unsichere Produkte und langsame Reaktion schädigen Vertrauen. | Können wir im Krisenfall schnell und glaubwürdig handeln? |
Anwendungszeitplan und Managementprioritäten
Der CRA trat am 10. Dezember 2024 in Kraft. Vorschriften zur Notifizierung von Konformitätsbewertungsstellen gelten seit 11. Juni 2026. Die Meldepflichten nach Artikel 14 gelten ab 11. September 2026; die wesentlichen übrigen Verpflichtungen ab 11. Dezember 2027.
| Zeitpunkt | Managementziel | Mindestresultat |
|---|---|---|
| Sofort | Scope und Verantwortung herstellen. | Produktregister, CRA Owner, Melde- und Eskalationsmodell. |
| Bis 11.09.2026 | Meldepflicht operativ beherrschen. | 24-/72-Stunden-Prozess, Übungen, Mindestdatensatz und Entscheidungsbefugnisse. |
| 2026–2027 | Produkte und Prozesse transformieren. | SSDLC, SBOM, Supportmodell, Evidenz und Konformitätsplanung. |
| Bis 11.12.2027 | Marktfähigkeit sichern. | Erfüllte Anforderungen, Bewertung, EU-Konformitätserklärung und CE. |
Produkte im Anwendungsbereich
Der CRA gilt grundsätzlich für Produkte mit digitalen Elementen, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk einschließt.
Die Managementfrage lautet nicht, ob ein Produkt „IT“ ist, sondern ob digitale Elemente Teil des angebotenen Produkts sind. Maschinen, Gateways, HMIs, Firmware, Apps, Konfigurationssoftware und erforderliche Cloud-Funktionen können gemeinsam bewertet werden müssen.
Ausnahmen und Abgrenzung
Bestimmte Produktgruppen werden durch sektorspezifische EU-Rechtsakte geregelt. Dazu können unter anderem Medizinprodukte, bestimmte Fahrzeuge, Luftfahrt- oder Schiffsausrüstung gehören. Die Abgrenzung ist produktbezogen vorzunehmen; ein Konzern kann gleichzeitig Produktlinien innerhalb und außerhalb des CRA führen.
Praxisregel: „Nicht betroffen“ ist keine Annahme, sondern eine dokumentierte Scope-Entscheidung mit Produktbeschreibung, Marktrolle, Rechtsgrundlage und Freigabe.
Wirtschaftsakteure und Verantwortlichkeiten
Der CRA unterscheidet insbesondere Hersteller, Bevollmächtigte, Importeure und Händler. Die Herstellerpflichten sind am weitreichendsten. White-Label-Modelle, Eigenmarken und wesentliche Änderungen können die Herstellerrolle auslösen.
| Rolle | Kernverantwortung | Managementrisiko |
|---|---|---|
| Hersteller | Risikobewertung, Anforderungen, Schwachstellen, Dokumentation, Konformität und Meldung. | Unterschätzte Herstellerrolle bei Eigenmarke oder Integration. |
| Importeur | Prüft Konformität und Unterlagen vor Bereitstellung. | Import nicht konformer Produkte. |
| Händler | Prüft Kennzeichnung und Sorgfaltspflichten. | Vertrieb trotz erkennbarer Nichtkonformität. |
| Wesentlich Ändernder | Kann Herstellerpflichten übernehmen. | Änderung ohne erneute Scope- und Konformitätsbewertung. |
Wichtige und kritische Produkte
Der CRA unterscheidet allgemeine Produkte, wichtige Produkte der Klassen I und II sowie kritische Produkte. Die Einstufung beeinflusst den zulässigen Konformitätsbewertungsweg. Sie sollte deshalb früh erfolgen und Entwicklungsplanung, Teststrategie und externe Kapazitäten berücksichtigen.
Wesentliche Cybersicherheitsanforderungen
Die Anforderungen betreffen sowohl Produkteigenschaften als auch den Umgang mit Schwachstellen. Ein Produkt kann bei Markteinführung technisch gut abgesichert sein und dennoch im Betrieb scheitern, wenn Updates, Meldung und Kommunikation nicht funktionieren.
| Anforderungsfeld | Praktische Bedeutung | Typische Evidenz |
|---|---|---|
| Risikobasierte Sicherheit | Schutzmaßnahmen passen zu Zweck, Exposition und Auswirkung. | Risikobewertung, Threat Model, Architekturentscheidungen. |
| Secure by Design | Security ist Teil von Anforderungen, Architektur, Entwicklung und Test. | Requirements, Reviews, Tests und Freigaben. |
| Secure by Default | Sichere Ausgangskonfiguration und geringe Angriffsfläche. | Baseline, Hardening Guide, Konfigurationstests. |
| Updates | Sicherheitsupdates können sicher verteilt und nachvollzogen werden. | Signierung, Rollout, Rollback, Kundeninformation. |
| Vulnerability Handling | Schwachstellen werden erkannt, bewertet, behoben und kommuniziert. | PSIRT, VDP, SLA, Advisories und Meldungen. |
Secure by Design und Secure by Default
Security darf nicht am Ende ergänzt werden. Produktanforderungen, Architektur, Toolchain, Build, Tests und Marktfreigabe benötigen verbindliche Security-Kriterien.
Die Geschäftsleitung sollte Security als Produkt-Gate etablieren. Funktion, Termin und Kosten allein dürfen keine Marktfreigabe bestimmen.
Produktlebenszyklus und Supportzeitraum
Der CRA zwingt Hersteller, Support technisch und wirtschaftlich zu beherrschen. Der Supportzeitraum muss die erwartete Nutzungsdauer und Art des Produkts berücksichtigen und beträgt grundsätzlich mindestens fünf Jahre, sofern die erwartete Nutzungsdauer nicht kürzer ist.
Für langlebige industrielle Produkte müssen Build-Umgebungen, Signaturschlüssel, Testsysteme, Komponentenwissen und Personal über lange Zeit verfügbar bleiben. Der Supportzeitraum gehört deshalb in Business Case, Preisgestaltung und Portfolioentscheidung.
Vulnerability Management und PSIRT
Ein Product Security Incident Response Team oder eine funktional gleichwertige Organisation ist der operative Kern der Schwachstellenbehandlung. Es koordiniert Intake, Triage, Betroffenheit, Fix, Advisory und regulatorische Meldung.
Das PSIRT benötigt definierte Befugnisse, Vertretung außerhalb normaler Geschäftszeiten und direkten Zugriff auf Produktdaten, Engineering, Legal und Kommunikation.
Meldepflichten ab 11. September 2026
Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Produktsicherheit melden. Das Unternehmen muss eine Frühwarnung innerhalb von 24 Stunden und eine vollständigere Meldung innerhalb von 72 Stunden operativ vorbereiten.
Board Readiness Test: Simulieren Sie einen Fall vom ersten Hinweis bis zur 24-Stunden-Meldung. Ohne Übung bleiben Rollen-, Daten- und Freigabelücken meist unentdeckt.
SBOM und Softwarelieferkette
Eine SBOM ist kein einmaliger Scanner-Export. Sie muss Komponenten und Abhängigkeiten so transparent machen, dass neue Schwachstellen schnell auf konkrete Produkte, Versionen und Kundenexposition abgebildet werden können.
Editierbarer SBOM-Standard, Datenmodell, Build-Zuordnung, Qualitätskontrollen und Betriebsprozess.
Arbeitsmittel unter Resources ansehenFreie und quelloffene Software
Open Source ist keine generelle Ausnahme für Hersteller, die Komponenten kommerziell in eigene Produkte integrieren. Verantwortung für das eigene Produkt bleibt bestehen. Unternehmen benötigen Regeln für Auswahl, Pflege, Forks, Maintainer-Risiken, EOL und Ersatz kritischer Komponenten.
Technische Dokumentation und Nachweise
Technische Dokumentation muss zeigen, wie Anforderungen erfüllt wurden. Ein belastbares Evidenzmodell verbindet Produktbeschreibung, Risikobewertung, Architektur, Tests, Komponenten, offene Risiken, Support und Konformitätsentscheidung.
Konformitätsbewertung und CE-Kennzeichnung
Der zulässige Konformitätsweg hängt insbesondere von der Produktkategorie und der Nutzung harmonisierter Standards oder anderer anerkannter Spezifikationen ab. Die CE-Kennzeichnung ersetzt weder die laufende Schwachstellenbehandlung noch den sicheren Lifecycle.
CRA Governance Operating Model
Ein CRA-Programm benötigt zentrale Methodik und dezentrale Produktverantwortung. Die zentrale Funktion steuert Mindeststandards, Klassifizierung, Reporting und Toolchain. Produktlinien verantworten Architektur, Evidenz, Fixes und Support.
Governance Charter, Executive RACI, PSIRT-Mandat, Produktfreigaben und Board Reporting.
Arbeitsmittel unter Resources ansehenExecutive Dashboard und Kennzahlen
Vorstände benötigen wenige entscheidungsrelevante Kennzahlen: Scope-Abdeckung, Konformitätsbereitschaft, Alter kritischer Schwachstellen, SBOM-Abdeckung, Reporting Readiness, Supportfähigkeit, Lieferantenabdeckung und Evidenzvollständigkeit.
Roadmap von 30 Tagen bis 24 Monate
| Phase | Schwerpunkt | Ergebnis |
|---|---|---|
| 0–30 Tage | Sponsor, Scope-Hypothese, Meldepflicht und kritische Produkte. | Mandat, initiales Produktregister und Reporting Gap Assessment. |
| 31–90 Tage | Rollenanalyse, Pilotprodukte, PSIRT und 24-Stunden-Übung. | Freigegebene Methodik und Sofortmaßnahmen. |
| 4–6 Monate | Secure Lifecycle, SBOM, Lieferanten, Toolchain und Evidenz. | Unternehmensstandard und Pilot-Evidenzpaket. |
| 7–12 Monate | Produktlinien ausrollen und technische Lücken schließen. | Messbare Readiness je Produktfamilie. |
| 13–24 Monate | Konformitätsproben, Audits, EOL- und Kundenentscheidungen. | Dauerhaftes Operating Model. |
Umsetzung nach Unternehmensgröße und Betriebsmodell
| Profil | Priorität |
|---|---|
| Kleiner Hersteller | Scope, externer Support, einfacher SSDLC, PSIRT-Mindestprozess und dokumentierter Konformitätsweg. |
| Mittelstand | Zentrale Product-Security-Funktion, standardisierte Toolchain, Produktregister und Managementdashboard. |
| Internationaler Hersteller | Globaler Standard, lokale Marktrollen, zentrale Meldung und harmonisierte Evidenz. |
| Konzern / DAX | Board Oversight, Product Security Office, Portfolio-Control-Tower, M&A-Due-Diligence und Continuous Compliance. |
Praxisfälle
Maschinenbauer mit Remote-Service
Produktgrenzen, Cloud-Funktion, Updatefähigkeit und Supportdauer müssen über SPS, HMI, Industrie-PC, Fernwartung und Serviceportal hinweg geklärt werden.
Softwareunternehmen mit Open-Source-Abhängigkeiten
Reproduzierbare Builds, SBOM je Release, Komponentenfreigabe und PSIRT-Triage verkürzen die Betroffenheitsanalyse.
White-Label-Anbieter
Wer Produkte unter eigener Marke vertreibt, kann Herstellerpflichten tragen, obwohl die technische Entwicklung extern erfolgt.
Zusammenhang mit anderen Frameworks
| Framework | Beziehung zum CRA |
|---|---|
| NIS2 | NIS2 schützt die Organisation; CRA adressiert Produkte. Incident-, Lieferanten- und Governance-Prozesse sollten verbunden werden. |
| ISO/IEC 27001 | Unterstützt ISMS, Risiko und Evidenz, ersetzt aber keine produktspezifische Konformität. |
| IEC 62443 | Starker technischer und prozessualer Bezug für industrielle Produkte und Secure Development. |
| NIST SSDF | Strukturiert sichere Softwareentwicklung. |
| EU AI Act | Produkte mit KI-Funktion können gleichzeitig AI-Act- und CRA-Pflichten auslösen. |
Audit- und Assessment-Perspektive
Eine belastbare Bewertung unterscheidet Design, Implementierung und Wirksamkeit. Eine Policy allein beweist keinen wirksamen Secure Lifecycle; ein Scanner allein keine vollständige Komponentenkenntnis; ein Penetrationstest keine nachhaltige Produktsicherheit.
Typische Feststellungen und Fehlinterpretationen
- Produktregister ist unvollständig oder nur vertriebsorientiert.
- Herstellerrolle ist bei Eigenmarken und Integration ungeklärt.
- SSDLC wird bei Terminnot umgangen.
- SBOM ist nicht releasebezogen oder operativ nutzbar.
- PSIRT besitzt keine 24/7-Eskalation.
- Supportversprechen sind nicht finanziert.
- Konformitätsunterlagen entstehen erst nach Marktstart.
- Open-Source-Komponenten werden pauschal als ausgenommen betrachtet.
CEO- und Vorstandsagenda
Der Vorstand sollte quartalsweise mindestens Scope-Abdeckung, kritische Produktlinien, Reporting Readiness, offene Hochrisiken, Supportfähigkeit, Lieferantenabhängigkeiten, Konformitätsplan und Investitionsbedarf bewerten.
CRA Executive Toolkit
Die Reference Edition vermittelt das vollständige Wissen. Das Toolkit liefert editierbare Arbeitsmittel für die praktische Umsetzung.
Scope & Governance
Produktregister, Rollenmodell, RACI und Board Reporting.
Secure Development
SSDLC, Security Gates, Threat Modeling und Releasefreigaben.
SBOM & Supply Chain
SBOM-Standard, Lieferantenanforderungen und Komponentenregister.
PSIRT
VDP, Triage, 24-/72-Stunden-Playbook und Advisory-Vorlagen.
Lifecycle
Supportzeitraum, Patch-SLA, EOL und Kundenkommunikation.
Self-Assessment
Scoring, Evidenzanforderungen, Maßnahmenplan und Auswertungsprompts.
Häufige Fragen
Was ist der Cyber Resilience Act?
Kurzantwort: Der CRA ist eine unmittelbar geltende EU-Verordnung mit horizontalen Cybersicherheitsanforderungen für Produkte mit digitalen Elementen.
Praktische Einordnung: Er verbindet Produktgestaltung, Schwachstellenbehandlung, Konformität, CE-Kennzeichnung, Marktüberwachung und Meldung über den gesamten Lebenszyklus.
Managementempfehlung: Benennen Sie einen Executive Sponsor und verbinden Sie Scope, Produktregister, Freigaben, Nachweise und Review.
Wann gilt der CRA?
Kurzantwort: Der CRA trat am 10. Dezember 2024 in Kraft. Meldepflichten gelten ab 11. September 2026; die Hauptpflichten ab 11. Dezember 2027.
Praktische Einordnung: Produktentwicklung, Toolchain, Verträge und Konformitätsbewertung benötigen häufig mehrere Releasezyklen.
Managementempfehlung: Planen Sie rückwärts vom Marktstart und priorisieren Sie die Reporting Readiness sofort.
Sind bestehende Produkte betroffen?
Kurzantwort: Die Einordnung hängt von Übergangsregeln, neuer Bereitstellung, Änderungen und Versionen ab.
Praktische Einordnung: Auch wenn eine konkrete Altversion nicht vollständig neu bewertet werden muss, können Kunden und Verträge bereits CRA-nahe Nachweise verlangen.
Managementempfehlung: Entscheiden Sie je Produktfamilie, welche Legacy-Produkte weitergeführt, modernisiert oder beendet werden.
Wer ist Hersteller?
Kurzantwort: Hersteller ist nicht zwingend der technische Entwickler.
Praktische Einordnung: Wer ein Produkt unter eigenem Namen oder eigener Marke vermarktet oder wesentlich ändert, kann Herstellerpflichten übernehmen.
Managementempfehlung: Dokumentieren Sie Rolle und Rechtseinheit je Produkt, Marke und Markt.
Sind Maschinen betroffen?
Kurzantwort: Maschinen können betroffen sein, wenn sie digitale Elemente und relevante Verbindungen enthalten.
Praktische Einordnung: SPS, HMI, Firmware, Fernwartung und Cloud-Funktion müssen als zusammenhängende Produktarchitektur betrachtet werden.
Managementempfehlung: Führen Sie eine produktbezogene Scope-Bewertung durch.
Ist SaaS betroffen?
Kurzantwort: Reine Dienstleistungen sind nicht automatisch Produkte mit digitalen Elementen.
Praktische Einordnung: Remote-Datenverarbeitung kann jedoch Teil des Produkts sein, wenn sie für dessen Funktion erforderlich ist.
Managementempfehlung: Bewerten Sie Architektur, Verantwortlichkeit und Vertragsmodell gemeinsam.
Was bedeutet Secure by Default?
Kurzantwort: Produkte sollen in einer angemessen sicheren Ausgangskonfiguration bereitgestellt werden.
Praktische Einordnung: Schwache Standardpasswörter, unnötige Dienste und übermäßige Privilegien widersprechen diesem Prinzip.
Managementempfehlung: Definieren und testen Sie verbindliche sichere Baselines.
Ist eine SBOM verpflichtend?
Kurzantwort: Der CRA verlangt Komponenten- und Schwachstellentransparenz; eine SBOM ist dafür ein zentrales praktisches Instrument.
Praktische Einordnung: Sie muss vollständig, versioniert, releasebezogen und im PSIRT nutzbar sein.
Managementempfehlung: Automatisieren Sie Erzeugung und Qualitätskontrolle im Build-Prozess.
Das SBOM Toolkit enthält editierbare Vorlagen, Register, Checklisten und Auswertungshilfen für die praktische Umsetzung.
Passende Arbeitsmittel unter Resources ansehenWie lang ist der Supportzeitraum?
Kurzantwort: Der Zeitraum richtet sich nach Art und erwarteter Nutzungsdauer und beträgt grundsätzlich mindestens fünf Jahre, sofern die Nutzungsdauer nicht kürzer ist.
Praktische Einordnung: Bei Industrieprodukten kann eine längere wirtschaftliche und technische Planung erforderlich sein.
Managementempfehlung: Treffen Sie je Produktlinie eine finanzierte Lifecycle-Entscheidung.
Müssen Sicherheitsupdates kostenlos sein?
Kurzantwort: Sicherheitsupdates zur Behebung von Schwachstellen sollen grundsätzlich ohne zusätzliche Kosten bereitgestellt werden.
Praktische Einordnung: Funktionale Weiterentwicklung und Sicherheitsbehebung müssen im Geschäftsmodell sauber getrennt werden.
Managementempfehlung: Verankern Sie Update- und Supportregeln in Produkt- und Vertragsmodell.
Was muss innerhalb von 24 Stunden gemeldet werden?
Kurzantwort: Für meldepflichtige aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle ist eine Frühwarnung vorgesehen.
Praktische Einordnung: Die Einordnung erfordert Produktdaten, Ausnutzungsinformationen, Severity und autorisierte Entscheider.
Managementempfehlung: Testen Sie einen verbindlichen 24-/72-Stunden-Prozess.
Was passiert nach 72 Stunden?
Kurzantwort: Eine vollständigere Meldung muss verfügbare Informationen zu Produkt, Auswirkung und Gegenmaßnahmen enthalten.
Praktische Einordnung: Technische Analyse, Legal und Kommunikation müssen parallel arbeiten.
Managementempfehlung: Definieren Sie Mindestdatensatz, Single Source of Truth und Freigaben.
Was ist Coordinated Vulnerability Disclosure?
Kurzantwort: Ein strukturierter Prozess für Entgegennahme, Bewertung, Behebung und koordinierte Veröffentlichung von Schwachstellen.
Praktische Einordnung: Er reduziert Konflikte mit Forschern und verbessert Kundenkommunikation.
Managementempfehlung: Veröffentlichen Sie eine VDP und etablieren Sie klare PSIRT-Abläufe.
Reicht ISO 27001 für den CRA?
Kurzantwort: Nein.
Praktische Einordnung: ISO 27001 unterstützt Governance und Evidenz, deckt produktspezifische Anforderungen, CE und Lifecycle jedoch nicht vollständig ab.
Managementempfehlung: Nutzen Sie vorhandene Kontrollen, ergänzen Sie aber eine dokumentierte CRA-Gap-Analyse.
Wie verhält sich CRA zu NIS2?
Kurzantwort: NIS2 adressiert die Organisation; CRA adressiert Produkte.
Praktische Einordnung: Ein Unternehmen kann beiden Regimen unterliegen. Incident-, Lieferanten- und Governance-Prozesse sollten harmonisiert werden.
Managementempfehlung: Bauen Sie gemeinsame Prozesse, aber getrennte Scope- und Nachweismodelle.
Wie verhält sich CRA zu IEC 62443?
Kurzantwort: IEC 62443 unterstützt industrielle Product Security und Secure Development.
Praktische Einordnung: Sie kann wesentliche technische Praktiken liefern, ersetzt aber nicht die rechtliche Konformitätsbewertung.
Managementempfehlung: Verwenden Sie IEC 62443 als technische Grundlage für industrielle Produktlinien.
Was ist eine wesentliche Änderung?
Kurzantwort: Eine Änderung kann wesentlich sein, wenn sie Konformität oder Zweck beeinflusst.
Praktische Einordnung: Change- und Release-Prozesse müssen CRA-Auswirkungen formell bewerten.
Managementempfehlung: Integrieren Sie eine CRA-Impact-Bewertung in jedes relevante Change Gate.
Was müssen Importeure tun?
Kurzantwort: Importeure prüfen vor Bereitstellung Konformität, Unterlagen und Kennzeichnung.
Praktische Einordnung: Bei Zweifeln oder Nichtkonformität dürfen Produkte nicht einfach weiter vertrieben werden.
Managementempfehlung: Definieren Sie einen formalen Importfreigabeprozess.
Was müssen Händler tun?
Kurzantwort: Händler prüfen mit angemessener Sorgfalt Kennzeichnung, Unterlagen und Akteursangaben.
Praktische Einordnung: Erkennbare Nichtkonformität löst weitere Pflichten aus.
Managementempfehlung: Schulen Sie Vertrieb und Distribution und dokumentieren Sie Prüfungen.
Wie behandeln wir Legacy-Produkte?
Kurzantwort: Legacy-Portfolios benötigen eine wirtschaftliche Entscheidung: modernisieren, kompensieren, migrieren oder auslaufen lassen.
Praktische Einordnung: Historische Toolchains und Komponenten lassen sich nicht unbegrenzt sicher pflegen.
Managementempfehlung: Erstellen Sie eine Portfolio-Matrix mit Support-, Risiko- und Migrationsentscheidung.
Das Product Lifecycle Security Toolkit enthält editierbare Vorlagen, Register, Checklisten und Auswertungshilfen für die praktische Umsetzung.
Passende Arbeitsmittel unter Resources ansehenWelche Rolle spielt der Einkauf?
Kurzantwort: Der Einkauf muss SBOM, Patch-SLA, Schwachstellenmeldung, Support und Nachweisrechte vertraglich absichern.
Praktische Einordnung: Ohne diese Rechte trägt der Hersteller ein nicht steuerbares Lieferkettenrisiko.
Managementempfehlung: Ergänzen Sie CRA-Klauseln und Lieferanten-Scorecards.
Das Supplier Security Toolkit enthält editierbare Vorlagen, Register, Checklisten und Auswertungshilfen für die praktische Umsetzung.
Passende Arbeitsmittel unter Resources ansehenWelche Rolle spielt Product Management?
Kurzantwort: Product Management verbindet Marktversprechen, Varianten, Supportzeitraum und EOL.
Praktische Einordnung: Lifecycle-Kosten müssen in Business Cases und Roadmaps enthalten sein.
Managementempfehlung: Machen Sie Supportfähigkeit zu einem Portfolio-Gate.
Welche Rolle spielt Quality?
Kurzantwort: Quality integriert CRA-Nachweise in Design Reviews, Freigaben und Konformitätsakten.
Praktische Einordnung: Parallele Systeme von Quality und Product Security erzeugen Lücken und Doppelarbeit.
Managementempfehlung: Definieren Sie ein gemeinsames Evidenz- und Freigabemodell.
Welche Rolle spielt der CISO?
Kurzantwort: Der CISO oder Product Security setzt Methodik, PSIRT- und Risikostandards.
Praktische Einordnung: Die technische Produktverantwortung bleibt bei Engineering und Product Owner.
Managementempfehlung: Klären Sie Entscheidungsrechte und Eskalationsschwellen.
Was sollte der Aufsichtsrat fragen?
Kurzantwort: Scope, kritische Produktlinien, Reporting Readiness, offene Hochrisiken, Supportfähigkeit, Lieferanten und Budget.
Praktische Einordnung: Der CRA ist ein Produkt- und Marktfähigkeitsrisiko.
Managementempfehlung: Etablieren Sie quartalsweises Board Reporting.
Wie hoch sind die Umsetzungskosten?
Kurzantwort: Sie hängen von Produktzahl, Komplexität, Legacy-Anteil, Toolchain und Lieferkette ab.
Praktische Einordnung: Die größte Dauerbelastung entsteht oft durch Engineering- und Supportkapazität, nicht durch einzelne Tools.
Managementempfehlung: Erstellen Sie ein mehrjähriges TCO- und Kapazitätsmodell.
Kann CRA zum Wettbewerbsvorteil werden?
Kurzantwort: Ja.
Praktische Einordnung: Transparente Supportzeiträume, schnelle Reaktion und belastbare Nachweise reduzieren Kundenrisiken.
Managementempfehlung: Nutzen Sie Product Security als Ausschreibungs- und Vertrauensmerkmal.
Welche drei Maßnahmen sind zuerst nötig?
Kurzantwort: Produkt- und Rollenregister, Reporting Readiness und ein repräsentativer Pilot.
Praktische Einordnung: Diese drei Elemente zeigen Scope, organisatorische Lücken und technische Realität.
Managementempfehlung: Starten Sie nicht mit einer reinen Dokumentenübung.
Das CRA Compliance Toolkit enthält editierbare Vorlagen, Register, Checklisten und Auswertungshilfen für die praktische Umsetzung.
Passende Arbeitsmittel unter Resources ansehenWie erkennen wir, ob wir bereit sind?
Kurzantwort: Readiness zeigt sich durch reproduzierbare Ergebnisse, nicht durch Policies.
Praktische Einordnung: Produktdaten, Release-Gates, Betroffenheitsanalyse, Meldung und Lifecycle müssen funktionieren.
Managementempfehlung: Führen Sie ein evidenzbasiertes Self-Assessment mit Pilotprodukt durch.
Das Executive CRA Self-Assessment enthält editierbare Vorlagen, Register, Checklisten und Auswertungshilfen für die praktische Umsetzung.
Passende Arbeitsmittel unter Resources ansehenWelche Bedeutung haben harmonisierte Standards?
Kurzantwort: Sie können Konformitätsbewertung und Vermutungswirkung unterstützen.
Praktische Einordnung: Sie ersetzen nicht die produktbezogene Risikobewertung und können nicht alle Besonderheiten abdecken.
Managementempfehlung: Verfolgen Sie Standardisierung früh und planen Sie verbleibende Evidenz.
Welche Daten braucht das PSIRT sofort?
Kurzantwort: Produktfamilie, Version, Komponenten, Exposition, Supportstatus, Kundenwirkung, Mitigations und Owner.
Praktische Einordnung: Manuelle Recherche über Tage ist mit Meldefristen nicht vereinbar.
Managementempfehlung: Verbinden Sie Produktregister, SBOM, Release- und Service-Daten.
Das Vulnerability Management Toolkit enthält editierbare Vorlagen, Register, Checklisten und Auswertungshilfen für die praktische Umsetzung.
Passende Arbeitsmittel unter Resources ansehenWas bedeutet CRA für kundenspezifische Softwarestände?
Kurzantwort: Sonderstände erhöhen Support- und Konformitätskomplexität.
Praktische Einordnung: Jede Abweichung kann eigene Komponenten, Tests und Updatepfade erzeugen.
Managementempfehlung: Begrenzen Sie Varianten und definieren Sie Baselines.
Wie wird CRA in den Entwicklungsprozess integriert?
Kurzantwort: Über Portfolio-, Requirements-, Architektur-, Lieferanten-, Build-, Test-, Release- und Lifecycle-Gates.
Praktische Einordnung: Ein Compliance-Check kurz vor Marktstart ist zu spät.
Managementempfehlung: Verknüpfen Sie jedes Gate mit Kriterien, Owner und Evidenz.
Das Secure Development Toolkit enthält editierbare Vorlagen, Register, Checklisten und Auswertungshilfen für die praktische Umsetzung.
Passende Arbeitsmittel unter Resources ansehenWelche Rolle spielt die interne Revision?
Kurzantwort: Sie bewertet Governance, Scope, Wirksamkeit und Managementaufsicht unabhängig.
Praktische Einordnung: Stichproben sollten die Evidenzkette vom Produktregister bis zum Schwachstellenfall verfolgen.
Managementempfehlung: Planen Sie frühe Readiness-Audits.
Das Product Security Audit Toolkit enthält editierbare Vorlagen, Register, Checklisten und Auswertungshilfen für die praktische Umsetzung.
Passende Arbeitsmittel unter Resources ansehenWie sollte der Vertrieb eingebunden werden?
Kurzantwort: Vertrieb benötigt klare Regeln zu Versionen, Support, Updates und zulässigen Zusagen.
Praktische Einordnung: Unbegrenzte Pflege oder ungesicherte Security-Versprechen erzeugen langfristige Risiken.
Managementempfehlung: Integrieren Sie CRA-Aussagen in Angebots- und Vertragsfreigabe.
Was ist bei End-of-Life kritisch?
Kurzantwort: EOL beendet nicht automatisch alle Sicherheits- und Kommunikationsrisiken.
Praktische Einordnung: Kunden benötigen Vorlauf, Migrationsoptionen und klare Informationen über das Ende von Updates.
Managementempfehlung: Definieren Sie einen formalen EOL-Prozess mit Executive-Freigabe.
Wie verhindert man ein Papierprogramm?
Kurzantwort: Jede Anforderung muss mit Prozess, Owner, Nachweis und Kennzahl verbunden sein.
Praktische Einordnung: Wirksamkeit zeigt sich an echten Produkten und simulierten Vorfällen.
Managementempfehlung: Machen Sie Releaseentscheidungen von Evidenz abhängig.
Muss ein Product Security Officer benannt werden?
Kurzantwort: Der CRA schreibt keinen bestimmten Titel für jedes Unternehmen vor.
Praktische Einordnung: Wichtig ist eine klar mandatierte zentrale Verantwortung mit Zugriff auf Management und Produktlinien.
Managementempfehlung: Benennen Sie eine Rolle, die Methodik, Eskalation und Reporting steuert.
Brauchen wir ein Product Security Board?
Kurzantwort: Bei mehreren Produktlinien oder wesentlichen Risiken ist ein Board meist sinnvoll.
Praktische Einordnung: Es löst Konflikte zwischen Termin, Kosten, Funktion und Restrisiko.
Managementempfehlung: Definieren Sie Mandat, Schwellenwerte und Teilnehmer.
Wie sollten Lieferanten bewertet werden?
Kurzantwort: Nach Kritikalität, Komponentenrolle, Updatefähigkeit, Schwachstellenprozess und Evidenz.
Praktische Einordnung: Ein allgemeiner Security-Fragebogen reicht für kritische Komponenten nicht aus.
Managementempfehlung: Nutzen Sie risikobasierte Due Diligence und Vertragsanforderungen.
Welche Rolle spielt M&A?
Kurzantwort: Übernahmen können unbekannte Product-Security-Schulden enthalten.
Praktische Einordnung: Fehlende SBOM, alte Toolchains und unklare Supportzusagen beeinflussen Kaufpreis und Integrationsaufwand.
Managementempfehlung: Integrieren Sie CRA in technische und rechtliche Due Diligence.
Wie oft muss der Scope überprüft werden?
Kurzantwort: Bei neuen Produkten, Versionen, Marken, Märkten, Akquisitionen und wesentlichen Änderungen.
Praktische Einordnung: Ein jährlicher Review allein reicht bei dynamischen Portfolios nicht aus.
Managementempfehlung: Definieren Sie ereignisgesteuerte Scope-Trigger.
Reicht ein Penetrationstest?
Kurzantwort: Nein.
Praktische Einordnung: Ein Penetrationstest ist eine Momentaufnahme und ersetzt weder Secure Development noch Lifecycle-Prozesse.
Managementempfehlung: Kombinieren Sie Tests mit Threat Modeling, SCA, Reviews und Governance.
Wie sollte Patch Management organisiert sein?
Kurzantwort: Mit risikobasierten SLA, Freigabe, Rollout, Rollback und Wirksamkeitskontrolle.
Praktische Einordnung: Produktpatches müssen technische, Safety-, Kunden- und Konformitätsfolgen berücksichtigen.
Managementempfehlung: Definieren Sie einen produktbezogenen Patch-Standard.
Das Secure Update & Patch Management Toolkit enthält editierbare Vorlagen, Register, Checklisten und Auswertungshilfen für die praktische Umsetzung.
Passende Arbeitsmittel unter Resources ansehenWie werden Security-Ausnahmen behandelt?
Kurzantwort: Ausnahmen müssen befristet, risikobewertet und genehmigt sein.
Praktische Einordnung: Dauerhafte Ausnahmen ohne Owner und Enddatum unterlaufen Release-Gates.
Managementempfehlung: Führen Sie ein zentrales Abweichungsregister.
Welche Nachweise sollten zehn Jahre verfügbar sein?
Kurzantwort: Konformitäts- und technische Unterlagen müssen entsprechend der gesetzlichen Aufbewahrungspflichten verfügbar bleiben.
Praktische Einordnung: Builds, Tests, Risikoentscheidungen und Erklärungen müssen langfristig reproduzierbar sein.
Managementempfehlung: Definieren Sie Archivierung, Integrität und Zugriff.
Wie werden kritische Produkte priorisiert?
Kurzantwort: Nach Produktklasse, Exposition, Kundenwirkung, Supportdauer und Schwachstellenhistorie.
Praktische Einordnung: Nicht jedes Produkt benötigt denselben Aufwand, aber jedes eine begründete Einstufung.
Managementempfehlung: Nutzen Sie ein produktbezogenes Priorisierungsmodell.
Was bedeutet CRA für Open Source?
Kurzantwort: Nicht-kommerzielle Entwicklung und kommerzielle Produktintegration sind zu unterscheiden.
Praktische Einordnung: Hersteller bleiben für das eigene Produkt verantwortlich, auch wenn die Ursache in einer Open-Source-Komponente liegt.
Managementempfehlung: Etablieren Sie Open-Source-Governance und EOL-Überwachung.
Wie sollte ein Konzern seine CRA-Governance organisieren?
Kurzantwort: Mit zentraler Methodik und dezentraler Produktverantwortung.
Praktische Einordnung: Ein rein zentrales Team kennt Produkte nicht tief genug; rein dezentrale Ansätze werden uneinheitlich.
Managementempfehlung: Etablieren Sie ein Product Security Office mit Produktlinien-Ownern.
Das Product Security Governance Toolkit enthält editierbare Vorlagen, Register, Checklisten und Auswertungshilfen für die praktische Umsetzung.
Passende Arbeitsmittel unter Resources ansehenWas ist die wichtigste erste Managemententscheidung?
Kurzantwort: Verantwortung und Scope verbindlich festzulegen.
Praktische Einordnung: Ohne diese Entscheidung bleiben Budget, Reporting, Pilotierung und Risikoakzeptanz ungeklärt.
Managementempfehlung: Mandatieren Sie Sponsor, Program Owner und Produktverantwortliche.
Glossar
| Begriff | Praktische Bedeutung |
|---|---|
| Produkt mit digitalen Elementen | Software- oder Hardwareprodukt einschließlich relevanter Remote-Datenverarbeitung mit direkter oder indirekter Datenverbindung. |
| Hersteller | Akteur, der ein Produkt entwickelt oder herstellen lässt und unter eigenem Namen oder eigener Marke vermarktet. |
| Secure by Design | Security wird von Anforderungen und Architektur bis Entwicklung, Test und Wartung integriert. |
| SBOM | Strukturierte Aufstellung der in einem Produkt enthaltenen Softwarekomponenten und Abhängigkeiten. |
| PSIRT | Organisation zur Behandlung produktbezogener Schwachstellen und Sicherheitsvorfälle. |
| Supportzeitraum | Zeitraum, in dem Schwachstellen behandelt und Sicherheitsupdates bereitgestellt werden. |
Primärquellen
Diese Reference Edition unterstützt die fachliche Einordnung und Projektvorbereitung. Maßgeblich bleiben die Verordnung, offizielle Leitlinien, harmonisierte Standards und die konkrete rechtliche Bewertung. Sie ersetzt keine Rechtsberatung.