E-Invoice Finder
Menu
Landen Software Deadlines Gidsen Checker Verplichting checken
ENFRDEPLNL
Polen · toegangsbeheer 2026

KSeF-certificaten, tokens en rechten beheren

Beheer KSeF-certificaten, tokens en rechten veilig met een checklist voor software, rotatie, offlinefacturen en toegang van medewerkers of leveranciers.

Praktische samenvatting:
  • Breng per Poolse entiteit in kaart welke personen, systemen en dienstverleners daadwerkelijk KSeF-handelingen uitvoeren.
  • Het grootste beheerrisico is een werkende sleutel bij een identiteit waarvan de rol, machtiging of zakelijke noodzaak intussen is gewijzigd.
  • Laat vóór productie vijf praktijkscenario’s demonstreren en bewaar uitvoer, logregels en schermafbeeldingen als acceptatiebewijs.
Bekijk Polen-readinessrapportOfficiële bronnen
Laatst gecontroleerd: 25 juli 2026Officiële bronnenDuidelijke samenvattingPraktische informatie, geen juridisch advies
Officiële bronnen eerst
Controledatums zichtbaar
Gratis checker zonder registratie

Wat u moet weten

Gids

Eerst oriënteren: drie controlesporen

Behandel KSeF-toegang niet als één technisch vinkje. Er zijn drie afzonderlijke controlesporen: de identiteit waarmee wordt geauthenticeerd, de machtigingen die op dat moment voor die identiteit gelden en de software die de beoogde handeling correct kan uitvoeren. Een certificaat kan dus nog geldig zijn terwijl een recht is ingetrokken; omgekeerd kan iemand gemachtigd zijn terwijl het ERP de vereiste ondertekening of sessieopbouw niet ondersteunt. Vraag per NIP, toepassing en gebruiker: wie handelt, wat mag die partij doen en via welk proces? • Beslis: interactief of batchgewijs werken, offlinefacturen nodig, intern beheer of uitbesteding. • Bewijs: actuele rechtenexport, certificaatregister, eigenaar en geslaagde softwaretest. • Scheid: technische geldigheid, organisatorische toestemming en productiegereedheid. Dit is een praktische beheerscheck, geen juridisch of fiscaal advies.

Gids

Certificaat, token en machtiging zijn niet hetzelfde

Het Poolse ministerie van Financiën beschrijft een KSeF-certificaat als authenticatiemethode. Bij certificaattype 1 worden interactieve en batch-API-sessies geauthenticeerd. De effectieve rechten zitten niet in dat certificaat: KSeF beoordeelt ze aan de hand van de NIP- of PESEL-identiteit en het machtigingenregister. Een token werkt anders, omdat daarin de bij uitgifte aangegeven rechten zijn vastgelegd. Volgens de officiële informatie kunnen tokens vanaf 1 februari 2026 worden gebruikt, maar verdwijnen ze per 1 januari 2027; daarna blijven certificaten als authenticatieroute over. Maak in beleid en schermteksten onderscheid tussen ‘identiteit geverifieerd’ en ‘handeling toegestaan’. Behandel een succesvolle login nooit als bewijs van verzend-, beheer- of inzagerecht. Voor tokens is een migratiepad nodig: eigenaar aanwijzen, afhankelijkheden vinden, certificaatauthenticatie testen en na gecontroleerde omschakeling intrekken.

Gids

Type 1, type 2 en offline scenario’s

Type 1 is bedoeld voor authenticatie van interactieve en batchsessies. Type 2 heeft een andere functie: het markeert de identiteit van de uitgever bij facturen die worden opgesteld in offline24, tijdens onbeschikbaarheid van KSeF of in een noodsituatie. Eén certificaat kan niet beide rollen vervullen. Een organisatie die zowel API-sessies opent als offlinefacturen voorbereidt, moet dus beide typen afzonderlijk aanvragen, opslaan, toewijzen en roteren. Vraag de leverancier niet alleen of ‘certificaten worden ondersteund’. Laat zien welk type wordt geselecteerd, hoe verwisseling wordt voorkomen en hoe de verificatielink voor de uitgever wordt verwerkt. Test na herstel wachtrij, verzending, fouten, statussen en aansluiting op de administratie. Bewaar invoer, tijdlijn, factuur, verificatielink, KSeF-respons en logs; alleen een certificaatbestand kunnen uploaden bewijst geen operationele werking.

