E-Invoice Finder
Menu
Pays Logiciels Échéances Guides Checker Vérifier obligation
ENFRDEPLNL
Pologne · checklist des accès 2026

Gouverner les certificats, jetons et droits KSeF

Sécurisez certificats KSeF, jetons et droits avec une checklist 2026 : logiciel, rotation, mode hors ligne, départs et accès des prestataires.

Résumé pratique :
  • Cartographiez chaque secret par entité, usage, responsable et échéance.
  • Un départ mal géré peut laisser un accès exploitable malgré une procédure RH terminée.
  • Faites exécuter les scénarios sensibles devant vous et récupérez les traces correspondantes.
Voir le rapport PologneSources officielles
Dernière vérification : 25 juillet 2026Sources officiellesRésumé clairInformation pratique, pas un conseil juridique
Sources officielles priorisées
Dates de vérification visibles
Checker gratuit, sans inscription

Ce qu’il faut savoir

Guide

1. Commencer par le bon périmètre

Le sujet comporte trois couches à examiner séparément : la preuve d’identité utilisée pour ouvrir une session, les autorisations consultées par KSeF et l’aptitude du logiciel à gérer le parcours complet. Le ministère polonais des Finances présente le certificat KSeF comme une méthode d’authentification ; cela ne signifie ni qu’il contient tous les droits, ni qu’un ERP qui l’importe est prêt pour la production. • Recensez les entités polonaises, NIP ou PESEL concernés, utilisateurs, robots, experts-comptables et intégrateurs. • Identifiez les usages interactifs, les lots API et les factures émises hors ligne. • Faites valider les choix sensibles par vos responsables fiscalité, sécurité et conformité : cette page apporte une méthode pratique, pas un avis juridique ou fiscal.

Guide

2. Certificat, jeton et autorisations : trois fonctions différentes

Un certificat de type 1 prouve l’identité lors de l’authentification d’une session interactive ou par lots. Les droits utilisables sont ensuite évalués à partir de l’identité NIP ou PESEL et du registre des autorisations ; ils ne sont pas inscrits dans le certificat. Un certificat encore valable peut donc correspondre à des droits réduits ou retirés. Le jeton suit une logique différente : les autorisations déclarées sont incorporées au jeton. Les jetons peuvent être utilisés depuis le 1er février 2026, mais la documentation officielle prévoit leur disparition au 1er janvier 2027. Traitez cette période comme une transition : inventaire des jetons, migration testée vers les certificats et date interne de retrait, sans attendre le dernier moment.

Guide

3. Type 1, type 2 et modes hors ligne

Les deux types ne sont pas interchangeables. Le type 1 sert à authentifier les sessions API interactives et par lots. Le type 2 est distinct : il permet d’indiquer l’identité de l’émetteur pour les factures offline24 ainsi que lors d’une indisponibilité du système ou d’une situation d’urgence. Un même certificat ne peut pas couvrir les deux fonctions. Pour le hors ligne, vérifiez plus que la génération d’un document. Le logiciel doit gérer le certificat de type 2 et le lien de vérification de l’émetteur, puis assurer la reprise prévue par son processus. Testez séparément offline24, indisponibilité et urgence avec une horloge maîtrisée, des journaux exploitables et une procédure de retour au service normal. Ne concluez pas qu’un test API en ligne valide ces parcours.

Guide

4. Identité, propriété et responsabilité

Les certificats KSeF peuvent être demandés et téléchargés via l’API KSeF 2.0 ou l’Application du contribuable depuis février 2026, après une authentification appropriée. Un certificat personnel ne peut être demandé, téléchargé et utilisé que par la personne concernée. Il ne doit donc pas devenir le secret générique d’une équipe, d’un prestataire ou d’un robot. Pour un certificat d’entreprise, désignez un propriétaire métier, un gardien technique et un approbateur distinct. Documentez qui peut demander, exporter, installer, renouveler et révoquer le certificat. La clé privée ne doit jamais être placée dans un ticket, un courriel, le code source ou une feuille de calcul partagée. Séparez aussi les coffres, comptes de service et journaux de chaque entité juridique.

Guide

5. Construire une matrice de moindre privilège

