Fachbeiträge zu Compliance, Identität, PKI und Betrieb. Praxisnah und ohne Werbesprech.https://datargo.com/blog/2026-06-23T00:00:00+00:00Datargohttps://datargo.com/blog/api-sicherheit-lieferkette/2026-06-23T00:00:00+00:002026-06-23T00:00:00+00:00

NIS2 zieht die Lieferkette in die Risikobetrachtung, und APIs sind ihre stillen Verbindungsstücke. Warum Berechtigungsfehler die größte API-Schwachstelle sind und warum sich nur absichern lässt, was sauber dokumentiert ist.

<p>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?</p> <h2 id="die-schnittstelle-ist-die-angriffsfläche">Die Schnittstelle ist die Angriffsfläche</h2> <p>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:</p> <ul> <li><strong>Autorisierung pro Objekt:</strong> Jede Anfrage prüft, ob der Aufrufer genau dieses Objekt sehen oder ändern darf, nicht nur, ob er angemeldet ist.</li> <li><strong>Authentifizierung:</strong> Tokens sind kurzlebig, gebunden und widerrufbar, statt langlebiger Allzweckschlüssel.</li> <li><strong>Begrenzung:</strong> Rate-Limiting und Quoten verhindern, dass eine Schnittstelle zur Datenabflussstelle oder zum Lastvektor wird.</li> </ul> <h2 id="was-man-nicht-dokumentiert-kann-man-nicht-absichern">Was man nicht dokumentiert, kann man nicht absichern</h2> <p>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.</p> <h2 id="sicherheit-als-nachweisbare-eigenschaft">Sicherheit als nachweisbare Eigenschaft</h2> <p>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.</p> <p>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.</p>https://datargo.com/blog/data-act-cloud-switching/2026-06-23T00:00:00+00:002026-06-23T00:00:00+00:00

Seit September 2025 gelten die Switching-Regeln des Data Act für neue Cloud-Verträge, zum Januar 2027 fällt das Entgeltverbot. Warum Anbieterwechsel vom Verhandlungsthema zum gesetzlichen Anspruch wird und was das für die Architektur heißt.

<p>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.</p> <h2 id="was-seit-september-2025-gilt">Was seit September 2025 gilt</h2> <p>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.</p> <h2 id="die-gebührenbremse-bis-januar-2027">Die Gebührenbremse bis Januar 2027</h2> <p>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.</p> <h2 id="switching-ist-mehr-als-ein-datenexport">Switching ist mehr als ein Datenexport</h2> <p>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:</p> <ul> <li><strong>Datenmodell:</strong> Liegen Inhalte in dokumentierten, offenen Strukturen vor oder in einem proprietären Schema?</li> <li><strong>Schnittstellen:</strong> Gibt es stabile, versionierte APIs für den Export laufender und historischer Daten?</li> <li><strong>Metadaten:</strong> Werden Konfiguration, Rechte und Verarbeitungslogik mit übergeben oder bleiben sie im alten System zurück?</li> </ul> <h2 id="was-das-für-die-architektur-heißt">Was das für die Architektur heißt</h2> <p>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.</p> <p>Der Data Act fragt nicht, ob Sie Ihre Kundinnen und Kunden halten wollen. Er fragt, ob diese gehen könnten, wenn sie es wollten.</p>https://datargo.com/blog/passkeys-unternehmen/2026-06-23T00:00:00+00:002026-06-23T00:00:00+00:00

Passwort plus SMS- oder TOTP-Code bleibt phishbar. Warum FIDO2-Passkeys das Origin-Problem lösen, wie ein risikobasierter Rollout aussieht und welche Fragen zu Wiederherstellung und Geräteverlust offen bleiben.