Gids

Identiteit, eigendom en verantwoordelijkheid

Koppel ieder certificaat aan een herkenbare eigenaar en een zakelijke taak. Een persoonlijk certificaat kan volgens de officiële documentatie alleen door de betreffende persoon worden aangevraagd, gedownload en gebruikt. Deel het daarom niet met collega’s, een boekhouder of een integratieleverancier. Voor een organisatiecertificaat is een interne bewaarketen nodig: wie mag de aanvraag doen, wie ontvangt het bestand, wie beheert de privésleutel en wie keurt installatie in productie goed? Verdeel de verantwoordelijkheid per Poolse entiteit. Bijvoorbeeld: Finance bezit het proces, IT beheert de sleutelkluis, Compliance beoordeelt machtigingen en een leverancier krijgt technisch beheer zonder exportmogelijkheid. Leg vast welke NIP- of PESEL-identiteit KSeF ziet. Beoordeel bij rolwijziging, vertrek of contracteinde tegelijk machtigingen, accounts, certificaten en lokale kopieën. Een account uitschakelen volstaat niet als de sleutel nog in middleware, een taak of back-up staat.

Gids

Een matrix voor minimale rechten

Maak vóór uitgifte een toegangsmatrix met rijen voor personen en technische identiteiten, en kolommen voor entiteit, omgeving, handeling, authenticatiemiddel, goedkeurder en einddatum. Ken alleen rechten toe die voor de taak nodig zijn en scheid beheer van dagelijks factuurwerk. Voorbeelden: • Een medewerker debiteurenbeheer mag voor één NIP facturen verzenden en statussen opvolgen, maar geen rechten beheren. • Een externe boekhouder krijgt alleen de noodzakelijke inzage voor afgesproken entiteiten en geen privésleutel van een medewerker. • ERP-middleware gebruikt een afzonderlijk beheerd type 1-certificaat; operators kunnen de sleutel niet exporteren. • De offlinefunctie gebruikt type 2 en is alleen toegankelijk voor het aangewezen noodteam. • Test- en productieomgevingen hebben gescheiden configuratie, geheimen en logtoegang. Herbeoordeel de matrix periodiek en bij elke rolwijziging. Vergelijk daarbij de interne goedkeuring met het actuele KSeF-machtigingenregister. De maximale geldigheid van een certificaat is twee jaar, maar die einddatum zegt niets over de actuele rechten of de blijvende noodzaak van toegang.

Gids

Levenscyclus: van inventaris tot intrekking

Houd één inventaris bij met certificaat-ID of vingerafdruk, type, gekoppelde identiteit, NIP, doel, omgeving, bewaarlocatie, uitgiftedatum, vervaldatum, eigenaar en vervanger. Noteer geen privésleutel of tokenwaarde in de inventaris. Certificaten kunnen vanaf februari 2026 na passende authenticatie worden aangevraagd en gedownload via de KSeF 2.0-API of de Taxpayer Application. Documenteer wie aanvraag en download uitvoerde en laat de bestemming controleren. Bewaar privésleutels in een beheerde secrets vault, HSM of vergelijkbare oplossing met beperkte export, logs, back-up en hersteltest. Plan rotatie ruim vóór afloop; installeer en test het nieuwe certificaat, schakel gecontroleerd om en trek het oude in zodra terugval niet meer nodig is. Trek ook direct in bij verlies, vermoed misbruik, verkeerde uitgifte, vertrek van de eigenaar of beëindiging van een leverancier. Zet nooit een privésleutel of token in tickets, e-mail, broncode of gedeelde spreadsheets. Leg bij een incident tijdstip, scope, getroffen entiteiten, genomen maatregelen en heruitgifte vast.

Gids

Vijf acceptatietests voor software en beveiliging