Partez des tâches réelles, pas des intitulés de poste. Une personne qui consulte les factures reçues n’a pas nécessairement à émettre, déléguer des droits ou administrer les secrets. Pour chaque accès, notez l’entité, l’identité, l’action autorisée, le motif, le valideur, la date de revue et la règle de retrait. • Salarié finance : consultation ou émission limitée à ses missions. • Expert-comptable : périmètre contractuel explicite, revu à chaque changement de mandat. • Intégrateur : accès temporaire à un environnement adapté, sans clé de production copiée. • Robot ERP : identité de service, secret en coffre et capacité minimale. Contrôlez les droits dans KSeF après toute modification : la seule possession d’un certificat ne prouve pas l’autorisation actuelle.

Guide

6. Gérer tout le cycle de vie

Tenez un inventaire central sans y stocker les secrets : identifiant interne, type 1 ou 2, identité associée, entité, usage, environnement, emplacement sécurisé, propriétaire, date d’émission, expiration et dernière revue. La validité maximale annoncée est de deux ans, mais cette limite ne remplace ni la rotation interne ni la revue des droits. À l’émission, appliquez une double validation et enregistrez la chaîne de conservation. Stockez la clé dans un coffre ou composant cryptographique adapté, limitez l’export et surveillez l’usage. Renouvelez avant expiration, testez le basculement et retirez l’ancien matériel. Révoquez sans délai en cas de compromission, changement de prestataire ou perte de contrôle. Le départ d’un salarié doit déclencher retrait des droits, révocation si nécessaire, rotation des secrets partagés interdits et contrôle des journaux.

Guide

7. Recette logiciel et sécurité en cinq scénarios

Demandez une démonstration exécutée et les preuves exportables suivantes. 1. Session API : authentification avec un type 1, signature XAdES-BES, identité reconnue et erreur lisible si le certificat est invalide. Preuves : requête masquée, résultat, horodatage et journal. 2. Droits modifiés : retirez une autorisation sans remplacer le certificat ; l’action doit être refusée alors que l’identité reste authentifiable. Preuves : matrice avant/après et refus KSeF. 3. Rotation : installez le nouveau certificat, basculez sans interruption, puis désactivez l’ancien. Preuves : procédure, versions et traces. 4. Hors ligne : émettez avec un type 2, contrôlez le lien de vérification de l’émetteur et la reprise. Preuves : facture test, lien, événements et statut final. 5. Séparation : tentez d’utiliser le secret ou le contexte d’une autre entité. Preuves : blocage, alerte et journaux cloisonnés.

Guide

8. Erreurs fréquentes et réponse à incident

Les erreurs les plus dangereuses sont discrètes : certificat personnel partagé, jeton oublié dans un script, type 1 utilisé comme preuve d’émission hors ligne, droits jamais revus, sauvegarde non chiffrée ou accès fournisseur laissé actif après le contrat. Autre confusion classique : présenter une date d’expiration lointaine comme preuve que les autorisations et l’intégration sont encore correctes. En cas de suspicion, stoppez l’usage du secret concerné, préservez les traces, identifiez les entités et opérations exposées, puis révoquez ou remplacez selon la situation. Retirez les droits associés, recherchez les copies dans les dépôts, tickets et outils d’automatisation, et vérifiez les actions KSeF. Consignez la chronologie, les décisions et les contrôles de retour en service. Faites intervenir les responsables sécurité, métier et conseil compétent lorsque l’impact potentiel l’exige.

Guide

9. Décider et passer à l’action

Choisissez votre dispositif selon cinq critères : identité appropriée, moindre privilège, stockage maîtrisé, compatibilité technique et preuve d’exploitation. Pour un logiciel commercial, exigez la gestion des certificats et la prise en charge de XAdES-BES pour l’authentification API. Si vous émettez hors ligne, ajoutez la gestion du type 2 et du lien de vérification de l’émetteur. Classez les écarts en trois groupes : bloquants avant mise en service, correctifs planifiés et risques acceptés par un responsable nommé. Commencez par supprimer les secrets partagés, inventorier les jetons avant leur retrait annoncé, attribuer les propriétaires et exécuter les cinq scénarios. Une certification valide, des permissions actuelles et un logiciel prêt sont trois preuves distinctes ; votre décision doit reposer sur les trois, ainsi que sur la capacité à réagir à un incident.

Checklist

Inventorier par entité tous les certificats, jetons, identités, usages, propriétaires et échéances.

Attribuer séparément les certificats de type 1 aux sessions API et de type 2 aux usages hors ligne.

