Why now – Palantir alternatives for Europe: what 'sovereign' actually means, and how European public bodies are decidingRegistrieren →
Cyber Resilience Act (CRA)

Sicher by Design — mit Nachweisen, die beim Code beginnen

Die Cyberresilienz-Verordnung macht Cybersicherheit zur Bedingung dafür, Hardware und Software auf dem EU-Markt bereitzustellen. Scrydon ist Secure by Default gebaut und behandelt die Herstellerpflichten des CRA als seine eigenen — und gibt Kunden, die Produkte auf der Plattform ausliefern, die Controls und Nachweise, die sie brauchen.

Geschrieben für Security-, Risiko- und Datenschutzteams — für die, die es nachweisen müssen, nicht nur beschreiben.

Worum es geht

Cyberresilienz-Verordnung (CRA)

Die Cyberresilienz-Verordnung (Cyber Resilience Act, Verordnung (EU) 2024/2847) legt horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen fest — Hardware und Software mit direkter oder indirekter Verbindung zu einem Gerät oder Netz —, die auf dem EU-Markt bereitgestellt werden. Hersteller müssen Produkte gemäß grundlegenden Cybersicherheitsanforderungen entwerfen, entwickeln und herstellen, über den Unterstützungszeitraum des Produkts einen Prozess zur Schwachstellenbehandlung betreiben, eine Software-Stückliste (SBOM) führen, Sicherheitsupdates bereitstellen, aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über die von der ENISA betriebene zentrale Meldeplattform melden und die Konformität durch die CE-Kennzeichnung nachweisen. Produktklassen mit höherem Risiko („wichtige“ und „kritische“ Produkte) unterliegen einer strengeren Konformitätsbewertung. Die Verordnung trat am 10. Dezember 2024 in Kraft; die Meldepflichten gelten ab dem 11. September 2026, die Hauptpflichten ab dem 11. Dezember 2027, mit Geldbußen von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Umsatzes.
Auf einen Blick
Geltungsbereich
Europäische Union
Gilt für
Hersteller, Einführer und Händler von Produkten mit digitalen Elementen — Hardware und Software —, die auf dem EU-Markt bereitgestellt werden, einschließlich Softwareanbietern und der Organisationen, die darauf vernetzte Produkte aufbauen.
Sprechen Sie mit uns
Wie wir helfen

Wie Scrydon Sie bei der Einhaltung unterstützt

Die Controls sind in die Runtime eingebaut, sodass Sie Compliance mit Nachweisen aus der Plattform selbst belegen können — statt sie im Nachhinein zusammenzutragen.

Secure by Default, ab Auslieferung

Fail-Closed-Defaults, ein mTLS-Service-Mesh, dreistufige Zugriffskontrolle und ein einziger Policy-as-Code-Entscheidungspunkt bedeuten, dass die Plattform in einer sicheren Konfiguration mit minimaler Angriffsfläche ausgeliefert wird. Genau das verlangen die grundlegenden Anforderungen des CRA von einem Produkt im Auslieferungszustand — Secure by Default, Schutz von Vertraulichkeit und Integrität, und nicht mehr Exposition als nötig.

Schwachstellenbehandlung und kontrollierte Updates

Als Softwarehersteller unterhält Scrydon einen Prozess zur Schwachstellenbehandlung und koordinierten Offenlegung für die Plattform und stellt über den Unterstützungszeitraum Sicherheitsupdates bereit. Da Deployments aus reproduzierbarer, Policy-gesteuerter Konfiguration laufen, können Sie diese Updates kontrolliert und nachweisbar durch Ihre eigenen Umgebungen ausrollen — auch in Air-Gap-Umgebungen.

Protokollierung für Erkennung und Meldung von Vorfällen

Die grundlegenden Anforderungen erwarten, dass ein Produkt relevante interne Aktivität aufzeichnet und überwacht, einschließlich Zugriff auf oder Änderung von Daten. Das unveränderliche, abfragbare Audit-Log tut genau das und liefert Ihnen Akteur-, IP- und Entscheidungsdetails, um eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Vorfall innerhalb der 24- und 72-Stunden-Fristen des CRA zu charakterisieren.

Eine Lieferkette, die Sie aufzählen können

Der CRA erwartet, dass Hersteller wissen, was in ihren Produkten steckt. Scrydon hält die KI- und Datenlieferkette explizit — externe KI-Anbieter sind Opt-in, Modelle laufen, wo Sie es wählen, und Plattformkomponenten sind dokumentiert —, sodass Ihre eigene Software-Stückliste und technische Dokumentation die Plattform und alles, was sie erreicht, ausweisen können.

