Security by Design im CRA: Anforderungen in geprüfte Ergebnisse überführen

„Security by Design“ ist kein Richtliniendokument zum Unterschreiben. Bei einem Produkt mit digitalen Elementen sollte es über den gesamten Produktlebenszyklus in Designentscheidungen, verringerter Angriffsfläche, sicheren Voreinstellungen, Updatebehandlung, Tests und Schwachstellenmanagement sichtbar sein.

Ein praktisches Modell ist einfach: Risiko → Anforderung → Designentscheidung → Maßnahme → Test → Ergebnis → Nachweis → Prüfung.

Überführen Sie wesentliche Anforderungen in Produktarbeit

Anhang I des CRA enthält wesentliche Cybersicherheitsanforderungen. In der praktischen Produktarbeit müssen Teams unter anderem folgende Bereiche bearbeiten:

• Gestaltung des Produkts mit einem dem Risiko angemessenen Cybersicherheitsniveau;
• Schutz vor unbefugtem Zugriff;
• Vertraulichkeit, Integrität und Verfügbarkeit von Daten und Funktionen;
• Verringerung der Angriffsfläche;
• Mechanismen zur Begrenzung der Auswirkungen eines Vorfalls;
• Aufzeichnung und Überwachung relevanter sicherheitsbezogener Aktivitäten;
• sichere Entfernung von Daten und Einstellungen;
• sichere Updateverteilung;
• regelmäßige Sicherheitstests und Prüfungen;
• koordinierte Offenlegung von Schwachstellen.

Eine Checkliste ist ein Ausgangspunkt. Sie ist kein Nachweis der Umsetzung.

Beispiel: „vor unbefugtem Zugriff schützen“

Eine schwache Aufzeichnung lautet:

„Das System hat eine Authentifizierung.“

Eine operative Aufzeichnung kann zeigen:

1. Risiko: Die Kompromittierung eines Administratorkontos könnte eine sicherheitskritische Konfiguration verändern.
2. Entscheidung: Privilegierte Rollen benötigen einen festgelegten Mechanismus zur Authentifizierung und Sitzungskontrolle.
3. Verantwortung: Eine benannte Person oder ein benanntes Team.
4. Umsetzung: Verknüpfung zur Entwicklungsänderung.
5. Test: Szenario zur Überprüfung des erforderlichen Verhaltens.
6. Ergebnis: PASS/FAIL mit Produktfassung und Datum.
7. Nachweis: Bericht, Protokoll, Bildschirmaufnahme oder Testartefakt.
8. Prüfung: Erneute Bewertung nach Änderungen der Authentifizierung oder des Risikoprofils.

Monate später kann die Organisation nicht nur zeigen, was sie tun wollte, sondern was tatsächlich überprüft wurde.

Sichere Voreinstellungen

Die Standardkonfiguration ist wichtig, weil viele Nutzer Sicherheitseinstellungen nach der Bereitstellung nicht ändern. CRA-Anforderungen betreffen unter anderem sichere Konfiguration, Updates und Schutzmechanismen.

Fragen Sie bei jeder sicherheitsrelevanten Funktion:

• Welche Konfiguration erhält ein neuer Nutzer standardmäßig?
• Warum ist diese Voreinstellung für die normale Nutzung angemessen?
• Welche Schutzmaßnahmen können abgeschwächt oder deaktiviert werden?
• Sind riskante Änderungen für den Nutzer verständlich?
• Kann das Produkt in einen sicheren Zustand zurückkehren?
• Welcher Test überprüft das Verhalten nach Installation und Update?

Integrieren Sie Sicherheit in den Release-Prozess statt nach dem Release in die Dokumentation

Eine Release-Prüfung sollte mindestens prüfen:

• ob sich das Bedrohungsmodell oder Risikoprofil geändert hat;
• ob neue Abhängigkeiten eingeführt wurden;
• ob Sicherheitstests die Änderung abdecken;
• ob zu bekannten Schwachstellen dokumentierte Entscheidungen bestehen;
• ob die Sicherheitsinformationen für Nutzer noch zutreffen;
• ob Annahmen und Abhängigkeiten des Unterstützungszeitraums weiterhin realistisch sind;
• ob Nachweise der richtigen Produktfassung beigefügt sind.

