E-Invoice Finder
Menu
Landen Software Deadlines Gidsen Checker Verplichting checken
ENFRDEPLNL
Polen · KSeF-beveiligingsincident

Gecompromitteerd KSeF-certificaat intrekken en vervangen

Beperk een gelekte KSeF-privésleutel, trek het juiste certificaat in, onderzoek misbruik en vervang ERP-inlogmiddelen beheerst.

Praktische samenvatting:
  • Afbakening: behandel elk serienummer en iedere uitrollocatie als een afzonderlijk onderzoeksobject.
  • Risico: een gekopieerde sleutel kan buiten de oorspronkelijke ERP-omgeving blijven bestaan.
  • Actie: laat herstel pas slagen na technische tests én bevestiging door de proceseigenaar.
Bekijk Polen-readinessrapportOfficiële bronnen
Laatst gecontroleerd: 31 juli 2026Officiële bronnenDuidelijke samenvattingPraktische informatie, geen juridisch advies
Officiële bronnen eerst
Controledatums zichtbaar
Gratis checker zonder registratie

Wat u moet weten

Gids

1. Triage en ernst bepalen

Start een gezamenlijk incidentrecord en benoem direct een incidentleider, een technisch eigenaar en een eigenaar vanuit finance of tax. Leg het eerste signaal, betrokken systemen, bekende tijdstippen, blootstellingsbereik en mogelijke toegang door derden vast. Een praktisch tijdpad is: in de eerste 15 minuten de coördinatie en bewaring van vluchtige gegevens regelen; in het eerste uur de betrokken geheimen en workloads isoleren, het serienummer bevestigen en een schone intrekkingsroute voorbereiden; daarna intrekken, onderzoek starten en een gecontroleerde vervanging plannen. Dit zijn aanbevolen incidentmaatregelen, geen wettelijk voorgeschreven KSeF-responstermijnen. Behandel onzekerheid expliciet: ‘mogelijk gekopieerd’ rechtvaardigt snelle beheersing, maar is nog geen bewijs van misbruik. Verhoog de ernst wanneer de sleutel publiek toegankelijk was, meerdere omgevingen bedient, niet aan een duidelijke eigenaar kan worden gekoppeld of wanneer loggegevens afwijkende factuuractiviteit tonen.

Gids

2. Exact certificaat, type, eigenaar en uitrollocaties vaststellen

Maak vóór intrekking een korte maar verifieerbare inventaris: certificaatserienummer, eigenaar, uitgevende context, geldigheid, status, type, aanmaakdatum, gebruikte sleutelopslag en alle deployments. Gebruik waar passend POST /certificates/query om certificaatmetadata op te vragen; officiële statussen omvatten Active, Blocked, Revoked en Expired. Vertrouw niet alleen op bestandsnamen of een ERP-label. Type 1 Authentication en Type 2 Offline zijn afzonderlijke certificaten met een ander doel: Type 1 kan voor authenticatie worden gebruikt, terwijl Type 2 dient om de uitgever te verifiëren bij offline24-, systeem-onbeschikbaarheids- en noodfacturen en geen API-sessie authenticeert. Stel daarom vast of één of beide typen geraakt zijn. Controleer productie, acceptatie, CI/CD, back-ups, integratieplatforms, HSM’s, secret stores, servers voor geplande verwerking en beheerderswerkplekken. De certificaateigenaar beslist over intrekking, security bewaakt de procedure, ERP-beheer inventariseert en finance valideert de impact. Voor distributeurs van entiteitscertificaten benadrukt het ministerie de verantwoordingsplicht rond downloaden, overdragen, gebruiken en intrekken. Die administratie kan de zoektocht naar kopieën en ontvangers aanzienlijk versnellen.

Gids

3. Beheersing en een schone intrekkingsroute

Isoleer de vermoedelijk getroffen secrets en workloads zonder bruikbare sporen te vernietigen. Haal een gelekte sleutel uit actieve configuraties, blokkeer ongecontroleerde toegang tot de opslaglocatie en voorkom dat automatische deployments de sleutel opnieuw uitrollen. Bewaar waar mogelijk hashes, configuratieversies, auditlogs en relevante snapshots voordat systemen worden opgeschoond. Voer de intrekking uit via een schoon, vertrouwd apparaat en een geautoriseerd account dat niet afhankelijk is van dezelfde mogelijk gecompromitteerde beheerketen. De officiële technische documentatie bepaalt dat alleen de eigenaar het KSeF-certificaat kan intrekken, onder meer wegens compromittering van de privésleutel, einde van gebruik of een organisatorische wijziging. De API-route is POST /certificates/{certificateSerialNumber}/revoke, met het serienummer en een optionele reden. Laat een tweede bevoegde medewerker serienummer en type controleren. Leg verzoek, respons, uitvoerder en tijdstip vast. Het uitzetten van een ERP-connector is nuttige tijdelijke beheersing, maar vervangt de officiële intrekking niet; omgekeerd ruimt intrekking geen gekopieerde bestanden, omgevingsvariabelen of configuratieback-ups op.