Vraag om een live demonstratie met jouw representatieve rollen en bewaar per test bewijs. Commerciële software moet certificaatbeheer en XAdES-BES voor API-authenticatie ondersteunen; voor offlinefacturering is ook verwerking van de verificatielink van de uitgever nodig. Test precies deze vijf scenario’s: 1. Type 1, interactief: open een sessie, voer een toegestane handeling uit en toon identiteit, KSeF-respons en auditlog. 2. Type 1, batch: verwerk meerdere facturen voor één NIP, probeer bewust een niet-toegestane handeling en toon dat actuele rechten worden afgedwongen. 3. Multi-entiteit en rotatie: wissel gecontroleerd van certificaat, bewijs dat entiteiten gescheiden blijven en dat het oude middel niet meer wordt gebruikt. 4. Offline24: maak met type 2 een representatieve factuur, controleer de issuer-verificatie, verzend later en leg tijdlijn en statussen vast. 5. Intrekking of incident: trek toegang in of simuleer een gecompromitteerde sleutel; toon blokkering, waarschuwing, logzoekactie en herstelprocedure. Accepteer geen presentatie als enige bewijs. Vraag configuratie-export zonder geheimen, ondertekeningsdetails, logfragmenten, foutmeldingen, rolmatrix en een ingevuld testrapport met datum en verantwoordelijke.

Gids

Veelgemaakte fouten en incidentrespons

Een veelgemaakte fout is denken dat een certificaat met een geldige einddatum automatisch de juiste machtigingen heeft. Andere risico’s zijn één certificaat voor beide typen proberen te gebruiken, een persoonlijk certificaat delen, dezelfde sleutel over meerdere NIP’s kopiëren, productiegeheimen in test plaatsen en leveranciers toegang laten houden na contracteinde. Ook een ERP dat kan inloggen maar geen XAdES-BES, rotatie zonder onderbreking of offlineverificatielink aankan, is niet productiegereed. Maak de incidentroute kort en uitvoerbaar: stop getroffen integraties waar nodig, bescherm bewijs, bepaal welke sleutel, token, identiteit en entiteiten geraakt zijn, trek het middel en overbodige machtigingen in, geef veilig opnieuw uit en controleer logs op afwijkende sessies of factuuracties. Informeer proceseigenaren en de leverancier volgens het incidentplan. Test met een nieuwe sleutel vóór hervatting. Registreer oorzaak en verbetering, zoals export blokkeren, waarschuwingen aanscherpen of offboarding automatiseren. Het ontbreken van een foutmelding is geen bewijs dat niets is gebeurd.

Gids

Besliscriteria en eerstvolgende acties

Kies het authenticatiemodel op basis van het proces, niet op basis van wat het snelst te installeren is. Voor blijvende API-integraties ligt tijdige voorbereiding op certificaten voor de hand vanwege het aangekondigde einde van tokens. Type 1 past bij interactieve of batchauthenticatie; type 2 is afzonderlijk nodig wanneer de organisatie de bedoelde offline- en storingsscenario’s gebruikt. Kies daarna een persoonlijke of organisatiegebonden beheerroute op basis van continuïteit, sleutelbewaring en vervanging. Werk in deze volgorde: inventariseer middelen, machtigingen en NIP’s; verwijder ongebruikte toegang; wijs eigenaren aan; regel benodigde certificaattypen; voer de vijf tests uit; plan tokenmigratie en rotatie; oefen intrekking en offboarding. Go/no-go vereist drie aparte bewijzen: het authenticatiemiddel is technisch bruikbaar, de actuele KSeF-rechten passen bij de taak en de software doorstaat het volledige proces inclusief fouten en herstel. Controleer officiële KSeF-bronnen opnieuw bij implementatie, omdat technische documentatie en procedures kunnen wijzigen.

Checklist

Inventariseer per NIP alle KSeF-certificaten, tokens, gebruikers, integraties en externe dienstverleners.

Leg voor ieder middel type, identiteit, doel, omgeving, eigenaar, bewaarlocatie en vervaldatum vast zonder geheimen te noteren.

Vergelijk de goedgekeurde toegangsmatrix met de actuele machtigingen in KSeF en verwijder overtollige rechten.

Vraag type 1 en type 2 afzonderlijk aan wanneer zowel API-sessies als de bedoelde offline scenario’s nodig zijn.

Bewaar privésleutels in een afgeschermde kluis met beperkte export, logging, herstelprocedure en toegewezen beheerders.

Bevestig met de leverancier ondersteuning voor certificaatbeheer, XAdES-BES, rotatie en issuer-verificatielinks.

Voer alle vijf acceptatietests uit en archiveer KSeF-responsen, logfragmenten, configuratiebewijs en het goedgekeurde testrapport.

