E-Invoice Finder
Menu
Länder Software Fristen Leitfäden Check Pflicht prüfen
ENFRDEPLNL
Polen · KSeF-Sicherheitsvorfall

KSeF-Zertifikat kompromittiert: sperren und ersetzen

Dämmen Sie einen KSeF-Schlüsselvorfall ein, widerrufen Sie das richtige Zertifikat und ersetzen Sie ERP-Zugangsdaten kontrolliert.

Kurzfazit:
  • Umfang: Zertifikatsvorfall und Berechtigungsprüfung sind zwei getrennte Arbeitsstränge.
  • Risiko: Kopierte Schlüssel können außerhalb des zuerst entdeckten ERP-Systems fortbestehen.
  • Aktion: Seriennummer verifizieren, sauber widerrufen und jede bekannte Installation gezielt neu ausrollen.
Polen-Readiness-BerichtOffizielle Quellen
Zuletzt geprüft: 31. Juli 2026Offizielle QuellenKlare ZusammenfassungPraktische Information, keine Rechtsberatung
Offizielle Quellen priorisiert
Prüfdatum sichtbar
Kostenloser Check ohne Registrierung

Was Sie wissen müssen

Leitfaden

1. Triage und Schweregrad festlegen

Behandeln Sie den Hinweis zunächst als möglichen Schlüsselvorfall, nicht automatisch als bestätigten Missbrauch. Eröffnen Sie ein Incident-Ticket, benennen Sie Einsatzleitung, KSeF-Fachverantwortung, ERP-Betrieb, Informationssicherheit und eine beweissichernde Person. In den ersten 30 Minuten sollten Alarmquelle, Entdeckungszeit, betroffene Umgebung, vermuteter Schlüsselpfad und laufende Rechnungsprozesse dokumentiert werden. Empfohlene Incident-Praxis ist, betroffene Secrets und Workloads zu isolieren: beispielsweise den verdächtigen Container aus dem Netzwerk nehmen, einen kompromittierten Secret-Store-Zugriff deaktivieren oder einen Exportordner sperren. Das ist keine besondere gesetzliche KSeF-Frist, sondern eine risikobasierte Schutzmaßnahme. Ordnen Sie die Lage nach nachvollziehbaren Kriterien ein. Hohe Dringlichkeit besteht etwa bei veröffentlichtem Private Key, unbekannten API-Aufrufen, Zugriff auf eine Produktionsintegration oder einem Schlüssel auf einem gestohlenen Gerät. Ein Fehlalarm ist wahrscheinlicher, wenn nur ein abgelaufenes Zertifikat gemeldet wurde und kein Schlüsselabfluss erkennbar ist; dennoch muss die Zuordnung geprüft werden. Vermeiden Sie vorschnelle Gesamtausfälle: Eine Abschaltung aller Rechnungswege kann mehr Schaden verursachen, ohne den kopierten Schlüssel einzudämmen. Entscheidungspunkt nach 30 bis 60 Minuten: Ist ein bestimmtes Zertifikat plausibel exponiert, wird der saubere Widerruf vorbereitet; ist die Identität noch unklar, bleibt die Umgebung isoliert, während Seriennummer und Nutzung ermittelt werden.

Leitfaden

2. Zertifikat, Typ, Eigentümer und Einsatzorte eindeutig bestimmen

Erstellen Sie eine belastbare Inventarzeile mit Seriennummer, Zertifikatseigentümer, juristischer Einheit, Zertifikatstyp, Ablaufdatum, Fingerabdruck, Schlüsselablage, ERP-Mandant, Schnittstellenkonto und allen Deployments. Die offizielle CIRFMF-Dokumentation nennt für Metadatenabfragen POST /certificates/query; mögliche Statuswerte sind Active, Blocked, Revoked und Expired. Prüfen Sie die Antwort über einen vertrauenswürdigen Administrationsweg und gleichen Sie sie mit CMDB, Secret Manager, Deployment-Manifesten und Übergabeprotokollen ab. Unternehmen, die Entity-Zertifikate verteilen, müssen laut Ministerium die Nachvollziehbarkeit von Download, Übergabe, Nutzung und Widerruf sicherstellen. Unterscheiden Sie Type 1 Authentication und Type 2 Offline. Type 1 dient der Authentifizierung, Type 2 der Prüfung des Ausstellers bei Rechnungen in offline24-, Systemausfall- oder Notfallverfahren. Ein Type-2-Zertifikat authentifiziert keine API-Sitzung. Das Zertifikat selbst trägt außerdem weder KSeF-Berechtigungen noch einen Unternehmenskontext; diese liegen in den jeweiligen KSeF-Zuordnungen. Beispiel: Findet das Team eine PEM-Datei im Offline-Signaturdienst, darf es daraus nicht schließen, dass auch der API-Zugang des ERP kompromittiert ist. Umgekehrt deckt der Austausch eines Type-1-Zertifikats keine Kopie eines separat eingesetzten Type-2-Schlüssels ab. Können Eigentümer oder Seriennummer nicht zweifelsfrei bestimmt werden, darf nicht auf Verdacht irgendein gleichnamiges Zertifikat widerrufen werden.

