CRA-Update-Pflicht: Mindestens 5 Jahre Sicherheitsupdates für eure App
Der Supportzeitraum eurer Hardware ist eingeplant. Der eurer App auch?
Der Cyber Resilience Act verpflichtet euch, Schwachstellen über den gesamten Supportzeitraum eures Produkts zu beheben und Sicherheitsupdates kostenlos bereitzustellen – der Zeitraum richtet sich nach der erwarteten Nutzungsdauer, in der Regel mindestens 5 Jahre. Das gilt für vernetzte Geräte samt Companion App genauso wie für Standalone-Apps. Hier steht, was „Sicherheitsupdate“ für eine App wirklich bedeutet, woran Update-Fähigkeit in der Praxis scheitert – und wie ihr sie dauerhaft sicherstellt.
Was die Update-Pflicht nach CRA verlangt
Wie lange, was es kosten darf – und wer es bei euch tut: drei Eckwerte, und am dritten scheitert es in der Praxis am häufigsten:
Supportzeitraum
≥ 5 Jahre
Sicherheitsupdates über die erwartete Nutzungsdauer des Produkts – bei Maschinen und Energie-Hardware oft deutlich länger.
Kosten für Nutzer
0 €
Kostenlos und unverzüglich – ein Abo für Pflicht-Patches ist mit dem CRA nicht vereinbar.
Der blinde Fleck
Die App
Die Firmware-Wartung ist meist geregelt. Die App hängt an einer einzelnen Person, einem Freelancer – oder an niemandem mehr. Hier reißt die Update-Fähigkeit zuerst.
Und die Pflicht verlangt keinen einmaligen Zustand, sondern eine dauerhafte Fähigkeit: jederzeit in wenigen Tagen einen Sicherheitspatch bauen, testen und in die Stores bringen. Wie wir das als Wartungsvertrag übernehmen →
Warum eine App auch ohne eigene Fehler altert
„Unsere App läuft doch" – der Satz klingt beruhigend. Aber angenommen, ihr ändert zwölf Monate lang keine Zeile Code. Das passiert trotzdem:
Laufend
Eine Bibliothek meldet eine CVE
Jede Abhängigkeit in eurer App kann morgen betroffen sein – ohne SBOM und Monitoring erfahrt ihr davon aus der Presse. Oder von der Marktüberwachung.
September
Das neue iOS ändert die Regeln
Geänderte Berechtigungen, Bluetooth-Verhalten, Hintergrund-Restriktionen – bricht regelmäßig genau die kritischen Geräte-Pfade.
Oktober
Android zieht nach
Neues Major-Release, gleiche Geschichte – zwei Plattformen, zwei Baustellen.
August · Frist
Google hebt die Target-SDK-Anforderung an
Wer nicht mitzieht, fliegt aus dem Store – und ein Produkt, dessen Pflicht-App nicht installierbar ist, ist faktisch defekt.
CRA-konforme Wartung ist deshalb keine Reaktion, sondern ein Betrieb: beobachten, bewerten, patchen, releasen – über Jahre.
Verwaiste Apps: das unterschätzte Compliance-Risiko
Gebaut von einem Freelancer, der nicht mehr erreichbar ist, oder einer Agentur, die es nicht mehr gibt: Ab Dezember 2027 ist das kein Ärgernis mehr, sondern ein Haftungsthema – denn wenn niemand eure App bauen kann, bleibt die Pflicht trotzdem bei euch. Prüft deshalb zuerst, ob euch diese vier Dinge gehören – vertraglich und faktisch:
01
Der aktuelle Quellcode
Der Stand, der wirklich im Store läuft – nicht ein Export von vor zwei Jahren auf irgendeinem Laptop.
02
Beide Store-Konten
Apple und Google – als Eigentümer, nicht als eingeladener Gast der alten Agentur.
03
Die Signing-Keys
Keys bzw. Zertifikate – ohne sie kann niemand ein Update unter der Identität eurer App ausliefern.
04
Eine reproduzierbare Build-Umgebung
Dokumentiert und nachvollziehbar – „es baut nur auf einem bestimmten Rechner“ zählt nicht.
Fehlt eines davon, ist eure Update-Fähigkeit eine Hoffnung, keine Fähigkeit. Die Reihenfolge dann: erst stabilisieren und bauen können, dann härten, dann modernisieren.
CRA-konformer Wartungsvertrag: Update-Fähigkeit als Dauerzustand
Wir betreiben eure App so, wie der CRA es verlangt – planbar im festen Monatspaket statt Feuerwehr-Einsätzen:
Überwachen
Dependency- & CVE-Monitoring
SBOM-basierter Abgleich gegen Schwachstellen-Feeds, Bewertung der Relevanz und dokumentierte Entscheidung pro Fund – denn nicht jede CVE in einer Bibliothek betrifft eure App.
Meldefähigkeit
Technische Zuarbeit für eure CRA-Meldeprozesse – Ereignis-Logging, Impact-Analyse, Formulierungshilfe für die technische Beschreibung.
Reagieren
mit SLASicherheitspatches
Vertraglich zugesagte Reaktions- und Release-Zeiten – werktags, nach Schweregrad gestaffelt – inklusive Store-Einreichung und beschleunigtem Review, wo möglich.
OS- & Store-Readiness
Jährliche Anpassung an neue iOS-/Android-Versionen und Target-SDK-Anforderungen, Tests auf realen Geräten – bei Geräte-Apps mit eurer Hardware.
Nachweisen
Release-Fähigkeit als Zustand
Gepflegte CI/CD-Pipeline, verwaltete Signing-Keys, jederzeit reproduzierbare Builds – dokumentiert, sodass ihr nie von einer einzelnen Person abhängt. Auch nicht von uns.
Quartalsbericht
Versionsstände im Feld, behobene Schwachstellen, anstehende Risiken – als Baustein für eure technische Dokumentation nach CRA.
Der Umfang richtet sich nach App-Größe und Kritikalität – typisch sind feste Monatspakete mit definiertem Kontingent plus SLA, transparent kalkuliert nach einem kurzen Blick in euer Repository. Zur Einordnung: ein Bruchteil dessen, was eine einzelne Notfall-Sanierung unter Fristendruck kostet.
Bei vernetzten Produkten gehört auch der Update-Kanal selbst dazu – wie wir den bauen, steht unter OTA-Firmware-Updates.
Häufige Fragen zur CRA-Update-Pflicht
Kurze Antworten zu Supportzeitraum, Kosten und Wartung – für den Einzelfall gilt wie immer: keine Rechtsberatung.
Wer patcht eure App, wenn morgen eine kritische CVE kommt – und ist das vertraglich gesichert?
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-konforme App-Wartung anfragen – mit Patch-SLA
Schilder uns kurz eure App und wer sie heute wartet – zwei, drei Sätze reichen. Du bekommst werktags innerhalb von 24 Stunden eine ehrliche Ersteinschätzung: wie es um eure Update-Fähigkeit steht und was ein Wartungsvertrag bei euch kosten würde. Unverbindlich, in klarer Sprache, ohne Verkaufsdruck.
Deine Daten werden ausschließlich zur Kontaktaufnahme verwendet. Keine Weitergabe an Dritte.
