CRA Secure by Default: Sichere Grundeinstellungen richtig umsetzen

Secure by Default bedeutet im Cyber Resilience Act, dass ein Produkt bereits in seiner ausgelieferten Grundeinstellung ein angemessenes Sicherheitsniveau bietet. Nutzer sollen nicht erst versteckte Optionen finden oder umfangreiche Hardening-Anleitungen durcharbeiten müssen, damit das Produkt vernünftig geschützt ist.

Einordnung im CRA-Wissen: Dieser Fachartikel gehört zum Themenbereich Technische Produktsicherheit. Dort finden Sie die angrenzenden Anforderungen und eine praktische Reihenfolge für die Umsetzung.

Sichere Voreinstellungen umfassen je nach Produkt auch die Auswahl geeigneter kryptografischer Verfahren und Schlüssel. Ihre Wirksamkeit muss für die tatsächlich ausgelieferte Konfiguration geprüft werden.

Was verlangt der CRA bei Secure by Default?

Anhang I Teil I verlangt, dass Produkte mit digitalen Elementen auf Grundlage der Risikobewertung mit einer sicheren Standardkonfiguration auf den Markt kommen. Zusätzlich muss die Möglichkeit bestehen, das Produkt auf seinen ursprünglichen Zustand zurückzusetzen. Für kundenspezifische B2B-Produkte kann im Einzelfall eine andere Konfiguration mit dem Geschäftskunden vereinbart werden.

Die Vorgabe ist Teil der umfassenden CRA-Herstellerpflichten. Sie soll verhindern, dass ein Produkt zwar sichere Funktionen besitzt, aber standardmäßig mit riskanten Einstellungen ausgeliefert wird.

Was ist eine sichere Standardkonfiguration?

Eine sichere Standardkonfiguration ist die Kombination von Einstellungen, mit der das Produkt ohne zusätzliche Sicherheitsarbeit des Nutzers in einem angemessenen Schutzmodus startet. Welche Einstellungen dazugehören, hängt von Produkt, Zweckbestimmung, Betriebsumgebung und Cybersicherheitsrisikobewertung ab.

Bei einer Webanwendung kann das beispielsweise bedeuten: sichere Session-Cookies, minimale Rollenrechte, deaktivierte Debug-Ausgabe und erzwungene verschlüsselte Verbindungen. Bei einem Netzwerkgerät können geschlossene Managementports, individuelle Zugangsdaten und deaktivierte unsichere Protokolle entscheidend sein.

Dürfen Produkte noch Standardpasswörter verwenden?

Universelle, öffentlich bekannte Standardpasswörter sind in einem risikobasierten Secure-by-Default-Konzept kaum vertretbar. Besser sind individuelle Zugangsdaten, sichere Ersteinrichtung oder die Pflicht, bei der ersten Inbetriebnahme ein eigenes starkes Passwort beziehungsweise einen anderen Authentisierungsfaktor festzulegen.

Entscheidend ist der Angriffspfad. Ein lokal erreichbares Wartungskonto kann ebenfalls relevant sein, wenn Angreifer vernünftigerweise Zugriff erhalten können. Hersteller sollten deshalb alle Konten, Tokens, Schlüssel und Servicezugänge betrachten – nicht nur das sichtbare Administratorpasswort.

Was bedeutet Least Privilege in der Grundeinstellung?

Nutzer, Prozesse und Dienste sollten standardmäßig nur die Berechtigungen besitzen, die sie für ihre Aufgabe benötigen. Administratorrechte dürfen nicht aus Bequemlichkeit an jede normale Funktion vergeben werden. Ebenso sollte ein Hintergrunddienst nicht auf Daten oder Systembereiche zugreifen können, die für seine Funktion irrelevant sind.

Least Privilege reduziert die Auswirkungen eines kompromittierten Kontos oder Prozesses. Es unterstützt damit auch die CRA-Anforderung, Auswirkungen von Sicherheitsvorfällen durch geeignete Exploit-Mitigation zu begrenzen.

Welche Schnittstellen sollten standardmäßig deaktiviert sein?

Alles, was für die vorgesehene Nutzung nicht benötigt wird, sollte kritisch hinterfragt werden. Dazu gehören Entwicklungs- und Debugschnittstellen, unsichere Altprotokolle, Fernwartungsfunktionen, Testkonten, Beispiel-APIs oder Ports, die nur in speziellen Szenarien benötigt werden.