Vérifier les autorisations KSeF actuelles indépendamment de la période de validité du certificat.

Appliquer le moindre privilège aux salariés, experts-comptables, intégrateurs et comptes de service.

Interdire les clés privées et jetons dans les courriels, tickets, dépôts de code et tableurs partagés.

Stocker les clés dans un coffre contrôlé avec accès, sauvegarde et journalisation adaptés.

Planifier émission, renouvellement, rotation, révocation et test de basculement avant expiration.

Relier les départs et fins de contrat au retrait des droits, à la révocation et à la revue des traces.

Tester XAdES-BES, les refus d’autorisation, le mode hors ligne, la rotation et la séparation des entités.

Obtenir du fournisseur les journaux, résultats API, procédures de reprise et preuves de chaque scénario.

Questions fréquentes

Faut-il choisir un certificat KSeF ou un jeton ?

Le choix doit tenir compte de la transition officielle. Les jetons, utilisables depuis le 1er février 2026, contiennent les autorisations déclarées, tandis qu’un certificat prouve une identité dont KSeF évalue les droits séparément. Les jetons doivent disparaître au 1er janvier 2027 : évitez donc une nouvelle dépendance durable et testez dès maintenant la migration vers les certificats.

Quel type de certificat KSeF faut-il demander ?

Demandez un type 1 pour authentifier les sessions interactives ou par lots via l’API. Utilisez un type 2 pour indiquer l’identité de l’émetteur sur les factures offline24, en période d’indisponibilité ou en situation d’urgence. Un certificat ne couvre pas les deux types ; les usages doivent être inventoriés et testés séparément.

Qui peut demander et utiliser un certificat personnel ?

Selon les informations officielles, seul l’individu concerné peut demander, télécharger et utiliser son certificat personnel, après l’authentification requise. Ne le transformez pas en identifiant collectif et ne le confiez pas à un intégrateur. Pour les automatisations ou besoins d’entreprise, définissez un modèle d’identité et de conservation compatible avec votre organisation.

Combien de temps un certificat KSeF reste-t-il valable ?

La durée maximale annoncée est de deux ans. La date d’expiration n’indique toutefois ni que les permissions sont encore présentes, ni que la clé est restée sûre, ni que le logiciel fonctionne avec les spécifications actuelles. Prévoyez des revues plus fréquentes, une rotation anticipée et un essai documenté du renouvellement.

Où stocker la clé privée d’un certificat KSeF ?

Placez-la dans un coffre de secrets ou un dispositif cryptographique adapté à votre architecture, avec accès nominatif ou de service, journalisation et sauvegarde contrôlée. Limitez fortement l’export. Ne transmettez jamais une clé privée ou un jeton par ticket, courriel, dépôt de code ou tableur partagé, même pour résoudre rapidement un incident.

Comment gérer l’accès d’un salarié, d’un expert-comptable ou d’un intégrateur ?

Attribuez des droits liés aux tâches, à l’entité et à une durée justifiée. Un expert-comptable ne devrait accéder qu’au périmètre du mandat ; un intégrateur devrait travailler avec un accès temporaire et sans copie du secret de production. À chaque changement de rôle ou de contrat, retirez les droits, examinez les certificats concernés et contrôlez les journaux.

Que faut-il prévoir pour offline24 et les autres modes hors ligne ?

Prévoyez un certificat de type 2, la création correcte du lien de vérification de l’émetteur et une procédure de reprise. Testez offline24, l’indisponibilité et l’urgence comme des scénarios distincts, avec facture témoin, horodatages, traces et statut final. La réussite d’une authentification en ligne de type 1 ne démontre pas cette capacité.

Quelles preuves demander pendant une démonstration du logiciel ?

Demandez les résultats des cinq scénarios de recette : authentification API et signature XAdES-BES, refus après retrait d’un droit, rotation, émission hors ligne avec lien de vérification, et séparation entre entités. Récupérez des journaux horodatés, identifiants, erreurs, versions de certificat masquées et procédures de reprise ; une capture d’écran ou une promesse de feuille de route ne suffit pas.

Réglementation, formats et termes clés

Commission européenneEN 16931Directive 2014/55/UEfacture électronique structuréeChecklist de gouvernance des certificats, jetons et droits KSeF en PolognePologne

À lire aussi

Sources officielles

Nous privilégions les sources gouvernementales et européennes officielles lorsque disponibles, avec des dates de vérification visibles.