Werden diese Fragen erst bei einem Audit gestellt, hat die Organisation einen Dokumentationsprozess statt Security by Design.

ENISA: wiederholbare Maßnahmen statt Slogans

ENISA veröffentlichte am 30. Juli 2026 ihr „Secure by Design and Default Playbook“ für KMU. Das Material konzentriert sich darauf, Grundsätze in wiederholbare Maßnahmen innerhalb bestehender Entwicklungs-, Produkt- und Release-Prozesse umzusetzen. Dasselbe Prinzip funktioniert bei der CRA-Umsetzung: Verwenden Sie den tatsächlichen Bereitstellungsprozess des Teams und machen Sie Zuständigkeit und Nachweise ausdrücklich sichtbar.

Mit dem möglichen Produktschaden beginnen

Der folgende Entwicklungsansatz ist unsere praktische Empfehlung zur Anwendung der wesentlichen Anforderungen. Beginnen Sie mit Zweckbestimmung und vorhersehbaren Bedingungen. Ermitteln Sie anschließend, was ein Angreifer verändern, lesen, unterbrechen oder missbrauchen könnte. Die Folgen unterscheiden sich zwischen vernetztem Sensor, Desktop-Werkzeug und Fernverwaltungskomponente. Eine allgemeine unternehmensweite Bedrohungsliste beschreibt diese Unterschiede nicht ausreichend. Die Risikobewertung muss deshalb den Produktkontext erklären, bevor konkrete Schutzmaßnahmen ausgewählt werden. Andernfalls beantwortet die Maßnahme möglicherweise eine andere Frage als das tatsächliche Risiko.

Bei einem hypothetischen industriellen Überwachungsgerät kann unbefugte Konfiguration die Zuverlässigkeit von Messungen beeinträchtigen. Ein fehlgeschlagenes Update kann ein unterstütztes Produkt verwundbar lassen. Benennen Sie Schnittstellen, Vertrauensgrenzen und beteiligte Komponenten. Fragen Sie, wie ein Angreifer die Funktion erreicht und was unerwünschtes Verhalten verhindert. Das macht die Diskussion konkret. Gleichzeitig werden prüfbedürftige Annahmen sichtbar, etwa ob eine Schnittstelle in der vorgesehenen Umgebung wirklich unerreichbar ist oder nur in einem einzelnen Testaufbau nicht genutzt wurde.

Das Wort „verschlüsselt“ beantwortet ein Risiko nicht vollständig. Verschlüsselung kann einen Teil des Datenflusses schützen, während Zugriffskontrolle, Schlüsselbehandlung oder Updateintegrität offenbleiben. Beschreiben Sie Sicherheitsziel und Umsetzungsgrenze. Die Aufzeichnung muss zeigen, warum die gewählte Maßnahme das bewertete Szenario behandelt und welche Risiken verbleiben. Das ist begründete Produktarbeit. Es ist keine Behauptung, dass eine bestimmte Technologie Konformität garantiert. Für jede Aussage muss klar sein, welche technische Eigenschaft tatsächlich geprüft oder durch einen belastbaren Nachweis gestützt wurde.

Voreinstellungen bei Erstnutzung und Änderung prüfen

Die Konfiguration bei erster Nutzung braucht eine eigene Prüfung. Betrachten Sie erreichbare Schnittstellen, anfängliche Zugangsdaten, Berechtigungen, optionale Integrationen und sichtbare Einstellungen. Ein Produkt, das vor gewöhnlicher Nutzung Fachwissen zur Härtung verlangt, kann andere Risiken erzeugen als ein Produkt mit angemessenen Voreinstellungen. Halten Sie die Begründung wichtiger Einstellungen fest und prüfen Sie sie anhand der Zweckbestimmung. Eine im Labor geeignete Prototypkonfiguration darf nicht unbemerkt zur Kundenkonfiguration werden, nur weil sie während der Entwicklung bequem war.

