Datargo · Blog

Ein Vorfall, zwei Meldewege: CRA und NIS2 seit dem 11. September 2026

2026-09-17T00:00:00+00:00

Seit dem 11. September 2026 gilt Artikel 14 des Cyber Resilience Act. Hersteller von Produkten mit digitalen Elementen müssen seitdem aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden. Die übrigen Pflichten der Verordnung greifen erst ab dem 11. Dezember 2027, die Meldepflicht ist ihnen also um mehr als ein Jahr vorgezogen. Sie gilt ausdrücklich auch für Produkte, die schon vor diesem Datum in Verkehr gebracht wurden.

Für viele Unternehmen ist das nicht die erste Meldepflicht. Wer als wichtige oder besonders wichtige Einrichtung unter das NIS2-Umsetzungsgesetz fällt, meldet erhebliche Sicherheitsvorfälle bereits seit Dezember 2025 an das BSI. Wer Software als Produkt vertreibt und zugleich selbst NIS2-Einrichtung ist, hat nun zwei Pflichten, die sich ähneln und doch nicht decken.

Was der CRA verlangt

Gemeldet wird über die Single Reporting Platform, die ENISA zum 11. September in Betrieb genommen hat. Eine einzige Meldung erreicht das als Koordinator zuständige CSIRT und ENISA zugleich. Für Deutschland ist das nach Angabe des BSI das CERT-Bund im BSI. Eine vorherige Registrierung ist nicht erforderlich.

Die Fristen sind gestuft:

Frühwarnung: unverzüglich, spätestens 24 Stunden, nachdem der Hersteller Kenntnis erlangt hat.
Meldung: spätestens nach 72 Stunden, mit ersten Angaben zu Art, Auswirkung und Gegenmaßnahmen.
Abschlussbericht: bei aktiv ausgenutzten Schwachstellen spätestens 14 Tage, nachdem eine Korrektur oder Abhilfe verfügbar ist; bei schwerwiegenden Vorfällen innerhalb eines Monats nach der Meldung.

Hinzu kommt eine Pflicht, die in der Diskussion oft untergeht: Nach Artikel 14 Absatz 8 informiert der Hersteller die betroffenen Nutzer über die Schwachstelle oder den Vorfall und über mögliche Abhilfen. Die Bußgeldvorschriften der Verordnung gelten erst mit ihrer vollen Anwendung ab Dezember 2027. Die Pflicht selbst besteht aber heute.

Warum eine Meldung die andere nicht ersetzt

CRA und NIS2 unterscheiden sich im Gegenstand. Der CRA knüpft an das Produkt an: Eine Schwachstelle gilt als aktiv ausgenutzt, wenn verlässliche Nachweise vorliegen, dass ein böswilliger Akteur sie ohne Zustimmung des Systemeigners ausgenutzt hat. Das kann bei einem Kunden geschehen, ohne dass die eigene Infrastruktur betroffen ist. NIS2 knüpft an die Einrichtung an: Ein Sicherheitsvorfall ist nach § 2 Nr. 11 BSIG erheblich, wenn er schwerwiegende Betriebsstörungen oder finanzielle Verluste verursacht oder verursachen kann oder Dritte erheblich schädigt.

Daraus folgen drei Konstellationen. Eine ausgenutzte Lücke im ausgelieferten Produkt ist CRA-meldepflichtig, aber nicht zwingend nach NIS2. Ein Ausfall des eigenen Betriebs ist NIS2-meldepflichtig, berührt aber nicht zwingend ein Produkt. Und ein Angriff über eine Produktschwachstelle auf die eigene Umgebung kann beide Pflichten auslösen, mit zwei Meldungen über zwei Kanäle: das BSI-Portal für NIS2, die ENISA-Plattform für den CRA. In Deutschland landen beide beim BSI, aber nicht im selben Vorgang.

Ein Lagebild, zwei Bewertungen

Doppelte Meldewege sind beherrschbar, doppelte Lagebilder nicht. Wer für jede Pflicht eine eigene Chronik führt, meldet früher oder später widersprüchliche Zeitpunkte. Bewährt hat sich ein gemeinsames Vorfallregister mit einer Chronik und zwei getrennten Prüfschritten: Ist ein Produkt betroffen und liegt eine aktive Ausnutzung vor? Ist der Betrieb erheblich gestört oder ein Dritter erheblich geschädigt?

Drei Punkte entscheiden, ob das im Ernstfall trägt. Erstens ein klar definierter Zeitpunkt der Kenntniserlangung, denn an ihm hängen beide 24-Stunden-Fristen. Zweitens eine benannte Stelle, die beide Prüfungen verantwortet und nicht erst im Vorfall bestimmt wird. Drittens Vorlagen für beide Kanäle, damit die Frühwarnung nicht an Formfragen scheitert.

Die Chronik beginnt fast immer mit einer Beobachtung: einem Ausfall, einem abgelaufenen Zertifikat, einer auffälligen Änderung an DNS oder Headern. Perstat, unser Produkt für Monitoring und Security Posture, hält solche Ereignisse mit Zeitstempel fest und liefert damit den Anfang dieser Chronik. Die Bewertung, ob gemeldet werden muss und wo, bleibt eine Entscheidung des Unternehmens.

Zwei Meldepflichten verlangen keine zwei Organisationen. Sie verlangen eine Chronik, die beiden standhält.

Ende von clientAuth: Warum mTLS mit öffentlichen Zertifikaten ausläuft

2026-09-16T00:00:00+00:00

Ein öffentlich vertrautes TLS-Zertifikat konnte lange zwei Dinge zugleich: einen Server gegenüber Browsern ausweisen und einen Client gegenüber einem anderen Server. Möglich machte das die Erweiterung Extended Key Usage mit den Zwecken serverAuth und clientAuth. Diese Doppelrolle endet. Die Richtlinie des Chrome Root Program verlangt Hierarchien, die ausschließlich der Server-Authentifizierung dienen.

Die Stichtage

Nach der Chrome Root Program Policy in der Fassung 1.8 gelten zwei Daten:

Seit dem 15. Juni 2026 dürfen neu an die CCADB gemeldete Zwischenzertifizierungsstellen nur noch den Zweck serverAuth ausweisen.
Ab dem 15. März 2027 gilt dasselbe für jedes ausgestellte Endzertifikat.

Die Zertifizierungsstellen stellen früher um. DigiCert etwa stellt öffentliche TLS-Zertifikate seit dem 1. Oktober 2025 standardmäßig ohne clientAuth aus und entfernt die Option nach eigener Ankündigung zum 1. März 2027 vollständig. Wer sich auf den Chrome-Stichtag verlässt, erfährt die Änderung deshalb womöglich schon bei der nächsten Verlängerung.

Bestehende Zertifikate bleiben bis zu ihrem Ablauf gültig. Weil die maximale Laufzeit seit dem 15. März 2026 bei 200 Tagen liegt, ist der Übergang aber kurz: Ein Zertifikat, das am letzten zulässigen Tag noch mit clientAuth ausgestellt wird, läuft spätestens Ende September 2027 aus. Danach trägt kein gültiges Endzertifikat aus einer von Chrome vertrauten Hierarchie mehr diesen Zweck.

Wo es bricht

Browser sind von der Änderung kaum betroffen, denn sie prüfen Server. Betroffen sind Verbindungen, bei denen ein System sich mit einem öffentlichen Zertifikat als Client ausweist:

Partnerschnittstellen: B2B-Verbindungen, bei denen beide Seiten sich per mTLS authentisieren und das Client-Zertifikat von einer öffentlichen CA stammt.
Server-zu-Server-Verkehr: Dienste, die ihr eigenes Serverzertifikat zugleich als Client-Identität gegenüber anderen Diensten verwenden.
Geräte und Agenten: Endpunkte, die mit öffentlich ausgestellten Zertifikaten gegenüber einem zentralen Dienst auftreten.

Das Tückische ist der Zeitpunkt. Der Fehler zeigt sich nicht am Stichtag, sondern bei der ersten Verlängerung danach, oft automatisiert und oft nachts. Das neue Zertifikat ist gültig, der TLS-Handshake scheitert trotzdem, weil die Gegenseite den Zweck clientAuth verlangt.

Client-Identitäten gehören in eine eigene PKI

Chrome schafft mTLS nicht ab. Die Richtlinie trennt nur die Zwecke: Öffentliche CAs weisen Server gegenüber der Allgemeinheit aus, Client-Identitäten werden in einer Vertrauensbeziehung ausgestellt, die die beteiligten Parteien selbst kontrollieren. Das ist sicherheitlich ohnehin sauberer. Wer einer öffentlichen CA als Client-Aussteller vertraut, akzeptiert potenziell jedes Zertifikat dieser CA, nicht nur die des eigenen Partners.

Für den Umstieg haben sich vier Schritte bewährt. Erstens das Inventar: Welche Zertifikate tragen heute clientAuth, und welche davon werden tatsächlich als Client eingesetzt? Das zeigt sich nicht am Zertifikat allein, sondern erst im Abgleich mit den Verbindungen. Zweitens eine eigene Zertifizierungsstelle für Client-Zwecke, getrennt von allem, was Server ausweist. Drittens die Abstimmung mit Partnern, denn jede Gegenseite muss den neuen Vertrauensanker hinterlegen, und das braucht Vorlauf. Viertens die Automatisierung der Ausstellung und Erneuerung, damit die eigene PKI nicht zur neuen manuellen Last wird.

NextPKI folgt genau diesem Muster: erst den Bestand sichtbar machen, dann die Erneuerung automatisieren, unabhängig von der ausstellenden CA. Der entscheidende Schritt liegt aber vor jedem Werkzeug, nämlich die Verbindungen zu finden, die heute stillschweigend auf clientAuth angewiesen sind.

Der 15. März 2027 ist nicht das Datum, an dem mTLS bricht. Er ist das Datum, ab dem jede Verlängerung es brechen kann.

NIS2 nach der Nachfrist: Vom Registrieren zum Melden

2026-09-15T00:00:00+00:00

Die gesetzliche Registrierungsfrist nach dem NIS2-Umsetzungsgesetz lief am 6. März 2026 ab, die vom BSI eingeräumte Nachsicht endete am 31. Juli. Das BSI weist heute unmissverständlich darauf hin, dass die Frist abgelaufen ist, und fordert betroffene Unternehmen auf, sich umgehend zu registrieren. Wer das noch nicht getan hat, bewegt sich nicht mehr in einer Übergangsphase.

Für die registrierten Einrichtungen stellt sich eine andere Frage. Die Registrierung ist ein einmaliger Vorgang, die Meldepflicht nach § 32 BSIG ist ein Dauerzustand. Ob ein Unternehmen sie erfüllen kann, zeigt sich erst im Vorfall.

Was die Zahlen sagen

Das BSI veröffentlicht den Stand regelmäßig. Zum Stichtag 30. Juni 2026 waren 17.945 Einrichtungen registriert, darunter 11.501 wichtige und 6.215 besonders wichtige Einrichtungen. Bis zum selben Stichtag zählt das BSI 692 Erstmeldungen nach NIS2 und insgesamt 1.659 NIS-2-Meldungen über das Portal. Die nächste Aktualisierung ist für den 31. Oktober 2026 angekündigt.

Aus diesen Zahlen lässt sich kein Urteil über einzelne Unternehmen ableiten, wohl aber eine Beobachtung: Das Verhältnis von registrierten Einrichtungen zu Erstmeldungen ist niedrig. Das kann bedeuten, dass wenige erhebliche Vorfälle auftreten. Es kann auch bedeuten, dass Vorfälle intern nicht als meldepflichtig erkannt werden. Welche der beiden Deutungen für das eigene Haus zutrifft, sollte jede Geschäftsleitung wissen, denn § 38 BSIG macht sie für die Umsetzung verantwortlich.

Wann ein Vorfall erheblich ist

Meldepflichtig ist nicht jeder Sicherheitsvorfall, sondern der erhebliche. § 2 Nr. 11 BSIG nennt zwei Maßstäbe: schwerwiegende Betriebsstörungen oder finanzielle Verluste für die Einrichtung selbst, oder erhebliche materielle oder immaterielle Schäden bei anderen. Beides gilt ausdrücklich auch dann, wenn der Schaden erst eintreten kann. Für Anbieter digitaler Infrastruktur und digitaler Dienste, etwa Cloud-, Rechenzentrums- und DNS-Dienste oder Managed Services, konkretisiert die Durchführungsverordnung (EU) 2024/2690 die Schwellen genauer.

