CRA-Schulungen für Entwicklerteams: Was ist Pflicht?

Was der CRA tatsächlich verlangt — und was er nicht verlangt

Wer nach einer expliziten Schulungspflicht im Cyber Resilience Act sucht, wird sie nicht finden. Das Wort „Schulung” kommt in der Verordnung nicht vor. Artikel 13 Absatz 1 formuliert stattdessen allgemeiner: Hersteller müssen „die notwendigen internen Prozesse einrichten”, um die Anforderungen des CRA dauerhaft zu erfüllen.¹

Das klingt nach Bürokratensprache. Ist es bei näherer Betrachtung aber nicht — es ist präzise: Der CRA schreibt nicht vor, wie ein Hersteller seine Organisation aufstellt. Er schreibt vor, was dabei herauskommen muss. Anhang I listet das detailliert auf: Schwachstellenmanagement, SBOM, Secure-by-Default-Konfiguration, Kryptographie nach Stand der Technik, Minimalprinzip bei Angriffsflächen, sicheres Update-Verfahren.²

Keine dieser Anforderungen kann ein Team erfüllen, das nicht versteht, was sie inhaltlich bedeuten. Schulung ist zwar keine Pflicht — aber das Ergebnis, das Schulung erzeugen soll, ist es. Das ist der entscheidende Unterschied.

Kein Prüfer wird fragen „Haben Ihre Entwickler ein Zertifikat?” — aber jeder Prüfer wird merken, ob das Team versteht, was Secure-by-Default bedeutet. Spätestens dann, wenn die technische Dokumentation vorgelegt wird und erklärbar sein muss, warum bestimmte Architekturentscheidungen getroffen wurden.

Ein Hersteller von industriellen MQTT-Gateways für die Maschinenanbindung — also ein typischer Industrie-4.0-Anbieter mit 15 Entwicklern — ist genau hier betroffen: Seine Entwickler bauen seit Jahren zuverlässige Protokollkonverter, haben aber nie systematisch über Default-Konfigurationen oder Angriffsflächen nachgedacht. Der CRA verlangt keine Zertifikate von ihnen. Er verlangt, dass das Produkt sicher konfiguriert ausgeliefert wird. Ob das Team das kann, zeigt sich in der Dokumentation.

Die praktische Lücke: Was viele Teams noch nicht wissen

Secure Coding ist in vielen Entwicklerteams kein Selbstverständnis — besonders nicht in KMUs, die über Jahre gewachsen sind und deren Entwickler primär auf Feature-Lieferung optimiert wurden. Das ist keine Kritik, sondern eine Bestandsaufnahme. Wer noch nie systematisch über Threat Modeling nachgedacht hat, kann keine STRIDE-basierte Risikoanalyse für eine Marktaufsichtsbehörde produzieren.

Was viele CRA-Berater nicht sagen: Die eigentliche Lücke liegt nicht im Wissen über die Verordnung selbst — die meisten Entwickler können Artikel 13 in zwanzig Minuten lesen. Die Lücke liegt im technischen Handwerkszeug, das nötig ist, um die Anforderungen operativ umzusetzen.

Vier konkrete Wissensfelder, die ein CRA-konformes Team beherrschen muss:

1. Schwachstellenklassifizierung und CVE-Monitoring Entwickler müssen verstehen, was eine CVE ist, wie CVSS-Scores zu interpretieren sind, und welche Schwelle eine Schwachstelle von „zu dokumentieren” zu „in 24 Stunden zu melden” macht. Artikel 14 CRA schreibt für aktiv ausgenutzte Schwachstellen eine Meldepflicht binnen 24 Stunden gegenüber ENISA vor — diese Frist einzuhalten setzt voraus, dass das Team Schwachstellen überhaupt erkennt und bewertet.¹

Konkret bedeutet das: Ein IoT-Startup, das embedded-Software für Heizungssteuerungen entwickelt, muss einen Prozess aufbauen, der neue CVEs in genutzten Open-Source-Bibliotheken automatisch meldet — und intern klärt, wer binnen Stunden entscheidet, ob eine Meldepflicht besteht. Ohne dieses Wissen ist die 24-Stunden-Frist nicht einhaltbar.

2. SBOM-Prozesse Anhang I Nr. 2 lit. f verlangt eine Software Bill of Materials.² Wer Abhängigkeiten nicht systematisch erfasst, kann keine vollständige SBOM produzieren — und erst recht nicht sicherstellen, dass sie aktuell bleibt. Das ist ein operatives Problem, das technisches Wissen erfordert: Wie werden Abhängigkeiten inventarisiert, welche Tools (SPDX, CycloneDX) kommen zum Einsatz, wer im Team trägt die Verantwortung?

3. Threat Modeling Risikoanalyse nach CRA ist nicht identisch mit einer ISO-27001-Risikobeurteilung. CRA-Risikoanalyse ist produktspezifisch und muss Bedrohungsmodelle für die konkrete Produktarchitektur umfassen. STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) ist der am weitesten verbreitete Rahmen für strukturiertes Threat Modeling und deckt die CRA-Anforderungen gut ab.

Das ist der Punkt, den viele übersehen: Ein STRIDE-Modell für ein industrielles Gateway sieht völlig anders aus als für eine Heizungssteuerungs-App. Die Methode ist dieselbe — die Bedrohungslandschaft nicht. Wer das nicht unterscheidet, produziert Dokumentation, die bei einer Prüfung sofort als generisch auffällt.

4. Secure-by-Default-Prinzipien Anhang I Nr. 1 lit. b formuliert explizit: Produkte müssen im Auslieferungszustand sicher konfiguriert sein — nicht erst nach manuellem Eingriff durch den Nutzer.² Keine voreingestellten Standard-Passwörter, minimale Netzwerkdienste im Standardbetrieb, deaktivierte Debugging-Schnittstellen. Entwickler, die noch nie bewusst über Default-Konfigurationen aus Sicherheitsperspektive nachgedacht haben, müssen das nachholen.