Leitfaden

3. Eindämmung und Widerruf über einen sauberen Pfad

Trennen Sie zuerst die vermutlich betroffene Ausführungsumgebung, ohne die Beweise zu überschreiben. Sperren Sie unkontrollierte Exporte, stoppen Sie nur die konkret betroffenen Jobs und entfernen Sie den Schlüssel aus aktiven Mounts, nachdem relevante Zeitstempel, Hashwerte und Konfigurationen gesichert wurden. Rotieren Sie Zugangsdaten zu Vault, CI/CD, ERP und Administrationskonten, wenn diese über denselben kompromittierten Pfad erreichbar waren. Der private Schlüssel sollte nach der organisatorischen Sicherheitsrichtlinie geschützt gespeichert werden; ein bloßes Verschieben in einen anderen Ordner ist keine belastbare Eindämmung. Der Widerruf muss aus einer vertrauenswürdigen, autorisierten Umgebung erfolgen, nicht aus dem möglicherweise manipulierten ERP-Server. Nach CIRFMF kann nur der Eigentümer sein KSeF-Zertifikat widerrufen, insbesondere bei Kompromittierung des privaten Schlüssels, Nutzungsende oder organisatorischer Änderung. Technisch ist POST /certificates/{certificateSerialNumber}/revoke mit der Seriennummer und optionalem Grund vorgesehen. Nutzen Sie Vier-Augen-Kontrolle: Eine Person liest Seriennummer, Typ und Eigentümer aus der bestätigten Inventarzeile vor, eine zweite vergleicht diese unmittelbar vor dem Aufruf. Protokollieren Sie Anforderungszeit, ausführende Identität, Antwort und anschließende Statusabfrage. Das ist eine empfohlene Sicherheitskontrolle, keine vom KSeF vorgegebene Reaktionsfrist.

Leitfaden

4. Wirkung des Widerrufs – und seine Grenzen

Die offizielle Widerrufsprozedur erklärt, dass ein gültiger Widerrufsantrag das Zertifikat in KSeF automatisch blockiert, unabhängig davon, wann eine Zertifikatswiderrufsliste veröffentlicht wird. Daher darf kein vermeintliches CRL-Zeitfenster als fortbestehende Nutzbarkeit in KSeF eingeplant werden. Prüfen Sie anschließend per Metadatenabfrage, ob der erwartete Status erreicht ist, und bewahren Sie die technische Bestätigung im Incident-Vorgang auf. Ein widerrufenes Zertifikat kann nicht erneut verwendet werden; für die Wiederinbetriebnahme ist ein neues Zertifikat erforderlich. Das Ministerium nennt eine maximale Zertifikatsgültigkeit von zwei Jahren, doch ein Vorfall kann einen früheren Ersatz erzwingen. Der Widerruf beseitigt nicht automatisch alle Folgen. Er entzieht dem Eigentümer keine KSeF-Berechtigungen, widerruft keine weiteren Zertifikate, beweist weder Missbrauch noch dessen Ausbleiben und entfernt keine kopierten Schlüssel oder Konfigurationen aus Backups, Images und Entwicklerrechnern. Berechtigungen müssen daher separat geprüft und bei Bedarf über den dafür vorgesehenen KSeF-Prozess angepasst werden. Ebenso braucht jede Kopie des alten Schlüssels eine dokumentierte Bereinigung oder Quarantäne. Wenn mehrere Zertifikate betroffen sein könnten, wird jedes anhand von Evidenz bewertet; ein pauschaler Massenwiderruf ist nur dann angemessen, wenn Reichweite und Kontinuitätsfolgen bewusst entschieden wurden.

Leitfaden

5. Untersuchung und Beweissicherung