Der Maßstab ist also bewusst weit gefasst, und er zielt auf Auswirkungen, nicht auf Angriffstechnik. Ein mehrstündiger Ausfall eines kundenrelevanten Dienstes kann erheblich sein, auch wenn am Ende eine Fehlkonfiguration und kein Angreifer dahintersteht.

Die Uhr beginnt mit der Kenntnis

§ 32 BSIG staffelt die Meldung: eine frühe Erstmeldung binnen 24 Stunden nach Kenntniserlangung, ob ein rechtswidriger oder böswilliger Hintergrund vermutet wird oder grenzüberschreitende Auswirkungen möglich sind; eine Meldung binnen 72 Stunden mit erster Bewertung von Schweregrad und Auswirkungen, gegebenenfalls mit Kompromittierungsindikatoren; auf Ersuchen des BSI eine Zwischenmeldung; und spätestens einen Monat nach der Meldung eine Abschlussmeldung.

Die kritische Stelle ist der Beginn. Die Frist läuft ab Kenntniserlangung, nicht ab dem Moment, in dem jemand den Vorfall als meldepflichtig einstuft. Wenn ein Alarm am Freitagabend eingeht und die Bewertung erst am Montag stattfindet, ist die 24-Stunden-Frist verstrichen, bevor über die Meldung überhaupt gesprochen wurde.

Meldefähig werden

Meldefähigkeit entsteht vor dem Vorfall. Vier Bausteine tragen sie:

Schwellen vorab festlegen: Welche Ausfälle, Datenabflüsse oder Beeinträchtigungen gelten für die eigenen Dienste als erheblich? Eine dokumentierte Einstufung vermeidet die Grundsatzdebatte im Ernstfall.
Zuständigkeit benennen: Wer entscheidet über die Meldung, wer vertritt, und wie wird diese Person außerhalb der Geschäftszeiten erreicht?
Zugang sicherstellen: Die Meldung erfolgt über das BSI-Portal. Der Zugang und die Berechtigungen müssen vorhanden sein, bevor sie gebraucht werden.
Eine Chronik führen: Erkennung, Bewertung und Maßnahmen mit Zeitstempeln, damit Erst-, Folge- und Abschlussmeldung auf denselben Fakten beruhen.

Eine Übung mit einem realistischen Szenario zeigt schnell, wo die Kette reißt. Meist ist es nicht die Technik, sondern die Übergabe zwischen dem Team, das den Vorfall bemerkt, und der Stelle, die über die Meldung entscheidet.

Perstat, unser Produkt für Monitoring und Security Posture, setzt am Anfang dieser Kette an: Ausfälle und sicherheitsrelevante Veränderungen werden erkannt, eskaliert und mit Zeitstempel festgehalten. Die Einstufung als erheblich und die Meldung selbst bleiben Aufgabe des Unternehmens.

Registriert zu sein beschreibt einen Status. Meldefähig zu sein beschreibt eine Fähigkeit, und nur sie wird im Ernstfall geprüft.

E-Rechnung ab 2027: Was Rechnungsaussteller bis zum Jahreswechsel klären sollten

2026-09-10T00:00:00+00:00

Seit dem 1. Januar 2025 müssen inländische Unternehmen E-Rechnungen empfangen können. Beim Versand gilt eine Übergangsregel nach § 27 Abs. 38 UStG: Bis zum 31. Dezember 2026 dürfen alle Rechnungsaussteller statt einer E-Rechnung noch eine sonstige Rechnung ausstellen, also Papier oder ein unstrukturiertes elektronisches Format. Zum Jahreswechsel endet diese Regel für einen großen Teil der Unternehmen.

Wen der Stichtag betrifft

Nach den Angaben des Bundesfinanzministeriums verlängert sich die Übergangsfrist bis Ende 2027 nur für Rechnungsaussteller mit einem Vorjahresumsatz von bis zu 800.000 Euro. Für 2027 ist damit der Umsatz des Jahres 2026 maßgeblich, also des laufenden Jahres. Wer diese Grenze überschreitet, stellt ab dem 1. Januar 2027 E-Rechnungen aus. Ab 2028 gilt die Pflicht für alle.

Daraus ergibt sich eine unbequeme Reihenfolge: Die endgültige Umsatzzahl steht erst nach dem Jahresabschluss fest, die Pflicht beginnt aber am ersten Tag des neuen Jahres. Unternehmen in der Nähe der Grenze sollten deshalb jetzt auf Basis ihrer Hochrechnung entscheiden und nicht auf den Abschluss warten. Wer die Frage mit der Steuerberatung klärt, sollte auch die Berechnungsgrundlage festhalten.

Eine zweite Übergangsregel betrifft den elektronischen Datenaustausch. EDI-Verfahren, die die Anforderungen an eine E-Rechnung nicht ohnehin erfüllen, dürfen noch bis Ende 2027 genutzt werden. Das verschafft Zeit, ersetzt aber nicht die Klärung, wie der Datenaustausch danach aussehen soll.

Welche Rechnungen betroffen sind

Die Pflicht erfasst Rechnungen zwischen inländischen Unternehmen. Rechnungen an Privatkunden fallen nicht darunter. Ausgenommen sind außerdem Kleinbetragsrechnungen bis 250 Euro brutto nach § 33 UStDV.

Als E-Rechnung gilt nur ein strukturiertes Format nach der europäischen Norm EN 16931. In der Praxis sind das XRechnung und ZUGFeRD ab Version 2.0.1, jeweils ohne die Profile MINIMUM und BASIC-WL, die zu wenige Angaben enthalten. Ein PDF bleibt eine sonstige Rechnung, auch wenn es per E-Mail versandt wird. Den Rahmen setzen die BMF-Schreiben vom 15. Oktober 2024 und vom 15. Oktober 2025.

Was bis Dezember sinnvoll ist

Gut drei Monate reichen nicht für eine grundlegende Neuausrichtung der Rechnungsstellung, wohl aber für die Punkte, die im Januar sonst zu Rückfragen führen:

Betroffenheit dokumentieren: Umsatzhochrechnung für 2026, Entscheidung und Begründung schriftlich festhalten.
Ausgangsrechnungen prüfen: Erzeugt das eigene System ein normkonformes Format, oder nur ein PDF mit Rechnungsbild? Eine Validierung gegen die Regeln der EN 16931 zeigt das schnell.
Sonderfälle erfassen: Gutschriften, Abschlags- und Schlussrechnungen sowie Korrekturen folgen denselben Regeln und werden in Tests gern vergessen.
Mit den wichtigsten Kunden testen: Einige Probe-Rechnungen an die umsatzstärksten Geschäftskunden zeigen, ob der Übertragungsweg und das Format beim Empfänger tatsächlich verarbeitet werden.
Stammdaten bereinigen: Fehlende oder veraltete Angaben fallen im strukturierten Format sofort auf, weil Pflichtfelder nicht mehr durch Freitext überdeckt werden.

Hinzu kommt die Aufbewahrung. Maßgeblich ist der strukturierte Datensatz, nicht die Sichtkopie. Wer bisher nur PDFs archiviert, sollte sicherstellen, dass ab Januar das Original revisionssicher abgelegt wird.

Der 1. Januar 2027 kommt für viele Unternehmen nicht überraschend. Überraschend wird er dort, wo erst die erste abgelehnte Rechnung zeigt, dass das eigene Format nicht trägt.

NIS2-Registrierung: Warum der 31. Juli 2026 die eigentliche Frist ist

2026-07-20T00:00:00+00:00

Die dreimonatige Registrierungsfrist nach dem NIS2-Umsetzungsgesetz ist am 6. März 2026 abgelaufen. Trotzdem ist für viele Einrichtungen die wichtigere Zahl eine andere: der 31. Juli 2026. Bis zu diesem Tag erwartet das BSI die ausstehenden Registrierungen und behandelt verspätete Meldungen bis dahin mit praktischer Nachsicht. Von rund 29.500 betroffenen Unternehmen hatten sich zum gesetzlichen Stichtag nur etwa 11.500 registriert, bis Ende Mai waren es rund 18.500. Es fehlt also weiterhin ein erheblicher Teil.

Wichtig ist die richtige Einordnung dieser Nachfrist. Sie ist eine Duldung bei der Registrierung, keine Verschiebung des Gesetzes. Die materiellen Pflichten gelten seit dem 6. Dezember 2025, unabhängig davon, ob eine Einrichtung sich schon gemeldet hat.

Registrierung ist kein Verwaltungsakt, sondern Selbsteinschätzung

Anders als im alten KRITIS-System stellt das BSI keinen Bescheid aus, der die Betroffenheit feststellt. Jede Einrichtung muss selbst prüfen, ob sie unter das Gesetz fällt, und sich gegebenenfalls aktiv registrieren. Diese Selbsteinschätzung nach §28 BSIG ist der eigentliche erste Schritt, nicht das Ausfüllen des Portalformulars.

Grob gilt: wichtige Einrichtungen ab 50 Beschäftigten oder mehr als 10 Millionen Euro Jahresumsatz, besonders wichtige Einrichtungen ab 250 Beschäftigten oder mehr als 50 Millionen Euro Umsatz. Maßgeblich ist zusätzlich die Zugehörigkeit zu einem der 18 Sektoren. Bestimmte Einrichtungen zählen unabhängig von ihrer Größe, etwa qualifizierte Vertrauensdiensteanbieter, DNS- und TLD-Betreiber oder Anbieter öffentlicher Telekommunikationsdienste. Wer hier zu eng prüft und sich fälschlich als nicht betroffen einstuft, trägt das Risiko selbst.

Wer bis Ende Juli handeln muss

Betroffen ist, wer die Kriterien erfüllt und sich noch nicht registriert hat. Das sind derzeit vor allem Einrichtungen, die ihre Betroffenheit noch nicht geprüft haben, und solche, die sie geprüft, die Registrierung aber aufgeschoben haben. Beides lässt sich in den verbleibenden Tagen nachholen, die Registrierung selbst ist der kleinere Aufwand.

Der größere Aufwand ist die ehrliche Bestandsaufnahme dahinter: Fällt mein Unternehmen unter das Gesetz, und erfülle ich bereits die Pflichten, die seit Dezember gelten? Wer die Registrierung nachholt, ohne diese Frage zu beantworten, hat formal gemeldet, aber inhaltlich wenig gewonnen.

Die Pflichten gelten unabhängig von der Registrierung

Die Registrierung ist die Eintrittskarte, nicht die Pflicht selbst. §30 verlangt Risikomanagementmaßnahmen, darunter Monitoring, Logging, Incident Handling, Business Continuity und Lieferkettensicherheit. §32 regelt die gestuften Meldepflichten mit Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden und Abschlussbericht binnen eines Monats. §38 nimmt die Geschäftsleitung in die Verantwortung, und §65 setzt den Rahmen mit Bußgeldern von bis zu 10 Millionen Euro.

Diese Pflichten laufen seit dem 6. Dezember 2025. Die Nachfrist beim BSI ändert daran nichts. Eine Einrichtung, die sich am 31. Juli registriert, aber im Juni einen erheblichen Vorfall nicht gemeldet hat, war zu diesem Zeitpunkt bereits säumig.

Was jetzt sinnvoll ist

Drei Schritte helfen unmittelbar: die Betroffenheit nach §28 sauber dokumentieren, damit die Einschätzung im Zweifel belegbar ist; die Registrierung nachholen, solange die Nachsicht des BSI gilt; und die Erkennung so aufstellen, dass die 24-Stunden-Frühwarnung realistisch erreichbar ist. Ein einmal durchgespielter Meldeablauf zeigt schnell, wo die Chronik eines Vorfalls reißt.

In unserem Modul Perstat sind Monitoring, Security Posture und ein append-only Audit-Trail so verbunden, dass sich die für §32 nötige Vorfallchronik nachvollziehbar erzeugen lässt. Der eigentliche Punkt ist aber unabhängig vom Werkzeug, nämlich die eigene Betroffenheit zu klären und die laufenden Pflichten nicht mit der einmaligen Registrierung zu verwechseln.

Die Registrierung ist der Anfang der Pflicht, nicht ihr Ende.

ViDA: Was nach der deutschen E-Rechnungspflicht kommt

2026-07-16T00:00:00+00:00

Viele Unternehmen betrachten die E-Rechnung als deutsches Thema mit deutschem Fahrplan: Empfang seit 2025, Versand ab 2027 und 2028. Das ist richtig, aber unvollständig. Über diesem nationalen Stufenplan liegt eine europäische Reform, die den Rahmen langfristig setzt: VAT in the Digital Age, kurz ViDA, formal beschlossen am 11. März 2025 als Richtlinie (EU) 2025/516. Wer seine E-Rechnungs-Architektur heute nur auf die deutschen Fristen auslegt, plant zu kurz.