Empfohlene Wissensquellen — ohne Lizenzkosten

Die meisten KMUs werden kein dediziertes Schulungsbudget für externe Kurse bereitstellen wollen. Das ist in Ordnung — die relevanten Inhalte sind kostenlos zugänglich:

ENISA — CRA-spezifische Leitfäden: Die Europäische Agentur für Cybersicherheit veröffentlicht regelmäßig technische Leitlinien zur Umsetzung des CRA, einschließlich Secure-Development-Prozessen und Schwachstellenmanagement. Direkter Bezug zum CRA-Wortlaut. https://www.enisa.europa.eu/topics/cyber-resilience-act

BSI IT-Grundschutz: Der IT-Grundschutz-Katalog des BSI deckt die relevanten Sicherheitsprinzipien für Software-Entwicklung ab und ist auf deutsch verfügbar. Für Hersteller, die mit deutschen Behörden interagieren, ist BSI-Sprache ein Vorteil. https://www.bsi.bund.de/grundschutz

OWASP — OWASP Top 10 und ASVS: Die OWASP Top 10 ist der Standardrahmen für Web-Application-Sicherheitsrisiken. Das Application Security Verification Standard (ASVS) geht tiefer und bietet ein strukturiertes Prüfraster. Beide sind kostenlos, aktiv gepflegt und international anerkannt. https://owasp.org

OWASP Threat Dragon: Kostenloses Open-Source-Tool für Threat Modeling. Für Teams, die STRIDE-basiertes Threat Modeling einführen wollen, ist das ein guter Einstiegspunkt ohne Vorinvestition.

CISA Secure by Design: Die US-amerikanische CISA und mehrere europäische Partner (darunter BSI, NCSC, ANSSI) haben gemeinsam „Secure by Design”-Leitlinien veröffentlicht, die direkt die Konzepte adressieren, die CRA Anhang I verlangt. https://www.cisa.gov/securebydesign

Zertifizierungen: Wann sie sich lohnen

Zertifizierungen wie CSSLP (Certified Secure Software Lifecycle Professional) oder CEH (Certified Ethical Hacker) sind teuer — die CSSLP-Prüfung kostet rund 600 USD, die Vorbereitung typischerweise nochmals das Doppelte an Zeit oder Lernmaterialien. Für die meisten KMU-Entwicklerteams ist das eine unverhältnismäßige Investition. Der CRA verlangt sie nicht.

Sinnvoll werden Zertifizierungen in zwei Szenarien: Erstens wenn ein Unternehmen einen dedizierten Security Engineer einstellt oder intern benennt, der die CRA-Verantwortung trägt — hier kann CSSLP eine sinnvolle Qualifikation sein. Zweitens wenn das Unternehmen seine Kunden aktiv über Sicherheitskompetenz informieren will und ein anerkanntes Credentials-Signal braucht.

In der Praxis erleben wir: Maschinenbau-KMUs, die in Zertifizierungen investieren, ohne vorher die operativen Prozesse aufzubauen, stehen bei einer Prüfung schlechter da als Teams ohne ein einziges Zertifikat — aber mit vollständiger Threat-Modeling-Dokumentation. Das interne Wissen der Entwickler, dokumentiert durch Code-Reviews, Threat-Modeling-Protokolle und Schulungsnachweise (auch informelle), ist mehr wert als externe Zertifikate ohne interne Praxis.

Was Marktaufsichtsbehörden sehen wollen

Prüft die Marktaufsichtsbehörde nach dem Kompetenznachweis — was sie darf, auch ohne konkreten Verdacht auf Verstoß — erwartet sie in der Regel folgende Belege:

Nachweise, dass im Entwicklungsprozess systematisches Threat Modeling stattfindet (Protokolle, Entscheidungsdokumentation)
Nachweis eines SBOM-Prozesses mit aktueller Liste der Abhängigkeiten
Nachweis eines CVE-Monitoring-Prozesses mit Reaktionszeiten
Interne Richtlinien zu Secure-by-Default-Konfiguration
Nachweis, dass Entwickler Sicherheitsanforderungen in Code-Reviews systematisch prüfen

Schulungszertifikate wären ein Bonus. Aber ohne die operativen Prozesse dahinter helfen sie nicht. Umgekehrt: Ein Team ohne ein einziges Zertifikat, das aber vollständige Threat-Modeling-Protokolle, eine gepflegte SBOM und dokumentierte CVE-Reaktionen vorweisen kann, steht deutlich besser da.

Für die vollständige Liste der Hersteller-Pflichten lesen Sie CRA-Pflichten für Hersteller. Die inhaltlichen Anforderungen an das Produkt selbst sind in CRA Anhang I — was Hersteller technisch liefern müssen dokumentiert.

Quellen

EU-Verordnung 2024/2847 (Cyber Resilience Act), Artikel 13 (Pflichten der Hersteller), Artikel 14 (Meldepflichten): https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
EU-Verordnung 2024/2847, Anhang I (Wesentliche Cybersicherheitsanforderungen), insbesondere Nr. 1 lit. a–k und Nr. 2 lit. a–g: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
ENISA — Cybersecurity in Software Development: https://www.enisa.europa.eu/topics/cyber-resilience-act
BSI — IT-Grundschutz-Kompendium: https://www.bsi.bund.de/grundschutz
OWASP — Application Security Verification Standard (ASVS): https://owasp.org/www-project-application-security-verification-standard/
CISA, BSI, NCSC u.a. — Secure by Design: https://www.cisa.gov/securebydesign