Das folgt zugleich der Anforderung, Angriffsflächen zu begrenzen. Wenn eine optionale Funktion aktiviert werden kann, sollte der Nutzer erkennen, welche Sicherheitsfolgen entstehen und welche zusätzlichen Schutzmaßnahmen notwendig sind.

Müssen automatische Sicherheitsupdates standardmäßig aktiviert sein?

Der CRA sieht vor, dass Sicherheitsupdates – soweit anwendbar – innerhalb eines angemessenen Zeitraums automatisch installiert werden können und diese Funktion standardmäßig aktiviert ist. Gleichzeitig muss es einen klaren und einfach nutzbaren Opt-out-Mechanismus und die Möglichkeit geben, Updates vorübergehend aufzuschieben.

Das bedeutet nicht, dass jedes industrielle System ungeprüft neu starten muss. Die konkrete Ausgestaltung muss zum Risiko und Einsatzzweck passen. Der Beitrag CRA-Sicherheitsupdates behandelt automatische Updates, Rollout und sichere Verteilung ausführlich.

Wie weit darf ein Nutzer sichere Einstellungen abschalten?

Der CRA verbietet nicht jede riskantere Benutzerentscheidung. Ein Nutzer kann bestimmte Funktionen bewusst deaktivieren oder verändern, wenn das Produkt dies vorsieht. Hersteller müssen aber sicherstellen, dass die Ausgangskonfiguration sicher ist und Auswirkungen nachvollziehbar kommuniziert werden.

Bei besonders kritischen Einstellungen können Warnungen, zusätzliche Bestätigungen oder Beschränkungen sinnvoll sein. Ein Produkt sollte nicht dazu verleiten, Sicherheitsmechanismen für Komfort auszuschalten, ohne die Konsequenzen sichtbar zu machen.

Was gilt bei kundenspezifischen B2B-Produkten?

Anhang I erlaubt eine Abweichung von der sicheren Standardkonfiguration, wenn Hersteller und Geschäftsnutzer dies bei einem kundenspezifischen Produkt vereinbaren. Diese Ausnahme ist kein allgemeiner Freibrief für unsichere Enterprise-Defaults.

Die Vereinbarung sollte produkt- und risikobezogen dokumentiert sein. Sinnvoll ist festzuhalten, welche Einstellung abweicht, warum der Geschäftskunde sie benötigt, welche Risiken entstehen und welche kompensierenden Maßnahmen vorgesehen sind. Dadurch bleibt die Entscheidung später nachvollziehbar.

Was bedeutet die Pflicht zum Zurücksetzen auf den ursprünglichen Zustand?

Ein Produkt soll grundsätzlich auf seinen ursprünglichen Zustand zurückgesetzt werden können. Die Reset-Funktion muss allerdings selbst sicher gestaltet sein. Ein Factory Reset darf beispielsweise nicht dazu führen, dass ein Gerät anschließend mit öffentlich bekannten Zugangsdaten oder einer unsicheren alten Softwareversion startet.

Hersteller sollten deshalb unterscheiden zwischen Konfigurationsreset, sicherer Datenlöschung und Software-Recovery. Je nach Produkt können diese Funktionen technisch getrennt sein, müssen aber für den Nutzer verständlich dokumentiert werden.

Wie behandelt man Cloud- und SaaS-nahe Funktionen?

Bei Produkten, die für ihre Funktion auf Remote-Datenverarbeitung angewiesen sind, gehören auch Cloud-Konfigurationen zum Sicherheitsmodell. Standardmäßig offene Freigaben, überbreite API-Berechtigungen oder ungeschützte Servicekonten können die Sicherheit des Produkts direkt beeinflussen.

Ob und wann Remote-Datenverarbeitung Teil des Produkts ist, erläutert der geplante Artikel CRA Remote-Datenverarbeitung. Für Secure by Default ist entscheidend, dass lokale und entfernte Komponenten zusammen betrachtet werden.

Welche Rolle spielt Datenminimierung?

Anhang I verlangt, dass nur Daten verarbeitet werden, die für den vorgesehenen Zweck angemessen, relevant und notwendig sind. Secure by Default sollte deshalb Datenerhebung, Telemetrie, Diagnoseinformationen und Aufbewahrungszeiten auf das notwendige Maß begrenzen.

Ein Produkt, das aus Komfort alle verfügbaren Daten sammelt und erst später Datenschutzoptionen anbietet, setzt keine starke sichere Grundeinstellung um. Besonders Telemetrie sollte transparent, zweckbezogen und im Einklang mit den übrigen rechtlichen Anforderungen konzipiert werden.

