Pflichten als Herausgeber nach der Cyberresilienz-Verordnung

graph TD
  P[Herausgeber der Anwendung] --> D[Auslieferung mit dem SDK]
  D --> M[app-manifest.json mit SHA-256]
  D --> S[delivery.json, signiert mit dem Lieferschlüssel]
  M --> B[Starter prüft jede Kopie]
  S --> B
  P --> R[Meldeablauf für Schwachstellen und Sicherheitsvorfälle]
  R --> C[CSIRT und ENISA über die einheitliche Meldeplattform]
  R --> U[Information der Nutzer]

Wer eine Access-Anwendung mit dem WKL Office SDK an Kunden ausliefert, ist für diese Anwendung Hersteller im Sinne der Verordnung (EU) 2024/2847 (Cyberresilienz-Verordnung). Diese Seite fasst zusammen, was die Verordnung von Ihnen verlangt, und zeigt, welche Teile davon SDK und Starter technisch unterstützen.

Wichtige Punkte

Meldepflichten gelten bereits. Art. 14 gilt seit dem 11. September 2026, die übrigen Pflichten ab dem 11. Dezember 2027 (Art. 71 Abs. 2). Die Meldepflicht greift ab der ersten Bereitstellung Ihrer Anwendung auf dem Unionsmarkt, auch bei unentgeltlicher Lieferung im Rahmen Ihrer Geschäftstätigkeit.
Prüfbare Lieferung. Jede ausgelieferte Datenbank steht mit Größe und SHA-256 in app-manifest.json. Der Starter legt nur Kopien ab, die dazu passen.
Signierte Auslieferung. Mit einem eigenen Lieferschlüssel signieren Sie die Liste aller Dateien einer Version. Starter mit Ihrem öffentlichen Schlüssel installieren nur, was Sie signiert haben.
Vorlage für den Meldeablauf. Einen Meldeablauf für Schwachstellen einrichten beschreibt die Schritte von der Meldung bis zum Abschlussbericht, mit Vorlagen für jede Meldung.

So greifen Verordnung und Werkzeuge ineinander

Wer Hersteller ist

Hersteller ist, wer ein Produkt mit digitalen Elementen entwickelt oder entwickeln lässt und unter eigenem Namen oder eigener Marke vermarktet. Für eine mit dem SDK gebaute Anwendung sind das Sie, nicht der Anbieter des SDK. Das SDK und die WKL-Komponenten sind Bestandteile Ihrer Anwendung. Finden Sie eine Schwachstelle in einem Bestandteil, melden Sie sie dessen Hersteller (Art. 13 Abs. 6). Hersteller des SDK und der WKL-Komponenten ist EMSR DATA, D.O.O.; wie Sie eine Schwachstelle im SDK melden, steht in SECURITY.de.md im Stammordner des SDK-Pakets.

Was Sie melden müssen

Anlass	Frühwarnung	Meldung	Abschlussbericht
aktiv ausgenutzte Schwachstelle	spätestens 24 h nach Kenntnis	spätestens 72 h nach Kenntnis	spätestens 14 Tage, nachdem eine Korrektur oder Risikominderung verfügbar ist
schwerwiegender Sicherheitsvorfall, der die Sicherheit der Anwendung betrifft	spätestens 24 h nach Kenntnis	spätestens 72 h nach Kenntnis	innerhalb eines Monats nach der Meldung

Aktiv ausgenutzt ist eine Schwachstelle, wenn verlässliche Nachweise vorliegen, dass ein böswilliger Akteur sie ohne Zustimmung des Systemeigners ausgenutzt hat (Art. 3 Nr. 42). Sie melden über die einheitliche Meldeplattform der ENISA (CRA Single Reporting Platform, CRA-SRP) an das koordinierende CSIRT des Mitgliedstaats Ihrer Hauptniederlassung; die ENISA erhält die Meldung gleichzeitig, und das CSIRT leitet sie an die CSIRTs der Mitgliedstaaten weiter, in denen Ihre Anwendung bereitgestellt ist (Art. 14 Abs. 7, Art. 16). Außerdem informieren Sie die betroffenen Nutzer über die Maßnahmen, die sie ergreifen können (Art. 14 Abs. 8).

In Deutschland

Koordinierendes CSIRT: CERT-Bund im Bundesamt für Sicherheit in der Informationstechnik (BSI). Maßgeblich ist der Mitgliedstaat, in dem Sie die Entscheidungen zur Cybersicherheit Ihrer Anwendung überwiegend treffen; das CSIRT wählen Sie bei der Meldung auf der Plattform aus.
Meldeplattform: Anmeldung und Fragen zur Plattform über die FAQ-Seite der ENISA, https://www.enisa.europa.eu/cra-srp (Helpdesk cra-srp-helpdesk@enisa.europa.eu). Melden Sie sich an, bevor Sie zum ersten Mal ausliefern, nicht erst im Ernstfall.
Verhältnis zum BSI-Gesetz: Das NIS-2-Umsetzungsgesetz (NIS2UmsuCG, in Kraft seit 6. Dezember 2025) verpflichtet besonders wichtige und wichtige Einrichtungen nach dem BSI-Gesetz zu eigenen Meldungen an das BSI. Diese Pflichten treffen Ihr Unternehmen nur, wenn es selbst eine solche Einrichtung ist, und Ihre Kunden, wenn sie es sind. Sie ersetzen die Meldung nach der Cyberresilienz-Verordnung nicht.

Was Ihre Lieferung tragen muss