Bauen Sie eine Zeitachse vom frühesten möglichen Zugriff bis zur bestätigten Eindämmung. Sichern Sie unveränderbar, soweit betrieblich und rechtlich zulässig, KSeF-Anfragen und -Antworten, ERP-Audit-Logs, Secret-Manager-Zugriffe, CI/CD-Läufe, Systemanmeldungen, Prozessstarts, Netzwerkereignisse und Rechnungsaktivitäten. Halten Sie Zeitzonen, Logquellen, Aufbewahrungsfristen und Prüfsummen fest. Vermeiden Sie Aussagen wie „kein Missbrauch“, wenn lediglich ein einzelnes Log keine Auffälligkeit zeigt; fehlende Ereignisse können auch durch kurze Aufbewahrung oder unvollständige Telemetrie entstehen. Suchen Sie nach Nutzung der konkreten Seriennummer beziehungsweise des zugehörigen Schlüssels, ungewöhnlichen Sitzungszeiten, neuen Herkunftsadressen, unerwarteten Rechnungsreferenzen und Änderungen an Berechtigungen. Vergleichen Sie technische KSeF-Daten mit ERP-Belegen und fachlicher Freigabe. Beispiel: Eine nächtliche Authentifizierung kann ein legitimer geplanter Verarbeitungslauf sein; verdächtig wird sie, wenn Deployment, Quellnetz und Rechnungslauf nicht zusammenpassen. Legen Sie für jeden Befund Evidenz, alternative Erklärung, Bewertung und Eigentümer fest. Datenschutz, Arbeitsrecht, Meldepflichten und externe Kommunikation gehören in die Hände der zuständigen internen oder externen Fachstellen; diese Seite ersetzt keine Rechtsberatung.

Leitfaden

6. Sauberer Ersatz und gestufte Bereitstellung

Erzeugen Sie ein neues Schlüsselpaar in einer vertrauenswürdigen Umgebung und beantragen Sie ein neues Zertifikat; verwenden Sie den alten privaten Schlüssel nicht erneut. Legen Sie fest, wer Schlüssel erzeugt, wer das Zertifikat beantragt, wer es freigibt und wer es in Produktion ausrollt. Speichern Sie den neuen Schlüssel in einem geeigneten Secret-Management- oder HSM-gestützten Verfahren entsprechend Ihrer Sicherheitsrichtlinie. Beschränken Sie Exportfähigkeit und Zugriff, dokumentieren Sie Übergaben und vermeiden Sie Klartextkopien in Tickets, Chat oder Build-Artefakten. Rotieren Sie abhängige Secrets, wenn deren Vertraulichkeit durch denselben Vorfall infrage steht. Der Rollout sollte einer Inventarliste folgen: Entwicklung, Test, Notfallumgebung, produktive ERP-Instanzen, Middleware, Signaturdienst und geplante Jobs. Beginnen Sie mit einer isolierten Funktionsprüfung, danach einem begrenzten Canary-Mandanten und erst dann dem breiten Rollout. Abnahmekriterien sind erfolgreiche, erwartungsgemäße Authentifizierung mit Type 1, korrekte Ausstellerprüfung mit Type 2, keine Verwendung der alten Seriennummer, vollständige Protokollierung und ein getesteter Rückfallweg, der nicht den kompromittierten Schlüssel reaktiviert. Markieren Sie jeden Einsatzort mit verantwortlicher Person und Abschlusszeit. Alte Schlüsselreste werden kontrolliert entfernt oder beweissicher verwahrt, nicht unkoordiniert gelöscht.

Leitfaden

7. Geschäftskontinuität für Authentication und Offline

Planen Sie Kontinuität getrennt nach Funktion. Fällt ein Type-1-Zertifikat weg, betrifft das die damit aufgebaute API-Authentifizierung; Ersatz und Sitzungstests müssen diesen Pfad adressieren. Ein widerrufenes Type-2-Zertifikat betrifft dagegen die Verifikation des Ausstellers in den vorgesehenen Offline-Szenarien und kann nicht als API-Anmeldeersatz dienen. Testen Sie deshalb zwei eigenständige Kontrollpunkte: eine autorisierte KSeF-Testsitzung für Authentication und einen fachlich validierten Offline-Signaturablauf mit anschließender Verarbeitung. Ein erfolgreicher API-Test sagt nichts über die Offline-Signatur aus. Für die Übergangsphase braucht der Betrieb eine freigegebene Rechnungspriorisierung, Ansprechpartner für manuelle Entscheidungen und klare Stop-Kriterien. Legen Sie etwa fest, welche Gesellschaften und Rechnungsströme nach erfolgreichem Canary-Test zuerst wieder anlaufen und wann bei widersprüchlichen Statusdaten pausiert wird. Tokens bleiben nach aktueller Ministeriumsangabe seit dem 1. Februar 2026 parallel zu Zertifikaten nutzbar; nach der derzeitigen Planung sollen Zertifikate ab dem 1. Januar 2027 die verbleibende Methode sein. Wechseln Sie in einem Vorfall nicht unbesehen auf einen vorhandenen Token: Dessen Speicherung, Reichweite, Berechtigungen und mögliche Exposition müssen separat bewertet und eingegrenzt werden.