Wiederholen Sie die Prüfung nach Updates und Migration. Eine sichere Erstinstallation belegt nicht, dass ein Upgrade Authentifizierung und Zugriffsbeschränkungen erhält. Bei einem hypothetischen Upgrade könnte eine neue Verwaltungs-API standardmäßig aktiviert sein, obwohl das Vorgängerrelease keinen solchen Endpunkt hatte. Die Release-Prüfung muss die Änderung erkennen und ihre Wirkung untersuchen. Ordnen Sie Konfiguration und Produktfassung dem Ergebnis zu. Dann kann eine andere Person später nachvollziehen, welcher Zustand geprüft wurde und unter welchen Voraussetzungen das Ergebnis gilt.

Können Nutzer einen Schutz abschwächen, prüfen Sie die Erklärung der Folgen und den Weg zurück zu einer sicheren Konfiguration. Ein Hinweis „auf eigenes Risiko fortfahren“ beschreibt das veränderte Verhalten nicht. Testen Sie die tatsächlich wirksame Einstellung sowie die Nutzeranweisung. Diese Design- und Bedienungsprüfungen sind praktische Empfehlungen. Sie werden an anwendbare Anforderungen des Anhangs I und bewertete Produktrisiken angepasst. Eine auffällige Warnung allein ist kein Nachweis dafür, dass die zugrunde liegende Schutzfunktion angemessen funktioniert.

Updates als Sicherheitsfunktion behandeln

Über ein Update akzeptiert ein Produkt neues ausführbares Verhalten. Bewerten Sie daher Vorbereitung, Genehmigung, Verteilung und Installation. Untersuchen Sie Integritätsprüfung, Berechtigung, Unterbrechung und Wiederherstellung passend zum Produkt. Ein Download über eine bekannte Adresse zeigt nicht allein, dass jedes Paket echt ist oder ein Fehler einen akzeptablen Zustand hinterlässt. Die Sicherheitsfrage betrifft den gesamten Weg bis zum tatsächlich ausgeführten neuen Zustand. Dazu gehören auch Zuständigkeit für Paketfreigabe und die technische Überprüfung an der Annahmestelle.

Bei einem hypothetischen Geräteupdate prüft das Team ein verändertes Paket, eine nicht unterstützte Fassung und Stromverlust während der Installation. Erwartete Reaktionen werden vor dem Test festgelegt. Das Ergebnis nennt Gerätemodell, vorhandene Firmware, versuchtes Paket und Wiederherstellungszustand. Ein solcher Bericht erklärt mehr als „Update getestet“. Er stützt die untersuchten Szenarien. Andere Sicherheitsfragen brauchen weiterhin ihre eigenen Anforderungen und Prüfungen. Eine gelungene Wiederherstellung beweist beispielsweise nicht automatisch die Wirksamkeit sämtlicher Berechtigungsregeln im Gerät.

Betrachten Sie die Wartung dieser Funktion über den Unterstützungszeitraum. Signierung, Build-Abhängigkeiten, Verteildienste und verantwortliche Menschen können sich über Jahre ändern. Ein Wartungsplan hält diese Abhängigkeiten und Prüfauslöser fest. Ein heute starker Release-Prozess begründet noch keine glaubwürdige mehrjährige Zusage, wenn ein unverzichtbares Werkzeug nächstes Jahr nicht mehr unterstützt wird. Verbinden Sie das Risiko mit einer Maßnahme, bevor die Zusage erfolgt. Die Produktleitung braucht die Grundlage dieser Entscheidung und nicht nur eine optimistische Einschätzung der Entwicklungsabteilung.

Zugriff und Angriffsfläche bewusst begrenzen

Erfassen Sie Schnittstellen für Befehle oder Daten: Netzwerkdienste, lokale Anschlüsse, Verwaltung, Dateiverarbeitung und entfernte Konfiguration. Bestimmen Sie notwendige Schnittstellen anhand der Zweckbestimmung und begründen Sie weitere aktiv bleibende Zugänge. Entfernen oder deaktivieren Sie unnötige Angriffsfläche, soweit angemessen. Diese Empfehlung folgt risikobasierter Entwicklung. Sie verlangt weder die Entfernung jeder Schnittstelle noch behauptet sie, ein Offline-Produkt habe keine Cybersicherheitsrisiken. Auch lokale Verarbeitung oder ein Update über einen Datenträger kann sicherheitsrelevant sein und eigene Schutzmaßnahmen benötigen.