Ab dem 11. Dezember 2027 gehören zu jeder Lieferung unter anderem Ihre Herstellerangaben, eine zentrale Anlaufstelle für Schwachstellen, das Enddatum des Unterstützungszeitraums (mindestens fünf Jahre, sofern die Anwendung nicht kürzer genutzt wird) und Anleitungen zur sicheren Verwendung (Art. 13 Abs. 8, 17, 19 und Anhang II). Sie müssen außerdem eine Software-Stückliste (SBOM) führen, also eine maschinenlesbare Liste der in der Anwendung enthaltenen Komponenten; sie nennt mindestens die obersten Abhängigkeiten (Anhang I Teil II Nr. 1). Aktualisierungen müssen Sie sicher verbreiten (Anhang I Teil II Nr. 7).

Bevor Sie Ihre Anwendung ab dem 11. Dezember 2027 bereitstellen, bewerten Sie ihre Konformität. Gehört sie zu keiner Kategorie wichtiger oder kritischer Produkte (Anhänge III und IV, beschrieben in der Durchführungsverordnung (EU) 2025/2392), genügt das Verfahren der internen Kontrolle (Modul A, Anhang VIII Teil I) ohne benannte Stelle. Danach stellen Sie die EU-Konformitätserklärung aus, legen sie oder eine vereinfachte Erklärung mit der Internetadresse der vollständigen jeder Lieferung bei und bringen die CE-Kennzeichnung auf der Erklärung oder auf der Website zu Ihrer Anwendung an. Technische Dokumentation und Erklärung bewahren Sie mindestens zehn Jahre auf (Art. 13 Abs. 12, 13 und 20, Art. 28, 30 und 32).

Wie Herstellerangaben und Meldeweg aussehen können, zeigt das SDK an sich selbst: Sein Paket enthält im Stammordner MANUFACTURER.md (Herstellerangaben, Art und Ende der Sicherheitsunterstützung) und SECURITY.md (Meldeweg und Strategie für die koordinierte Offenlegung von Schwachstellen), jeweils auf Englisch, Deutsch (.de.md) und Slowenisch (.sl.md). Für Ihre Anwendung brauchen Sie entsprechende Angaben mit Ihrer Firma, Ihren Kontakten und Ihren Daten.

Wobei SDK und Starter helfen

Pflicht	Unterstützung	Grenze
Aktualisierungen sicher verbreiten (Anhang I Teil II Nr. 7)	`wkl-office deliver` schreibt `app-manifest.json` mit Größe und SHA-256 der Datenbank; der Starter prüft jede Kopie dagegen	Prüft die Unversehrtheit, nicht die Herkunft
Herkunft der Lieferung nachweisen	Signierte Auslieferung: `/publish /key` des Starters schreibt `delivery.json` mit Größe und SHA-256 jeder Datei und signiert sie mit Ihrem Lieferschlüssel (ECDSA P-256); Starter mit `deliveryKey` installieren nur signierte Versionen	Programme aus `actions` sind nicht abgedeckt; der Schutz hängt am Schreibschutz der Projektdatei des Starters (Abschnitt „Signierte Auslieferungen“ der Projektdatei des Starters)
Rückkehr der Benutzer zu einer verwundbaren Version verhindern	Ab Starter 2.2.4 installiert ein Starter mit `deliveryKey` eine niedrigere Version als je beim Benutzer installiert nur, wenn die signierte Auslieferung die höhere zurückzieht; bewusst zurück gehen Sie mit `/publish /key <name> /withdraw <version>` (Signierte Auslieferung veröffentlichen des Starters)	Ein Benutzer, der die höhere Version nie hatte, installiert die ältere Auslieferung; `deliver` warnt, wenn das Starter-Paket älter als 2.2.4 ist
Sicherheitsaktualisierungen unverzüglich verteilen (Anhang I Teil II Nr. 8)	Der Starter installiert eine neue Version beim nächsten Start jedes Benutzers	Die Verteilung auf die Freigabe ist Ihre Aufgabe
Anleitungen zu Installation, Aktualisierung und Entfernung (Anhang II Nr. 8)	Die Doku des Starters beschreibt Installation, Aktualisierung und Entfernen (`/uninstall`) für die IT	Anleitungen zu Ihrer Anwendung schreiben Sie selbst
Meldeablauf (Art. 14)	Vorlage mit Schritten, Fristen und Meldetexten	Personen, Zugang zur Meldeplattform und Ablage der Vorgangsakten legen Sie fest

Nicht unterstützt sind heute eine Software-Stückliste und Angaben zum Unterstützungszeitraum. Diese Teile erstellen Sie selbst.

Einordnung und Quellen

Diese Seite fasst die Pflichten zusammen, die Sie als Hersteller Ihrer Anwendung treffen, und zeigt, was SDK und Starter dazu beitragen. Verbindlich ist der Text der Verordnung. Ob Ihre Anwendung ein wichtiges oder kritisches Produkt ist und welche Konformitätsbewertung sie braucht, beurteilen Sie anhand der Anhänge III und IV, bei Bedarf mit Ihrer Rechtsberatung. Die Angaben beruhen auf der deutschen Fassung der Verordnung im Amtsblatt der Europäischen Union (ABl. L, 20.11.2024, http://data.europa.eu/eli/reg/2024/2847/oj), der Durchführungsverordnung (EU) 2025/2392 (ABl. L, 1.12.2025, http://data.europa.eu/eli/reg_impl/2025/2392/oj) und dem Factsheet der ENISA zur einheitlichen Meldeplattform (Stand September 2026).