Leitfaden

8. Praxisfälle und häufige Fehler

Szenario A: Ein Entwickler findet einen Type-1-Private-Key in einem öffentlich erreichbaren Build-Artefakt. Das Team sperrt den Artefaktzugriff, sichert Logs und Hashwerte, bestätigt Seriennummer und Eigentümer, widerruft über einen sauberen Administrationsrechner, prüft KSeF-Aktivität und ersetzt Schlüssel sowie Zertifikat gestuft. Zusätzlich werden CI-Zugangsdaten rotiert, weil derselbe Build-Pfad betroffen war. Szenario B: Ein Laptop mit einem Type-2-Schlüssel geht verloren. Hier wird der Offline-Zertifikatspfad untersucht und ersetzt; die API-Authentifizierung gilt nicht automatisch als kompromittiert, wird aber geprüft, falls weitere Secrets auf dem Gerät lagen. Szenario C: Das Monitoring meldet „Expired“. Ablauf ist nicht dasselbe wie Revoked oder eine bestätigte Kompromittierung. Das Team prüft Status und Nutzung, stellt ein neues Zertifikat bereit und untersucht nur dann einen Sicherheitsvorfall, wenn zusätzliche Hinweise vorliegen. Häufige Fehler sind das Widerrufen der falschen Seriennummer, das Gleichsetzen von Zertifikat und KSeF-Berechtigung, die Wiederverwendung des alten Schlüssels, das Überschreiben von Logs durch hektische Neuinstallationen sowie ein Rollback auf kompromittierte Konfigurationen. Ebenfalls riskant ist ein unkontrollierter Token als Notlösung. Gute Entscheidungen stützen sich auf Typ, Eigentümer, Expositionsnachweis, Prozesskritikalität, verfügbare Ersatzwege und überprüfbare Abnahmekriterien.

Leitfaden

9. Software- und Sicherheitsentscheidungen sowie nächste Schritte

Bewerten Sie KSeF-Software nicht nur nach Funktionsumfang. Wichtige Kriterien sind eine sichtbare Zertifikatsinventur mit Seriennummer und Typ, rollenbasierte Administration, Vier-Augen-Freigaben, Secret-Manager- oder HSM-Anbindung, manipulationsgeschützte Audit-Logs, getrennte Tests für Type 1 und Type 2, kontrollierter Zertifikatswechsel und ein exportierbarer Deployment-Nachweis. Fragen Sie Anbieter konkret, wie Schlüssel erzeugt und gespeichert werden, welche Mitarbeiter exportieren können, wie widerrufene Seriennummern aus allen Instanzen entfernt werden und wie ein Rollout ohne Rückgriff auf alte Secrets gestoppt oder fortgesetzt wird. Priorisieren Sie Maßnahmen nach Risikoreduktion, Beweiserhalt und Rechnungskontinuität. Sofort: Vorfallführung aktivieren, Umgebung isolieren, Identität bestätigen und den autorisierten Widerruf auslösen. Danach: Nutzung untersuchen, abhängige Zugänge rotieren, neues Schlüsselpaar und Zertifikat ausgeben und gestuft bereitstellen. Innerhalb des anschließenden Verbesserungszyklus: vollständiges Zertifikatsregister, Eigentümervertretung, Alarmierung für Statusänderungen, regelmäßige Wiederherstellungstests und eine Übung für Authentication- und Offline-Ausfall ergänzen. Ein KSeF-Sicherheitsaudit oder eine ERP-Integrationsprüfung ist besonders sinnvoll, wenn Zertifikatseigentümer unbekannt sind, Schlüssel manuell verteilt werden, Logs keine Seriennummerbezüge erlauben oder mehrere Gesellschaften dieselbe technische Infrastruktur nutzen.

Checkliste

Incident-Leitung, KSeF-Verantwortung, ERP-Betrieb und Beweissicherung namentlich zuweisen.

Betroffene Workloads und Secret-Zugriffe eingrenzen, ohne Logs oder Schlüsselspuren zu überschreiben.

Seriennummer, Status, Typ, Eigentümer, Ablaufdatum und juristische Einheit verifizieren.

Alle ERP-, Middleware-, Signatur-, CI/CD- und Backup-Einsatzorte des Schlüssels inventarisieren.

Widerruf aus einer sauberen autorisierten Umgebung mit Vier-Augen-Abgleich durchführen.

KSeF-Status nach dem Widerruf abfragen und technische Bestätigung beweissicher ablegen.