Evidence Packs je Framework

Evidence Packs bilden Plattform-Controls auf die grundlegenden Anforderungen des CRA ab — neben ISO 27001 und NIS2 — und geben Produktsicherheits-, Compliance- und Konformitätsbewertungsarbeit einen dokumentierten Ausgangspunkt für die technische Dokumentation und Risikobewertung, die die Verordnung verlangt.

Zentrale Anforderungen

CRA: Was von Ihnen verlangt wird

  • Entwerfen, entwickeln und stellen Sie Produkte gemäß den grundlegenden Cybersicherheitsanforderungen des CRA her — Secure by Default.
  • Führen Sie eine Cybersicherheits-Risikobewertung durch und halten Sie technische Dokumentation vor, einschließlich einer Software-Stückliste (SBOM).
  • Betreiben Sie einen Prozess zur Schwachstellenbehandlung mit koordinierter Offenlegung und kostenlosen Sicherheitsupdates über den Unterstützungszeitraum (mindestens fünf Jahre, sofern die erwartete Produktlebensdauer nicht kürzer ist).
  • Melden Sie aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht binnen 14 Tagen.
  • Durchlaufen Sie die anwendbare Konformitätsbewertung — strenger für wichtige und kritische Produkte — und bringen Sie die CE-Kennzeichnung an.
  • Geben Sie Nutzern klare Sicherheitsinformationen, Anleitungen und einen festgelegten Unterstützungszeitraum.
  • Halten Sie den Zeitplan ein: Meldepflichten ab dem 11. September 2026, Hauptpflichten ab dem 11. Dezember 2027.
Wo die Grenze verläuft

Was wir liefern und was bei Ihnen bleibt

Kein Anbieter kann an Ihrer Stelle konform sein. Wir bauen die Controls in die Plattform ein und liefern die Nachweise; die Bewertung Ihres eigenen Betriebs bleibt bei Ihnen. Hier ist die Aufteilung, klar benannt, damit sie nicht erst spät im Security-Review auftaucht.

Scrydon liefert

  • Controls, die standardmäßig in der Runtime durchgesetzt werden — nicht der Konfiguration überlassen.
  • Eine unveränderliche, abfragbare Aufzeichnung darüber, was ausgeführt wurde, in wessen Auftrag und auf welchen Daten.
  • Nachweispakete, zugeordnet zu den auf dieser Seite genannten Pflichten.
  • Dokumentierte Architektur und Datenflüsse, die Ihre Prüfer lesen können.
  • Betrieb innerhalb Ihres eigenen Perimeters — bis hin zur vollständigen Trennung vom Netz.

In Ihrer Verantwortung bleibt

  • Die Einstufung Ihrer eigenen Systeme und Daten nach dem Framework.
  • Ihre Risikobewertung, Datenschutz-Folgenabschätzung und Konformitätsbewertung.
  • Wem Sie Zugriff gewähren — und auf welcher Grundlage.
  • Ihre Incident Response und Ihre Meldepflichten.
  • Die operative Sicherheit der Umgebung, in der Sie es betreiben.
FAQ

Häufig gestellte Fragen

