Cyber Resilience Act (CRA): Was Hersteller vernetzter Produkte und App-Anbieter jetzt umsetzen müssen
Euer Produkt ist vernetzt – oder eure App ist das Produkt? Dann betrifft euch das.
Der Cyber Resilience Act (auf Deutsch: Cyberresilienz-Verordnung, EU 2024/2847) macht Cybersicherheit zur Voraussetzung für den EU-Markt – für vernetzte Geräte samt zugehöriger Software genauso wie für kommerziell angebotene Apps ohne Hardware. Ab dem 11.09.2026 gelten die Meldepflichten, ab dem 11.12.2027 die vollen Anforderungen. Hier steht, was bis wann zu tun ist und wie ihr es pragmatisch umsetzt.
Was ist der Cyber Resilience Act?
Der Cyber Resilience Act (EU 2024/2847) legt erstmals einheitliche Cybersicherheitsanforderungen für alle „Produkte mit digitalen Elementen" fest – vom smarten Thermostat bis zur Werkzeugmaschine, ausdrücklich auch für kommerziell angebotene Apps. Drei Daten stecken den Rahmen ab:
In Kraft seit
10.12.2024
Der CRA ist geltendes EU-Recht. Die Übergangsfristen laufen bereits.
Meldepflichten ab
11.09.2026
Aktiv ausgenutzte Schwachstellen und schwere Vorfälle: Frühwarnung binnen 24 Stunden – auch für euer heutiges Portfolio.
Volle Geltung ab
11.12.2027
Neue Produkte mit digitalen Elementen brauchen CRA-Konformität fürs CE-Kennzeichen.
Die nächste Frist ist die kritische – und sie gilt nicht erst für neue Produkte: Was die Meldepflichten ab 09/2026 verlangen →
Für wen gilt der CRA – und wer trägt die Verantwortung?
Verantwortlich seid ihr – der Hersteller.
Wenn auf dem Karton euer Name steht – oder ihr eine App kommerziell in der EU anbietet. Auch für zugekaufte Komponenten und beauftragte Software.
Die allermeisten Produkte fallen in die Standardkategorie mit Selbstbewertung der Konformität; nur für "wichtige" und "kritische" Produkte (z. B. bestimmte Sicherheitskomponenten) gelten strengere Bewertungsverfahren – die Einstufung klärt ihr am besten früh mit eurer Regulatory-Beratung. Ob euer Produkt und eure App überhaupt betroffen sind, könnt ihr dagegen sofort prüfen: Zum Selbsttest mit acht Fragen →
Gilt der CRA auch für Apps ohne Hardware?
Ja – und wo genau die Grenze läuft, zeigt der Überblick:
Kommerziell angebotene Apps – mit oder ohne Hardware
Selbst ein Produkt mit digitalen Elementen: Security by Design, SBOM, kostenlose Updates und die Meldepflichten ab 09/2026 gelten in vollem Umfang.
Reine Web-Dienste & SaaS
Was als Software ausgeliefert wird, ist CRA-Terrain – was ausschließlich als Dienst läuft, fällt je nach Sektor unter NIS2.
Apps als Frontend eines Dienstes
Läuft die eigentliche Funktion auf euren Servern, zählt dieser Cloud-Anteil mit zur App – und damit zum CRA. Wo genau die Grenze zum reinen Dienst verläuft, präzisiert die EU noch: Klärt euren Fall deshalb früh mit eurer Rechtsberatung.
Nicht-kommerzielle Software
Freie Open-Source-Projekte außerhalb einer Geschäftstätigkeit – die Bibliotheken in eurer kommerziellen App müsst ihr über SBOM trotzdem im Griff haben.
CRA vs. NIS2 vs. RED vs. BFSG – die Abgrenzung im Detail →
Praktisch heißt das: Die technischen Hausaufgaben sind dieselben wie bei vernetzten Produkten – nur ohne Firmware-Kanal. Ein guter Startpunkt: der Selbsttest – sechs der acht Fragen gelten für jede App.
CRA-Pflichten in Klartext: Was auf Hersteller und App-Anbieter zukommt
Sechs Pflichtenblöcke entlang des Produkt-Lebenszyklus – drei davon vertiefen wir in eigenen Leitfäden:
Phase 1 · Konzeption & Entwicklung
Security by Design
Cybersicherheit muss von der Konzeption an berücksichtigt und über eine Risikobewertung dokumentiert werden – nicht nachträglich angeflanscht.
Phase 2 · Release
Sicher bei Auslieferung
Keine bekannten ausnutzbaren Schwachstellen bei Auslieferung, sichere Standardkonfiguration, Schutz vor unbefugtem Zugriff, Verschlüsselung, Datenminimierung.
Technische Dokumentation & CE
Ohne dokumentierte CRA-Konformität kein CE-Kennzeichen, ohne CE-Kennzeichen kein EU-Markt – die Dokumentation ist der Nachweis, nicht die Kür.
Phase 3 · Betrieb – über den gesamten Supportzeitraum
Schwachstellenmanagement & SBOM
Schwachstellen identifizieren, dokumentieren und beheben – dazu eine SBOM in maschinenlesbarem Format und eine erreichbare Kontaktstelle für Schwachstellenmeldungen.
SBOM für eure App erstellen →Kostenlose Sicherheitsupdates
Über den Supportzeitraum, der der erwarteten Nutzungsdauer entspricht – in der Regel mindestens 5 Jahre. Kein Abo, keine Paywall.
Was das für eure App heißt →Meldepflichten ab 09/2026
Aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle müssen ab dem 11.09.2026 binnen 24 Stunden gemeldet werden.
Fristen und Ablauf der Meldepflicht →Wo eure App heute steht, muss keine Schätzfrage bleiben: Der CRA-Readiness-Check klärt es in 2–3 Tagen – mit priorisiertem Maßnahmenkatalog zum Festpreis.
Was heißt der CRA konkret für eure App?
Die grundlegenden Anforderungen aus Anhang I des CRA lesen sich abstrakt – übersetzt in App-Realität werden sie sehr konkret. Links das Verordnungs-Deutsch, rechts, was es in eurer App bedeutet – bei Companion Apps genauso wie bei Standalone-Apps ohne Hardware:
„Sichere Standardkonfiguration"
Sichere Voreinstellungen statt „Passwort 0000"
„Schutz vor unbefugtem Zugriff"
Sauberes Session- und Token-Handling
„Vertraulichkeit der Daten"
Verschlüsselte Kommunikation zu Gerät & Cloud
„Sicherer Update-Mechanismus"
Ein Update-Kanal, der jederzeit funktioniert
„Sorgfalt bei Komponenten Dritter"
Drittanbieter-SDKs im Griff – samt SBOM
„Security-Logging & Monitoring"
Vorfälle, die ihr überhaupt bemerkt
Die Vertiefung für euer Tech-Team: Wir haben jede Anforderung aus Anhang I auf App-Realität übersetzt – mit dem Ist-Zustand, der in gewachsenen Bestands-Apps typisch ist, und dem jeweiligen To-do.
Selbsttest: Wie CRA-ready seid ihr?
Acht Fragen, ehrlich beantwortet. Jedes „Nein“ oder „Weiß nicht“ ist ein Punkt für euer Maßnahmen-Backlog.
01
Habt ihr eine aktuelle, maschinenlesbare SBOM für eure App – bei Geräte-Apps inklusive der nativen SDKs eurer Chip- und Komponentenlieferanten?
02
Wisst ihr innerhalb eines Tages, ob eine neu veröffentlichte CVE eine Bibliothek in eurer App betrifft?
03
Gibt es einen definierten Prozess (und eine erreichbare Person), um binnen 24 Stunden eine Erstmeldung an CSIRT und ENISA abzugeben – auch am Wochenende?
04
Könnt ihr ein Sicherheitsupdate eurer App innerhalb weniger Tage bauen, testen und in beide Stores ausrollen?
05
Ist die Kommunikation zwischen App, Backend und – falls vorhanden – eurem Gerät durchgehend verschlüsselt und authentifiziert?
06
Sind Debug-Schnittstellen, Test-Endpoints und ausführliche Logs in der Produktions-App deaktiviert?
07
Habt ihr für jedes Drittanbieter-SDK in der App geklärt, welche Daten es erhebt und wer es pflegt?
08
Ist vertraglich geregelt, wer eure App über die nächsten 5+ Jahre wartet – und was passiert, wenn diese Person oder Agentur ausfällt?
Mehr als zwei „Nein“? Damit seid ihr in guter Gesellschaft – kaum eine Bestands-App ist heute CRA-ready, und bis zu den Fristen ist jedes davon lösbar. Entscheidend ist, jetzt zu wissen, welche Lücken kritisch sind und welche warten können: Genau das klärt der CRA-Readiness-Check in 2–3 Tagen, zum Festpreis, mit priorisiertem Maßnahmenkatalog.
Aus Neins ein Backlog machen: Zum Readiness-CheckCRA im Detail: Leitfäden für jede Pflicht
Frist im Nacken, Audit vor der Brust oder einfach Grundlagen klären? Je nach Situation ist ein anderer Einstieg der richtige – jede Seite beantwortet eine Pflicht bis zur Umsetzung:
CRA-Anforderungen an Apps
Anhang I auf App-Realität gemappt: jede Anforderung mit typischem Ist-Zustand und konkretem To-do.
Anforderungen ansehenMeldepflichten ab September 2026
24-h-Frühwarnung, 72-h-Meldung, Abschlussbericht – und was ihr organisatorisch wie technisch dafür braucht.
Zu den MeldepflichtenUpdate-Pflicht & App-Wartung
Mindestens 5 Jahre kostenlose Sicherheitsupdates: was das heißt – und wer eure App eigentlich wartet.
Zur Update-PflichtSBOM für Mobile Apps
CycloneDX & SPDX für Flutter, KMP und native Apps – alle Abhängigkeitsebenen, Tooling, CI-Integration.
Zur SBOM-AnleitungCRA vs. RED vs. NIS2 vs. BFSG
Vier Regelwerke, eine Tabelle: welche Pflichten euer Produkt, euer Unternehmen und eure App treffen.
Abgrenzung ansehenCRA-Checkliste für Hersteller
20 Punkte entlang des Produktlebenszyklus – als PDF zum Abhaken fürs nächste Produkt-Meeting.
Checkliste holenCRA-Readiness-Check für Hersteller
Das Festpreis-Audit: In 2–3 Tagen kennt ihr eure Lücken – als Backlog, priorisiert nach Frist und Risiko.
Readiness-Check anfragenSo werdet ihr CRA-konform: von der Bestandsaufnahme bis zum Betrieb
Ein PDF patcht keine App. Konform wird euer Produkt erst, wenn SBOM, Update-Fähigkeit und Meldeprozesse wirklich laufen – im Code und in der Pipeline. So gehen wir vor:
Readiness-Check
Bestandsaufnahme auf Lesezugriff: Code-Review der sicherheitsrelevanten Pfade, Manifest- und Konfigurationsanalyse, SBOM-Erzeugung. Am Ende steht ein Befund mit priorisiertem Maßnahmenkatalog – ohne Eingriffe in euren laufenden Betrieb.
SBOM in der CI
Die Stückliste eurer App – die SBOM – entsteht als automatischer Pipeline-Schritt statt als Jahresprojekt: erzeugt je Ökosystem, zusammengeführt pro Release und laufend gegen CVE-Datenbanken abgeglichen.
Update-Fähigkeit & Meldeprozess
Damit aus einer Schwachstelle ein Patch wird: eine Release-Pipeline, die ein Sicherheitsupdate in Tagen statt Monaten in beide Stores bringt – plus den Prozess für die Meldepflichten ab September 2026 mit 24-Stunden-Frühwarnung.
Betrieb über den Supportzeitraum
Der CRA verlangt Sicherheitsupdates über den gesamten Supportzeitraum eures Produkts. Wir betreuen eure App mit Wartungsvertrag und Patch-SLA – damit die Update-Pflicht nicht mit dem Projektende endet.
Warum wir der richtige Partner für eure CRA-Umsetzung sind
Der CRA-Markt ist voller Checklisten, Gutachten und Zertifikats-Versprechen. Das Problem: Ein PDF patcht keine App. Konform wird euer Produkt erst, wenn SBOM, Update-Fähigkeit und Meldeprozesse wirklich laufen – im Code und in der Pipeline. Genau dort arbeiten wir.
Wir beheben, was wir finden
Die Gap-Analyse ist bei uns der Anfang, nicht das Ergebnis: SBOM in der CI, Update-Fähigkeit, Security-Logging und Meldeprozesse setzen dieselben Entwickler um, die den Befund erhoben haben – statt ein Gutachten zu übergeben und zu gehen.
Zum CRA-Readiness-Check →Seniors statt Junior-Staffing
Ein Senior-Entwickler verantwortet Prüfung und Umsetzung durchgehend – fremde Codebasen lesen und Risiken bewerten gehört zu den schwersten Aufgaben der App-Entwicklung, nicht zu den Anlernaufgaben.
Das Team kennenlernen →Technik von uns, Recht von eurer Kanzlei
Wir versprechen keine Rechtssicherheit per Generator: Die Konformitätsbewertung bleibt bei euch und eurer Regulatory-Beratung – wir liefern die belastbare technische Grundlage dafür.
Häufige Fragen zum Cyber Resilience Act (FAQ)
Kurze Antworten auf die Fragen, die uns Hersteller und App-Anbieter am häufigsten stellen. Für die Tiefe verlinken die Antworten auf die jeweiligen Leitfäden – und für den Einzelfall gilt wie immer: keine Rechtsberatung.
Der 11.09.2026 rückt näher – wisst ihr schon, was bis dahin stehen muss?
Sprich direkt mit James & Joanna – ohne Vertrieb, ohne Umwege.
25+
Jahre Erfahrung
40+
Anwendungen
10+
Top-DACH-Firmen vertrauen
MVP
~6 Wochen
Buche eine 15-minütige Erstberatung – kostenlos & unverbindlich.
CRA-Umsetzung für eure App anfragen – vom Readiness-Check bis zur Wartung
Schilder uns kurz euer Produkt und eure App – zwei, drei Sätze reichen. Du bekommst werktags innerhalb von 24 Stunden eine ehrliche Ersteinschätzung: ob der CRA euch betrifft, welche Fristen für euch zählen und was die nächsten Schritte wären. Unverbindlich, in klarer Sprache und ohne Verkaufsdruck.
Deine Daten werden ausschließlich zur Kontaktaufnahme verwendet. Keine Weitergabe an Dritte.