Der wichtigste Punkt vorab: ViDA und die deutsche Pflicht widersprechen sich nicht, sie greifen ineinander. Beide setzen auf die europäische Norm EN 16931 als strukturiertes Format. Wer diese Norm sauber umsetzt, arbeitet in beide Richtungen.

Der Rahmen hat sich schon 2025 verschoben

Ein oft übersehener Baustein ist bereits in Kraft. Seit dem 14. April 2025 dürfen Mitgliedstaaten eine inländische B2B-E-Rechnungspflicht einführen, ohne dafür eine Sondergenehmigung der EU zu benötigen, und ohne dass der Rechnungsempfänger zustimmen muss. Genau das ist die rechtliche Grundlage, auf der nationale Pflichten wie die deutsche jetzt ohne Umweg stehen. Die strukturierte E-Rechnung nach EN 16931 wird damit vom Sonderfall zum europäischen Normalfall.

2030 ist das eigentliche Datum

Der deutsche Stufenplan endet 2028, die europäische Reform beginnt danach erst richtig. Die zentralen Termine:

1. Januar 2027: kleinere Klarstellungen bei One-Stop-Shop und IOSS.
1. Juli 2028: neue Plattformregeln (Deemed Supplier) für kurzfristige Vermietung und Personenbeförderung sowie Schritte zur einheitlichen Mehrwertsteuer-Registrierung.
1. Juli 2030: digitale Meldepflichten (Digital Reporting Requirements) für grenzüberschreitende innergemeinschaftliche B2B-Umsätze. Die Rechnung muss strukturiert nach EN 16931 ausgestellt werden, und zwar binnen 10 Tagen nach dem Steuertatbestand. Die bisherige Zusammenfassende Meldung entfällt.
1. Januar 2035: nationale Echtzeit-Meldesysteme müssen an das EU-Modell angeglichen sein.

Für den grenzüberschreitenden Handel ist 2030 damit die härtere Zäsur als 2028. Wer heute nur an den innerdeutschen Versand denkt, verpasst die Meldedimension, die kurz darauf folgt.

Meldung ist nicht gleich Rechnung

Der konzeptionelle Sprung bei ViDA liegt weniger im Format als im Meldeweg. Bislang gilt: Rechnung stellen, später sammeln, periodisch melden. Künftig rückt die Meldung nah an die Transaktion. Die strukturierte Rechnung ist zugleich der Datensatz, der der Steuerverwaltung nahezu zeitnah gemeldet wird. Das verändert Anforderungen an Datenqualität und Zeitpunkt: Ein Format, das erst im Nachhinein korrigiert wird, passt nicht zu einer Meldung, die binnen Tagen fällig ist.

Wer die Empfangs- und Versandprozesse heute aufbaut, sollte deshalb zwei Dinge trennen und beide bedenken: das Format (EN 16931, in Deutschland als XRechnung und ZUGFeRD) und die spätere Meldefähigkeit über interoperable Wege wie Peppol.

Was jetzt sinnvoll ist

Drei Prüfungen zahlen sich aus: Ist die eingesetzte Lösung wirklich EN-16931-konform, oder nur PDF-mit-Anhang? Sind grenzüberschreitende B2B-Umsätze im Prozess sauber getrennt, weil genau sie 2030 zuerst betroffen sind? Und ist die Architektur auf interoperable Übertragung ausgelegt, damit eine spätere Meldepflicht keine Neuimplementierung erzwingt?

Unsere eigene Abrechnung stellt Rechnungen von Beginn an nach EN 16931 aus, mit XRechnung und ZUGFeRD, ausgerichtet auf die Norm, die sowohl die deutsche Pflicht als auch ViDA trägt. Der eigentliche Punkt ist aber unabhängig vom Werkzeug, nämlich die E-Rechnung nicht als deutsches Zwischenziel zu behandeln, sondern als Baustein eines europäischen Meldesystems, das 2030 scharf gestellt wird.

Die deutsche Pflicht ist die erste Stufe. ViDA ist die Treppe.

Cloud Sovereignty Framework: Wenn Souveränität zur messbaren Vergabegröße wird

2026-07-13T00:00:00+00:00

Digitale Souveränität war lange ein Begriff für Grundsatzreden, schwer zu fassen und noch schwerer zu prüfen. Mit dem Cloud Sovereignty Framework hat die EU-Kommission daraus ein Bewertungsraster gemacht. Die im Oktober 2025 veröffentlichte Fassung (Version 1.2.1) definiert acht Souveränitätsziele und eine Methodik, mit der sich Cloud-Anbieter strukturiert einordnen lassen. Im April 2026 folgte die Praxisprobe: ein Rahmenvertrag über 180 Millionen Euro für souveräne Cloud-Dienste der EU-Institutionen, vergeben an vier europäische Anbieter.

Damit verschiebt sich die Debatte. Souveränität ist nicht mehr nur ein Versprechen im Marketing, sondern ein Kriterium, das in Ausschreibungen abgefragt und bepunktet wird.

Acht Ziele statt eines Bauchgefühls

Das Framework gruppiert Souveränität in acht Zieldimensionen: strategisch, rechtlich und jurisdiktionell, Daten und KI, operativ, Lieferkette, technologisch, Sicherheit und Compliance sowie ökologische Nachhaltigkeit. Der Reiz liegt in der Vollständigkeit. Wer nur auf den Hosting-Standort schaut, erfasst vielleicht die rechtliche Dimension, übersieht aber die Lieferkette hinter dem Betrieb oder die Frage, wer im Ernstfall die Kontrolle über den technischen Stack behält.

Erst das Zusammenspiel ergibt ein belastbares Bild. Ein Anbieter kann in Frankfurt hosten und trotzdem an einer Konzernmutter außerhalb der EU hängen, deren Jurisdiktion im Zweifel durchgreift.

SEAL macht das Ergebnis vergleichbar

Kern der Methodik ist der Sovereignty Effectiveness Assurance Level, kurz SEAL. Er bündelt die Bewertung zu Stufen, die Schwellen für unterschiedliche Souveränitätsansprüche markieren: SEAL-2 für die höchste Stufe der Datensouveränität, SEAL-3 für technologische Autonomie und SEAL-4 für vollständige Souveränität. Eine Behörde muss so nicht jedes Detail selbst gewichten, sondern kann eine Zielstufe vorgeben und Angebote daran messen.

Das ist der eigentliche Fortschritt. Eine Stufenlogik übersetzt ein diffuses Ziel in eine Anforderung, die sich ausschreiben, vergleichen und nachprüfen lässt. Für Anbieter heißt das: Souveränität wird testierbar, nicht nur behauptbar.

Warum das über die Institutionen hinaus wirkt

Die erste Vergabe betraf die EU-Institutionen selbst, mit vier europäischen Anbietern als Zuschlagsempfängern. Interessant ist aber die angekündigte Fortschreibung: Die Kommission arbeitet daran, die Bewertungsmethodik auch anderen Behörden und Mitgliedstaaten zugänglich zu machen. Sobald nationale und kommunale Vergabestellen dasselbe Raster nutzen, wird SEAL zu einer gemeinsamen Sprache für Souveränität in der öffentlichen Beschaffung.

Für Unternehmen, die an den öffentlichen Sektor liefern oder regulierte Kunden bedienen, ist das ein Frühindikator. Was heute für EU-Institutionen gilt, taucht erfahrungsgemäß bald in nachgelagerten Ausschreibungen und Lieferantenfragebögen wieder auf.

Was jetzt sinnvoll ist

Drei Fragen lohnen sich unabhängig von der nächsten Ausschreibung: In welchen der acht Dimensionen ist die eigene Cloud-Nutzung tatsächlich souverän, und wo hängt sie an einer außereuropäischen Jurisdiktion? Welche Zielstufe brauchen die eigenen Anwendungsfälle wirklich, denn nicht jede Last verlangt SEAL-4? Und lässt sich die eigene Position belegen, nicht nur behaupten?

Die Datargo-Plattform ist auf EU-Hosting in Frankfurt und Betreiberkontrolle in der EU ausgelegt, was mehrere dieser Dimensionen zugleich adressiert. Der eigentliche Punkt ist aber unabhängig vom Anbieter, nämlich Souveränität künftig entlang der acht Ziele zu prüfen statt am einzelnen Rechenzentrumsstandort.

Souveränität wird nicht länger behauptet. Sie wird bewertet.

APIs als Teil der Lieferkette: warum Schnittstellensicherheit zur Nachweispflicht wird

2026-06-23T00:00:00+00:00

Software ist heute selten ein Monolith. Module, Partnerdienste und Mandanten reden über Schnittstellen miteinander, und genau diese APIs sind die stillen Verbindungsstücke der Lieferkette. NIS2 verlangt in der Risikobetrachtung ausdrücklich die Sicherheit der Lieferkette. Damit rückt eine Frage in den Vordergrund, die lange als rein technisch galt: Wie sicher und wie prüfbar sind die eigenen Schnittstellen?

Die Schnittstelle ist die Angriffsfläche

Die häufigsten API-Schwachstellen sind keine exotischen Exploits, sondern Berechtigungsfehler. In der OWASP API Security Top 10 steht Broken Object Level Authorization an erster Stelle: Eine API liefert Daten aus, ohne sauber zu prüfen, ob der anfragende Account sie überhaupt sehen darf. Eine veränderte Objekt-ID im Request genügt dann, um fremde Datensätze abzurufen. Drei Kontrollpunkte entscheiden in der Praxis über die Robustheit:

Autorisierung pro Objekt: Jede Anfrage prüft, ob der Aufrufer genau dieses Objekt sehen oder ändern darf, nicht nur, ob er angemeldet ist.
Authentifizierung: Tokens sind kurzlebig, gebunden und widerrufbar, statt langlebiger Allzweckschlüssel.
Begrenzung: Rate-Limiting und Quoten verhindern, dass eine Schnittstelle zur Datenabflussstelle oder zum Lastvektor wird.

Was man nicht dokumentiert, kann man nicht absichern

Viele Vorfälle gehen nicht auf bekannte, sondern auf vergessene Schnittstellen zurück: Shadow-APIs, die nie im Inventar landeten, und Zombie-APIs, die nach einem Versionswechsel offen blieben. Ohne vollständiges, aktuelles Inventar bleibt jede Absicherung lückenhaft. Eine gepflegte OpenAPI-Beschreibung ist dabei mehr als Komfort für Entwickler: Sie ist der Vertrag, gegen den sich Berechtigungen, Versionen und erwartetes Verhalten überhaupt prüfen lassen. Ein dediziertes Developer-Portal, das diese Beschreibungen mandantenfähig und versioniert vorhält, macht aus verstreutem Wissen ein nachvollziehbares Verzeichnis.

Sicherheit als nachweisbare Eigenschaft

Im Prüfungsfall genügt es nicht zu sagen, die APIs seien abgesichert. Gefragt ist Evidenz: welche Schnittstellen existieren, in welcher Version, mit welchen Berechtigungen, und wer wann was abgerufen hat. Versionierung, Zugriffsprotokolle und ein gepflegtes Schnittstellenverzeichnis verwandeln Sicherheit von einer Behauptung in eine belegbare Eigenschaft. Das ist dieselbe Logik, die NIS2 an anderer Stelle für Monitoring und Meldung anlegt, nur angewandt auf die Verbindungsstücke zwischen den Systemen.

Die Lieferkette ist nur so vertrauenswürdig wie ihre Schnittstellen. Und eine Schnittstelle, die niemand vollständig kennt, lässt sich weder absichern noch belegen.

Der EU Data Act und das Ende der Wechselgebühren: Cloud-Switching wird zur Pflicht

2026-06-23T00:00:00+00:00

Anbieterbindung war lange ein kommerzielles Druckmittel: Wer wechseln wollte, zahlte für den Ausgang, kämpfte mit proprietären Formaten und verlor Wochen an Migrationsarbeit. Der EU Data Act (Verordnung (EU) 2023/2854) dreht diese Logik um. Seit dem 12. September 2025 ist die Verordnung anwendbar, und ihr Kapitel VI macht den Wechsel des Cloud-Anbieters zu einem durchsetzbaren Recht der Kundinnen und Kunden.

Was seit September 2025 gilt

Anbieter von Datenverarbeitungsdiensten (IaaS, PaaS, SaaS) müssen alle Hindernisse abbauen, die einen Wechsel erschweren, also vorkommerzielle, kommerzielle, technische, vertragliche und organisatorische Hürden. Konkret heißt das: eine maximale Kündigungsfrist von zwei Monaten, eine Übergangsphase von 30 Tagen für den eigentlichen Umzug (bei technischer Unmöglichkeit auf bis zu sieben Monate verlängerbar) und das Recht, Daten und digitale Vermögenswerte mitzunehmen. Für Neuverträge gelten diese Pflichten bereits.