KSeF-, ERP-, Vault- und Netzwerkprotokolle auf unerwartete Nutzung und Rechnungen prüfen.

Abhängige Zugangsdaten nach Expositionspfad bewerten und erforderliche Secrets rotieren.

Neues Schlüsselpaar erzeugen, neues Zertifikat ausstellen und nach Deployment-Inventar ausrollen.

Authentication und Offline-Signatur getrennt testen, überwachen und im Nachgang Verbesserungen beschließen.

Häufige Fragen

Wie widerrufe ich ein kompromittiertes KSeF-Zertifikat?

Bestätigen Sie zuerst Seriennummer und Eigentümer. Nach der CIRFMF-Dokumentation kann nur der Eigentümer den Widerruf über POST /certificates/{certificateSerialNumber}/revoke veranlassen; ein Grund ist optional. Führen Sie den Aufruf über einen sauberen, autorisierten Pfad aus, dokumentieren Sie die Antwort und kontrollieren Sie anschließend den Zertifikatsstatus.

Wann wirkt die Sperre in KSeF?

Laut offizieller Widerrufsprozedur blockiert ein gültiger Widerrufsantrag das Zertifikat automatisch in KSeF, unabhängig von der Veröffentlichung einer CRL. Planen Sie daher kein Nutzungsfenster aufgrund einer vermeintlichen CRL-Verzögerung ein. Die erfolgreiche Statusprüfung sollte trotzdem Teil des Incident-Nachweises sein.

Entzieht der Zertifikatswiderruf auch die KSeF-Berechtigungen?

Nein. Das Zertifikat ist ein Identitäts- und Authentifizierungsmechanismus und trägt selbst keine KSeF-Berechtigungen oder einen Unternehmenskontext. Prüfen und ändern Sie Berechtigungen separat, wenn der Vorfall nahelegt, dass Konten, Rollen oder Zuordnungen ebenfalls betroffen sind.

Was unterscheidet Type 1 Authentication von Type 2 Offline?

Type 1 wird zur Authentifizierung verwendet. Type 2 unterstützt die Prüfung des Rechnungsausstellers bei offline24-, Systemausfall- und Notfallrechnungen, authentifiziert aber keine API-Sitzung. Inventur, Ersatz und Tests müssen deshalb für beide Funktionen getrennt erfolgen.

Kann ein widerrufenes Zertifikat später wieder aktiviert werden?

Nein. Nach den offiziellen technischen Angaben kann es nach dem Widerruf nicht erneut genutzt werden. Erzeugen Sie ein neues Schlüsselpaar und beantragen Sie ein neues Zertifikat, statt den alten privaten Schlüssel in einer neuen Konfiguration wiederzuverwenden.

Wie rotiert man das Zertifikat ohne unnötigen Rechnungsausfall?

Erfassen Sie zuerst alle Deployments und priorisieren Sie kritische Rechnungsströme. Stellen Sie den Ersatz über Test, begrenzten Canary-Einsatz und gestuften Produktionsrollout bereit; prüfen Sie Authentication und Offline-Signatur separat. Der Rückfallplan darf das kompromittierte Zertifikat oder dessen Schlüssel nicht reaktivieren.

Reicht der Widerruf aus, wenn der private Schlüssel kopiert wurde?

Nein. Der Widerruf blockiert das Zertifikat in KSeF, entfernt aber keine Kopien aus Images, Backups, Entwicklergeräten oder Secret-Stores und belegt nicht, ob ein Missbrauch stattgefunden hat. Suchen Sie nach Kopien und Nutzung, rotieren Sie mitbetroffene Secrets und bereinigen oder quarantänisieren Sie alte Konfigurationen kontrolliert.

Sollten wir vorübergehend auf einen KSeF-Token wechseln?

Nicht ohne eigene Risikoprüfung. Tokens sind nach aktueller Vorgabe seit dem 1. Februar 2026 noch parallel nutzbar, während Zertifikate nach derzeitiger Planung ab dem 1. Januar 2027 die verbleibende Methode sein sollen. Prüfen Sie Reichweite, Berechtigungen, Speicherort und mögliche Exposition eines Tokens, bevor er überhaupt als Übergangslösung infrage kommt.

Wichtige Regeln, Formate und Begriffe

Europäische KommissionEN 16931Richtlinie 2014/55/EUstrukturierte elektronische RechnungKompromittiertes KSeF-Zertifikat und Notfall-WiderrufPolen

Weiterlesen

Offizielle Quellen

Wir priorisieren offizielle Regierungs- und EU-Quellen, soweit verfügbar, und zeigen Prüfdatumsangaben sichtbar an.