Gids

4. Werking van intrekking — en de grenzen ervan

Volgens de officiële intrekkingsprocedure blokkeert een geldig intrekkingsverzoek het certificaat automatisch in KSeF, onafhankelijk van publicatie op een certificate revocation list. Ga dus niet uit van een venster waarin een correct ingetrokken certificaat binnen KSeF bruikbaar blijft vanwege een vermeende CRL-vertraging. Controleer de uitkomst via de certificaatquery en leg de niet-bruikbare status vast. Een ingetrokken certificaat kan niet opnieuw worden gebruikt; er is een nieuw certificaat nodig. Intrekking verwijdert echter niet de KSeF-rechten van de eigenaar, maakt andere certificaten niet ongeldig en bewijst niet dat de sleutel is misbruikt. Zij herstelt evenmin gekopieerde sleutels of kwetsbare configuratie. KSeF-certificaten zijn mechanismen voor identiteit en authenticatie, geen dragers van machtigingen of van een bedrijfscontext. Als een medewerker of entiteit geen toegang meer mag hebben, behandel het aanpassen van de rechtenmatrix daarom als een afzonderlijke, geautoriseerde actie. Het ministerie vermeldt bovendien dat certificaten maximaal twee jaar geldig kunnen zijn; reguliere vervanging wegens verloop blijft dus naast incidentintrekking nodig.

Gids

5. Onderzoek en bewijs veiligstellen

Bepaal een onderzoeksvenster vanaf het vroegst aannemelijke moment van blootstelling tot en met bevestigde intrekking. Verzamel logs uit KSeF-integraties, API-gateways, ERP, secret stores, identity providers, CI/CD, endpoints en netwerkbeveiliging. Zoek naar onverwachte sessies, nieuwe bronadressen, ongebruikelijke tijden, afwijkende volumes, mislukte authenticatie, onbekende factuurnummers en veranderingen in configuratie of sleuteltoegang. Vergelijk KSeF-activiteiten met het ERP-grootboek, verkoopregister, verzendwachtrijen en bekende gebruikershandelingen. Bewaar originele exports onveranderd en documenteer herkomst, tijdzone en controlesom. Beperk toegang tot onderzoeksgegevens. Afwezige logs bewijzen niet dat er niets gebeurde; een KSeF-statuswijziging zegt evenmin wat eerdere activiteit betekende. De incidentleider houdt een besluitenlog bij; security leidt forensische analyse; finance beoordeelt de zakelijke betekenis van verdachte facturen; legal of privacy wordt ingeschakeld wanneer de feiten daar aanleiding toe geven. Dit is operationele incidentrespons en geen vervanging voor juridisch advies of voor eventuele sectorspecifieke meldplichten.

Gids

6. Schone vervanging en gefaseerde uitrol

Genereer een nieuwe privésleutel in een vertrouwde omgeving en vraag een nieuw certificaat aan; hergebruik nooit de oude sleutel. Sla de sleutel op volgens het beveiligingsbeleid van de organisatie, bij voorkeur in een beheerde secret store, HSM of vergelijkbare voorziening met beperkte toegang, logging en rotatieprocedures. Controleer vóór productie wie eigenaar is, welk certificaattype is aangevraagd en welke integratie het mag gebruiken. Rol vervolgens gefaseerd uit: eerst een gecontroleerde testomgeving, daarna één productieconnector of beperkte factuurstroom, en pas na geslaagde validatie de resterende deployments. Houd een expliciete inventaris bij met versie, locatie, verantwoordelijke en uitroltijdstip. Test bij Type 1 dat authenticatie en de bedoelde API-handeling werken zonder bredere rechten te veronderstellen. Test bij Type 2 afzonderlijk de offlineondertekening en verificatieketen; een geslaagde API-login zegt daar niets over. Roteer ook afhankelijke secrets wanneer de blootstelling mogelijk meer omvatte dan de privésleutel, bijvoorbeeld kluisreferenties, serviceaccountwachtwoorden of deploymenttokens. Verwijder de oude sleutel gecontroleerd uit actieve en herstelomgevingen nadat bewijs is veiliggesteld. Monitor daarna fouten, wachtrijen, certificaatstatus en afwijkende activiteiten en laat finance de eerste facturen functioneel aftekenen.