Die Gebührenbremse bis Januar 2027

Der Data Act reduziert Wechselentgelte schrittweise. Zum 12. Januar 2027 greift das vollständige Verbot: Für den Wechsel zwischen Datenverarbeitungsdiensten dürfen dann keine Entgelte mehr verlangt werden. Bis zum 12. September 2027 müssen zudem Altverträge im B2B-Bereich von unfairen Klauseln befreit werden. Wer seine Preis- und Vertragsmodelle auf Ausstiegskosten gestützt hat, verliert diese Grundlage absehbar.

Switching ist mehr als ein Datenexport

Der praktische Knackpunkt liegt in der funktionalen Äquivalenz. Ein Export von Rohdaten genügt nicht, wenn die Zielumgebung damit nichts anfangen kann. Der Data Act verlangt offene Schnittstellen und, wo möglich, gängige Formate, damit ein Dienst beim Ziel wieder lauffähig wird. Drei Fragen entscheiden in der Praxis, ob ein Wechsel real durchführbar ist:

Datenmodell: Liegen Inhalte in dokumentierten, offenen Strukturen vor oder in einem proprietären Schema?
Schnittstellen: Gibt es stabile, versionierte APIs für den Export laufender und historischer Daten?
Metadaten: Werden Konfiguration, Rechte und Verarbeitungslogik mit übergeben oder bleiben sie im alten System zurück?

Was das für die Architektur heißt

Souveränität ist hier kein Häkchen, sondern eine Eigenschaft des Systementwurfs. Wer Portabilität erst beim Auszug bedenkt, hat sie verloren. Offene Datenmodelle, dokumentierte Exportwege und ein Hosting im europäischen Rechtsraum reduzieren nicht nur das Lock-in-Risiko, sie sind zunehmend die Voraussetzung dafür, die Data-Act-Pflichten überhaupt erfüllen zu können. Bei einer Suite, die ihre Module über offene Schnittstellen und ein Hosting in Frankfurt zusammenhält, ist der Anbieterwechsel keine Drohkulisse, sondern ein nachvollziehbarer Vorgang.

Der Data Act fragt nicht, ob Sie Ihre Kundinnen und Kunden halten wollen. Er fragt, ob diese gehen könnten, wenn sie es wollten.

Passkeys im Unternehmen: phishing-resistente Anmeldung jenseits von Passwort und OTP

2026-06-23T00:00:00+00:00

Phishing bleibt das verlässlichste Einfallstor in Unternehmensnetze, und die meisten Zweitfaktoren ändern daran wenig. Passwort plus SMS-Code, TOTP-App oder Push-Bestätigung gilt als Mehrfaktor-Authentifizierung, ist aber im Kern angreifbar: Wer die Nutzerin auf eine gefälschte Seite lockt, kann auch den Zweitfaktor in Echtzeit abgreifen. FIDO2-Passkeys setzen an genau dieser Stelle an.

Warum klassische MFA phishbar bleibt

Das Problem ist nicht die Anzahl der Faktoren, sondern ihre Übertragbarkeit. Ein Einmalcode ist ein geteiltes Geheimnis: Er funktioniert überall dort, wo er eingegeben wird, auch auf der Phishing-Seite. Es fehlt die Bindung an die echte Gegenstelle. Genau diese Bindung leistet WebAuthn, der Standard hinter Passkeys.

Was Passkeys anders machen

Ein Passkey ist ein kryptografisches Schlüsselpaar. Der private Schlüssel verlässt das Gerät nie, signiert wird nur gegenüber der Domain, für die der Passkey registriert wurde. Diese Origin-Bindung macht die klassische Phishing-Umleitung wirkungslos: Eine gefälschte Domain erhält schlicht keine gültige Signatur. Es gibt kein Geheimnis, das man auf der falschen Seite eingeben könnte. Das BSI hat dazu ein formales Bedrohungsmodell veröffentlicht, und mit der Technischen Richtlinie BSI TR-03188 existiert eine Vorgabe für den Betrieb eines Passkey-Servers.

Synced, device-bound oder Hardware-Key

Passkey ist nicht gleich Passkey. Ein tragfähiger Rollout staffelt die Variante nach Schutzbedarf:

Hardware-Sicherheitsschlüssel: für privilegierte Zugänge und Administration, wo höchste Sicherheit zählt.
Gerätegebundene Passkeys: auf verwalteten Firmengeräten, an die Hardware gekoppelt und nicht synchronisierbar.
Synchronisierte Passkeys: für die breite Belegschaft, komfortabel über mehrere Geräte, mit etwas geringerem Härtegrad.

Diese Abstufung deckt sich mit der Erwartung, die Aufsicht und Prüfwesen zunehmend formulieren: Für sensible administrative Zugänge gilt phishing-resistente Authentifizierung zunehmend als Anforderung, nicht als Empfehlung.

Die offenen Fragen

Der schwierige Teil liegt nicht in der Anmeldung, sondern in den Randfällen. Was passiert beim Geräteverlust? Wie sieht ein Wiederherstellungsweg aus, der nicht selbst zur phishbaren Hintertür wird? Und wie geht man mit Altsystemen um, die WebAuthn noch nicht sprechen? Ein durchdachter Rollout beantwortet diese Fragen vorab, statt sie im Störfall zu improvisieren. Als Klammer der Plattform verankert Datargo ID Single Sign-On und MFA an einer Stelle, was diese Fragen bündelt, statt sie über jede Anwendung einzeln zu verteilen.

Die entscheidende Verschiebung ist diese: weg von einem Geheimnis, das man kennen und damit verraten kann, hin zu einem Schlüssel, der an Gerät und Gegenstelle gebunden bleibt.

Wenn der Chatbot sich zu erkennen geben muss: KI-Transparenz im Kundenservice ab August 2026

2026-06-23T00:00:00+00:00

Automatisierte Erstantworten, KI-gestützte Ticket-Vorklassifikation, generierte Antwortvorschläge: Im Kundenservice ist KI längst Alltag. Ab dem 2. August 2026 wird Artikel 50 des EU AI Act durchsetzbar, und damit gelten verbindliche Transparenzpflichten für genau diese Systeme. Diese Pflichten sind von den Vorgaben für Anbieter universeller KI-Modelle (GPAI) zu trennen: Hier geht es nicht um das Modell, sondern um die Interaktion mit Menschen.

Was Artikel 50 verlangt

Der Kern ist eine Hinweispflicht. Anbieter von KI-Systemen, die zur direkten Interaktion mit Menschen bestimmt sind (etwa Chatbots), müssen sicherstellen, dass die betroffene Person erkennt, dass sie mit einem KI-System kommuniziert. Der Hinweis muss spätestens zum Zeitpunkt der ersten Interaktion erfolgen, es sei denn, der KI-Einsatz ist aus den Umständen offensichtlich. Hinzu kommt: KI-erzeugte oder bearbeitete Inhalte müssen maschinenlesbar als solche markiert werden, und Inhalte von öffentlichem Interesse, die als echt erscheinen könnten, sind gesondert zu kennzeichnen.

Was “informiert” praktisch heißt

Eine Zeile im Impressum reicht nicht. Der Hinweis muss klar, vor oder zu Beginn des Gesprächs und für die Nutzerin verständlich sein. In der Praxis bedeutet das mehr als ein Banner:

Sichtbarkeit: Der KI-Hinweis steht am Anfang des Dialogs, nicht in einer ausklappbaren Fußnote.
Sprache: Der Hinweis erscheint in der Sprache, in der die Person den Kontakt aufnimmt, nicht nur auf Englisch.
Übergabe: Beim Wechsel zwischen KI und menschlicher Bearbeitung sollte erkennbar bleiben, mit wem gerade gesprochen wird.

Mehr als ein Hinweisbanner

Die schwierigere Seite ist die Nachweisbarkeit. Wer im Prüfungsfall zeigen will, dass der Hinweis tatsächlich und konsistent ausgespielt wurde, braucht eine Protokollierung der Konfiguration und der ausgelieferten Hinweise. In mandantenfähigen Umgebungen kommt hinzu, dass jede Mandantin ihre eigenen Kanäle, Sprachen und Eskalationswege betreibt: Die Transparenzlogik muss pro Mandant greifen, nicht nur global. Ein Customer-Service-Hub wie Datargo CRM, der Live-Chat, Tickets und Kontakte mandantenfähig zusammenführt, bietet dafür den natürlichen Ort, um Hinweis, Sprachzuordnung und Mensch-Übergabe einheitlich zu verankern.

Artikel 50 verbietet KI im Kundenservice nicht. Er verlangt nur, dass niemand im Unklaren darüber bleibt, mit wem oder mit was er spricht.

47-Tage-Zertifikate: Der CA/Browser-Fahrplan bis 2029

2026-06-09T00:00:00+00:00

Die Diskussion ist entschieden, und ein Teil davon ist bereits Betriebsrealität: Seit dem 15. März 2026 dürfen öffentlich vertrauenswürdige TLS-Zertifikate höchstens 200 Tage gültig sein, nicht mehr 398. Das ist die erste Stufe eines Fahrplans, den das CA/Browser-Forum im April 2025 mit Ballot SC-081v3 beschlossen hat: einstimmig, mit 29 Ja-Stimmen und keiner Gegenstimme. Am Ende dieses Fahrplans steht eine maximale Laufzeit von 47 Tagen.

Wer Zertifikate noch von Hand bestellt und im Kalender notiert, sollte die nächsten drei Jahre als Umbauprojekt einplanen, nicht als Reihe von Einzelterminen.

Der Fahrplan in Zahlen

Die maximale Gültigkeit sinkt in klar terminierten Stufen:

bis 14. März 2026: 398 Tage (der bisherige Standard)
ab 15. März 2026: 200 Tage (gilt heute)
ab 15. März 2027: 100 Tage
ab 15. März 2029: 47 Tage

Parallel, und das ist der operativ anspruchsvollere Teil, verkürzt sich die Wiederverwendbarkeit der Domain-Validierung (Domain Control Validation, DCV). Die einmal geprüfte Kontrolle über eine Domain darf künftig deutlich kürzer „nachgenutzt" werden, bevor sie erneut bestätigt werden muss:

ab 15. März 2026: 200 Tage
ab 15. März 2027: 100 Tage
ab 15. März 2029: 10 Tage

Für OV- und EV-Zertifikate sinkt zusätzlich die Wiederverwendbarkeit der geprüften Organisationsdaten (Subject Identity Information) zum 15. März 2026 von 825 auf 398 Tage.

Die 47 Tage sind also nur die Schlagzeile. Die 10 Tage DCV-Reuse ab 2029 sind der eigentliche Taktgeber: Ab dann muss faktisch alle zehn Tage neu nachgewiesen werden, dass die Domain noch unter eigener Kontrolle steht.

Warum die Verkürzung kommt

Hinter dem Schritt steht eine einfache Sicherheitslogik. Ein Zertifikat ist eine Vertrauensaussage mit Verfallsdatum. Je länger es gültig ist, desto länger wirkt eine Fehlausstellung, ein kompromittierter Schlüssel oder ein veralteter kryptografischer Parameter fort. Der klassische Gegenmechanismus, die Sperrung über CRL und OCSP, funktioniert in der Praxis unzuverlässig: Sperrlisten werden nicht überall zeitnah ausgewertet, OCSP wird zunehmend abgekündigt. Kurze Laufzeiten ersetzen die Sperrung durch das Ablaufen. Ein Problem heilt sich, weil das betroffene Zertifikat ohnehin bald ungültig wird.

Der zweite Treiber ist Krypto-Agilität. Wer Zertifikate regelmäßig erneuert, kann Algorithmen, Schlüssellängen und Profile im laufenden Betrieb wechseln, eine Grundvoraussetzung für die anstehende Migration zu Post-Quantum-Verfahren. Lange Laufzeiten zementieren dagegen den Status quo.

Was das für den Betrieb bedeutet

Die zentrale Folge ist banal und unausweichlich: Manuelle Erneuerung skaliert nicht mehr. Ein 47-Tage-Zertifikat wird, mit vernünftigem Puffer, etwa alle 30 Tage ausgetauscht. Über einen mittelgroßen Bestand hinweg ist das kein Kalendereintrag mehr, sondern ein Prozess, der ohne menschliches Zutun laufen muss.

Drei Fähigkeiten entscheiden darüber, ob dieser Umbau gelingt:

Automatisierung. ACME (RFC 8555) ist der etablierte Standard für automatische Ausstellung und Erneuerung, nicht nur für Let’s Encrypt, sondern zunehmend auch für kommerzielle und interne CAs. Wo ACME nicht greift, braucht es API-gestützte Renewal-Workflows mit Approval, damit Compliance-Kontrollen erhalten bleiben.

Discovery. Automatisieren lässt sich nur, was man kennt. Der typische Ausfall im Jahr 2029 wird nicht das gut gepflegte Zertifikat auf dem Hauptsystem sein, sondern das vergessene auf einem Load-Balancer-Endpoint, einer Appliance oder in einem Cloud-Account, den niemand mehr auf dem Schirm hat. Aktive Netzscans und passive Cloud-Discovery sind die Voraussetzung dafür, dass kurze Laufzeiten nicht zu kurzfristigen Ausfällen werden.

Eigentümerschaft. Jedes Zertifikat braucht einen klar zugeordneten Verantwortlichen, eine bekannte CA und ein hinterlegtes Erneuerungsverfahren. Ein Inventar, das diese drei Angaben pro Zertifikat führt, ist die eigentliche Versicherung gegen die 47-Tage-Realität.

Genau dieses Muster (Discovery zuerst, dann CA-agnostische Automatisierung mit Approval) liegt unserem Modul NextPKI zugrunde. Die regulatorische Stoßrichtung ist davon unabhängig: Wer den Bestand sichtbar macht und die Erneuerung automatisiert, ist vorbereitet, ganz gleich mit welchem Werkzeug.

Was jetzt sinnvoll ist

Drei Jahre klingen nach viel Zeit, aber die 200-Tage-Stufe läuft bereits. Konkret lohnt sich jetzt: ein vollständiges Inventar aller TLS-Zertifikate über Netz, Cloud und Endpunkte hinweg; die Identifikation aller Stellen, an denen heute noch manuell erneuert wird; ein Pilot mit ACME-basiertem Auto-Renewal auf unkritischen Diensten; und die Klärung, welche internen Systeme bis 2029 zehntägige Domain-Revalidierung technisch überhaupt mittragen können.

Die 47 Tage kommen nicht überraschend und nicht auf einmal. Sie kommen in Stufen, und die erste steht bereits.

Cyber Resilience Act: Was der 11. September 2026 für Hersteller digitaler Produkte bedeutet

2026-06-09T00:00:00+00:00

In knapp drei Monaten wird aus einer Verordnung Betriebsrealität. Ab dem 11. September 2026 greifen die ersten verbindlichen Pflichten des Cyber Resilience Act (Verordnung (EU) 2024/2847), und zwar genau die, die am meisten Prozess voraussetzen: die Meldung aktiv ausgenutzter Schwachstellen und schwerer Sicherheitsvorfälle. Die übrigen Produkt- und Konformitätspflichten folgen mit der vollständigen Anwendung am 11. Dezember 2027.

Wer Produkte mit digitalen Elementen in der EU herstellt, importiert oder vertreibt, sollte den September daher nicht als fernes Datum behandeln, sondern als den Tag, an dem ein funktionierender Meldeweg vorhanden sein muss.

Was am 11. September 2026 beginnt

Der CRA verpflichtet Hersteller, eine aktiv ausgenutzte Schwachstelle oder einen schweren Sicherheitsvorfall in einem gestaffelten Verfahren zu melden. Eine erste Frühwarnung geht binnen 24 Stunden an das zuständige CSIRT und an die ENISA, eine ausführlichere Meldung folgt binnen 72 Stunden, ein Abschlussbericht später. Adressiert wird das über eine zentrale europäische Meldeplattform.

Wichtig ist die Abgrenzung zu NIS2: Dort meldet eine betroffene Einrichtung Vorfälle in ihrem eigenen Betrieb. Beim CRA meldet der Hersteller eine Schwachstelle in seinem Produkt, unabhängig davon, bei welchem Kunden sie ausgenutzt wird. Beide Regime können gleichzeitig gelten, und sie verlangen unterschiedliche Meldewege.

Was bis Dezember 2027 dazukommt

Die Meldepflicht ist nur der erste Baustein. Mit der vollständigen Anwendung verlangt der CRA über den gesamten Produktlebenszyklus hinweg nachweisbare Sicherheit:

Security by Design: Sicherheit ist Teil der Entwicklung, nicht ein nachträglicher Aufsatz. Das umfasst sichere Voreinstellungen und eine angreifbare Fläche, die so klein wie möglich gehalten wird.
Software Bill of Materials (SBOM): Hersteller müssen die enthaltenen Komponenten und Abhängigkeiten kennen und dokumentieren. Ohne diese Stückliste lässt sich bei einer neuen Schwachstelle nicht beantworten, ob das eigene Produkt betroffen ist.
Schwachstellenmanagement und Updates: Sicherheitsupdates müssen über mindestens fünf Jahre bereitgestellt werden, oder über die erwartbare Lebensdauer des Produkts, falls diese kürzer ist.
CE-Kennzeichnung: Ab Dezember 2027 dürfen Produkte mit digitalen Elementen ohne CRA-Konformität nicht mehr in der EU in Verkehr gebracht werden.

Eine Ausnahme für kleine und mittlere Unternehmen gibt es nicht. Wer betroffene Produkte herstellt oder importiert, fällt unabhängig von seiner Größe unter die Verordnung.

Was das praktisch bedeutet

Die Meldepflicht ab September ist organisatorisch anspruchsvoller, als die kurze Frist vermuten lässt. 24 Stunden bis zur Frühwarnung sind keine Zeit, um erst eine Zuständigkeit zu klären. Es braucht vorab einen benannten Verantwortlichen, einen dokumentierten Prozess und die technische Fähigkeit, einen Vorfall überhaupt zeitnah zu erkennen.

Genau hier verbinden sich zwei Themen, die oft getrennt behandelt werden: das Erkennen (Monitoring und Security Posture) und das Belegen (eine nachvollziehbare Spur, wer wann was gemeldet hat). Wer beides bereits für NIS2 oder ISO 27001 aufgebaut hat, kann darauf aufsetzen. In unserem Modul Perstat ist dieses Muster aus kontinuierlicher Überwachung und auditierbarer Evidenz angelegt, doch die regulatorische Anforderung steht unabhängig vom Werkzeug: Ohne verlässliche Erkennung läuft jede Meldefrist ins Leere.

Was jetzt sinnvoll ist

Drei Schritte lohnen sich vor September: erstens klären, welche eigenen Produkte als „Produkte mit digitalen Elementen" gelten und damit in den Anwendungsbereich fallen. Zweitens den Meldeprozess für aktiv ausgenutzte Schwachstellen aufsetzen, mit klarer Zuständigkeit und den Fristen 24 Stunden, 72 Stunden und Abschlussbericht. Drittens mit dem Aufbau einer SBOM beginnen, denn sie ist die Voraussetzung dafür, im Ernstfall überhaupt sagen zu können, ob man betroffen ist.

Der 11. September 2026 markiert nicht das Ende der Vorbereitung, sondern den Beginn der Pflicht. Die Arbeit dahinter, Erkennung und Dokumentation, lässt sich nicht in 24 Stunden nachholen.

eIDAS 2.0 und das EUDI-Wallet: Was akzeptierende Stellen bis Ende 2026 vorbereiten müssen

2026-06-09T00:00:00+00:00