Wie sollten Logging-Einstellungen standardmäßig aussehen?

Der CRA verlangt sicherheitsrelevante Informationen durch Aufzeichnung und Überwachung relevanter interner Aktivitäten, einschließlich Zugriffen oder Änderungen an Daten, Diensten und Funktionen. Gleichzeitig muss ein Opt-out-Mechanismus für den Nutzer vorgesehen sein.

Die Grundeinstellung sollte genug Information liefern, um relevante Sicherheitsereignisse zu erkennen, ohne unnötig sensible Inhalte zu protokollieren. Der Artikel CRA Logging & Monitoring vertieft Aufbewahrung, Ereignisauswahl und Datenschutz.

Wie prüft man sichere Defaults systematisch?

Eine Default-Konfigurationsprüfung sollte Teil jedes Releases sein. Sie testet einen frischen Installations- oder Auslieferungszustand, nicht die gehärtete Umgebung eines Entwicklers. Dabei werden Konten, Dienste, Ports, Berechtigungen, Updateverhalten, Telemetrie, Verschlüsselung und Logging erfasst.

Warum reicht eine Hardening-Anleitung nicht?

Eine Anleitung kann zusätzliche Schutzmaßnahmen beschreiben, ersetzt aber keine sichere Ausgangskonfiguration. Wenn jeder Nutzer erst zwanzig Schritte durchführen muss, damit ein Produkt ein angemessenes Sicherheitsniveau erreicht, wird der Zweck von Secure by Default verfehlt.

Hersteller sollten deshalb die häufigsten sicheren Entscheidungen bereits vorkonfigurieren. Hardening-Guides sind für besondere Risikoumgebungen und weitergehende Schutzbedürfnisse sinnvoll.

Wie dokumentiert man Secure by Default?

Die technische Dokumentation sollte zeigen, welche Standardkonfiguration vorgesehen ist, welche Sicherheitsziele damit erfüllt werden und wie Abweichungen behandelt werden. Hilfreich sind Konfigurationsbaseline, Testnachweise, Screenshots oder automatisierte Konfigurationsreports sowie die Verbindung zur Risikobewertung.

Bei optionalen unsicheren Einstellungen sollte nachvollziehbar sein, warum sie angeboten werden und welche Warnungen oder kompensierenden Kontrollen existieren. Bei B2B-Sondervereinbarungen gehört auch die dokumentierte Abweichung in den Prozess.

Welche typischen Fehler treten auf?

• Adminoberflächen sind ohne Not im gesamten Netzwerk erreichbar.
• Alle Nutzer erhalten zunächst Administratorrechte.
• Debugmodus oder ausführliche Fehlermeldungen bleiben aktiv.
• Unsichere Altprotokolle sind aus Kompatibilitätsgründen standardmäßig eingeschaltet.
• Automatische Security Updates sind vorhanden, aber standardmäßig deaktiviert.
• Factory Reset stellt unsichere Zugangsdaten wieder her.
• Telemetrie und Datensammlung sind umfangreicher als für den Zweck erforderlich.

Wie können Hersteller bestehende Produkte umstellen?

Bei bestehenden Produktlinien sollte zuerst eine Baseline des aktuellen Auslieferungszustands erstellt werden. Anschließend werden Einstellungen nach Risiko priorisiert: öffentlich erreichbare Dienste, Standardzugänge, administrative Rechte und Updatefunktionen zuerst, Komfortoptionen später.

Änderungen an Defaults können bestehende Kundenprozesse beeinflussen. Deshalb braucht es Migrationshinweise und Tests. Bei tiefgreifenden Änderungen ist zusätzlich zu prüfen, ob Auswirkungen auf die Konformitätsbewertung oder die Zweckbestimmung entstehen.

Wie verhindert man, dass Updates sichere Defaults wieder verschlechtern?

Default-Konfigurationen sollten wie Code versioniert und getestet werden. Ein neues Feature darf nicht unbemerkt eine zusätzliche Schnittstelle öffnen oder eine Berechtigung erweitern. Automatisierte Konfigurationstests können bekannte Baselines vergleichen und Abweichungen anzeigen.

Besonders relevant sind Migrationspfade: Ein Update darf eine vom Nutzer bewusst gehärtete Einstellung nicht ohne Grund zurücksetzen. Umgekehrt muss der Hersteller überlegen, ob kritische neue Sicherheitsdefaults auch für bestehende Installationen aktiviert werden müssen.

Was gilt für Installateure und Integratoren?