<p>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.</p> <h2 id="warum-klassische-mfa-phishbar-bleibt">Warum klassische MFA phishbar bleibt</h2> <p>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.</p> <h2 id="was-passkeys-anders-machen">Was Passkeys anders machen</h2> <p>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.</p> <h2 id="synced-device-bound-oder-hardware-key">Synced, device-bound oder Hardware-Key</h2> <p>Passkey ist nicht gleich Passkey. Ein tragfähiger Rollout staffelt die Variante nach Schutzbedarf:</p> <ul> <li><strong>Hardware-Sicherheitsschlüssel:</strong> für privilegierte Zugänge und Administration, wo höchste Sicherheit zählt.</li> <li><strong>Gerätegebundene Passkeys:</strong> auf verwalteten Firmengeräten, an die Hardware gekoppelt und nicht synchronisierbar.</li> <li><strong>Synchronisierte Passkeys:</strong> für die breite Belegschaft, komfortabel über mehrere Geräte, mit etwas geringerem Härtegrad.</li> </ul> <p>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.</p> <h2 id="die-offenen-fragen">Die offenen Fragen</h2> <p>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.</p> <p>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.</p>https://datargo.com/blog/ki-transparenzpflicht-kundenservice/2026-06-23T00:00:00+00:002026-06-23T00:00:00+00:00

Ab dem 2. August 2026 sind die Transparenzpflichten aus Artikel 50 des EU AI Act durchsetzbar. Was die Hinweispflicht bei Chatbots und die Kennzeichnung KI-erzeugter Inhalte konkret für den Kundenservice bedeuten.

<p>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.</p> <h2 id="was-artikel-50-verlangt">Was Artikel 50 verlangt</h2> <p>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.</p> <h2 id="was-informiert-praktisch-heißt">Was &ldquo;informiert&rdquo; praktisch heißt</h2> <p>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:</p> <ul> <li><strong>Sichtbarkeit:</strong> Der KI-Hinweis steht am Anfang des Dialogs, nicht in einer ausklappbaren Fußnote.</li> <li><strong>Sprache:</strong> Der Hinweis erscheint in der Sprache, in der die Person den Kontakt aufnimmt, nicht nur auf Englisch.</li> <li><strong>Übergabe:</strong> Beim Wechsel zwischen KI und menschlicher Bearbeitung sollte erkennbar bleiben, mit wem gerade gesprochen wird.</li> </ul> <h2 id="mehr-als-ein-hinweisbanner">Mehr als ein Hinweisbanner</h2> <p>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.</p> <p>Artikel 50 verbietet KI im Kundenservice nicht. Er verlangt nur, dass niemand im Unklaren darüber bleibt, mit wem oder mit was er spricht.</p>https://datargo.com/blog/47-tage-tls-zertifikate/2026-06-09T00:00:00+00:002026-06-09T00:00:00+00:00

Das CA/Browser-Forum senkt die maximale TLS-Laufzeit stufenweise auf 47 Tage. Was die Stufen 200, 100 und 47 Tage für Discovery, Renewal-Automatisierung und Betriebsteams bedeuten.

