Die CRA-Anforderungen an Security by Design umfassen nach Annex I technische Schutzmaßnahmen, Schwachstellenmanagement und Update-Pflichten, die mit NIS2 und AI Act Cybersecurity-Anforderungen harmonisiert sind. Für Hersteller bedeutet das nach der EU-VO 2024/2847: Cybersicherheit ist keine spätere Härtung mehr, sondern Teil von Entwicklung, Dokumentation, CE-Konformität und Produktpflege über den gesamten Lebenszyklus.
Praktisch relevant werden zwei feste Daten. Seit dem 10. Dezember 2024 ist die Verordnung in Kraft. Ab dem 11. September 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle. Ab dem 11. Dezember 2027 müssen neue Produkte mit digitalen Elementen die übrigen CRA-Pflichten vollständig erfüllen, also insbesondere Annex I, technische Dokumentation und Konformitätsbewertung.
Wenn Sie zuerst den Gesamtüberblick brauchen, lesen Sie ergänzend unsere Pillar-Seite zum Cyber Resilience Act. Für Zeitachsen, SBOM und CE-Prozess helfen außerdem die Beiträge zu CRA-Fristen, CRA-SBOM, CRA-CE-Kennzeichnung und unser Glossareintrag zur CE-Kennzeichnung für KI.
Was bedeutet Security by Design nach dem CRA?
Security by Design bedeutet im CRA, dass Hersteller Sicherheitsanforderungen nicht erst nach Markteinführung ergänzen dürfen, sondern bereits bei Planung, Design, Entwicklung, Produktion, Auslieferung und Wartung berücksichtigen müssen. Die zentrale Rechtsgrundlage ist Annex I Teil I der EU-VO 2024/2847 in Verbindung mit Art. 13 zur Cybersecurity-Risikobewertung.
Konkret verlangt der CRA erstens eine dokumentierte Risikobetrachtung. Hersteller müssen die für ihr Produkt relevanten Bedrohungen, Angriffswege, missbräuchlichen Nutzungsszenarien und möglichen Auswirkungen auf Nutzer, verbundene Geräte und andere Netze analysieren. Daraus folgt unmittelbar, welche der wesentlichen Anforderungen aus Annex I für das konkrete Produkt gelten und wie sie technisch umgesetzt werden.
Zweitens verlangt Security by Design eine Sicherheitsarchitektur, die ohne bekannte ausnutzbare Schwachstellen in den Markt geht. Das klingt selbstverständlich, ist aber operativ anspruchsvoll. Gemeint sind unter anderem Secure Coding, abgesicherte Build- und Release-Prozesse, saubere Abhängigkeitsverwaltung, sinnvolle Authentisierung, abgesicherte Schnittstellen, Logging und ein Update-Mechanismus, der Sicherheitskorrekturen verlässlich verteilt.
Drittens ist Security by Design im CRA eng mit anderen Regimen verzahnt. Wer Produkte mit digitalen Elementen baut, die zugleich unter NIS2-Lieferkettenanforderungen oder als Hochrisiko-KI unter den AI Act, insbesondere Art. 15, fallen, kann Sicherheitsprozesse nicht getrennt organisieren. NIS2 verlangt in Art. 21 der Richtlinie (EU) 2022/2555 organisatorische Sicherheitsmaßnahmen; der CRA verlangt die technische Produktumsetzung; der AI Act adressiert Robustheit und Cybersicherheit von Hochrisiko-KI. Für Hersteller ist daher ein gemeinsames Secure-Development- und Vulnerability-Management-Modell meist der wirtschaftlichste Weg.
Die 13 wesentlichen Cybersecurity-Anforderungen (Annex I)
Annex I Teil I enthält 13 wesentliche Produktanforderungen, die Hersteller risikobasiert auf ihr Produkt anwenden müssen. Die folgende Übersicht übersetzt die Norm in Umsetzungssprache für KMU und zeigt zugleich, wo sich Parallelen zu NIS2 und AI Act ergeben.
| Nr. | CRA-Anforderung nach Annex I Teil I | Umsetzungsbeispiel im Unternehmen | Parallele zu NIS2 / AI Act |
|---|---|---|---|
| 1 | Angemessenes Cybersicherheitsniveau auf Basis der Risiken | Threat Modeling, Abuse Cases, Sicherheitsanforderungen im Lastenheft | NIS2 Art. 21 Risikomanagement, AI Act Art. 15 Robustheit |
| 2 | Keine bekannten ausnutzbaren Schwachstellen bei Markteinführung | SAST, DAST, Review-Gates, Release-Freigabe nur nach Fix kritischer Findings | NIS2 Schwachstellenmanagement |
| 3 | Sichere Standardkonfiguration | Standardpasswörter verbieten, unnötige Ports deaktivieren, automatische Security-Updates standardmäßig aktivieren | NIS2 Cyberhygiene |
| 4 | Schutz vor unbefugtem Zugriff | Rollenmodell, MFA für Admin-Zugänge, Zertifikate, Zugriffskontrollen | NIS2 Zugriffsschutz, AI Act Art. 15 |
| 5 | Schutz der Vertraulichkeit | Verschlüsselung in Ruhe und bei Übertragung, Secret Management, Schlüsselrotation | NIS2 Kryptografie |
| 6 | Schutz der Integrität | Signierte Updates, Manipulationsschutz, Hashing, Integritätsprüfungen | NIS2 Integrität, AI Act Art. 15 |
| 7 | Datenminimierung | Nur erforderliche Telemetrie, begrenzte Logging-Felder, Privacy-by-Design bei Diagnosedaten | DSGVO-Prinzip, NIS2 Datenhygiene |
| 8 | Schutz der Verfügbarkeit und Resilienz | Rate Limits, Back-off, Failover, Wiederanlauf nach Incident, DoS-Schutz | NIS2 Business Continuity |
| 9 | Begrenzung negativer Auswirkungen auf andere Dienste | Kein übermäßiger Netzwerkverkehr, sichere Fehlerzustände, Isolation kompromittierter Komponenten | NIS2 Netzwerksicherheit |
| 10 | Begrenzung der Angriffsfläche | Hardening von APIs, minimale Dienste, Deaktivierung unnötiger Funktionen | NIS2 Cyberhygiene |
| 11 | Minderung der Incident-Auswirkungen | Sandboxing, Speicherschutz, Privilege Separation, sichere Fallbacks | AI Act Art. 15, NIS2 Incident Handling |
| 12 | Sicherheitsrelevante Protokollierung und Monitoring | Audit-Logs zu Zugriff, Konfigurationsänderungen und Datenmanipulation, mit Opt-out für Nutzer | NIS2 Logging, AI Act Nachvollziehbarkeit |
| 13 | Sichere und dauerhafte Datenlöschung bzw. sichere Übertragbarkeit | Factory Reset, Löschfunktion für Konten, sichere Exportpfade bei Gerätewechsel | NIS2 Lebenszyklus-Sicherheit |
Für viele Hersteller sind insbesondere die Nummern 2, 3, 10 und 12 der operative Engpass. Nicht weil die Anforderungen unverständlich wären, sondern weil sie Reife in Entwicklung, Produktmanagement und Support voraussetzen. Wer noch mit uneinheitlichen Release-Prozessen, manuell gepflegten Komponentenlisten und unklaren Logging-Standards arbeitet, muss zuerst die Grundlagen einer belastbaren Produkt-Security-Governance aufbauen.
Wichtig ist außerdem die risikobasierte Logik. Der CRA sagt nicht, dass jedes Produkt jede Kontrolle in identischer Tiefe umsetzen muss. Ein vernetzter Sensor, eine Unternehmenssoftware und ein industrielles Steuerungssystem tragen unterschiedliche Risiken. Trotzdem müssen alle drei nachvollziehbar darlegen können, warum bestimmte technische Maßnahmen angemessen sind und wie diese in der Entwicklung abgesichert wurden.
Security by Default — Sichere Standardkonfiguration
Security by Default heißt nach Annex I Teil I Buchstabe b und c praktisch: Das Produkt muss in der Ausgangskonfiguration sicher nutzbar sein, ohne dass der Kunde erst sicherheitsrelevante Einstellungen manuell nachziehen muss. Hersteller dürfen also nicht von unsicheren Werkseinstellungen ausgehen und darauf vertrauen, dass der Integrator oder Endkunde später schon alles richtig härtet.
Die häufigsten Problemfelder sind bekannt. Vordefinierte Standardkennwörter, offene Debug-Schnittstellen, aktivierte Testkonten, unverschlüsselte Management-Protokolle, unnötige Netzwerkdienste und deaktivierte Update-Funktionen sind mit dem CRA schwer vereinbar. Für viele KMU ist die wichtigste Konsequenz deshalb banal, aber wirkungsvoll: Produktteams brauchen vor Auslieferung eine feste Security-Default-Checkliste.
Besonders relevant ist die Update-Logik. Annex I Teil II Nr. 7 und 8 verlangt sichere Verteilung von Updates und grundsätzlich eine zeitnahe, kostenlose Bereitstellung von Sicherheitsupdates. Wo Sicherheitsupdates technisch automatisch eingespielt werden können, soll dies standardmäßig vorgesehen sein. Nutzer dürfen davon abweichen, aber die Voreinstellung muss sicher sein. Genau darin liegt der Unterschied zwischen bloßer Update-Fähigkeit und echter Security by Default.
Für Hersteller mit B2B- oder OEM-Produkten folgt daraus eine zweite Pflicht: Sie müssen in der Nutzerdokumentation erklären, welche Sicherheitseinstellungen vorausgesetzt werden und wie automatische Sicherheitsupdates deaktiviert oder verwaltet werden können. Diese Informationspflichten finden sich nicht in Annex I selbst, sondern ergänzend in Annex II zu den Informationen und Anweisungen für Nutzer.
Vulnerability Handling — Schwachstellenmanagement als Pflicht
Vulnerability Handling ist im CRA keine Support-Kür, sondern eine eigenständige Pflicht aus Annex I Teil II. Hersteller müssen Schwachstellen und Komponenten dokumentieren, Schwachstellen ohne Verzögerung beheben, die Sicherheit ihrer Produkte regelmäßig testen, eine Policy zur koordinierten Offenlegung durchsetzen und sichere Update-Mechanismen betreiben.
Die erste zentrale Vorgabe ist die Komponenten-Transparenz. Annex I Teil II Nr. 1 verlangt, dass Hersteller Schwachstellen und enthaltene Komponenten dokumentieren, einschließlich einer Software Bill of Materials in einem gängigen, maschinenlesbaren Format mindestens auf Ebene der Top-Level-Abhängigkeiten. Für die Praxis bedeutet das: Ohne SBOM wird CRA-Compliance bei Software und vernetzter Hardware unnötig schwer.
Die zweite zentrale Vorgabe ist Reaktionsgeschwindigkeit. Annex I Teil II Nr. 2 verpflichtet Hersteller, Schwachstellen ohne Verzögerung zu adressieren und zu beheben, einschließlich Security-Updates. Soweit technisch möglich, sollen neue Sicherheitsupdates getrennt von Funktionsupdates bereitgestellt werden. Diese Trennung ist für regulierte Kunden wichtig, weil ein Security-Fix häufig schneller freigegeben werden kann als ein Funktionsrelease.
Die dritte zentrale Vorgabe ist Meldefähigkeit. Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle über die Single Reporting Platform an die zuständigen CSIRTs melden; die Information wird an ENISA weitergegeben. Die 24-Stunden-Frist ist deshalb keine bloße Theorie. Unternehmen brauchen bis dahin klare interne Triage-Regeln, Ansprechpartner, Kontaktwege und Entscheidungslogiken.
Die vierte zentrale Vorgabe ist Transparenz gegenüber Nutzern. Sobald ein Sicherheitsupdate verfügbar ist, müssen Informationen über behobene Schwachstellen, betroffene Produkte, Auswirkungen, Schweregrad und empfohlene Gegenmaßnahmen zugänglich gemacht werden. Ein reines Changelog ohne klare Handlungsanweisung reicht dafür praktisch nicht aus.
Technische Dokumentation und Konformitätsbewertung
Die technische Dokumentation ist der Dreh- und Angelpunkt der CRA-Compliance, weil sie nach Art. 31 und Annex VII belegen muss, dass Produkt und Herstellerprozesse Annex I tatsächlich erfüllen. Wer technische Maßnahmen implementiert, sie aber nicht nachvollziehbar dokumentiert, scheitert spätestens in der Konformitätsbewertung.
Mindestens enthalten sein sollten eine Produktbeschreibung, die Cybersecurity-Risikobewertung, die Zuordnung der relevanten Annex-I-Anforderungen, die gewählten technischen Lösungen, Test- und Prüfnachweise, Angaben zur SBOM, der festgelegte Supportzeitraum sowie Informationen zu Update-, Disclosure- und Incident-Prozessen. Die Dokumentation muss vor Markteinführung vorliegen und während des Supportzeitraums fortlaufend aktualisiert werden.
Für KMU ist die gute Nachricht: Nicht jedes Produkt braucht automatisch dieselbe externe Prüftiefe. Viele Produkte mit digitalen Elementen laufen über interne Kontrolle und Hersteller-Selbsterklärung. Für wichtige Produkte nach Annex III Klasse I oder II kann jedoch eine strengere Konformitätsbewertung mit benannter Stelle oder zertifizierungsnahen Verfahren erforderlich sein, vor allem wenn harmonisierte Normen oder Common Specifications nicht oder nur teilweise angewendet werden.
Die Konsequenz für das Projektmanagement ist klar. Security by Design muss in den Produktentstehungsprozess eingebaut werden, bevor das CE-Thema auf dem Tisch landet. Wenn Teams erst kurz vor dem Go-live anfangen, Risikobewertung, Testnachweise und Supportzusagen zusammenzusuchen, steigen Aufwand, Verzögerungsrisiko und Nachbesserungskosten massiv. Für den Detailprozess ist unser Beitrag zur CRA-CE-Kennzeichnung der sinnvollste Anschluss.
Pflichten über den gesamten Produktlebenszyklus (mind. 5 Jahre)
Der CRA endet nicht mit der Markteinführung. Art. 13 Abs. 8 verpflichtet Hersteller, einen Supportzeitraum festzulegen, der die erwartete Nutzungsdauer des Produkts widerspiegelt. Grundsätzlich muss dieser Zeitraum mindestens fünf Jahre betragen. Ist die zu erwartende Nutzung kürzer, darf der Zeitraum entsprechend kürzer sein; ist sie länger, muss der Support länger laufen. Für Industrieprodukte, Betriebssysteme oder Netzkomponenten ist daher oft mehr als fünf Jahre erforderlich.
Zusätzlich verlangt Art. 13, dass der Endzeitpunkt des Supportzeitraums bereits beim Kauf klar angegeben wird. Nutzer sollen also wissen, bis wann Schwachstellenbehandlung und Sicherheitsupdates erwartet werden dürfen. Wo technisch möglich, sollen Nutzer sogar informiert werden, wenn das Produkt das Ende dieses Zeitraums erreicht hat.
Noch strenger ist die Verfügbarkeit einzelner Updates. Nach Art. 13 Abs. 9 muss jedes während des Supportzeitraums bereitgestellte Sicherheitsupdate mindestens zehn Jahre nach Bereitstellung oder für den Rest des Supportzeitraums verfügbar bleiben, je nachdem, welcher Zeitraum länger ist. Für Hersteller mit gewachsenen Download-Portalen und verstreuten Release-Artefakten ist das oft organisatorisch anspruchsvoller als die Entwicklung des Patches selbst.
Für bestehende Produkte ist die Lage differenziert. Produkte, die bereits vor dem 11. Dezember 2027 auf dem Markt waren, müssen nicht automatisch rückwirkend vollständig CRA-konform gemacht werden. Sobald aber nach diesem Datum neue Produkte in Verkehr gebracht oder bestehende Produkte wesentlich geändert werden, ist zu prüfen, ob eine neue CRA-Bewertung erforderlich wird. Hersteller sollten deshalb ihre Legacy- und New-Product-Strategie spätestens 2026 sauber trennen.
Praktische Umsetzung für KMU — 7 Schritte
KMU sollten CRA-Compliance als Produkt- und Prozessprogramm aufsetzen, nicht als Einzelprojekt der Rechtsabteilung. Ein praktikabler Einstieg besteht aus sieben Schritten, die auch mit begrenzten Ressourcen funktionieren.
1. Scope festlegen
Identifizieren Sie zuerst alle Produkte mit digitalen Elementen, die Sie in der EU in Verkehr bringen. Dazu zählen nicht nur smarte Geräte, sondern oft auch lokale Software, Cloud-verbundene Anwendungen, Embedded-Komponenten und digitale Zusatzmodule für Maschinen.
2. Produktklassen und Risikoprofil bestimmen
Ordnen Sie jedes Produkt grob nach Kritikalität, Konnektivität, Datenverarbeitung, Angriffsfläche und möglicher Schadenswirkung ein. Prüfen Sie außerdem, ob das Produkt voraussichtlich unter die Kategorien wichtiger Produkte nach Annex III fällt.
3. CRA-Risikobewertung durchführen
Leiten Sie aus Architektur, Schnittstellen, Nutzergruppen und Missbrauchsszenarien eine Cybersecurity-Risikobewertung nach Art. 13 ab. Das Ergebnis muss nicht akademisch sein, aber nachvollziehbar auf die 13 Annex-I-Anforderungen abbilden.
4. Secure-Development-Mindeststandard definieren
Legen Sie verbindlich fest, welche Security-Defaults, Testverfahren, Freigabekriterien, Logging-Standards, Kryptovorgaben und Update-Prozesse produktübergreifend gelten. Hier liegt meist der größte Hebel, weil ein gemeinsamer Mindeststandard spätere Dokumentation stark vereinfacht.
5. SBOM- und Vulnerability-Prozess einführen
Bauen Sie für jede relevante Produktlinie einen gepflegten Komponentenbestand auf, richten Sie einen Meldekanal für Schwachstellen ein und definieren Sie SLA-gestützte Reaktionspfade für kritische, hohe und mittlere Findings. Wer hier spät beginnt, scheitert fast immer an operativer Hektik statt an juristischen Detailfragen.
6. Technische Dokumentation laufend mitführen
Pflegen Sie Risikobewertung, Testnachweise, Supportzeitraum, Nutzerinformationen und Konformitätsunterlagen nicht erst vor dem Audit, sondern releasebegleitend. Für KMU ist ein einfacher, versionierter Dokumentationsordner oft ausreichend, solange Zuständigkeiten und Freigaben klar sind.
7. Cross-Regulation sauber verzahnen
Verknüpfen Sie CRA-Arbeitspakete mit bestehenden Maßnahmen aus NIS2, Produktsicherheit, Datenschutz und gegebenenfalls AI Act. Wenn Ihr Unternehmen zusätzlich KI-Systeme entwickelt oder betreibt, profitieren Sie meist von einem gemeinsamen Governance-Verständnis und einer dokumentierten Grundqualifizierung der verantwortlichen Rollen. Dafür kann unsere EU-AI-Act-Schulung eine sinnvolle Basis sein, weil sie Verantwortlichkeiten, Dokumentation und Sicherheitslogik verständlich in Prozesse übersetzt.
Häufig gestellte Fragen (FAQ)
Was genau bedeutet Security by Design im CRA?
Security by Design bedeutet, dass Sicherheitsanforderungen von Anfang an Teil des Produkts sein müssen. Nach Annex I Teil I der EU-VO 2024/2847 reicht es nicht, Probleme nach Auslieferung zu reparieren. Hersteller müssen bereits vor Markteinführung Risiken bewerten, sichere Konfigurationen vorsehen, Angriffsflächen begrenzen, Schutzmechanismen integrieren und dies alles dokumentieren.
Welche Dokumentation müssen Hersteller führen?
Hersteller müssen nach Art. 31 und Annex VII eine technische Dokumentation führen, die die CRA-Konformität des Produkts und der Herstellerprozesse belegt. Dazu gehören insbesondere Produktbeschreibung, Risikobewertung, Zuordnung der relevanten Annex-I-Anforderungen, Test- und Prüfergebnisse, Supportzeitraum, Nutzerinformationen, Update- und Disclosure-Prozesse sowie gegebenenfalls Angaben zur SBOM.
Wie lange müssen Sicherheitsupdates bereitgestellt werden?
Der Supportzeitraum muss nach Art. 13 Abs. 8 grundsätzlich mindestens fünf Jahre betragen, sofern die erwartete Nutzungsdauer nicht kürzer ist. Bei Produkten mit längerer realistischer Nutzung, etwa in Industrieumgebungen, kann der erforderliche Zeitraum deutlich darüber liegen. Einzelne Sicherheitsupdates müssen nach Art. 13 Abs. 9 mindestens zehn Jahre ab Veröffentlichung oder bis zum Ende des Supportzeitraums verfügbar bleiben, je nachdem, welcher Zeitraum länger ist.
Gilt Security by Design auch für bestehende Produkte?
Nicht automatisch rückwirkend für jedes Altprodukt. Maßgeblich ist vor allem, ob ein Produkt nach dem 11. Dezember 2027 neu in Verkehr gebracht oder wesentlich verändert wird. Hersteller sollten deshalb für Bestandsprodukte, Wartungsversionen und Neuprodukte eine getrennte CRA-Strategie festlegen, um unnötige Re-Assessment-Schleifen zu vermeiden.
Gibt es Überschneidungen mit NIS2 und AI Act?
Ja, aber die Ebenen unterscheiden sich. Der CRA adressiert technische Produktsicherheit, NIS2 organisatorische Sicherheitsmaßnahmen und der AI Act die Robustheit und Cybersicherheit von Hochrisiko-KI. In der Praxis überschneiden sich diese Regime bei Risikomanagement, Secure Development, Incident Handling, Logging und Update-Prozessen. Wer diese Themen getrennt organisiert, zahlt fast immer mit Doppelarbeit.
Fazit und nächster Schritt
Die wichtigste Botschaft lautet: CRA-Compliance beginnt nicht bei der CE-Erklärung, sondern bei Architektur, Default-Einstellungen, Schwachstellenmanagement und belastbarer Dokumentation. Hersteller, die 2026 noch auf Ad-hoc-Fixes setzen, werden die Daten 11. September 2026 und 11. Dezember 2027 nur mit hohem Druck erreichen.
Wenn Sie Verantwortlichkeiten, Nachweislogik und regulatorische Schnittstellen zwischen CRA, NIS2 und AI Act intern sauber aufsetzen wollen, ist unsere EU-AI-Act-Schulung ein pragmatischer Einstieg für Geschäftsführung, Compliance und Produktverantwortliche. Sie ersetzt keine CRA-Produkttests, schafft aber das gemeinsame Governance-Verständnis, das für Security by Design in der Praxis meistens zuerst fehlt.