Bei Produkten, die in größere Systeme integriert werden, sollten Hersteller dokumentieren, welche sicheren Grundeinstellungen erwartet werden und welche Änderungen der Integrator verantwortet. Notwendige Integrationsinformationen gehören nach CRA in die Nutzer- und Produktinformationen.

Ein Hersteller sollte vermeiden, dass sein Produkt nur in einer internen Testkonfiguration sicher ist. Typische reale Integrationsszenarien gehören bereits in die Secure-by-Design-Betrachtung.

Wie sollten sichere Defaults bei mehreren Produktvarianten verwaltet werden?

Viele Hersteller liefern dasselbe Produkt in unterschiedlichen Editionen, Regionen oder Hardwarevarianten aus. Sichere Grundeinstellungen sollten deshalb nicht als manuell gepflegte Einzelliste existieren, sondern als versionierte Baseline pro Produktfamilie. Jede Abweichung braucht einen nachvollziehbaren Grund und sollte im Releaseprozess sichtbar sein.

Besonders kritisch sind kundenspezifische Konfigurationen. Wenn Vertrieb oder Projektteam vor Auslieferung Einstellungen verändern, muss klar bleiben, welche Werte die sichere Baseline verlassen und wer diese Abweichung freigibt. Sonst entsteht zwischen Entwicklung und tatsächlicher Auslieferung eine Sicherheitslücke.

Wie kann ein sicherer Einrichtungsassistent helfen?

Ein Onboarding- oder Setup-Assistent kann sichere Defaults mit notwendigen Nutzerentscheidungen verbinden. Er kann beispielsweise individuelle Zugangsdaten erzwingen, Netzwerkfreigaben erklären, automatische Sicherheitsupdates voreingestellt lassen und risikoreiche Optionen nur nach bewusster Bestätigung aktivieren.

Der Assistent sollte nicht versuchen, Nutzer zu möglichst vielen Freigaben zu bewegen. Gute Secure-by-Default-UX macht den sicheren Weg zum einfachsten Weg und kennzeichnet Abweichungen verständlich.

Was passiert mit sicheren Grundeinstellungen während des Supports?

Neue Schwachstellen können zeigen, dass eine bisher vertretbare Grundeinstellung nicht mehr angemessen ist. Hersteller sollten deshalb während des Supportzeitraums prüfen, ob Defaults angepasst werden müssen. Ein Security Update kann beispielsweise ein altes Protokoll deaktivieren, eine neue Authentisierungsanforderung einführen oder die Mindestschlüssellänge erhöhen.

Solche Änderungen brauchen Kompatibilitätstests und klare Nutzerinformation. Bei Geschäftskunden sollte außerdem berücksichtigt werden, ob automatisierte Prozesse betroffen sind. Sicherheit darf nicht aus Angst vor jeder Verhaltensänderung dauerhaft auf einem veralteten Stand eingefroren werden.

Wie sollte eine Default-Baseline freigegeben werden?

Vor einem Release sollte eine definierte Person oder Rolle bestätigen, dass die ausgelieferte Baseline mit Risikobewertung und Security-Anforderungen übereinstimmt. Der Nachweis kann aus einer automatisierten Konfigurationsliste, einem Testreport und dokumentierten Ausnahmen bestehen.

Damit lässt sich später genau zeigen, welche Einstellungen ein Kunde beim erstmaligen Start erhalten hat. Das ist besonders hilfreich, wenn Supportfälle oder Sicherheitsvorfälle Jahre nach dem ursprünglichen Release untersucht werden.

Wie sollte man Abweichungen von der sicheren Baseline behandeln?

Jede dauerhafte Abweichung sollte einen dokumentierten Grund, einen Verantwortlichen und – soweit nötig – kompensierende Maßnahmen erhalten. Besonders bei Geschäftskunden ist wichtig, dass eine gewünschte Sonderkonfiguration nicht stillschweigend zum neuen Standard für andere Kunden wird.

Ein regelmäßiger Vergleich zwischen ausgelieferter Konfiguration und freigegebener Baseline zeigt zudem, ob Vertrieb, Installation oder Support Einstellungen verändern, die ursprünglich aus Sicherheitsgründen bewusst gewählt wurden.

Wo steht Secure by Default im CRA?

Die ausdrückliche Anforderung findet sich in Anhang I Teil I Nummer 2 Buchstabe b der Verordnung (EU) 2024/2847. Weitere Default-relevante Anforderungen betreffen automatische Sicherheitsupdates, Zugriffsschutz, Datenminimierung, Logging und sichere Datenlöschung.