<p>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 <strong>200 Tage</strong> gültig sein, nicht mehr 398. Das ist die erste Stufe eines Fahrplans, den das CA/Browser-Forum im April 2025 mit Ballot <strong>SC-081v3</strong> beschlossen hat: einstimmig, mit 29 Ja-Stimmen und keiner Gegenstimme. Am Ende dieses Fahrplans steht eine maximale Laufzeit von <strong>47 Tagen</strong>.</p> <p>Wer Zertifikate noch von Hand bestellt und im Kalender notiert, sollte die nächsten drei Jahre als Umbauprojekt einplanen, nicht als Reihe von Einzelterminen.</p> <h2 id="der-fahrplan-in-zahlen">Der Fahrplan in Zahlen</h2> <p>Die maximale Gültigkeit sinkt in klar terminierten Stufen:</p> <ul> <li><strong>bis 14. März 2026:</strong> 398 Tage (der bisherige Standard)</li> <li><strong>ab 15. März 2026:</strong> 200 Tage (gilt heute)</li> <li><strong>ab 15. März 2027:</strong> 100 Tage</li> <li><strong>ab 15. März 2029:</strong> 47 Tage</li> </ul> <p>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&quot; werden, bevor sie erneut bestätigt werden muss:</p> <ul> <li><strong>ab 15. März 2026:</strong> 200 Tage</li> <li><strong>ab 15. März 2027:</strong> 100 Tage</li> <li><strong>ab 15. März 2029:</strong> 10 Tage</li> </ul> <p>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.</p> <p>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.</p> <h2 id="warum-die-verkürzung-kommt">Warum die Verkürzung kommt</h2> <p>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.</p> <p>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.</p> <h2 id="was-das-für-den-betrieb-bedeutet">Was das für den Betrieb bedeutet</h2> <p>Die zentrale Folge ist banal und unausweichlich: <strong>Manuelle Erneuerung skaliert nicht mehr.</strong> 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.</p> <p>Drei Fähigkeiten entscheiden darüber, ob dieser Umbau gelingt:</p> <p><strong>Automatisierung.</strong> ACME (RFC 8555) ist der etablierte Standard für automatische Ausstellung und Erneuerung, nicht nur für Let&rsquo;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.</p> <p><strong>Discovery.</strong> 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.</p> <p><strong>Eigentümerschaft.</strong> 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.</p> <p>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.</p> <h2 id="was-jetzt-sinnvoll-ist">Was jetzt sinnvoll ist</h2> <p>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.</p> <p>Die 47 Tage kommen nicht überraschend und nicht auf einmal. Sie kommen in Stufen, und die erste steht bereits.</p>https://datargo.com/blog/cyber-resilience-act-meldepflicht-2026/2026-06-09T00:00:00+00:002026-06-09T00:00:00+00:00

Ab dem 11. September 2026 gelten die ersten verbindlichen CRA-Pflichten. Was die Meldung aktiv ausgenutzter Schwachstellen, SBOM und Security by Design für Hersteller, Importeure und Händler konkret heißt.

<p>In knapp drei Monaten wird aus einer Verordnung Betriebsrealität. Ab dem <strong>11. September 2026</strong> 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 <strong>11. Dezember 2027</strong>.</p> <p>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.</p> <h2 id="was-am-11-september-2026-beginnt">Was am 11. September 2026 beginnt</h2> <p>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.</p> <p>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.</p> <h2 id="was-bis-dezember-2027-dazukommt">Was bis Dezember 2027 dazukommt</h2> <p>Die Meldepflicht ist nur der erste Baustein. Mit der vollständigen Anwendung verlangt der CRA über den gesamten Produktlebenszyklus hinweg nachweisbare Sicherheit:</p> <ul> <li><strong>Security by Design:</strong> 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.</li> <li><strong>Software Bill of Materials (SBOM):</strong> 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.</li> <li><strong>Schwachstellenmanagement und Updates:</strong> Sicherheitsupdates müssen über mindestens fünf Jahre bereitgestellt werden, oder über die erwartbare Lebensdauer des Produkts, falls diese kürzer ist.</li> <li><strong>CE-Kennzeichnung:</strong> Ab Dezember 2027 dürfen Produkte mit digitalen Elementen ohne CRA-Konformität nicht mehr in der EU in Verkehr gebracht werden.</li> </ul> <p>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.</p> <h2 id="was-das-praktisch-bedeutet">Was das praktisch bedeutet</h2> <p>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.</p> <p>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 Datargo Monitor 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.</p> <h2 id="was-jetzt-sinnvoll-ist">Was jetzt sinnvoll ist</h2> <p>Drei Schritte lohnen sich vor September: erstens klären, welche eigenen Produkte als „Produkte mit digitalen Elementen&quot; 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.</p> <p>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.</p>https://datargo.com/blog/eidas-2-eudi-wallet/2026-06-09T00:00:00+00:002026-06-09T00:00:00+00:00

Die EU-Staaten müssen das EUDI-Wallet bis Dezember 2026 bereitstellen. Ein nüchterner Überblick über die technischen und rechtlichen Weichen, die Unternehmen als Relying Party jetzt stellen sollten.

