E-Invoice Finder
Menu
Pays Logiciels Échéances Guides Checker Vérifier obligation
ENFRDEPLNL
Pologne · exploitation des certificats KSeF

Inventaire et rotation des certificats KSeF

Inventoriez les certificats KSeF, surveillez leur expiration et sécurisez leur rotation ERP avec tests, retour arrière et révocation contrôlée.

Résumé pratique :
  • • Portée : gouvernez chaque identité technique selon son usage et son environnement.
  • • Risque : une dépendance non recensée peut transformer le retrait en incident.
  • • Action : exigez une preuve horodatée avant chaque décision de fin de vie.
Voir le rapport PologneSources officielles
Dernière vérification : 2 août 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

Piloter le cycle de vie avant qu’il ne provoque une coupure

Une expiration ignorée peut arrêter l’authentification KSeF d’un connecteur ERP ; un certificat Offline oublié peut, lui, perturber les scénarios hors ligne concernés. Cartographiez donc le cycle complet : demande, émission, téléchargement, transfert contrôlé, déploiement, utilisation, surveillance, remplacement puis révocation ou expiration. N’attendez pas l’incident pour désigner les responsables. Le propriétaire métier confirme les usages et entités touchés ; l’équipe intégration connaît les instances ; la sécurité encadre la clé privée ; l’exploitation suit les alertes ; une personne habilitée décide de la révocation. Simulez une échéance proche et vérifiez que l’alerte devient un changement planifié. Conservez inventaire daté, approbations, tests et journaux de bascule, jamais la clé privée. Cette organisation est une pratique recommandée, pas une fenêtre imposée par KSeF.

Guide

Construire un inventaire possédé et exploitable

Créez un registre dont un responsable nommé garantit l’exactitude. Pour chaque certificat, consignez un nom unique et explicite, le numéro de série, le type, le statut, les dates de début et de fin de validité, l’entité utilisatrice, l’environnement, l’ERP ou service déployé, le coffre ou HSM de référence, le propriétaire, le suppléant et la procédure de retrait. Référencez seulement l’emplacement sécurisé : n’insérez ni clé privée, ni secret, ni copie du certificat avec sa clé dans le registre, un ticket ou un journal. Rapprochez périodiquement ce registre de la requête officielle POST /certificates/query, qui renvoie les métadonnées actives et historiques et accepte notamment des filtres sur le statut, l’expiration, le nom, le type et le numéro de série. Faites examiner tout certificat sans propriétaire, déploiement non recensé, doublon de nom ou composant utilisant une référence obsolète. Conservez l’export, la décision et la correction.

Guide

Comprendre types, validité, statuts et droits

Un certificat KSeF est un justificatif d’identité : il ne porte ni autorisations KSeF ni contexte d’entreprise. Les droits sont contrôlés côté serveur ; un certificat techniquement valide ne garantit donc pas qu’une opération est autorisée. Le Type 1 Authentication sert à l’authentification auprès de KSeF. Le Type 2 Offline sert uniquement à confirmer l’identité de l’émetteur et l’intégrité d’une facture dans les modes offline24, indisponibilité du système et urgence ; il ne peut pas ouvrir une session API. Les deux types sont délivrés séparément et doivent avoir des lignes d’inventaire et des essais distincts. Selon le ministère polonais des Finances, la validité ne dépasse pas deux ans à compter de la création ou d’une date de début choisie par le contribuable. Les statuts interrogeables comprennent Active, Blocked, Revoked et Expired. Votre logiciel doit présenter séparément validité cryptographique, statut officiel, type, droits effectivement constatés et déploiement technique, sans transformer l’un en preuve des autres.

Guide

Surveiller l’échéance et organiser l’escalade

Calculez les échéances depuis les métadonnées officielles et adaptez les alertes au délai réel de votre organisation : approbation, génération de clé, recette, fenêtres de changement et disponibilité des responsables. KSeF ne fixe ni délai d’alerte obligatoire ni période de chevauchement standard. Une équipe complexe peut retenir plusieurs seuils internes, par exemple information, ouverture automatique du changement puis escalade, à condition de les documenter comme politique interne. Chaque alerte doit contenir numéro de série, type, usage, propriétaire, date limite et action attendue, mais aucune donnée secrète. Testez le mécanisme sur une donnée non productive et vérifiez notification, prise en charge, relance et tableau de bord. Escaladez tout certificat sans propriétaire, remplacement sans créneau ou échec de recette. Mesurez les certificats arrivant à échéance sans plan approuvé, les alertes non acquittées et les écarts entre KSeF et l’inventaire ; gardez les captures ou événements qui prouvent l’exécution.