Gilt die Cyberresilienz-Verordnung für Scrydon selbst?+
Ja. Software, die auf dem EU-Markt bereitgestellt wird, ist ein Produkt mit digitalen Elementen; Scrydon ist also Hersteller im Sinne des CRA und behandelt die Pflichten als seine eigenen: Secure-by-Design-Engineering, ein Prozess zur Schwachstellenbehandlung und Offenlegung, Sicherheitsupdates über den Unterstützungszeitraum und Vorbereitung auf die ab dem 11. September 2026 geltenden Meldepflichten. Unser Sicherheitsniveau beschreiben wir auf der Seite Vertrauen & Sicherheit und veröffentlichen Status statt Versprechen. Diese Seite behandelt auch, wie die Plattform Kunden unterstützt, die selbst Hersteller sind.
Gilt der CRA für uns, wenn wir auf Scrydon aufbauen?+
Wenn Sie ein Produkt mit digitalen Elementen auf dem EU-Markt bereitstellen — ein Gerät, eine Anwendung oder Software mit Konnektivität —, sind Sie Hersteller, und der CRA gilt für dieses Produkt, einschließlich der auf der Plattform aufgebauten Teile. Rein intern genutzte Software und rein als SaaS erbrachte Dienste liegen in der Regel außerhalb des CRA, wobei Datenfernverarbeitung, von der ein Produkt abhängt, in den Anwendungsbereich fällt und Dienste unter NIS2 fallen. Wo Sie betroffen sind, liefert Scrydon sichere Voreinstellungen, Protokollierung und dokumentierte Komponenten, auf die sich Ihre eigene Konformitätsarbeit stützen kann.
Ab wann gelten die CRA-Pflichten?+
Die Verordnung trat am 10. Dezember 2024 in Kraft. Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle gelten ab dem 11. September 2026, die Bestimmungen zu Konformitätsbewertungsstellen ab dem 11. Juni 2026 und die Hauptpflichten — grundlegende Anforderungen, Schwachstellenbehandlung, Konformitätsbewertung und CE-Kennzeichnung — ab dem 11. Dezember 2027. Da diese Termine in die Lebensdauer heute entworfener Produkte fallen, ist der Aufbau auf einer Secure-by-Default-Plattform ein Weg, sie ohne Nachrüstung einzuhalten.
Wie hilft die Plattform bei den grundlegenden Cybersicherheitsanforderungen?+
Die grundlegenden Anforderungen in Anhang I umfassen sichere Standardkonfiguration, Schutz von Vertraulichkeit und Integrität, Zugriffskontrolle, minimale Angriffsfläche, Widerstandsfähigkeit gegen Angriffe und Protokollierung relevanter interner Aktivität. Fail-Closed-Defaults, mTLS-Service-Mesh, dreistufige Zugriffskontrolle, Policy-as-Code-Autorisierung, DLP-Guardrails und das unveränderliche Audit-Log von Scrydon bilden auf jede davon ab, und Evidence Packs dokumentieren die Zuordnung für Ihre technische Dokumentation.
Welche Meldefristen gelten für Schwachstellen und Vorfälle, und wie hilft Scrydon?+
Hersteller müssen bei einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Vorfall binnen 24 Stunden nach Kenntnisnahme eine Frühwarnung abgeben, binnen 72 Stunden eine ausführlichere Meldung und binnen 14 Tagen einen Abschlussbericht (ein Monat bei Vorfällen), über die zentrale Meldeplattform. Das Audit-Log liefert Ihnen Akteur-, IP- und Entscheidungsdetails, um schnell zu charakterisieren, was passiert ist; der eigene Offenlegungsprozess von Scrydon hält Sie zur Plattform auf dem Laufenden. Die Meldungen für Ihr Produkt einzureichen bleibt Ihre Pflicht als Hersteller.
Wie unterstützt Scrydon die Software-Stückliste (SBOM)?+
Der CRA verlangt von Herstellern, die Komponenten ihrer Produkte mindestens bis zur Ebene der direkten Abhängigkeiten in einer maschinenlesbaren SBOM zu identifizieren und zu dokumentieren. Scrydon dokumentiert die Komponenten, die es ausliefert, sodass SBOM und technische Dokumentation Ihres Produkts die Plattform ausweisen können, und hält die KI-Lieferkette durch Opt-in für externe Anbieter und Ihre Wahl des Modellstandorts explizit. Die SBOM für Ihr Produkt als Ganzes zu erstellen und zu pflegen bleibt Ihre Verantwortung.
Wie verhält sich der CRA zu NIS2 und ISO 27001?+
Der CRA reguliert Produkte; NIS2 reguliert die Einrichtungen und Dienste, die sie nutzen; ISO 27001 steuert das Sicherheitsmanagement einer Organisation. Sie sind darauf angelegt, einander zu verstärken: CRA-konforme Produkte helfen NIS2-Einrichtungen, ihre Lieferkettensicherheit nachzuweisen, und ein ISO 27001-ISMS ist die natürliche Heimat für die Prozesse zur Schwachstellenbehandlung und sicheren Entwicklung, die der CRA verlangt. Die Evidence Packs von Scrydon bilden seine Controls auf alle drei ab, sodass dieselben Nachweise für jedes Rahmenwerk dienen.

Oder schreiben Sie uns

Sagen Sie uns, woran Sie arbeiten und wer antworten soll. Ein Mensch liest es und antwortet innerhalb eines Werktags.

Wir verwenden diese Angaben nur, um Ihnen zu antworten. Datenschutzerklärung

Lieber schreiben? Senden Sie eine E-Mail an hello [at] scrydon.com und wir melden uns bei Ihnen.