In rund einem halben Jahr läuft eine Frist ab, die viele Unternehmen noch als ferne Regulierung behandeln: Bis zum 24. Dezember 2026 müssen alle 27 EU-Mitgliedstaaten ihren Bürgerinnen und Bürgern mindestens ein European Digital Identity Wallet (EUDI-Wallet) bereitstellen. Grundlage ist die Verordnung (EU) 2024/1183 („eIDAS 2.0"), die seit dem 20. Mai 2024 in Kraft ist.

Für die Mehrzahl der Unternehmen ist die spannendere Frage nicht, wann das Wallet kommt, sondern wann sie es akzeptieren müssen. Und diese Frist folgt unmittelbar.

Wo der Rollout im Juni 2026 steht

Der regulatorische Unterbau ist weit gediehen. Das Architecture and Reference Framework (ARF) liegt in Version 2.8 vor, und es sind bereits 31 Durchführungsrechtsakte veröffentlicht, die auf Dutzende technischer Standards verweisen. Am 8. April 2026 hat die Europäische Kommission die Durchführungsverordnung zur Wallet-Registrierung (Enrollment) nachgelegt, einen zentralen Baustein, weil er regelt, wie Nutzer ihre Identität sicher ins Wallet bringen.

Der Umsetzungsstand der Mitgliedstaaten ist allerdings ungleich. Frankreich gilt mit „France Identité" als am weitesten, betreibt bereits einen produktiven Dienst und baut ihn zum offiziellen EUDI-Wallet aus; Italien und Polen folgen dicht dahinter. Deutschland hat angekündigt, seine staatlich getriebene Variante zum 2. Januar 2027 zu starten, also kurz nach Ablauf der EU-Frist.

Relying Party: die Rolle, die fast jeden betrifft

Eine Relying Party (vertrauender Beteiligter, akzeptierende Stelle) ist jede Stelle, die sich für Identifizierung oder Authentifizierung auf Wallet-Nachweise stützen möchte, vom Onboarding über die Altersprüfung bis zur starken Kundenauthentifizierung.

Die zeitliche Logik der Verordnung ist eindeutig: Sobald die Wallets verfügbar sind, müssen regulierte Sektoren und sehr große Online-Plattformen das EUDI-Wallet etwa ein Jahr später zur Authentifizierung akzeptieren. Aus der Bereitstellungsfrist Ende 2026 wird damit für viele eine Akzeptanzpflicht ab etwa Ende 2027. Banken, Versicherer, Telekommunikations- und Energieversorger, das Gesundheitswesen und große Plattformen stehen dabei in der ersten Reihe; alle anderen können das Wallet freiwillig akzeptieren und tun gut daran, die Integration nicht erst kurz vor knapp zu beginnen.

Was eine Relying Party jetzt klären sollte

Registrierung. Akzeptierende Stellen müssen sich vor der ersten Nutzung bei einer nationalen Registrierungsstelle anmelden und dabei angeben, welche Attribute sie zu welchem Zweck abfragen. Diese Registrierung ist kein Formalakt, sondern die rechtliche Grundlage dafür, überhaupt Daten anfragen zu dürfen.

Datensparsamkeit. Das Wallet ist auf selektive Offenlegung ausgelegt: Nutzer sollen genau die Attribute teilen, die ein Dienst wirklich braucht, etwa „über 18" statt des vollständigen Geburtsdatums. Wer mehr abfragt, als der Zweck rechtfertigt, gerät sowohl mit der eIDAS-Logik als auch mit der DSGVO in Konflikt. Die Definition des minimalen Attributsatzes pro Anwendungsfall ist deshalb die erste fachliche Aufgabe, nicht die letzte.

Technische Integration. Die Präsentation von Nachweisen stützt sich auf etablierte offene Protokolle und Formate, darunter OpenID for Verifiable Presentations sowie die Nachweisformate ISO/IEC 18013-5 (mdoc) und SD-JWT VC. Hinzu kommen Vertrauenslisten, über die ein Dienst prüft, ob ein vorgelegtes Wallet und seine Aussteller echt und zugelassen sind. Wer hier auf Standards setzt statt auf proprietäre Adapter, hält sich die Wallets verschiedener Mitgliedstaaten offen.

Anwendungsfälle und Governance. Onboarding und KYC, Altersnachweis, starke Kundenauthentifizierung und qualifizierte elektronische Signaturen über das Wallet sind die naheliegenden Felder. Jeder dieser Fälle braucht eine saubere Einwilligungs- und Protokollierungslogik: wer hat wann welches Attribut zu welchem Zweck angefragt und erhalten.

In unserem Modul Datargo ID ist genau diese Relying-Party-Rolle der rote Faden: ein Login als Klammer, vorbereitet auf den EUDI-Pfad. Der eigentliche Punkt ist aber unabhängig vom Werkzeug: Die Weichen für Registrierung, Attributminimierung und standardbasierte Integration stellt jede akzeptierende Stelle für sich.

Der nüchterne Zeitplan

Bis Ende 2026 werden die Wallets bereitgestellt, ab Anfang 2027 erscheinen die nationalen Lösungen (Deutschland am 2. Januar 2027), und etwa ein Jahr nach Verfügbarkeit greift die Akzeptanzpflicht für regulierte Sektoren. Das klingt nach 2027 und 2028, beginnt aber als Vorbereitungsaufgabe heute: Attributbedarf bestimmen, Registrierungsweg klären, eine standardbasierte Integration pilotieren. Die Frist ist gesetzt; die Vorbereitung ist freiwillig nur noch im Zeitpunkt, nicht im Ob.

Datensouveränität nach dem Data Privacy Framework: warum EU-Hosting zur Architekturfrage wird

2026-06-02T00:00:00+00:00

Wer personenbezogene Daten in die USA übermittelt, stützt sich seit 2023 auf den Angemessenheitsbeschluss zum EU-US Data Privacy Framework (DPF). Im September 2025 hat das Gericht der Europäischen Union (EuG) eine Klage dagegen abgewiesen, das Framework bleibt damit gültige Rechtsgrundlage. Doch der Fall ist nicht abgeschlossen: Ende Oktober 2025 wurde Rechtsmittel zum Europäischen Gerichtshof eingelegt (Rechtssache C-703/25 P). Ein erneutes Kippen, ein „Schrems III", ist nicht ausgeschlossen.

Diese Unsicherheit ist kein Grund zur Panik, aber ein guter Anlass, eine Frage von der Compliance-Ebene auf die Architekturebene zu heben.

Warum das mehr als ein Häkchen ist

Der bequeme Umgang mit Datentransfers besteht darin, sie als Vertragsfrage zu behandeln: Solange ein gültiger Beschluss oder Standardvertragsklauseln vorliegen, ist die Übermittlung gedeckt. Das stimmt rechtlich, verkennt aber das eigentliche Risiko. Jede Rechtsgrundlage für Drittlandstransfers steht seit Jahren unter Vorbehalt. Safe Harbor fiel 2015, das Privacy Shield 2020, und der aktuelle Rahmen wird gerichtlich überprüft. Wer seine Architektur an einer Rechtsgrundlage ausrichtet, die alle paar Jahre wackelt, baut eine Abhängigkeit ein, die er nicht kontrolliert.

Die robustere Frage lautet nicht „ist der Transfer gedeckt", sondern „findet der Transfer überhaupt statt". Daten, die die EU nicht verlassen und auf die kein Drittland-Zugriff besteht, brauchen keinen Angemessenheitsbeschluss.

Drei Architekturentscheidungen

Hosting-Standort. Wo die Daten physisch liegen, ist die erste und sichtbarste Entscheidung. Ein Rechenzentrum in Frankfurt statt in einer US-Region ist die Grundlage, aber für sich allein nicht ausreichend, denn der Standort allein sagt nichts über die Kontrolle.

Betreiberkontrolle. Entscheidend ist, wer rechtlich und tatsächlich Zugriff auf die Daten und die Infrastruktur hat. Ein in der EU stehender Server, der von einem Unternehmen betrieben wird, das einem Drittlandrecht mit weitreichenden Herausgabepflichten unterliegt, löst das Problem nur halb. Die Frage nach dem anwendbaren Recht des Betreibers gehört deshalb zur Architektur, nicht nur zum Vertrag.

Verschlüsselungshoheit. Wer die Schlüssel hält, kontrolliert den Zugriff. Verschlüsselung, bei der ausschließlich der Kunde über die Schlüssel verfügt, macht einen Zugriff durch Dritte technisch wirkungslos, selbst wenn dieser rechtlich erzwungen würde. Schlüsselhoheit verlagert die Kontrolle von einer Zusage zu einer technischen Eigenschaft.

Souveränität als Voreinstellung, nicht als Nachrüstung

Diese drei Entscheidungen lassen sich nachträglich nur schwer und teuer ändern. Sie gehören an den Anfang einer Architektur, nicht in ein Projekt, das erst startet, wenn ein Gericht den nächsten Beschluss kippt. Genau das meint Souveränität by design: nicht die nachträgliche Absicherung eines Transfers, sondern eine Auslegung, die den problematischen Transfer gar nicht erst nötig macht.

In unserer Plattform ist EU-Hosting in Frankfurt die Voreinstellung, nicht die Premium-Option. Der Punkt selbst ist jedoch unabhängig vom Anbieter: Wer Standort, Betreiberkontrolle und Schlüsselhoheit früh klärt, macht sich von der nächsten gerichtlichen Wendung unabhängig.

Das Data Privacy Framework mag die aktuelle Prüfung überstehen oder nicht. Eine Architektur, die nicht von der Antwort abhängt, ist in beiden Fällen die ruhigere Wahl.

EU AI Act: GPAI-Durchsetzung ab 2. August 2026 und was der Digital Omnibus verschoben hat

2026-05-26T00:00:00+00:00

Der EU AI Act gilt seit August 2024, doch viele seiner Pflichten greifen gestaffelt. Ein Datum sticht heraus: Am 2. August 2026 beginnt die aktive Durchsetzung gegenüber Anbietern von General-Purpose-AI-Modellen (GPAI) durch das EU AI Office, und parallel werden die nationalen Sanktionsregime wirksam. In Deutschland greift dazu das KI-Maßnahmen- und Innovationsgesetz (KI-MIG). Wer KI einsetzt oder bereitstellt, sollte den Stichtag kennen, aber auch die jüngsten Verschiebungen.

Was am 2. August 2026 beginnt

Die Pflichten für GPAI-Modelle sind seit August 2025 anwendbar. Was im August 2026 dazukommt, ist die Durchsetzung: Ein Jahr nach Anwendbarkeit erhält das AI Office die Befugnisse, sie auch tatsächlich zu vollziehen. Dazu gehören Informationsanforderungen, der Zugang zu Modellen und, als äußerstes Mittel, der Rückruf eines Modells. Aus einer Pflicht auf dem Papier wird damit eine durchsetzbare Pflicht.

Für die meisten Unternehmen ist nicht die Rolle des GPAI-Anbieters relevant, sondern die des Betreibers oder Anbieters nachgelagerter Systeme. Auch sie sollten wissen, welche Transparenz- und Dokumentationspflichten zu welchem Zeitpunkt greifen.

Was der Digital Omnibus vom Mai 2026 verschoben hat

Am 7. Mai 2026 hat die EU mit dem sogenannten Digital Omnibus einzelne Teilpflichten zeitlich gestreckt. Das ändert nichts am August-Stichtag für die GPAI-Durchsetzung, verschiebt aber andere Bausteine:

Hochrisiko-Systeme nach Anhang III: verschoben auf den 2. Dezember 2027.
Hochrisiko-Systeme nach Anhang I: verschoben auf den 2. August 2028.
Transparenzpflichten nach Artikel 50 (etwa Kennzeichnung von KI-generierten Inhalten): verschoben auf den 2. Dezember 2026.
KI-Reallabore: verschoben auf den 2. August 2027.

Diese Streckung ist kein Freibrief. Sie verschafft Zeit für die anspruchsvolleren Hochrisiko-Anforderungen, lässt aber die GPAI-Durchsetzung und die nationalen Sanktionen zum August unberührt.

Was das praktisch heißt

Drei Aufgaben sind unabhängig vom genauen Datum sinnvoll. Erstens eine Bestandsaufnahme: Welche KI-Systeme setzt das Unternehmen ein oder stellt es bereit, und in welche Risikoklasse fallen sie? Ohne diese Klarheit lässt sich keine Frist sinnvoll planen. Zweitens die Transparenz: Ab Dezember 2026 verlangt Artikel 50, dass bestimmte KI-Interaktionen und KI-generierte Inhalte erkennbar gemacht werden. Drittens die Dokumentation, denn die Durchsetzung ab August stützt sich darauf, dass Pflichten nicht nur erfüllt, sondern auch belegt sind.

Dieser letzte Punkt verbindet den AI Act mit den übrigen Compliance-Regimen. Ob NIS2, DORA oder AI Act: Die wiederkehrende Anforderung ist eine nachvollziehbare, auditierbare Spur dessen, was ein System tut und wer es verantwortet. Eine Plattform, die diese Spur ohnehin als Nebenprodukt des Betriebs erzeugt, erleichtert die Vorbereitung, gleich für welches Regime. Die Aufgabe selbst bleibt jedoch dieselbe: erst wissen, was man betreibt, dann belegen, dass es den Regeln entspricht.

Der 2. August 2026 ist kein abstrakter Termin. Er ist der Punkt, an dem die GPAI-Pflichten Zähne bekommen. Was der Digital Omnibus verschoben hat, betrifft die Hochrisiko-Schiene, nicht diesen Kern.

SD-JWT VC und OpenID4VP: die Protokolle hinter dem EUDI-Wallet

2026-05-12T00:00:00+00:00

Über das EUDI-Wallet wird viel auf der politischen und organisatorischen Ebene gesprochen: Bereitstellung durch die Mitgliedstaaten bis Ende 2026, Registrierungspflichten, Akzeptanzfristen. Wer das Wallet aber tatsächlich akzeptieren will, steht irgendwann vor einer technischen Frage: Wie prüfe ich konkret, dass ein vorgelegtes Attribut echt, gültig und für meinen Zweck ausreichend ist? Dieser Beitrag schaut auf die Verifikationsseite und die Bausteine, die dort zusammenkommen.

Drei Formate, ein Zusammenspiel

Die Architecture and Reference Framework (ARF), inzwischen in Version 2.x, legt die technischen Standards fest. Für akzeptierende Stellen sind drei davon zentral.

SD-JWT VC (Selective Disclosure JWT Verifiable Credential) ist ein Nachweisformat, das selektive Offenlegung ermöglicht. Der Aussteller signiert ein Bündel von Attributen, aber so, dass die nutzende Person einzelne davon offenlegen kann, ohne die übrigen preiszugeben. Technisch geschieht das über Salted Hashes: Jedes Attribut wird einzeln gehasht, signiert wird über die Hashes. Wer ein Attribut zeigt, liefert den passenden Klartext und Salt mit, der Rest bleibt verborgen, die Signatur bleibt prüfbar.

ISO/IEC 18013-5 (mdoc) ist das aus dem mobilen Führerschein stammende Format, das im EUDI-Kontext für bestimmte Nachweise parallel genutzt wird. Eine akzeptierende Stelle sollte beide Formate verarbeiten können, da die Mitgliedstaaten nicht überall identisch vorgehen.

OpenID for Verifiable Presentations (OpenID4VP) ist das Protokoll, über das die Präsentation läuft. Es definiert, wie eine prüfende Stelle eine Anfrage stellt (welche Attribute, zu welchem Zweck) und wie das Wallet die Antwort signiert zurückliefert.

Was selektive Offenlegung praktisch ändert

Das gängige Beispiel ist die Altersprüfung. Statt das volle Geburtsdatum zu übertragen, kann das Wallet allein das abgeleitete Attribut „über 18" offenlegen. Für die akzeptierende Stelle heißt das: Sie sollte ihre Anfragen so formulieren, dass sie genau das Prädikat erhält, das sie braucht, nicht den vollständigen Datensatz dahinter. Datenminimierung ist hier kein nachgelagerter Datenschutzgedanke, sondern in das Protokoll eingebaut.

Der schwierige Teil: Vertrauen statt Gültigkeit

Eine Signatur zu prüfen ist die leichte Aufgabe. Die schwierige ist die Frage dahinter: Ist der Aussteller, der dieses Attribut signiert hat, überhaupt berechtigt und echt? Hier kommen Vertrauenslisten ins Spiel. Die EU und die Mitgliedstaaten führen Register, über die eine prüfende Stelle verlässlich feststellt, ob ein Wallet und seine Aussteller authentisch und zugelassen sind. Ohne diese Anbindung prüft man zwar eine korrekte Signatur, weiß aber nicht, ob die dahinterstehende Identität vertrauenswürdig ist.

Genauso wichtig ist die umgekehrte Richtung: Die prüfende Stelle selbst muss sich vor der ersten Nutzung bei einem nationalen Register registrieren und dabei angeben, welche Attribute sie zu welchem Zweck anfragt. Erst diese Registrierung ist die rechtliche Grundlage, überhaupt Daten anfragen zu dürfen.

Warum sich der Blick auf Standards lohnt

Wer auf die offenen Formate und Protokolle setzt statt auf proprietäre Adapter, hält die Wallets unterschiedlicher Mitgliedstaaten in Reichweite, ohne pro Land neu integrieren zu müssen. In unserem Modul Datargo ID ist diese akzeptierende Rolle der rote Faden, vom Single Sign-On bis zum EUDI-Pfad. Der technische Kern gilt jedoch unabhängig vom Werkzeug: Wer SD-JWT VC, mdoc und OpenID4VP verarbeiten kann und die Vertrauenslisten korrekt anbindet, ist für die Verifikation gerüstet, gleich aus welchem Mitgliedstaat das Wallet stammt.

Die Bereitstellung des Wallets ist eine politische Frist. Die Verifikation sauber aufzusetzen ist eine technische Aufgabe, und sie beginnt mit dem Verständnis dieser drei Bausteine.

Strukturierte E-Rechnungen GoBD-konform aufbewahren: die 8-Jahres-Frage

2026-04-21T00:00:00+00:00

Die Diskussion um die E-Rechnung dreht sich meist um das Ausstellen und Empfangen. Die unauffälligere, aber langlebigere Pflicht beginnt erst danach: die Aufbewahrung. Eine strukturierte Rechnung ist kein Dokument im klassischen Sinn, sondern ein Datensatz, und der muss über Jahre unveränderbar und maschinell auswertbar erhalten bleiben. Wer das beim Aufbau seiner Prozesse mitdenkt, vermeidet später teure Nacharbeit.

Was sich an der Frist geändert hat

Lange galt für Buchungsbelege eine zehnjährige Aufbewahrungsfrist. Das vierte Bürokratieentlastungsgesetz (BEG IV) hat sie zum 1. Januar 2025 auf acht Jahre verkürzt. Die neue Frist gilt für alle Belege, deren bisherige Zehnjahresfrist zu diesem Zeitpunkt noch nicht abgelaufen war.

Zwei Einschränkungen sind wichtig. Erstens betrifft die Verkürzung Buchungsbelege wie Rechnungen, Quittungen und Zahlungsbelege. Jahresabschlüsse und die Verfahrensdokumentation bleiben bei zehn Jahren. Zweitens ist die kürzere Frist nicht nur eine Erleichterung: Wer Belege nach acht statt zehn Jahren löschen darf, sollte sein Löschkonzept entsprechend anpassen, auch mit Blick auf die DSGVO. Eine pauschale Verlängerung „sicherheitshalber" steht im Spannungsverhältnis zur Pflicht, personenbezogene Daten nicht länger als nötig vorzuhalten.

Was „revisionssicher" technisch verlangt

Die GoBD fordern für aufbewahrungspflichtige elektronische Unterlagen im Kern drei Eigenschaften: Unveränderbarkeit, vollständige und zeitgerechte Erfassung sowie jederzeitige Verfügbarkeit und maschinelle Auswertbarkeit über die gesamte Frist. Unveränderbarkeit heißt nicht, dass eine Datei in einem Ordner liegt, den niemand anfasst. Sie heißt, dass nachträgliche Änderungen technisch ausgeschlossen oder lückenlos protokolliert sind und dass der Originalzustand wiederherstellbar bleibt.

Für strukturierte Formate kommt eine zweite Anforderung hinzu, die oft unterschätzt wird.

Sichtkopie ist nicht gleich Datensatz

Eine XRechnung ist ein reiner XML-Datensatz. ZUGFeRD ist hybrid: ein PDF mit eingebettetem XML. Der entscheidende Punkt: Aufbewahrungspflichtig ist der strukturierte Datensatz, nicht eine daraus erzeugte PDF-Sichtkopie. Wer eine eingehende XRechnung als PDF ausdruckt oder rendert und nur dieses Bild archiviert, hat den maßgeblichen Beleg nicht GoBD-konform aufbewahrt. Das Original ist die XML-Struktur, und genau sie muss über acht Jahre unverändert und auswertbar vorliegen.

Das hat Folgen für die Architektur. Es reicht nicht, am Eingang eine schöne Ansicht zu erzeugen. Der Datensatz muss in seiner strukturierten Form abgelegt, indexiert und gegen Veränderung gesichert werden. Eine Verfahrensdokumentation hält fest, wie genau dieser Weg verläuft: vom Empfang über die Prüfung bis zur Ablage.

Wo das in der Praxis zusammenläuft

Spätestens ab 2027, wenn die strukturierte E-Rechnung im inländischen B2B-Verkehr zum Regelfall wird, treffen drei Dinge aufeinander: das Format (XRechnung oder ZUGFeRD nach EN 16931), die Buchung im kaufmännischen Kern und die revisionssichere Ablage. In unserer eigenen Abrechnung sind E-Rechnung nach EN 16931 und GoBD-Buchhaltung als ein durchgehender Weg angelegt, doch die Anforderung selbst ist werkzeugunabhängig: Der maßgebliche Datensatz muss unverändert, auswertbar und für die volle Frist auffindbar bleiben.

Die 8-Jahres-Frist klingt nach weniger Aufwand als die alte. In der Sache verlagert sie den Aufwand nur: weg vom Löschen, hin zu sauberer Aufbewahrung des richtigen Objekts, nämlich des Datensatzes, nicht seines Abbilds.

NIS2 in der Praxis: Von der Meldepflicht zum belastbaren Nachweis

2026-04-14T00:00:00+00:00

Seit dem 6. Dezember 2025 ist NIS2 in Deutschland geltendes Recht. Das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) wurde am 13. November 2025 vom Bundestag beschlossen, am 20. November vom Bundesrat bestätigt und ist ohne Übergangsfrist in Kraft getreten. Betroffen sind rund 29.500 Unternehmen in 18 Sektoren. Die BSI-Registrierungsfrist am 6. März 2026 ist verstrichen, eine verspätete Registrierung bleibt möglich und ist ratsam.