Guide

Préparer l’enrôlement du nouveau certificat et le chevauchement

Le remplacement à échéance consiste à demander puis déployer un nouveau certificat ; n’inventez ni point d’accès de renouvellement ni renouvellement automatique. Depuis février 2026, la demande et le téléchargement sont disponibles via l’API KSeF 2.0 et l’Application du contribuable. Le parcours API officiel commence par GET /certificates/limits et GET /certificates/enrollments/data. Générez ensuite une clé privée et une CSR PKCS#10 dans un environnement contrôlé, puis envoyez POST /certificates/enrollments avec le nom, le type, la CSR et, si utile, validFrom. Suivez GET /certificates/enrollments/{referenceNumber}, puis récupérez le certificat avec POST /certificates/retrieve. N’exposez jamais la clé dans les traces de pipeline. Une émission sous double contrôle et un coffre de secrets ou HSM, lorsque pertinent, réduisent le risque. Choisissez une coexistence interne assez longue pour vos tests et votre retour arrière, sans la présenter comme une règle officielle. Documentez capacité disponible, approbateurs, empreintes, chaîne de garde et critères d’abandon.

Guide

Déployer et tester la rotation Authentication

Pour un Type 1 Authentication, déployez d’abord le nouveau couple certificat-clé sur une instance pilote ou un connecteur de recette représentatif. La configuration doit référencer le secret par identifiant, limiter les accès du service et empêcher son impression dans les erreurs. Vérifiez l’ouverture d’une session KSeF, une opération API autorisée, une opération volontairement non autorisée et le comportement après redémarrage : le succès d’identité ne doit pas masquer le contrôle serveur des droits. Observez numéro de série utilisé, latence, taux d’échec et corrélation des journaux, sans journaliser la clé. Testez aussi le retour à l’ancienne référence tant que celle-ci est encore utilisable. L’intégration exécute les essais, la sécurité valide la garde du secret, le métier confirme le flux et l’exploitation approuve le passage général. Conservez résultats horodatés, version, instances couvertes, anomalies et décision go/no-go. Étendez ensuite le déploiement par vagues.

Guide

Déployer et tester la rotation Offline

Un Type 2 Offline exige un plan différent : ne tentez pas de l’utiliser pour authentifier l’API. Vérifiez que le composant d’émission hors ligne sélectionne le nouveau certificat pour confirmer l’identité de l’émetteur et l’intégrité des factures produites dans offline24, pendant une indisponibilité du système ou en mode urgence. Constituez des cas représentatifs sans provoquer d’incident réel : génération selon chaque mode pris en charge, validation de la signature ou du marquage attendu, remise ultérieure dans le flux normal et traitement d’un document créé avant la bascule. Confirmez aussi que l’ancien et le nouveau numéro de série restent correctement attribués aux documents de leur période. Le responsable facturation valide le scénario, l’intégration contrôle la remise, la sécurité vérifie l’usage de la clé et l’exploitation observe les files. Conservez factures de test expurgées, métadonnées, résultats et rapprochement final. Un test de session API avec ce type serait une fausse preuve et doit être rejeté.

Guide

Basculer, révoquer et conserver une preuve de retour arrière

Avant la bascule finale, confirmez la couverture de toutes les instances, l’absence d’échecs anormaux, la sauvegarde de la configuration précédente et l’autorité de décision. Pendant le changement, notez heure, version, numéro de série déployé et indicateurs observés. En cas d’échec, revenez à la référence précédente si elle reste sûre et valide, restaurez la configuration testée, puis analysez l’incident. Après une période d’observation définie en interne et la preuve que plus aucun composant ne dépend de l’ancien certificat, son propriétaire peut le révoquer via POST /certificates/{certificateSerialNumber}/revoke ; un certificat révoqué ne peut pas être réutilisé. Ne révoquez donc pas sur la seule foi d’un déploiement déclaré. Erreurs courantes : confondre certificat et droits, mélanger les deux types, copier une clé dans un ticket, oublier une instance, révoquer avant les tests ou laisser l’ancien actif sans décision. Une compromission exige une réponse urgente distincte de la rotation normale à échéance. Archivez approbations, essais, télémétrie, décision et confirmation de révocation.

Guide

Choisir le logiciel et lancer les prochaines actions

