Seit dem 6. Dezember 2025 ist das NIS2-Umsetzungsgesetz in Deutschland in Kraft und wird vom Bundesamt für Sicherheit in der Informationstechnik durchgesetzt (BSI). Rund 29.500 Unternehmen fallen seither unter die NIS2-Aufsicht des BSI -- zuvor waren es nur etwa 4.500 (BSI). Wer die neuen Pflichten verletzt, riskiert Bußgelder von bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes (NIS2-Umsetzungsgesetz). Für Handels- und Industrieunternehmen mit angebundenem Online-Shop rücken damit ausgerechnet die Verbindungen in den Mittelpunkt, die bisher im Verborgenen liefen: die APIs zwischen Shop, ERP-System und Warenwirtschaft. Über diese Schnittstellen fließen Bestell-, Kunden-, Preis- und Lagerdaten -- und genau hier entstehen die Angriffsflächen, die NIS2 adressiert. Dieser Beitrag ordnet die neuen Pflichten konkret auf ERP-Shop-Schnittstellen ein und zeigt in fünf Schritten, wie eine bestehende Anbindung NIS2-konform abgesichert wird: von der Inventarisierung über Verschlüsselung und Authentifizierung bis zu Monitoring und Lieferketten-Nachweisen.
Was NIS2 für die ERP-Shop-Schnittstelle bedeutet
NIS2 ist die zweite EU-Richtlinie zur Netz- und Informationssicherheit. Deutschland hat sie mit dem NIS2-Umsetzungsgesetz in nationales Recht überführt, das seit dem 6. Dezember 2025 ohne Übergangsfrist gilt (BSI). Ein Unternehmen ist betroffen, wenn es drei Kriterien erfüllt: Zugehörigkeit zu einem der regulierten Sektoren, ab 50 Beschäftigten oder mehr als 10 Millionen Euro Jahresumsatz und die Einstufung als besonders wichtige oder wichtige Einrichtung nach dem BSI-Gesetz (BSI). Viele Großhändler, Hersteller und Handelsunternehmen mit E-Commerce-Anbindung fallen erstmals unter diese Aufsicht, ohne es sofort zu bemerken.
Der Kern der Pflichten steht in Paragraf 30 BSIG: Betroffene Einrichtungen müssen geeignete technische und organisatorische Maßnahmen ergreifen, um die Risiken für ihre Netz- und Informationssysteme zu beherrschen (BSI). Dazu zählen ausdrücklich Risikoanalyse, Zugriffskontrolle, Multi-Faktor-Authentifizierung, Kryptografie und Verschlüsselung sowie die Sicherheit der Lieferkette (BSI). Eine ERP-Shop-Schnittstelle ist ein solches Netz- und Informationssystem: Sie verarbeitet geschäftskritische Daten und ist von außen erreichbar. Damit gilt für sie derselbe Maßstab wie für das ERP oder den Shop selbst.
| Merkmal | Besonders wichtige Einrichtung | Wichtige Einrichtung |
|---|---|---|
| Größe (Richtwert) | ab 250 Beschäftigte oder über 50 Mio. Euro Umsatz | ab 50 Beschäftigte oder über 10 Mio. Euro Umsatz |
| Aufsicht durch das BSI | proaktiv, auch anlasslose Prüfungen möglich | reaktiv, nach Vorfall oder konkretem Hinweis |
| Bußgeldrahmen | bis 10 Mio. Euro oder 2% des Weltumsatzes | bis 7 Mio. Euro oder 1,4% des Weltumsatzes |
| Registrierung beim BSI | verpflichtend | verpflichtend |
| Meldepflicht bei Vorfällen | 24 h / 72 h / 1 Monat | 24 h / 72 h / 1 Monat |
Warum die Schnittstelle und nicht nur das ERP zählt
Neu regulierte Einrichtungen müssen sich zudem innerhalb von drei Monaten beim BSI registrieren und Kontaktdaten sowie öffentliche IP-Bereiche hinterlegen (BSI). Damit rückt automatisch die Frage in den Vordergrund, welche Schnittstellen überhaupt nach außen erreichbar sind -- eine Frage, die sich ohne vollständiges Schnittstellen-Inventar nicht beantworten lässt.
Das Risiko alter, undokumentierter ERP-Anbindungen
Die größte Gefahr geht selten von der neu gebauten Schnittstelle aus, sondern von der alten, die niemand mehr auf dem Schirm hat. Über Jahre wachsen zwischen Shop und ERP Punkt-zu-Punkt-Verbindungen, Import-Skripte und Zusatz-Endpunkte, die einmal für eine Migration oder ein Sonderprojekt entstanden sind. Wie tief solche Altlasten reichen, zeigt unser Beitrag zur Migration von Legacy-ERP-Systemen. OWASP führt genau dieses Problem als eigenes Risiko: API9:2023 Improper Inventory Management beschreibt veraltete, undokumentierte oder vergessene Endpunkte, die weiterhin erreichbar sind (OWASP).
Das häufigste API-Risiko überhaupt ist die fehlerhafte Objekt-Autorisierung, im Original Broken Object Level Authorization. Sie belegt seit 2019 und auch in der Ausgabe 2023 Platz 1 der OWASP API Security Top 10 (OWASP). Dabei manipuliert ein Angreifer die ID eines Objekts in der Anfrage -- etwa eine Bestell- oder Kundennummer -- und erhält Zugriff auf fremde Datensätze, weil die Schnittstelle die Berechtigung nicht pro Objekt prüft (OWASP). Gerade ältere ERP-Anbindungen, die schlicht jede übergebene ID vertrauen, sind hierfür anfällig.
Eine Schnittstelle, die niemand mehr dokumentiert, ist kein Restrisiko, sondern die wahrscheinlichste Eintrittstür. NIS2 zwingt dazu, diese vergessenen Verbindungen endlich sichtbar zu machen.
- Vergessene Endpunkte: Test- und Alt-Endpunkte aus frühen Projektphasen laufen weiter, ohne aktuelle Absicherung.
- Statische Zugangsdaten: Fest im Code hinterlegte API-Schlüssel oder Basic-Auth-Passwörter, die seit Jahren nicht rotiert wurden.
- Fehlende Objekt-Prüfung: Die Schnittstelle liefert Datensätze allein anhand der übergebenen ID aus, ohne die Berechtigung zu prüfen.
- Unverschlüsselte Strecken: Interne Verbindungen, die im Rechenzentrum noch im Klartext laufen, weil sie als vertrauenswürdig galten.
- Keine Protokollierung: Zugriffe werden nicht geloggt, sodass ein Datenabfluss unbemerkt bleibt und im Vorfall nicht rekonstruierbar ist.
Statische Schlüssel im Code sind das Kernproblem
Die wirtschaftliche Dimension ist erheblich: 87 Prozent aller deutschen Unternehmen wurden zuletzt Opfer von Datendiebstahl, Industriespionage oder Sabotage (Bitkom). Der jährliche Gesamtschaden für die deutsche Wirtschaft liegt bei 289,2 Milliarden Euro, wovon rund 70 Prozent auf Cyberangriffe zurückgehen (Bitkom). NIS2 ist damit weniger eine bürokratische Pflichtübung als die regulatorische Antwort auf eine reale, messbare Bedrohungslage.
Schritt 1: Inventarisierung aller Schnittstellen
Absichern lässt sich nur, was bekannt ist. Der erste Schritt ist deshalb ein vollständiges Inventar aller Schnittstellen zwischen Shop, ERP und angrenzenden Systemen. OWASP nennt fehlendes Schnittstellen-Inventar ausdrücklich als eigenes Risiko und empfiehlt, jede API-Version und jeden Endpunkt zu erfassen und alte Versionen kontrolliert abzuschalten (OWASP). Wie sich Versionsstände sauber führen und ausrangieren lassen, vertieft unser Beitrag zur API-Versionierung für langlebige Schnittstellen.
Ein belastbares Inventar erfasst pro Schnittstelle mehr als nur die URL. Es dokumentiert, welche Datenklassen fließen, wie authentifiziert wird, wer die Verbindung betreibt und in welchem Versions- und Patch-Stand sie läuft. Erst diese Übersicht macht das Risiko jeder einzelnen Verbindung bewertbar und bildet die Grundlage für die später geforderte Dokumentation gegenüber dem BSI.
Endpunkte und Versionen
Jede erreichbare Route mit Methode, Version und Zweck -- inklusive der Alt-Endpunkte, die im Tagesgeschäft niemand mehr erwähnt.
Authentifizierungsverfahren
Pro Schnittstelle festhalten, ob API-Key, Basic-Auth, OAuth oder mTLS im Einsatz ist -- schwache Verfahren werden so sofort sichtbar.
Datenklassen
Welche Daten fließen: personenbezogene Kundendaten, Preise, Lagerbestände oder Zahlungsinformationen. Das bestimmt den Schutzbedarf.
Betreiber und Standort
Wer die Schnittstelle betreibt, in welchem Rechenzentrum sie läuft und ob externe Dienstleister beteiligt sind.
Versions- und Patch-Stand
Welche Bibliotheken und Laufzeiten im Einsatz sind und wann zuletzt aktualisiert wurde -- die Basis für das Schwachstellenmanagement.
Verantwortlichkeit
Eine benannte Ansprechperson je Schnittstelle, damit im Vorfall klar ist, wer handeln und melden muss.
Schritt 2: Ende-zu-Ende-Verschlüsselung
Paragraf 30 Absatz 2 Nummer 8 BSIG schreibt den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung vor (BSI). Für eine ERP-Shop-Schnittstelle bedeutet das: Jede Verbindung -- vom Browser bis zum ERP und zurück -- läuft über aktuelles Transport Layer Security, in der Regel TLS 1.3. Entscheidend ist das Wort Ende-zu-Ende. Es genügt nicht, nur die Außenverbindung zum Shop zu verschlüsseln und die internen Strecken zwischen Middleware und ERP im Klartext zu belassen, weil sie als vertrauenswürdig gelten.
Der Zero-Trust-Grundsatz kennt kein vertrauenswürdiges internes Netz mehr: Jede Verbindung wird verschlüsselt und jeder Aufrufer authentifiziert, unabhängig davon, ob er innerhalb oder außerhalb des Rechenzentrums sitzt. In der Praxis wird die Middleware zum zentralen Ort, an dem TLS-Terminierung, Zertifikatsverwaltung und Schlüsselrotation gebündelt und einheitlich durchgesetzt werden -- statt in jeder Punkt-zu-Punkt-Verbindung erneut.
Verschlüsselung ist mehr als HTTPS an der Außenkante
Schritt 3: Authentifizierung mit OAuth 2.0, OIDC und mTLS
Statische API-Schlüssel und Basic-Auth gehören zu den häufigsten Schwachstellen alter Anbindungen. OWASP führt fehlerhafte Authentifizierung als API2:2023 Broken Authentication auf Platz 2 der API Security Top 10 (OWASP). Der Standard für moderne, delegierte Zugriffe ist stattdessen OAuth 2.0 in Verbindung mit OpenID Connect: Ein Autorisierungsserver stellt kurzlebige Access Tokens mit eng gefasstem Berechtigungsumfang aus, statt dauerhaft gültige Passwörter im Code zu hinterlegen.
Für die Maschine-zu-Maschine-Kommunikation zwischen Shop und ERP kommt mutual TLS hinzu. Bei mTLS weisen sich beide Seiten mit Zertifikaten aus -- nicht nur der Server gegenüber dem Client, sondern auch der Client gegenüber dem Server. Die IETF standardisiert mit RFC 8705 die OAuth-2.0-Authentifizierung über mTLS und zertifikatsgebundene Access Tokens, sodass ein Token nur mit dem passenden Client-Zertifikat nutzbar ist (IETF RFC 8705). Ein gestohlenes Token allein bringt einem Angreifer damit nichts mehr. Wie sich diese Logik an zentraler Stelle bündeln lässt, zeigt der Vergleich REST-API gegen Middleware.
| Aspekt | Alte Anbindung | NIS2-konforme Anbindung |
|---|---|---|
| Authentifizierung | Statischer API-Key oder Basic-Auth | OAuth 2.0 mit OpenID Connect |
| Maschine-zu-Maschine | Passwort im Code | mTLS mit Client-Zertifikaten (RFC 8705) |
| Token-Gültigkeit | dauerhaft, selten rotiert | kurzlebig, automatisch erneuert |
| Berechtigungsumfang | Vollzugriff | eng gefasste Scopes je Aufgabe |
| Widerruf | nur durch globalen Schlüsseltausch | gezielt pro Token oder Zertifikat |
OAuth 2.0 und OIDC
Delegierte Autorisierung mit kurzlebigen Tokens und überprüfbarer Identität -- kein Passwort mehr im Quelltext der Integration.
mTLS zwischen Diensten
Beidseitige Zertifikatsprüfung für die Service-zu-Service-Kommunikation, gebunden an das jeweilige Client-Zertifikat.
Least Privilege
Jeder Zugang erhält nur die Rechte, die er für seine Aufgabe braucht -- eng gefasste Scopes statt pauschalem Vollzugriff.
Multi-Faktor für Betreiber
Zugänge zu Verwaltung und Deployment der Schnittstelle werden mit Multi-Faktor-Authentifizierung geschützt, wie Paragraf 30 BSIG es verlangt.
Automatische Rotation
Schlüssel und Zertifikate werden regelmäßig und ohne Ausfall erneuert, sodass kompromittierte Geheimnisse schnell wertlos werden.
Objekt-Autorisierung
Jede Anfrage prüft die Berechtigung pro Datensatz und schließt so die fehlerhafte Objekt-Autorisierung von OWASP-Platz 1 aus.
Schritt 4: Monitoring und Meldepflicht
NIS2 verlangt nicht nur Vorbeugung, sondern auch die Fähigkeit, Vorfälle zu erkennen und fristgerecht zu melden. Bei einem erheblichen Sicherheitsvorfall gilt eine gestaffelte Meldekette an das BSI: eine Erstmeldung innerhalb von 24 Stunden, eine Detailmeldung nach 72 Stunden und ein Abschlussbericht nach spätestens einem Monat (BSI). Diese Fristen lassen sich nur einhalten, wenn die Schnittstelle lückenlos protokolliert und Anomalien automatisch auffallen.
- Zugriffsprotokolle: Jeder Aufruf mit Zeitstempel, Identität, Endpunkt und Ergebnis -- die Grundlage für jede spätere Rekonstruktion.
- Anomalie-Erkennung: Auffällige Muster wie plötzliche Massenabfragen einzelner Datensätze oder ungewohnte Zugriffszeiten werden erkannt und alarmiert.
- Rate Limiting: Begrenzte Aufrufraten schützen vor automatisiertem Abgriff und vor der unbegrenzten Ressourcennutzung, die OWASP als API4:2023 führt.
- Fehler- und Ausfallüberwachung: Steigende Fehlerraten oder Zeitüberschreitungen deuten frühzeitig auf Angriffe oder Störungen hin.
- Aufbewahrung: Protokolle werden so lange revisionssicher vorgehalten, dass sich ein Vorfall auch rückwirkend aufklären lässt.
Schnelligkeit vor Vollständigkeit
Wie ein durchgängiges Monitoring von Schnittstellen technisch aufgebaut wird, beschreibt unser Beitrag zur Observability von Schnittstellen. Eng damit verbunden ist eine saubere Fehlerbehandlung in Schnittstellen, denn nur wer Fehlerzustände sichtbar macht, kann einen Angriff von einer harmlosen Störung unterscheiden. Zur Einordnung der Bedrohungslage: DDoS-Angriffe waren zuletzt mit über 46 Prozent die am häufigsten gemeldete Cyberbedrohung im EU-Raum (ENISA).
Schritt 5: Lieferketten-Nachweise
Paragraf 30 BSIG nennt die Sicherheit der Lieferkette ausdrücklich als eigene Maßnahme, einschließlich der sicherheitsbezogenen Aspekte der Beziehungen zu unmittelbaren Anbietern und Diensteanbietern (BSI). Für ERP-Shop-Schnittstellen ist das besonders relevant, weil an ihnen fast immer Dritte beteiligt sind: der Shop-Betreiber, ein ERP-Dienstleister, eine Zahlungsanbindung oder ein externer Middleware-Anbieter. Jeder dieser Beteiligten kann selbst zum Einfallstor werden.
OWASP führt die unsichere Nutzung fremder Schnittstellen als API10:2023 Unsafe Consumption of APIs -- also das ungeprüfte Vertrauen in Daten und Verfügbarkeit von Drittanbietern (OWASP). Wie real diese Gefahr ist, zeigt der von ENISA dokumentierte Fall der Backdoor in XZ Utils: Ein kompromittiertes Open-Source-Paket konnte ganze Software-Lieferketten gefährden (ENISA). Für den Betreiber einer Schnittstelle bedeutet das, die Sicherheit der eingebundenen Dienste nicht anzunehmen, sondern nachweisen zu lassen.
Vertragliche Zusicherungen
Sicherheitsanforderungen und Meldepflichten der Dienstleister werden vertraglich verankert, damit ein Vorfall beim Anbieter nicht ungemeldet bleibt.
Software-Stückliste
Eine Übersicht der eingebundenen Komponenten und Bibliotheken macht sichtbar, welche Fremdsoftware in der Schnittstelle steckt und aktuell gehalten werden muss.
Zertifikate und Prüfberichte
Nachweise wie unabhängige Prüfberichte oder Zertifizierungen der Anbieter dokumentieren deren Sicherheitsniveau nachvollziehbar.
Regelmäßige Neubewertung
Die Risikobewertung der Anbieter wird nicht einmalig, sondern wiederkehrend durchgeführt und bei Änderungen aktualisiert.
Bonitäts- und Fremddienste gehören ins Lieferketten-Bild
Der Weg zur NIS2-konformen Schnittstelle
Der Weg von einer gewachsenen Anbindung zu einer NIS2-konformen Schnittstelle lässt sich strukturiert gehen. Am Anfang steht selten ein Neubau, sondern ein ehrlicher Blick auf den Bestand: Welche Schnittstellen existieren, wie sind sie abgesichert und wo klaffen Lücken gegenüber Paragraf 30 BSIG. Aus diesem Befund ergeben sich Prioritäten -- die größten Risiken zuerst, der Rest planbar danach.
1. Audit und Inventar
Vollständige Erfassung aller Schnittstellen, Bewertung von Authentifizierung, Verschlüsselung und Protokollierung gegen die NIS2-Anforderungen.
2. Absicherung
Ablösung statischer Schlüssel durch OAuth 2.0, OpenID Connect und mTLS, durchgängige Verschlüsselung und Einführung von Monitoring und Rate Limiting.
3. Dokumentation
Nachvollziehbare Dokumentation von Schnittstellen, Maßnahmen und Lieferketten-Nachweisen als Grundlage für Prüfungen und Meldungen.
4. Konforme Entwicklung
Neue Schnittstellen werden von Beginn an nach NIS2-Maßstab entwickelt -- mit sicheren Standards, Least Privilege und eingebautem Monitoring.
NIS2 ist kein einmaliges Projekt, sondern ein Betriebszustand. Eine Schnittstelle, die dokumentiert, verschlüsselt, sauber authentifiziert und überwacht ist, erfüllt nicht nur die Pflicht, sondern läuft auch verlässlicher.
Wer die Absicherung in eine größere Integrationsstrategie einbettet, findet weiterführende Ansätze in unserem Beitrag zur OCI-PunchOut-Anbindung von Beschaffungsportalen sowie zur SAP Integration Suite und Clean-Core-Anbindung. Beide zeigen, wie sich Sicherheit nicht als Nachtrag, sondern als Teil der Architektur denken lässt.
Quellen und Studien