CRA-Anforderungen an Apps: Anhang I Punkt für Punkt übersetzt

Die 8 Anforderungen aus Anhang I – übersetzt auf eure App

So lest ihr die Karten: die Pflicht in Klartext, daneben der typische Ist-Zustand (ehrlich, nicht schmeichelhaft) und das To-do. Zählt mit, wie oft ihr euch im Ist-Zustand wiedererkennt.

1. 01

   Sichere Standardkonfiguration (Secure by Default)

   Anforderung

   Das Produkt wird mit sicheren Voreinstellungen ausgeliefert – Sicherheit ist der Auslieferungszustand, nicht die Option.

   Typischer Ist-Zustand

   • Standard-PINs wie „0000“ beim Pairing
   • Offene Provisioning-Fenster ohne Ablauf
   • „Passwort später festlegen" wird nie erzwungen
   • Datenintensive Features per Opt-out

   To-do

   • Erzwungene Erstkonfiguration im Onboarding: individuelles Passwort, Pairing-Bestätigung
   • Zeitlich begrenzte Einrichtungs-Fenster
   • Opt-in statt Opt-out

   Ein UX-Thema – Security gehört ins Onboarding-Design, nicht ins Audit danach.

2. 02

   Schutz vor unbefugtem Zugriff

   Anforderung

   Zugriff nur nach Authentifizierung; sauberes Identitäts- und Rechtemanagement über den Lebenszyklus.

   Typischer Ist-Zustand

   • Auth-Tokens ohne Ablauf im Klartext in SharedPreferences/UserDefaults
   • BLE-Kommandos ohne Bonding für jeden erreichbar
   • Kein Token-Widerruf beim Geräteverkauf

   To-do

   • Tokens in Keystore/Keychain, kurze Lebensdauer plus Refresh
   • Zugriff erst nach Bonding und App-Layer-Auth
   • Sauberer Ownership-Transfer – der im IoT chronisch vergessene Flow

   Bonding und Ownership-Transfer betreffen nur Apps mit Gerät.

3. 03

   Vertraulichkeit: Verschlüsselung in Transit und at Rest

   Anforderung

   Schutz gespeicherter, übertragener und verarbeiteter Daten nach Stand der Technik.

   Typischer Ist-Zustand

   • TLS zur Cloud ja – aber Klartext-Protokoll zwischen App und Gerät im lokalen Netz
   • Sensible Daten unverschlüsselt in der lokalen Datenbank
   • Kein Pinning bei kritischen Endpoints

   To-do

   • Verschlüsselung auch auf der letzten Meile: LE Secure Connections, TLS/DTLS im LAN
   • Verschlüsselte lokale Persistenz für sensible Daten
   • Certificate Pinning dort, wo Firmware oder Kommandos fließen
4. 04

   Integrität und Datenminimierung

   Anforderung

   Schutz vor Manipulation; verarbeitet werden nur Daten, die für den Zweck erforderlich sind.

   Typischer Ist-Zustand

   • Firmware-Blobs werden ungeprüft ans Gerät durchgereicht
   • Analytics-SDKs sammeln Geräte-IDs, Standort und Netzwerkinfos – „weil das SDK das halt macht"

   To-do

   • Signaturprüfung in der Update-Kette: App prüft, Gerät prüft nochmal
   • Checksummen für Konfigurationsdaten
   • Audit aller Dritt-SDKs: Welche Daten fließen wozu? Raus damit ohne Produktzweck

   Die Datenminimierung zahlt gleichzeitig auf die DSGVO ein.

5. 05

   Minimierung der Angriffsfläche

   Anforderung

   Angriffsflächen so klein wie möglich, keine unnötigen Schnittstellen.

   Typischer Ist-Zustand

   • Debug-Endpoints und Staging-URLs im Release-Build
   • Exportierte Android-Komponenten ohne Permission
   • Logging inklusive Tokens
   • Ungehärtete WebViews, vergessene Deeplink-Handler

   To-do

   • Build-Varianten strikt trennen – Debug-Code darf im Release nicht existieren
   • Manifest-/Info.plist-Review
   • Log-Hygiene und WebView-Härtung

   Der Bereich mit den schnellsten Wins – vieles ist in Tagen behoben.

6. 06

   Sicherer Update-Mechanismus

   Anforderung

   Sicherheitsupdates müssen möglich, standardmäßig automatisch und kostenlos sein – für das Gesamtprodukt inklusive App.

   Typischer Ist-Zustand

   • App-Updates laufen über die Stores – so weit gut
   • Firmware kommt unsigniert von einem vergessenen S3-Bucket, ohne Rollback
   • Niemand weiß, welche Versionen im Feld laufen

   To-do

   • Signierte, versionierte Update-Kette mit der App als kontrolliertem Kanal
   • Gestaffelte Rollouts mit Rollback-Pfad
   • Feld-Telemetrie über Versionsstände

   Die organisatorische Seite – Supportzeitraum, Wartungsvertrag – steht unter Update-Pflicht & Wartung.

7. 07

   Security-Logging und Monitoring

   Anforderung

   Sicherheitsrelevante Ereignisse aufzeichnen und überwachen können – mit Opt-out für Nutzer.

   Typischer Ist-Zustand

   • Crash-Reporting ist da – einen Angriff würde aber niemand bemerken
   • Fehlgeschlagene Auth-Versuche, anomale Update-Aktivität und manipulierte Uploads tauchen nirgends auf

   To-do

   • Definieren, was ein sicherheitsrelevantes Ereignis in eurem Produkt ist
   • Strukturiert erfassen – ohne Datensammelei
   • Alarme daran hängen

   Ohne Erkennung sind die Meldepflichten ab 09/2026 praktisch unerfüllbar – man meldet nur, was man bemerkt.

8. 08

   Drittanbieter-Komponenten im Griff

   Anforderung

   Sorgfaltspflicht bei der Integration von Komponenten Dritter; Schwachstellen darin müssen behandelt werden.

   Typischer Ist-Zustand

   • 40–120 direkte und transitive Abhängigkeiten plus binäre Vendor-SDKs, deren Version niemand kennt
   • Kein Prozess, der bei einer neuen CVE anschlägt

   To-do

   • SBOM erzeugen und in der CI aktuell halten
   • Gegen CVE-Feeds abgleichen (z. B. Dependency-Track)
   • Support-Zusagen der SDK-Lieferanten einfordern

   Der CRA verpflichtet auch eure Zulieferkette zur Kooperation.

Die gute Nachricht: Nichts in Anhang I verlangt Forschung – sondern solides Handwerk und funktionierende Prozesse: saubere Defaults, gepflegte Abhängigkeiten, eine belastbare Update-Kette, Logging mit Augenmaß. Vieles davon lässt sich schrittweise mit der normalen Weiterentwicklung eurer App umsetzen – und gerade bei Angriffsfläche und Drittanbieter-Komponenten sind die ersten Fortschritte oft schnell erreicht.

Die Werkzeuge zu den größten Blöcken im Detail: SBOM für Mobile Apps, Update-Pflicht & Wartung und Meldepflichten ab 09/2026.