Plan certificaatrotatie ruim vóór afloop en test het nieuwe middel voordat het oude wordt ingetrokken.

Koppel intrekking van accounts, rechten, certificaten en opgeslagen kopieën aan uitdiensttreding en leveranciersoffboarding.

Oefen de incidentprocedure voor een verloren of uitgelekte sleutel, inclusief blokkering, logonderzoek, heruitgifte en nacontrole.

Veelgestelde vragen

Kies ik in 2026 voor een KSeF-certificaat of een token?

Een token kan volgens de officiële informatie vanaf 1 februari 2026 worden gebruikt, maar verdwijnt per 1 januari 2027. Voor een duurzame integratie is het verstandig certificaatauthenticatie nu al te ontwerpen en te testen. Wie tijdelijk tokens gebruikt, moet afhankelijkheden inventariseren, een migratiedatum vastleggen en na de omschakeling controleren dat de token werkelijk is ingetrokken.

Welk certificaattype heb ik nodig?

Type 1 authenticeert interactieve en batch-API-sessies. Type 2 markeert de identiteit van de uitgever voor facturen in offline24, bij systeemonbeschikbaarheid en in noodsituaties. Eén certificaat kan niet voor beide typen dienen. Gebruik je beide procesgroepen, beheer dan twee afzonderlijke certificaten met een duidelijk doel en eigen tests.

Geeft een KSeF-certificaat automatisch rechten?

Nee. Het certificaat bewijst de NIP- of PESEL-identiteit; de effectieve rechten worden afzonderlijk beoordeeld via het KSeF-machtigingenregister. Controleer daarom zowel certificaatstatus als actuele machtiging. Een geldig certificaat kan blijven bestaan nadat een rol of recht is veranderd, en softwareondersteuning vormt nog een derde, aparte voorwaarde.

Wie mag een certificaat aanvragen en downloaden?

Volgens de officiële documentatie kan een persoonlijk certificaat alleen door de betreffende persoon worden aangevraagd, gedownload en gebruikt. Voor organisatiecertificaten moet de onderneming zelf vastleggen wie aanvraag, download, installatie en goedkeuring uitvoert. Vanaf februari 2026 kan dit na passende authenticatie via de KSeF 2.0-API of Taxpayer Application.

Hoe lang is een KSeF-certificaat geldig?

De maximale geldigheid is twee jaar. Wacht niet tot de laatste dag: plan een rotatievenster, wijs een vervanger aan, installeer en test het nieuwe certificaat en trek daarna het oude in. De vervaldatum is geen bevestiging van actuele rechten en evenmin bewijs dat ERP of facturatiesoftware klaar is.

Waar bewaar ik de privésleutel?

Gebruik bij voorkeur een beheerde secrets vault, HSM of vergelijkbare beveiligde voorziening met beperkte export, toegangsregistratie, back-up en getest herstel. Plaats een privésleutel of token nooit in een ticket, e-mail, broncode of gedeelde spreadsheet. Beperk toegang tot aangewezen beheerders en registreer iedere installatie of kopie.

Wat doe ik met toegang van een medewerker, boekhouder of leverancier?

Geef elke partij alleen de noodzakelijke rechten voor de juiste entiteit en taak. Deel geen persoonlijk certificaat. Bij functiewijziging, uitdiensttreding of contracteinde moeten KSeF-machtigingen, applicatieaccounts, certificaten, tokens, lokale kopieën en geplande processen gezamenlijk worden beoordeeld en zo nodig ingetrokken; controleer logs om te bevestigen dat de toegang niet meer wordt gebruikt.

Welk bewijs vraag ik tijdens een softwaredemo?

Vraag een uitvoering van interactieve authenticatie, batchverwerking, multi-entiteitscheiding en rotatie, offline24 met type 2, en intrekking na een gesimuleerd incident. Bewaar KSeF-responsen, XAdES-BES- of ondertekeningsdetails, verificatielink, foutmeldingen, relevante logregels en configuratie-export zonder geheimen. Een roadmap of verkooppresentatie bewijst geen productiegereedheid.

Belangrijke regels, formaten en termen

Europese CommissieEN 16931Richtlijn 2014/55/EUgestructureerde elektronische factuurChecklist voor beheer van KSeF-certificaten, tokens en rechten in PolenPolen

Lees verder

Officiële bronnen

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