Viele Häuser haben die Umsetzung als Registrierungs- und Dokumentationsaufgabe behandelt. Der schwierigere Teil beginnt danach: im Ernstfall belegen zu können, was passiert ist.

Die Uhr läuft in Stunden, nicht in Wochen

Die Meldepflichten (§32) sind gestuft und eng getaktet. Bei einem erheblichen Sicherheitsvorfall gilt: Frühwarnung innerhalb von 24 Stunden, Meldung innerhalb von 72 Stunden, Abschlussbericht innerhalb eines Monats. Diese Fristen lassen sich nur halten, wenn ein Vorfall schnell erkannt und nachvollziehbar rekonstruiert werden kann. Wer erst beim Schreiben der Meldung merkt, dass die nötigen Daten fehlen, hat die Frist faktisch schon gerissen.

Was der Prüfer sehen will

§30 verlangt Risikomanagementmaßnahmen: Monitoring, Logging, Incident Handling, Business Continuity und Lieferkettensicherheit. Der entscheidende Unterschied liegt zwischen “wir betreiben Monitoring” und “wir können belegen, was wann passiert ist”. Eine Aufsicht akzeptiert keine Absichtserklärung, sie will Evidenz.

Belastbar ist ein Nachweis dann, wenn er drei Eigenschaften hat:

Lückenlos: Erkennung, Eskalation und Reaktion sind durchgängig zeitgestempelt, ohne dunkle Phasen im Verlauf.
Unveränderbar: Logs und Incident-Verläufe liegen append-only vor, nachträglich nicht still korrigierbar.
Rekonstruierbar: Aus dem Trail lässt sich die Vorfallchronik so ableiten, dass sie auf die 24-, 72- und 30-Tage-Fristen abbildet.

Genau hier scheitern viele Setups: Monitoring ist vorhanden, aber die Daten liegen verstreut, sind überschreibbar oder lassen sich nicht zu einer prüffesten Chronik zusammenfügen.

Verantwortung lässt sich nicht delegieren

§38 nimmt die Geschäftsleitung in die Pflicht, die Maßnahmen zu billigen und ihre Umsetzung zu überwachen. Diese Verantwortung ist nicht an die IT abtretbar. §65 setzt den Rahmen mit Bußgeldern von bis zu 10 Millionen Euro. Das verschiebt NIS2 von einer technischen zu einer Leitungsaufgabe.

Was jetzt sinnvoll ist

Drei Schritte zahlen unmittelbar ein: die eigenen Pflichten sauber auf §30 und §32 mappen; die Erkennung so aufstellen, dass die 24-Stunden-Frühwarnung realistisch erreichbar ist; und die Protokollierung auf unveränderbare, ausreichend lang aufbewahrte Trails umstellen. Ein einmal durchgespielter Meldeablauf zeigt schnell, wo die Chronik reißt.

In unserem Modul Perstat sind Monitoring, Security Posture und ein append-only Audit-Trail so verbunden, dass sich NIS2-Evidenz on demand erzeugen lässt. Der eigentliche Punkt ist aber unabhängig vom Werkzeug, nämlich Erkennung und Protokollierung so zu führen, dass am Ende eine prüffeste Chronik steht und nicht eine Sammlung verstreuter Logzeilen.

NIS2 fragt nicht, ob Sie Monitoring betreiben. Es fragt, ob Sie es beweisen können.

ACME jenseits des Webservers: Zertifikatsautomatisierung für interne Dienste und mTLS

2026-03-17T00:00:00+00:00

Die Verkürzung öffentlicher TLS-Laufzeiten auf perspektivisch 47 Tage hat ein Bewusstsein dafür geschaffen, dass manuelle Erneuerung nicht mehr skaliert. Was dabei oft übersehen wird: Im Inneren eines Unternehmens stecken meist deutlich mehr Zertifikate als an der nach außen sichtbaren Kante. Service-zu-Service-Kommunikation, mTLS in einem Service-Mesh, interne APIs und Datenbankverbindungen leben alle von Zertifikaten, und diese folgen anderen Mustern als das öffentliche Web.

Warum „intern" nicht „einfacher" heißt

Am öffentlichen Webserver ist die Lage übersichtlich: eine Handvoll Domains, eine öffentliche CA, ein klar definierter Validierungsweg. Im Inneren kehrt sich das Verhältnis um. Hier gibt es oft hunderte oder tausende kurzlebiger Endpunkte, die dynamisch entstehen und vergehen, etwa wenn ein Orchestrator neue Container startet. Eine interne CA stellt für sie Zertifikate aus, die niemand öffentlich sieht, die aber genauso ablaufen, sich genauso erneuern müssen und im Fehlerfall genauso einen Dienst lahmlegen.

Der Unterschied zur öffentlichen Welt ist also nicht geringere Bedeutung, sondern höhere Frequenz und Dynamik. Bei mTLS, wo sich beide Seiten gegenseitig mit einem Zertifikat ausweisen, verdoppelt sich die Zahl der zu verwaltenden Identitäten zusätzlich.

ACME ist nicht nur für Let’s Encrypt

ACME (RFC 8555) ist als Protokoll für die automatische Ausstellung und Erneuerung bekannt geworden, vor allem über Let’s Encrypt im öffentlichen Web. Das Protokoll selbst ist aber CA-agnostisch. Eine interne CA kann eine ACME-Schnittstelle anbieten, und dann erneuern sich interne Dienste nach demselben Mechanismus selbst, ohne dass jemand ein Zertifikat von Hand bestellt.

Für die interne Validierung greifen dabei andere Challenge-Typen als im öffentlichen Web. Die HTTP-Challenge, die für öffentliche Domains üblich ist, passt selten zu internen Diensten. Stattdessen kommen DNS-basierte Verfahren oder, je nach Umgebung, an die Plattform gebundene Identitätsnachweise zum Zug. Service-Meshes lösen das teils intern über eine eigene Identitätsschicht und kurzlebige Zertifikate mit Lebensdauern von Stunden statt Wochen.

Was den Unterschied macht

Drei Fähigkeiten entscheiden darüber, ob interne Automatisierung trägt.

Discovery auch nach innen. Der gefährliche Ausfall ist selten das gepflegte Frontend-Zertifikat. Es ist das vergessene Zertifikat auf einem internen Dienst, einer Appliance oder in einem Cluster, den niemand mehr aktiv beobachtet. Ein Inventar muss interne Endpunkte ebenso erfassen wie öffentliche.

Eine CA-agnostische Sicht. In gewachsenen Umgebungen existieren meist mehrere CAs nebeneinander: eine öffentliche für die Außenkante, eine oder mehrere interne, dazu vielleicht eine Cloud-eigene. Eine Verwaltung, die über alle hinweg einen einheitlichen Blick und einheitliche Erneuerung bietet, verhindert, dass jede CA ihre eigene Insel mit eigenen Lücken wird.

Erneuerung mit Kontrolle. Vollautomatik ist das Ziel, aber nicht um den Preis verlorener Nachvollziehbarkeit. Wo es nötig ist, gehört zum automatischen Renewal ein dokumentierter Genehmigungs- und Protokollschritt, damit auch bei hoher Frequenz nachvollziehbar bleibt, was wann ausgestellt wurde.

Genau dieses Muster, Discovery zuerst, dann CA-agnostische Automatisierung mit Approval, liegt unserem Modul NextPKI zugrunde. Die Stoßrichtung gilt jedoch unabhängig vom Werkzeug: Wer die kurzen Laufzeiten der Außenkante beherrscht, aber das Innere übersieht, hat das eigentliche Volumen nicht im Griff.