Berechtigungen brauchen ebenfalls eine Begründung. Ein Dienst mit mehr Zugriff als für seine Funktion nötig kann die Folgen einer Kompromittierung erhöhen. Prüfen Sie Lese-, Schreib- und Änderungsmöglichkeiten und testen Sie die gewählten Begrenzungen. Bei einem hypothetischen lokalen Agenten wird etwa geprüft, ob gewöhnliche Datenerfassung allgemeine Änderungen fremder Systemeinstellungen erlaubt. Der konkrete Mechanismus hängt von Plattform und Architektur ab. Dokumentieren Sie deshalb das tatsächliche Verhalten und nicht nur eine allgemeine Richtlinie, die minimale Rechte fordert.

Beziehen Sie Diagnose und Support ein. Eine verdeckte Debug-Schnittstelle, dauerhaftes gemeinsames Wartungskonto oder unbegrenzter Protokollexport kann sonstige Schutzmaßnahmen schwächen. Legen Sie Genehmigung, gegebenenfalls zeitliche Begrenzung und Aufzeichnung von Supportzugriffen fest. Bei sensiblen Protokollinhalten werden Erfassungsbedarf und Schutz bewertet. Die Aussage „das verwendet nur der Support“ beweist keine Unmissbrauchbarkeit. Die Kontrolle muss zeigen, wer die Funktion technisch auslösen kann und welche Einschränkungen tatsächlich wirken. Dabei sind auch Fehlerfälle und verbliebene Testzugänge relevant.

Tests auf die Designfrage ausrichten

Ein Sicherheitstest nennt geprüftes Verhalten, Voraussetzungen, erwartetes Ergebnis und Produktfassung. Ein umfangreicher Penetrationstestbericht kann wertvoll sein. Er ersetzt aber nicht jede produktbezogene Überprüfung. Umgekehrt zeigen Hunderte automatisierte Tests nicht, dass das Bedrohungsmodell wesentliche Funktionen erfasst. Nutzen Sie unterschiedliche Nachweise für unterschiedliche Aussagen und nennen Sie ihre Grenzen. Damit wird eine Prüfung nicht abgewertet. Ihre Aussage wird so genau, dass sie bei der Anforderungsbewertung und einer späteren Änderung sinnvoll verwendet werden kann.

Bei einer hypothetischen Änderung der Rollenverwaltung werden erlaubte und versuchte unerlaubte Handlungen geprüft. Hinzu kommen relevante Szenarien wie Sitzungsablauf, Rollenentzug oder Wiederverwendung eines Tokens. Die Nachweise werden mit Anforderung und Risiko verbunden, aus denen die Änderung entstand. Eine prüfende Person sieht dann den Zweck des Tests. Eine losgelöste Liste grüner Ergebnisse zeigt diese Verbindung nicht. Halten Sie außerdem fest, welche Konfiguration und Konten verwendet wurden, damit sich das Verhalten bei Bedarf erneut überprüfen lässt.

Fehler erzeugen Entwicklungsarbeit und Entscheidungen. Löschen Sie ein fehlgeschlagenes Ergebnis nicht, wenn später ein Test besteht. Bewahren Sie Verlauf und Korrektur. Wird ein verbleibendes Risiko akzeptiert, gehören verantwortliche Genehmigung und Grundlage dazu. Eine solche Genehmigung setzt keine zwingende gesetzliche Anforderung außer Kraft. Sie erklärt eine Risikoentscheidung und wird anhand geltender Produktpflichten geprüft. Ein internes Ausnahmeformular ist daher keine allgemeine Erlaubnis, eine verpflichtende Schutzmaßnahme zu ignorieren. Sein tatsächlicher Entscheidungsumfang muss sichtbar bleiben.

Die Release-Prüfung als Verbindungspunkt nutzen

Unsere empfohlene Release-Prüfung fragt nach Änderungen von Risiken, Schnittstellen, Abhängigkeiten, Voreinstellungen, Updatebehandlung und Nutzeranweisungen. Der Aufwand richtet sich nach der Änderung. Eine kleine Textkorrektur braucht nicht dieselbe Untersuchung wie der Austausch der Authentifizierung. Die zuständige Person begründet den benötigten Prüfumfang und verbindet die Ergebnisse mit Nachweisen. So wird Verhältnismäßigkeit nachvollziehbar, ohne jede Änderung pauschal als unwichtig einzustufen oder bei jedem Release dieselbe umfangreiche Prüfung ohne technischen Bezug zu wiederholen.