<p>In rund einem halben Jahr läuft eine Frist ab, die viele Unternehmen noch als ferne Regulierung behandeln: Bis zum <strong>24. Dezember 2026</strong> müssen alle 27 EU-Mitgliedstaaten ihren Bürgerinnen und Bürgern mindestens ein <strong>European Digital Identity Wallet (EUDI-Wallet)</strong> bereitstellen. Grundlage ist die Verordnung (EU) 2024/1183 („eIDAS 2.0&quot;), die seit dem 20. Mai 2024 in Kraft ist.</p> <p>Für die Mehrzahl der Unternehmen ist die spannendere Frage nicht, wann das Wallet kommt, sondern wann sie es <strong>akzeptieren</strong> müssen. Und diese Frist folgt unmittelbar.</p> <h2 id="wo-der-rollout-im-juni-2026-steht">Wo der Rollout im Juni 2026 steht</h2> <p>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.</p> <p>Der Umsetzungsstand der Mitgliedstaaten ist allerdings ungleich. Frankreich gilt mit „France Identité&quot; als am weitesten, betreibt bereits einen produktiven Dienst und baut ihn zum offiziellen EUDI-Wallet aus; Italien und Polen folgen dicht dahinter. <strong>Deutschland</strong> hat angekündigt, seine staatlich getriebene Variante zum <strong>2. Januar 2027</strong> zu starten, also kurz nach Ablauf der EU-Frist.</p> <h2 id="relying-party-die-rolle-die-fast-jeden-betrifft">Relying Party: die Rolle, die fast jeden betrifft</h2> <p>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.</p> <p>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 <strong>etwa ein Jahr später</strong> 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.</p> <h2 id="was-eine-relying-party-jetzt-klären-sollte">Was eine Relying Party jetzt klären sollte</h2> <p><strong>Registrierung.</strong> 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.</p> <p><strong>Datensparsamkeit.</strong> Das Wallet ist auf selektive Offenlegung ausgelegt: Nutzer sollen genau die Attribute teilen, die ein Dienst wirklich braucht, etwa „über 18&quot; 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.</p> <p><strong>Technische Integration.</strong> 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.</p> <p><strong>Anwendungsfälle und Governance.</strong> 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.</p> <p>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.</p> <h2 id="der-nüchterne-zeitplan">Der nüchterne Zeitplan</h2> <p>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.</p>https://datargo.com/blog/datensouveraenitaet-data-privacy-framework/2026-06-02T00:00:00+00:002026-06-02T00:00:00+00:00

Das EU-US Data Privacy Framework bleibt vorerst gültig, steht aber unter Revision. Warum Hosting-Standort, Betreiberkontrolle und Verschlüsselungshoheit keine Compliance-Häkchen sind, sondern Architekturentscheidungen mit langer Halbwertszeit.

<p>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&quot;, ist nicht ausgeschlossen.</p> <p>Diese Unsicherheit ist kein Grund zur Panik, aber ein guter Anlass, eine Frage von der Compliance-Ebene auf die Architekturebene zu heben.</p> <h2 id="warum-das-mehr-als-ein-häkchen-ist">Warum das mehr als ein Häkchen ist</h2> <p>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.</p> <p>Die robustere Frage lautet nicht „ist der Transfer gedeckt&quot;, sondern „findet der Transfer überhaupt statt&quot;. Daten, die die EU nicht verlassen und auf die kein Drittland-Zugriff besteht, brauchen keinen Angemessenheitsbeschluss.</p> <h2 id="drei-architekturentscheidungen">Drei Architekturentscheidungen</h2> <p><strong>Hosting-Standort.</strong> 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.</p> <p><strong>Betreiberkontrolle.</strong> 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.</p> <p><strong>Verschlüsselungshoheit.</strong> 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.</p> <h2 id="souveränität-als-voreinstellung-nicht-als-nachrüstung">Souveränität als Voreinstellung, nicht als Nachrüstung</h2> <p>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.</p> <p>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.</p> <p>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.</p>https://datargo.com/blog/ai-act-gpai-durchsetzung-2026/2026-05-26T00:00:00+00:002026-05-26T00:00:00+00:00