Gids

7. Bedrijfscontinuïteit voor authenticatie- en offlinecertificaten

Maak continuïteit afhankelijk van de feitelijke certificaatfunctie. Bij een ingetrokken Type 1 Authentication-certificaat kan de betreffende integratie geen nieuwe sessies via dat certificaat opzetten; plan een gecontroleerde vervanging en bepaal welke factuurstromen tijdelijk kunnen worden gepauzeerd of via een vooraf goedgekeurde alternatieve connector kunnen lopen. Bij een getroffen Type 2 Offline-certificaat ligt het risico bij uitgifte en verificatie in offline24-, systeem-onbeschikbaarheids- of noodscenario’s; dit certificaat is geen noodoplossing voor API-authenticatie. Houd daarom afzonderlijke runbooks, eigenaars en tests voor beide typen. Tokens blijven volgens de huidige ministeriële informatie naast certificaten bruikbaar vanaf 1 februari 2026, terwijl certificaten vanaf 1 januari 2027 de beoogde resterende methode zijn. Schakel tijdens een incident niet gedachteloos over op een token: beoordeel en begrens eerst de tokenrechten, opslag, eigenaar, logging en vervaldatum. Gebruik alleen een vooraf ontworpen fallback die het risico niet verplaatst naar een minder beheerd geheim. Laat finance bepalen welke factuurtermijnen kritisch zijn, IT welke capaciteit veilig beschikbaar is en security of de fallback voldoende is afgeschermd. Documenteer handmatige stappen en voer achteraf reconciliatie uit om dubbele, ontbrekende of verkeerd ondertekende facturen te vinden.

Gids

8. Uitgewerkte scenario’s en veelgemaakte fouten

Scenario A: een Type 1-sleutel staat kort in een openbaar codearchief. Behandel het serienummer als gecompromitteerd, bewaar repository- en toegangslogs, trek via een schoon pad in, zoek naar sessies sinds de eerste publicatie en geef een nieuwe sleutel en certificaat uit. Alleen de commit verwijderen is onvoldoende, omdat forks, caches of clones kunnen bestaan. Scenario B: een laptop met een Type 2-sleutel raakt zoek. Stel vast of de sleutel exporteerbaar en de schijf afdoende beschermd was, maar wacht bij reële blootstelling niet op volledige zekerheid voordat de eigenaar intrekt. Controleer offlinefacturen en verspreidingsadministratie en vervang het certificaat vóór de volgende offlineprocedure. Scenario C: een leverancier beheerde certificaat en ERP-connector. Laat beide partijen serienummers, logs en deployments bevestigen, met onafhankelijke controle op kritieke stappen. Veelgemaakte fouten zijn het verkeerde certificaat intrekken, Type 2 als API-inlogmiddel behandelen, rechten en certificaten verwarren, oud sleutelmateriaal hergebruiken en productie in één keer omschakelen. Een onbeperkt token als snelle uitweg creëert bovendien een tweede onbeheerd geheim.

Gids

9. Criteria voor software- en beveiligingskeuzes en vervolgstappen

Beoordeel KSeF-software en ERP-integratie op aantoonbaar certificaatbeheer, niet alleen op succesvolle factuurverzending. Vraag of het product serienummer, type, eigenaar, status en deployment kan inventariseren; of intrekking via een duidelijk geautoriseerd proces verloopt; of sleutelmaterialen niet in gewone configuratiebestanden of logs belanden; en of toegang, export en wijzigingen controleerbaar zijn. Verlang afzonderlijke tests voor Type 1-authenticatie en Type 2-offlineondertekening, plus een gefaseerde rollover zonder langdurige facturatiestop. Controleer exporteerbaarheid van auditgegevens, ondersteuning voor HSM of secret stores, functiescheiding, herstelprocedures en inzicht in onderaannemers. Laat leveranciers uitleggen hoe zij sleutelkopieën uit caches, back-ups en deploymentplatforms verwijderen. Prioriteer op blootstellingsbereik, bedrijfsimpact, bewijssterkte en herstelbaarheid, niet alleen op de snelste herstart. Sluit het incident pas wanneer intrekking is bevestigd, alle bekende deployments zijn vervangen of opgeschoond, relevante factuuractiviteit is gereconcilieerd, monitoring geen onverklaarde signalen toont en de proceseigenaar accepteert dat restrisico’s zijn vastgelegd. Rond af met een post-incidentreview en verbeter de rechtenmatrix, sleutelopslag, inventaris, training en oefenscenario’s.