Évaluez l’ERP, le connecteur ou l’outil de gestion sur des démonstrations observables. Il doit importer les métadonnées KSeF, distinguer Type 1 et Type 2, suivre statut et échéance, attribuer propriétaire et suppléant, alerter avec escalade, référencer un coffre sans révéler les clés, déployer par environnement, identifier le numéro de série réellement utilisé et produire une piste d’audit exportable. Demandez un scénario complet : nouveau certificat, pilote, échec simulé, retour arrière, reprise, surveillance puis révocation contrôlée. Vérifiez les contrôles d’accès, le double contrôle, l’intégration secret manager ou HSM, la détection des instances oubliées et la séparation entre expiration et compromission. Commencez par exporter les certificats officiels, rapprocher les déploiements, nommer les propriétaires et classer les échéances. Puis traitez en priorité les éléments orphelins et organisez un exercice sur chaque type. Les informations présentées ici sont pratiques et attribuées avec prudence aux sources officielles ; elles ne remplacent pas un avis juridique, fiscal ou de sécurité adapté à votre situation.

Checklist

Rapprocher l’inventaire interne avec POST /certificates/query et faire traiter chaque écart par un propriétaire nommé.

Enregistrer numéro de série, type, statut, validité, usage, environnement, propriétaire et suppléant sans aucune clé privée.

Attribuer des noms uniques qui permettent d’identifier le service et l’environnement sans divulguer de secret.

Configurer des seuils d’alerte internes adaptés aux délais de validation, de test et de déploiement.

Vérifier les limites et données d’enrôlement avant de générer la CSR PKCS#10 et la clé dans un espace sécurisé.

Faire approuver l’émission et le transfert du nouveau certificat sous double contrôle.

Tester un Type 1 par une authentification observée, un contrôle de droits et un retour arrière.

Tester séparément un Type 2 sur les scénarios hors ligne pris en charge et leur remise ultérieure.

Déployer par vagues en suivant le numéro de série réellement utilisé et les erreurs de chaque instance.

Révoquer l’ancien certificat seulement après preuve de la bascule et conserver le dossier de changement complet.

Questions fréquentes

Combien de temps un certificat KSeF est-il valide ?

Le ministère polonais des Finances indique une durée maximale de deux ans à compter de la création du certificat ou d’une date de début de validité choisie par le contribuable. Consultez les métadonnées de chaque certificat plutôt que de déduire son échéance d’une convention interne.

Le renouvellement d’un certificat KSeF est-il automatique ?

Non. Les sources officielles décrivent l’enrôlement et la récupération d’un certificat, pas un renouvellement automatique ni un point d’accès officiel de renouvellement. Opérationnellement, traitez l’échéance comme la demande, le déploiement et la validation d’un nouveau certificat.

Un certificat KSeF contient-il les droits de l’entreprise ?

Non. Il sert à établir une identité et ne contient ni permissions KSeF ni contexte d’entreprise. Les autorisations sont vérifiées côté serveur ; il faut donc tester séparément l’authentification et les opérations que l’identité est autorisée à réaliser.

Quelle différence existe-t-il entre Type 1 et Type 2 ?

Le Type 1 Authentication sert à s’authentifier auprès de KSeF. Le Type 2 Offline confirme l’identité de l’émetteur et l’intégrité d’une facture dans offline24, lors d’une indisponibilité ou en urgence ; il ne permet pas d’authentifier une session API. Ils sont émis séparément.

Comment effectuer une rotation ERP sans interruption ?

Demandez le nouveau certificat assez tôt selon vos propres délais, déployez-le sur un pilote, testez les flux et le retour arrière, puis élargissez la bascule par vagues tout en observant le numéro de série utilisé et les erreurs. La durée de coexistence relève de votre plan, pas d’une règle KSeF annoncée.

Quand faut-il révoquer l’ancien certificat ?

Après avoir prouvé que toutes les instances visées utilisent le nouveau certificat, que les tests métier et techniques ont réussi et que la période d’observation interne est satisfaisante. Le propriétaire peut alors appeler le point d’accès officiel de révocation ; la réutilisation devient impossible.

Que peut rechercher POST /certificates/query ?

Cette requête fournit des métadonnées de certificats actifs et historiques. La documentation officielle mentionne des filtres portant notamment sur les statuts Active, Blocked, Revoked ou Expired, l’expiration, le nom, le type et le numéro de série, ce qui facilite le rapprochement d’inventaire.

La rotation à échéance suffit-elle si la clé privée est compromise ?

Non. Une suspicion de compromission nécessite une réponse urgente : contenir l’usage, évaluer les composants touchés, remplacer les secrets et décider rapidement de la révocation selon la procédure d’incident. Ne l’attendez pas comme une rotation planifiée et évitez toute exposition supplémentaire dans les tickets ou journaux.

Réglementation, formats et termes clés

Commission européenneEN 16931Directive 2014/55/UEfacture électronique structuréeInventaire, expiration et rotation des certificats KSeFPologne

À lire aussi

Sources officielles

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