Ab August beginnt die aktive Durchsetzung der GPAI-Pflichten. Ein nüchterner Überblick, was jetzt gilt, was der Digital Omnibus vom Mai 2026 verschoben hat und welche Fristen bleiben.

<p>Der EU AI Act gilt seit August 2024, doch viele seiner Pflichten greifen gestaffelt. Ein Datum sticht heraus: Am <strong>2. August 2026</strong> 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.</p> <h2 id="was-am-2-august-2026-beginnt">Was am 2. August 2026 beginnt</h2> <p>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.</p> <p>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.</p> <h2 id="was-der-digital-omnibus-vom-mai-2026-verschoben-hat">Was der Digital Omnibus vom Mai 2026 verschoben hat</h2> <p>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:</p> <ul> <li><strong>Hochrisiko-Systeme nach Anhang III:</strong> verschoben auf den 2. Dezember 2027.</li> <li><strong>Hochrisiko-Systeme nach Anhang I:</strong> verschoben auf den 2. August 2028.</li> <li><strong>Transparenzpflichten nach Artikel 50</strong> (etwa Kennzeichnung von KI-generierten Inhalten): verschoben auf den 2. Dezember 2026.</li> <li><strong>KI-Reallabore:</strong> verschoben auf den 2. August 2027.</li> </ul> <p>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.</p> <h2 id="was-das-praktisch-heißt">Was das praktisch heißt</h2> <p>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.</p> <p>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.</p> <p>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.</p>https://datargo.com/blog/eudi-wallet-protokolle-sdjwt-openid4vp/2026-05-12T00:00:00+00:002026-05-12T00:00:00+00:00

Wie eine prüfende Stelle ein Wallet-Attribut tatsächlich validiert: ein technischer Blick auf selektive Offenlegung, Präsentationsprotokolle und Vertrauenslisten hinter dem EUDI-Wallet.