Verbinden Sie Produkt-, Entwicklungs- und Sicherheitsverantwortung. Das Produktmanagement kennt zugesagtes Verhalten und Nutzung, die Entwicklung die Umsetzung und die Sicherheitsprüfung die Bedrohungsannahmen. In einem kleinen Team kann eine Person mehrere Rollen innehaben. Dokumentieren Sie die Aufteilung und benennen Sie bei wichtigen Ausnahmen die Genehmigung. Das Ziel ist verantwortliche Prüfung. Eine Sitzung, von der nur die Anwesenheitsliste übrig bleibt, erklärt keine Sicherheitsentscheidung. Der Beschluss muss zeigen, was geprüft wurde und welches Ergebnis daraus folgte.

Die Release-Freigabe nennt offene Bedingungen und deren Behandlung. Ein geplanter Test ist noch kein Prüfnachweis. Eine unbestätigte Lieferantenangabe ist noch keine bestätigte Komponenteneigenschaft. Halten Sie diese Zustände auch bei Dokumentation und Kundenaussagen auseinander. Das verhindert die Beschreibung von Schutzfunktionen, die bisher nur in einer Aufgabenliste stehen. Eine genaue Freigabe kann daher offene Punkte enthalten. Sie muss deren Bedeutung, Zuständigkeit und den tatsächlichen Entscheidungsgrund beschreiben, statt sie hinter einem allgemeinen positiven Status zu verbergen.

Eine vollständige Designentscheidung nachvollziehen

Wählen Sie eine tatsächliche sicherheitsrelevante Funktion und verfolgen Sie Risiko, Anforderung, Design, Änderung, Test und Prüfung. Eine nicht an der Umsetzung beteiligte Person versucht, die Begründung anhand der Aufzeichnungen zu erklären. Fehlender Kontext führt zu einer Verbesserungsaufgabe. Diese praktische Prüfung betrifft Nachweisqualität. Sie ist keine unabhängige Erklärung der CRA-Konformität des gesamten Produkts. Ihr Wert liegt darin, dass sie eine konkrete Lücke im Zusammenhang zwischen Entscheidung und überprüftem Verhalten sichtbar macht.

Wiederholen Sie die Prüfung nach wichtigen Änderungen oder Schwachstellenbefunden. Neue Informationen können eine alte Annahme widerlegen, obwohl der Code unverändert ist. Aktualisieren Sie dann Risiko und Tests, statt lediglich einen getrennten Vorfallsfall anzulegen. Security by Design soll Erkenntnisse in Produkt und künftige Entscheidungen überführen. Eine unveränderte Richtlinie bei wiederkehrender Schwäche zeigt diese Lernschleife nicht. Eine verbesserte Konstruktion und der dazugehörige Prüfnachweis machen dagegen deutlich, wie die Erkenntnis tatsächlich verarbeitet und bei späteren Releases berücksichtigt wurde.

Wie Pulsar einen nachweisgestützten Ablauf unterstützt

Risiken, Kontrollen, Aufgaben, Dokumente, Nachweise, Audits und Berichte in Pulsar können eine Designentscheidung mit Umsetzung, Überprüfung und erneuter Prüfung verbinden.

KI in Pulsar sollte ein Assistent für die Erstellung von Entwürfen bleiben. Sie sollte weder eine Risikobewertung noch eine Sicherheitsausnahme oder eine Entscheidung zur Produktkonformität selbstständig genehmigen.

Pulsar GRC am Ablauf von der Anforderung zum Nachweis ansehen

Verwandte Leitfäden

• SBOM im CRA
• Technische CRA-Dokumentation
• CRA-Meldungen innerhalb von 24 und 72 Stunden

Quellen

• Verordnung (EU) 2024/2847 — Anhang I
• ENISA — Secure by Design and Default Playbook

Quellen geprüft: 2. Oktober 2026.

• Pulsar GRC — Zugriff, Datenisolierung und Export (Polnisch)