Checklist

Open één incidentrecord en wijs incidentleiding, security, ERP-beheer en finance-eigenaarschap toe.

Leg het vermoedelijke blootstellingsvenster vast en bewaar vluchtige logs en configuratiegegevens.

Bevestig serienummer, certificaattype, eigenaar, status en alle bekende uitrollocaties.

Isoleer getroffen workloads en voorkom automatische heruitrol van het gelekte geheim.

Laat de certificaateigenaar het juiste serienummer via een schoon, geautoriseerd pad intrekken.

Verifieer de status na intrekking en archiveer verzoek, respons, uitvoerder en tijdstip.

Onderzoek KSeF-, ERP-, kluis-, endpoint- en deploymentlogs op ongebruikelijke activiteit.

Genereer een nieuwe privésleutel en certificaatcombinatie zonder oud sleutelmateriaal te hergebruiken.

Rol per geïnventariseerde omgeving gefaseerd uit en test authenticatie en offlineondertekening apart.

Reconcilieer facturen, monitor de nieuwe situatie en leg verbeteracties vast in de evaluatie achteraf.

Veelgestelde vragen

Hoe trek ik een KSeF-certificaat in?

De officiële technische route is POST /certificates/{certificateSerialNumber}/revoke met het serienummer en desgewenst een reden. Alleen de eigenaar kan intrekken. Controleer vooraf type en serienummer, gebruik een schoon geautoriseerd pad en verifieer daarna de certificaatstatus.

Wanneer werkt de blokkade na een geldig intrekkingsverzoek?

De officiële procedure vermeldt dat een geldig verzoek het certificaat automatisch in KSeF blokkeert, onafhankelijk van CRL-publicatie. Leg de API-respons vast en controleer de status; verzin geen extra wachttijd en baseer herstel niet uitsluitend op een onbevestigde aanvraag.

Verdwijnen de KSeF-rechten van de eigenaar door intrekking?

Nee. Het certificaat identificeert of authenticeert, maar draagt geen KSeF-machtigingen of bedrijfscontext. Als rechten moeten worden ingetrokken of aangepast, moet dat afzonderlijk via de bevoegde rechtenbeheerprocedure gebeuren.

Wat is het verschil tussen Type 1 Authentication en Type 2 Offline bij een incident?

Type 1 wordt voor authenticatie gebruikt. Type 2 ondersteunt verificatie van de uitgever bij offline24-, systeem-onbeschikbaarheids- en noodfacturen en kan geen API-sessie authenticeren. Inventariseer, vervang en test beide functies daarom afzonderlijk.

Kan een ingetrokken certificaat na herstel opnieuw worden geactiveerd?

Nee. Een ingetrokken certificaat kan niet opnieuw worden gebruikt. Genereer nieuw sleutelmateriaal, vraag een nieuw certificaat aan en voer een gecontroleerde uitrol uit; koppel het nieuwe certificaat niet aan de mogelijk buitgemaakte privésleutel.

Bewijst intrekking dat er geen misbruik heeft plaatsgevonden?

Nee. Intrekking beperkt toekomstig gebruik van dat certificaat in KSeF, maar zegt niets definitiefs over activiteit vóór de blokkade. Onderzoek logs en factuurstromen binnen het aannemelijke blootstellingsvenster en documenteer beperkingen in de beschikbare gegevens.

Kunnen we tijdelijk naar een token overschakelen om facturatie door te laten gaan?

Alleen na een afzonderlijke risicoanalyse en met beperkte rechten, veilige opslag, logging, een duidelijke eigenaar en een uitfaseringsplan. Volgens de huidige informatie blijven tokens vanaf 1 februari 2026 naast certificaten bruikbaar, maar zijn certificaten vanaf 1 januari 2027 de beoogde resterende methode.

Hoe vervangen we het certificaat zonder een langdurige facturatiestop?

Werk met een vooraf geïnventariseerde, gefaseerde rollover: maak een nieuwe sleutel en certificaatcombinatie, test in een gecontroleerde omgeving, migreer één connector of beperkte stroom, valideer facturen en schaal daarna uit. Houd voor authenticatie en offlinefacturatie afzonderlijke fallback- en reconciliatiestappen aan.

Belangrijke regels, formaten en termen

Europese CommissieEN 16931Richtlijn 2014/55/EUgestructureerde elektronische factuurGecompromitteerd KSeF-certificaat en spoedintrekkingPolen

Lees verder

Officiële bronnen

We geven voorrang aan officiële overheids- en EU-bronnen waar beschikbaar en tonen controledatums zichtbaar.