<p>Ü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.</p> <h2 id="drei-formate-ein-zusammenspiel">Drei Formate, ein Zusammenspiel</h2> <p>Die Architecture and Reference Framework (ARF), inzwischen in Version 2.x, legt die technischen Standards fest. Für akzeptierende Stellen sind drei davon zentral.</p> <p><strong>SD-JWT VC</strong> (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.</p> <p><strong>ISO/IEC 18013-5 (mdoc)</strong> 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.</p> <p><strong>OpenID for Verifiable Presentations (OpenID4VP)</strong> 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.</p> <h2 id="was-selektive-offenlegung-praktisch-ändert">Was selektive Offenlegung praktisch ändert</h2> <p>Das gängige Beispiel ist die Altersprüfung. Statt das volle Geburtsdatum zu übertragen, kann das Wallet allein das abgeleitete Attribut „über 18&quot; 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.</p> <h2 id="der-schwierige-teil-vertrauen-statt-gültigkeit">Der schwierige Teil: Vertrauen statt Gültigkeit</h2> <p>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 <strong>Vertrauenslisten</strong> 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.</p> <p>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.</p> <h2 id="warum-sich-der-blick-auf-standards-lohnt">Warum sich der Blick auf Standards lohnt</h2> <p>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.</p> <p>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.</p>https://datargo.com/blog/e-rechnung-archivierung-gobd/2026-04-21T00:00:00+00:002026-04-21T00:00:00+00:00

Ab 2027 wird die strukturierte E-Rechnung zum Pflichtformat. Was revisionssichere Aufbewahrung, die verkürzte 8-Jahres-Frist und der Unterschied zwischen Sichtkopie und maßgeblichem Datensatz praktisch bedeuten.

<p>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.</p> <h2 id="was-sich-an-der-frist-geändert-hat">Was sich an der Frist geändert hat</h2> <p>Lange galt für Buchungsbelege eine zehnjährige Aufbewahrungsfrist. Das vierte Bürokratieentlastungsgesetz (BEG IV) hat sie zum 1. Januar 2025 auf <strong>acht Jahre</strong> verkürzt. Die neue Frist gilt für alle Belege, deren bisherige Zehnjahresfrist zu diesem Zeitpunkt noch nicht abgelaufen war.</p> <p>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&quot; steht im Spannungsverhältnis zur Pflicht, personenbezogene Daten nicht länger als nötig vorzuhalten.</p> <h2 id="was-revisionssicher-technisch-verlangt">Was „revisionssicher&quot; technisch verlangt</h2> <p>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.</p> <p>Für strukturierte Formate kommt eine zweite Anforderung hinzu, die oft unterschätzt wird.</p> <h2 id="sichtkopie-ist-nicht-gleich-datensatz">Sichtkopie ist nicht gleich Datensatz</h2> <p>Eine XRechnung ist ein reiner XML-Datensatz. ZUGFeRD ist hybrid: ein PDF mit eingebettetem XML. Der entscheidende Punkt: Aufbewahrungspflichtig ist der <strong>strukturierte Datensatz</strong>, 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.</p> <p>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.</p> <h2 id="wo-das-in-der-praxis-zusammenläuft">Wo das in der Praxis zusammenläuft</h2> <p>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 unserem Modul Datargo ERP 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.</p> <p>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.</p>https://datargo.com/blog/nis2-praxis-nachweis/2026-04-14T00:00:00+00:002026-04-14T00:00:00+00:00

Seit Dezember 2025 ist NIS2 deutsches Recht. Was Monitoring, Meldung und Logging im Prüfungsfall wirklich belegen müssen, und wo Unternehmen jetzt stehen.

<p>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.</p> <p>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.</p> <h2 id="die-uhr-läuft-in-stunden-nicht-in-wochen">Die Uhr läuft in Stunden, nicht in Wochen</h2> <p>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.</p> <h2 id="was-der-prüfer-sehen-will">Was der Prüfer sehen will</h2> <p>§30 verlangt Risikomanagementmaßnahmen: Monitoring, Logging, Incident Handling, Business Continuity und Lieferkettensicherheit. Der entscheidende Unterschied liegt zwischen &ldquo;wir betreiben Monitoring&rdquo; und &ldquo;wir können belegen, was wann passiert ist&rdquo;. Eine Aufsicht akzeptiert keine Absichtserklärung, sie will Evidenz.</p> <p>Belastbar ist ein Nachweis dann, wenn er drei Eigenschaften hat:</p> <ul> <li><strong>Lückenlos:</strong> Erkennung, Eskalation und Reaktion sind durchgängig zeitgestempelt, ohne dunkle Phasen im Verlauf.</li> <li><strong>Unveränderbar:</strong> Logs und Incident-Verläufe liegen append-only vor, nachträglich nicht still korrigierbar.</li> <li><strong>Rekonstruierbar:</strong> Aus dem Trail lässt sich die Vorfallchronik so ableiten, dass sie auf die 24-, 72- und 30-Tage-Fristen abbildet.</li> </ul> <p>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.</p> <h2 id="verantwortung-lässt-sich-nicht-delegieren">Verantwortung lässt sich nicht delegieren</h2> <p>§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.</p> <h2 id="was-jetzt-sinnvoll-ist">Was jetzt sinnvoll ist</h2> <p>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.</p> <p>In unserem Modul Datargo Monitor 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.</p> <p>NIS2 fragt nicht, ob Sie Monitoring betreiben. Es fragt, ob Sie es beweisen können.</p>https://datargo.com/blog/acme-interne-pki-mtls/2026-03-17T00:00:00+00:002026-03-17T00:00:00+00:00

Kurze Laufzeiten lassen sich nur automatisiert beherrschen. Warum interne PKI, Service-Mesh und mTLS anderen Mustern folgen als das öffentliche Web und wie ACME auch hinter der Firewall funktioniert.

<p>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.</p> <h2 id="warum-intern-nicht-einfacher-heißt">Warum „intern&quot; nicht „einfacher&quot; heißt</h2> <p>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.</p> <p>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.</p> <h2 id="acme-ist-nicht-nur-für-lets-encrypt">ACME ist nicht nur für Let&rsquo;s Encrypt</h2> <p>ACME (RFC 8555) ist als Protokoll für die automatische Ausstellung und Erneuerung bekannt geworden, vor allem über Let&rsquo;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.</p> <p>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.</p> <h2 id="was-den-unterschied-macht">Was den Unterschied macht</h2> <p>Drei Fähigkeiten entscheiden darüber, ob interne Automatisierung trägt.</p> <p><strong>Discovery auch nach innen.</strong> 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.</p> <p><strong>Eine CA-agnostische Sicht.</strong> 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.</p> <p><strong>Erneuerung mit Kontrolle.</strong> 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.</p> <p>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.</p> <p>Die 47-Tage-Diskussion ist ein guter Anlass, den Blick zu weiten. Die meisten Zertifikate eines Unternehmens stehen nicht im Schaufenster, sondern im Maschinenraum.</p>https://datargo.com/blog/dora-drittparteienrisiko/2025-12-09T00:00:00+00:002025-12-09T00:00:00+00:00

Seit Januar 2025 gilt DORA im Finanzsektor, mit Folgen für jeden Zulieferer. Was Auslagerungsregister, Meldeketten und die ersten kritischen Einstufungen bedeuten.

<p>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.</p> <p>Die naheliegende Reaktion vieler IT-Dienstleister lautet: betrifft mich nicht, ich bin keine Bank. Das ist ein Trugschluss. DORA wandert über die Lieferkette.</p> <h2 id="warum-die-verordnung-jeden-zulieferer-erreicht">Warum die Verordnung jeden Zulieferer erreicht</h2> <p>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.</p> <p>Was das Finanzunternehmen an Pflichten trägt, reicht es vertraglich an seine Dienstleister weiter. In der Praxis verlangen Finanzkunden inzwischen:</p> <ul> <li><strong>DORA-konforme Vertragsklauseln</strong> mit klaren Leistungs-, Sicherheits- und Beendigungsregelungen.</li> <li><strong>Audit- und Zugangsrechte</strong>, damit Kunde und Aufsicht prüfen können.</li> <li><strong>Transparenz über Sub-Auslagerung</strong>, also wer hinter dem Dienstleister noch beteiligt ist.</li> <li><strong>Meldeketten bei Vorfällen</strong>, schnell genug, damit der Finanzkunde seine eigenen Fristen hält.</li> <li><strong>Exit- und Kontinuitätspläne</strong> sowie Nachweise aus Resilienz-Tests.</li> </ul> <h2 id="incident-reporting-ist-eine-kette-kein-formular">Incident-Reporting ist eine Kette, kein Formular</h2> <p>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.</p> <h2 id="kritisch-eingestuft-heißt-direkte-aufsicht">Kritisch eingestuft heißt direkte Aufsicht</h2> <p>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.</p> <h2 id="was-jetzt-sinnvoll-ist">Was jetzt sinnvoll ist</h2> <p>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 Datargo Monitor 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.</p> <p>DORA ist kein reines Bankenthema. Es ist die Anforderung, die Ihre Finanzkunden ab sofort an Sie weiterreichen.</p>https://datargo.com/blog/post-quantum-migration/2025-09-16T00:00:00+00:002025-09-16T00:00:00+00:00

Mit den finalen NIST-Standards und 'harvest now, decrypt later' wird Krypto-Agilität zur Betriebsaufgabe. Ein praxisnaher Einstieg in Inventar und schrittweise Umstellung.

<p>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.</p> <h2 id="harvest-now-decrypt-later-macht-die-sache-dringend">&ldquo;Harvest now, decrypt later&rdquo; macht die Sache dringend</h2> <p>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.</p> <p>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.</p> <h2 id="warum-die-umstellung-jahre-dauert">Warum die Umstellung Jahre dauert</h2> <p>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.</p> <p>Der Weg ist in der Reihenfolge klar:</p> <ul> <li><strong>Inventarisieren:</strong> sichtbar machen, wo welche Kryptografie steckt, inklusive eingebetteter und vergessener Nutzung.</li> <li><strong>Priorisieren:</strong> zuerst die langlebigen Daten, die heute schon dem Harvest-now-Risiko unterliegen.</li> <li><strong>Krypto-Agilität herstellen:</strong> Algorithmen so kapseln, dass sie ohne Codeänderung im aufrufenden System wechselbar sind.</li> <li><strong>Hybrid pilotieren:</strong> klassische und Post-Quantum-Verfahren parallel, um Interoperabilität und Performance zu prüfen.</li> <li><strong>Automatisieren und fordern:</strong> Erneuerung automatisieren und Lieferanten verbindlich auf PQC-Fähigkeit verpflichten.</li> </ul> <h2 id="krypto-agilität-ist-der-eigentliche-hebel">Krypto-Agilität ist der eigentliche Hebel</h2> <p>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.</p> <p>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.</p> <p>2026 ist das Jahr, in dem Inventar und Pilot stehen sollten. Dann ist 2030 nur noch der Abschluss, kein Schreckdatum.</p>https://datargo.com/blog/e-rechnungspflicht-stufenplan/2025-02-11T00:00:00+00:002025-02-11T00:00:00+00:00

Empfang seit Januar 2025, Versand ab 2027 und 2028. Was EN 16931, XRechnung und ZUGFeRD unterscheidet und welche Formatfallen in der Praxis wirklich zählen.

<p>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.</p> <p>Rund um diese Pflicht kursieren mehr Halbwahrheiten als bei den meisten Steuerthemen. Drei davon lohnt es sich auszuräumen.</p> <h2 id="mythos-1-eine-pdf-ist-eine-e-rechnung">Mythos 1: &ldquo;Eine PDF ist eine E-Rechnung&rdquo;</h2> <p>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 &ldquo;sonstige Rechnung&rdquo;. Maßgeblich ist das maschinenlesbare XML, nicht das Bild für das menschliche Auge.</p> <p>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 &ldquo;EN 16931&rdquo; (Comfort) sind normkonform. Die kleineren Profile MINIMUM und BASIC WL tragen zu wenig Daten, um als vollwertige Rechnung zu gelten.</p> <h2 id="mythos-2-das-betrifft-erst-2027-und-nur-die-großen">Mythos 2: &ldquo;Das betrifft erst 2027, und nur die Großen&rdquo;</h2> <p>Der Empfang betrifft seit Januar 2025 alle. Erst der Versand ist gestaffelt:</p> <ul> <li>seit 1.1.2025: Empfangspflicht für alle inländischen Unternehmen</li> <li>ab 1.1.2027: Versandpflicht für Unternehmen mit mehr als 800.000 Euro Vorjahresumsatz</li> <li>ab 1.1.2028: Versandpflicht für alle übrigen B2B-Beziehungen</li> </ul> <p>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.</p> <h2 id="mythos-3-empfang-heißt-nur-dass-die-mail-ankommt">Mythos 3: &ldquo;Empfang heißt nur, dass die Mail ankommt&rdquo;</h2> <p>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:</p> <ul> <li><strong>Validierung:</strong> Das eingehende XML sollte gegen Schema und Geschäftsregeln der EN 16931 geprüft werden, sonst landen fehlerhafte Rechnungen unbemerkt im Bestand.</li> <li><strong>Sichtbarmachung:</strong> Ein Viewer, der das XML lesbar darstellt, damit Fachabteilungen ohne XML-Kenntnisse prüfen können.</li> <li><strong>GoBD-konforme Archivierung:</strong> Aufbewahrt werden muss das strukturierte Original, unveränderbar und revisionssicher verkettet, nicht nur ein PDF-Ausdruck.</li> </ul> <p>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.</p> <h2 id="was-jetzt-sinnvoll-ist">Was jetzt sinnvoll ist</h2> <p>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 unserem kaufmännischen Kern Datargo ERP 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.</p> <p>Die Pflicht kommt nicht erst 2027. Sie hat 2025 begonnen, nur eben leise, auf der Empfangsseite.</p>