Die 47-Tage-Diskussion ist ein guter Anlass, den Blick zu weiten. Die meisten Zertifikate eines Unternehmens stehen nicht im Schaufenster, sondern im Maschinenraum.

DORA für IKT-Dienstleister: Drittparteienrisiko und Incident-Reporting

2025-12-09T00:00:00+00:00

DORA, der Digital Operational Resilience Act (Verordnung (EU) 2022/2554), gilt seit dem 17. Januar 2025 für den europäischen Finanzsektor. Seit dem 19. November 2025 ist die Aufsicht konkret geworden: Die europäischen Aufsichtsbehörden EBA, EIOPA und ESMA haben die erste offizielle Liste von 19 als kritisch eingestuften IKT-Drittdienstleistern veröffentlicht, darunter AWS, Google Cloud, Microsoft, Oracle, SAP, IBM und die Deutsche Telekom. Die Liste wird jährlich fortgeschrieben.

Die naheliegende Reaktion vieler IT-Dienstleister lautet: betrifft mich nicht, ich bin keine Bank. Das ist ein Trugschluss. DORA wandert über die Lieferkette.

Warum die Verordnung jeden Zulieferer erreicht

Finanzunternehmen tragen das Risiko ihrer IKT-Auslagerungen selbst und müssen es nachweisbar steuern. Bis zum 30. April 2025 mussten sie ihr Informationsregister melden, ein vollständiges Verzeichnis aller vertraglichen Vereinbarungen mit IKT-Drittdienstleistern. Damit ist jede Auslagerung für die Aufsicht sichtbar, auch die zu nicht kritischen Anbietern.

Was das Finanzunternehmen an Pflichten trägt, reicht es vertraglich an seine Dienstleister weiter. In der Praxis verlangen Finanzkunden inzwischen:

DORA-konforme Vertragsklauseln mit klaren Leistungs-, Sicherheits- und Beendigungsregelungen.
Audit- und Zugangsrechte, damit Kunde und Aufsicht prüfen können.
Transparenz über Sub-Auslagerung, also wer hinter dem Dienstleister noch beteiligt ist.
Meldeketten bei Vorfällen, schnell genug, damit der Finanzkunde seine eigenen Fristen hält.
Exit- und Kontinuitätspläne sowie Nachweise aus Resilienz-Tests.

Incident-Reporting ist eine Kette, kein Formular

DORA verlangt für schwerwiegende IKT-Vorfälle eine gestufte Meldung: eine Erstmeldung binnen weniger Stunden nach Einstufung, einen Zwischenbericht und einen Abschlussbericht binnen eines Monats. Für Zulieferer heißt das: Der Vorfall muss nicht nur intern erkannt, sondern der Finanzkunde so rechtzeitig informiert werden, dass dieser seine regulatorische Uhr einhalten kann. Wer hier zu spät oder zu vage meldet, gefährdet die Compliance des Kunden und damit die eigene Geschäftsbeziehung.

Kritisch eingestuft heißt direkte Aufsicht

Wer als kritischer IKT-Drittdienstleister benannt wird, untersteht der direkten Aufsicht eines federführenden Overseers auf EU-Ebene. Da die Liste jährlich aktualisiert wird, ist die Einstufung kein statischer Zustand: Wer heute nicht gelistet ist, kann es mit wachsender Bedeutung im Finanzsektor werden.

Was jetzt sinnvoll ist

Für IKT-Dienstleister mit Finanzkunden lohnt sich, die eigenen Verträge auf DORA-Klauseln zu prüfen, die Sub-Auslagerung sauber zu dokumentieren und die Vorfallmeldung so zu proben, dass die Kette bis zum Finanzkunden in Stunden trägt. In unserem Modul Perstat greifen Monitoring, Incident-Engine und ein append-only Audit-Trail so ineinander, dass sich die Nachweise für solche Meldeketten erzeugen lassen. Der eigentliche Punkt ist aber unabhängig vom Werkzeug, nämlich die eigene Resilienz so zu dokumentieren, dass der Finanzkunde sich darauf verlassen kann.

DORA ist kein reines Bankenthema. Es ist die Anforderung, die Ihre Finanzkunden ab sofort an Sie weiterreichen.

Post-Quantum-Kryptografie: Warum die Migration 2026 beginnt, nicht 2030

2025-09-16T00:00:00+00:00

Seit August 2024 sind die ersten drei Post-Quantum-Standards final. NIST hat FIPS 203 (ML-KEM, abgeleitet von Kyber), FIPS 204 (ML-DSA, aus Dilithium) und FIPS 205 (SLH-DSA, aus SPHINCS+) veröffentlicht und damit einen achtjährigen Auswahlprozess abgeschlossen. Viele lesen die Schlagzeile, sehen die oft genannte Jahreszahl 2030 und legen das Thema wieder weg. Das ist ein Missverständnis: 2030 ist eine Frist, kein Startschuss.

“Harvest now, decrypt later” macht die Sache dringend

Die Bedrohung wartet nicht auf den ersten leistungsfähigen Quantenrechner. Angreifer fangen heute verschlüsselten Verkehr ab und speichern ihn, um ihn später zu entschlüsseln. Alles, was lange schützenswert bleibt, ist damit schon jetzt exponiert: Verträge, Gesundheits- und Personaldaten, langlebige Schlüssel, geistiges Eigentum, Staats- und Geschäftsgeheimnisse. Für diese Daten zählt nicht, wann ein Quantenrechner praktisch wird, sondern wie lange sie geheim bleiben müssen.

Die NSA setzt mit CNSA 2.0 das Jahr 2030 als verbindliche Frist für nationale Sicherheitssysteme. Das BSI rät seit Jahren zur frühzeitigen Umstellung und zu Krypto-Agilität. Beides beschreibt ein Ziel, keinen bequemen Aufschub.

Warum die Umstellung Jahre dauert

Wer einmal versucht hat, den eigenen Kryptografie-Bestand zu inventarisieren, kennt das Problem: Niemand weiß genau, wo überall welche Algorithmen, Schlüssel und Zertifikate im Einsatz sind. Hinzu kommen Abhängigkeiten von Bibliotheken, Hardware, Protokollen und Partnern, die nicht im eigenen Takt migrieren. Eine PQC-Umstellung ist deshalb kein Schalter, sondern ein mehrjähriges Programm.

Der Weg ist in der Reihenfolge klar:

Inventarisieren: sichtbar machen, wo welche Kryptografie steckt, inklusive eingebetteter und vergessener Nutzung.
Priorisieren: zuerst die langlebigen Daten, die heute schon dem Harvest-now-Risiko unterliegen.
Krypto-Agilität herstellen: Algorithmen so kapseln, dass sie ohne Codeänderung im aufrufenden System wechselbar sind.
Hybrid pilotieren: klassische und Post-Quantum-Verfahren parallel, um Interoperabilität und Performance zu prüfen.
Automatisieren und fordern: Erneuerung automatisieren und Lieferanten verbindlich auf PQC-Fähigkeit verpflichten.

Krypto-Agilität ist der eigentliche Hebel

Der häufigste Denkfehler ist, PQC als einmaligen Austausch zu sehen. Die Algorithmen werden sich weiterentwickeln, Parameter werden nachgeschärft, einzelne Verfahren könnten fallen. Was bleibt, ist die Anforderung, Algorithmen wechseln zu können, ohne jedes aufrufende System anzufassen. Wer diese Agilität heute einbaut, übersteht nicht nur die erste PQC-Welle, sondern auch die nächste.

In unserem Modul NextPKI ist genau das angelegt: krypto-agil von Anfang an, RSA, ECDSA und Ed25519 heute, Post-Quantum-Verfahren vorbereitet, mit Policy je Tenant. Der eigentliche Punkt ist aber unabhängig vom Werkzeug, nämlich Agilität als Eigenschaft zu bauen und nicht als spätere Migration.

2026 ist das Jahr, in dem Inventar und Pilot stehen sollten. Dann ist 2030 nur noch der Abschluss, kein Schreckdatum.

E-Rechnungspflicht in Deutschland: Der Stufenplan 2025 bis 2028 ohne Mythen

2025-02-11T00:00:00+00:00

Seit dem 1. Januar 2025 ist die E-Rechnung im deutschen B2B-Geschäft keine Kür mehr. Die erste Stufe der neuen Pflicht gilt: Jedes inländische Unternehmen muss strukturierte elektronische Rechnungen empfangen können. Versenden muss man noch nicht zwingend elektronisch, empfangen aber schon. Rechtsgrundlage ist das Wachstumschancengesetz, das der Bundesrat am 22. März 2024 verabschiedet hat; die Details regelt das BMF-Schreiben vom 15. Oktober 2024.

Rund um diese Pflicht kursieren mehr Halbwahrheiten als bei den meisten Steuerthemen. Drei davon lohnt es sich auszuräumen.

Mythos 1: “Eine PDF ist eine E-Rechnung”

Nein. Eine E-Rechnung im Sinne der Norm EN 16931 ist ein strukturierter Datensatz, den Software ohne Medienbruch verarbeiten kann. Eine klassische PDF, auch wenn sie per E-Mail kommt, ist ab Geltung der Pflicht nur eine “sonstige Rechnung”. Maßgeblich ist das maschinenlesbare XML, nicht das Bild für das menschliche Auge.

In Deutschland erfüllen zwei Formate die Norm: XRechnung, ein reines XML nach der CIUS der EN 16931, und ZUGFeRD ab Version 2, ein Hybrid aus PDF/A-3 mit eingebettetem XML. Bei ZUGFeRD führt das XML, nicht das sichtbare PDF. Wichtig dabei: Nur die Profile ab “EN 16931” (Comfort) sind normkonform. Die kleineren Profile MINIMUM und BASIC WL tragen zu wenig Daten, um als vollwertige Rechnung zu gelten.

Mythos 2: “Das betrifft erst 2027, und nur die Großen”

Der Empfang betrifft seit Januar 2025 alle. Erst der Versand ist gestaffelt:

seit 1.1.2025: Empfangspflicht für alle inländischen Unternehmen
ab 1.1.2027: Versandpflicht für Unternehmen mit mehr als 800.000 Euro Vorjahresumsatz
ab 1.1.2028: Versandpflicht für alle übrigen B2B-Beziehungen

Bis Ende 2026 dürfen Papier und unstrukturierte Formate im Einvernehmen weiter genutzt werden, für kleinere Aussteller gibt es eine zusätzliche Schonfrist bis Ende 2027. Etablierte EDI-Verfahren bleiben unter Bedingungen zulässig, müssen aber an die Norm heranreichen. Wer den Versand erst 2027 anfasst, hat trotzdem heute schon eine Empfangsbaustelle.

Mythos 3: “Empfang heißt nur, dass die Mail ankommt”

Rechtlich genügt eine E-Mail-Adresse, damit eine E-Rechnung zugestellt werden kann. Fachlich ist das die halbe Miete. Drei Dinge gehören dazu:

Validierung: Das eingehende XML sollte gegen Schema und Geschäftsregeln der EN 16931 geprüft werden, sonst landen fehlerhafte Rechnungen unbemerkt im Bestand.
Sichtbarmachung: Ein Viewer, der das XML lesbar darstellt, damit Fachabteilungen ohne XML-Kenntnisse prüfen können.
GoBD-konforme Archivierung: Aufbewahrt werden muss das strukturierte Original, unveränderbar und revisionssicher verkettet, nicht nur ein PDF-Ausdruck.

Gerade der letzte Punkt wird unterschätzt. Wer ausschließlich den Sichtbeleg archiviert und das XML verwirft, hat die Rechnung im rechtlichen Sinn nicht aufbewahrt.

Was jetzt sinnvoll ist

Der Empfang ist Pflicht und sollte sauber stehen: Validierung, Viewer, revisionssicheres Archiv des XML. Parallel lohnt der Blick auf den Versand. Welche Kundenbeziehungen fallen 2027 unter die Pflicht, welche Formate erwarten die Empfänger, und wie kommt das strukturierte Original sauber aus dem eigenen System. In unserer eigenen Abrechnung sind EN 16931, XRechnung und ZUGFeRD sowie die GoBD-konforme Verkettung von Beginn an angelegt. Der eigentliche Punkt ist aber unabhängig vom Werkzeug, nämlich das strukturierte Original als führenden Beleg zu behandeln und nicht als Beiwerk zur PDF.

Die Pflicht kommt nicht erst 2027. Sie hat 2025 begonnen, nur eben leise, auf der Empfangsseite.