E-Invoice Finder
Menu
Pays Logiciels Échéances Guides Checker Vérifier obligation
ENFRDEPLNL
Pologne · bascule d’authentification KSeF

Migration du jeton KSeF au certificat pour ERP et API

Migrez les intégrations ERP et API des jetons KSeF vers les certificats Authentication avant 2027 avec tests parallèles, droits et retour arrière.

Résumé pratique :
  • Échéance : les jetons système KSeF ne seront plus utilisables à compter du 1er janvier 2027.
  • Périmètre : la bascule concerne la couche d’identité du connecteur, sans transférer les autorisations dans le certificat.
  • Priorité : désignez maintenant un responsable de mise en production et fixez des seuils mesurables d’acceptation.
Voir le rapport PologneSources officielles
Dernière vérification : 3 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

1. Comprendre l’échéance et le changement d’architecture

Depuis le 1er février 2026, une intégration KSeF peut utiliser un jeton KSeF ou un certificat KSeF. À partir du 1er janvier 2027, seul le certificat restera accepté comme moyen d’authentification. Il ne s’agit pas d’une conversion automatique : un jeton KSeF embarque les permissions déclarées lors de sa création, tandis qu’un certificat atteste une identité. Les autorisations associées au contexte demandé sont alors gérées et contrôlées côté KSeF. Le certificat ne porte d’ailleurs aucun contexte d’entreprise ; la demande de connexion indique ce contexte, puis KSeF vérifie l’existence d’au moins une permission active. Pour un ERP, le changement touche donc le coffre de secrets, la signature, le client API, la gestion des sessions, la supervision et les procédures d’exploitation. Aucun délai de grâce officiel après l’échéance ne doit être supposé. Le programme doit séparer trois objets : l’ancien jeton système KSeF, le certificat durable et sa clé privée, puis les jetons temporaires d’authentification, d’accès et de rafraîchissement délivrés pendant une session.

Guide

2. Cartographier les dépendances et établir la référence des droits

Commencez par recenser chaque endroit où un jeton KSeF est lu ou copié : connecteur ERP, middleware, ordonnanceur, coffre de secrets, variable de déploiement, procédure de support et scénario de reprise. Pour chaque flux, notez l’entité ou le NIP concerné, l’environnement, les opérations réalisées, le volume, le propriétaire métier, le propriétaire technique et le compte de service. Exportez ou relevez ensuite les permissions actives afin de constituer une référence datée, approuvée par Finance et par le responsable KSeF. Cette photographie permettra de vérifier que l’authentification par certificat retrouve bien les droits nécessaires, sans prétendre que ceux-ci résident dans le certificat. Exemple : le connecteur SAP d’une filiale polonaise envoie les factures de vente, consulte leur statut et récupère les UPO ; le service fiscal valide le contexte, l’équipe IAM valide l’identité et les permissions, et l’équipe intégration documente les appels. Les éléments de preuve comprennent l’inventaire signé, les identifiants de configuration, la matrice rôles-opérations et les résultats de requêtes autorisées ou refusées. Le risque principal est un jeton partagé cachant des usages non documentés.

Guide

3. Choisir et obtenir le type 1, puis protéger la clé

Pour authentifier un ERP ou un client API, choisissez un certificat KSeF de type 1 Authentication. Le type 2 Offline est délivré séparément : il confirme l’identité de l’émetteur et l’intégrité d’une facture dans les modes offline24, indisponibilité du système et urgence, mais il ne peut pas ouvrir une session API. L’obtention du certificat doit être préparée avec le propriétaire de l’identité, l’administrateur KSeF et l’équipe sécurité. Point important pour la migration : les données d’enrôlement d’un certificat ne peuvent être obtenues qu’après une authentification XAdES, et non au moyen d’un jeton KSeF. Prévoyez donc ce prérequis plutôt que de découvrir un blocage en fin de projet. Générez et conservez la clé privée dans un mécanisme adapté à votre architecture — coffre de clés, HSM ou service de signature contrôlé — avec accès minimal, journalisation, sauvegarde ou procédure de récupération appropriée. Ne placez ni clé ni mot de passe dans le dépôt du connecteur. Documentez l’empreinte, le propriétaire, les environnements autorisés et la procédure de révocation, sans transformer ce chantier de bascule en un guide général de rotation des certificats.

Guide

4. Implémenter XAdES et gérer correctement les jetons de session

Le parcours par certificat commence par POST /auth/challenge. Le connecteur construit ensuite un AuthTokenRequest pour le contexte choisi, le signe en XAdES avec la clé correspondant au certificat, puis poursuit le parcours prévu par l’API afin d’obtenir les éléments temporaires d’authentification, d’accès et de rafraîchissement. L’aperçu officiel précise que les logiciels commerciaux doivent prendre en charge la signature XAdES-BES pour cette authentification. Le certificat à longue durée de vie ne remplace donc pas le jeton JWT d’accès utilisé dans une session : il sert à établir l’identité au début du parcours, tandis que le client doit stocker en mémoire ou dans un espace temporaire protégé les jetons de session, suivre leur durée de vie et rafraîchir ou recréer la session selon la documentation. À l’inverse, l’ancien parcours chiffre le jeton KSeF et l’envoie à POST /auth/ksef-token. Implémentez les deux chemins derrière une option de configuration explicite, avec bibliothèques, métriques et messages d’erreur distincts. Vérifiez aussi l’horloge, les algorithmes de signature, la chaîne du certificat, l’encodage XML et la corrélation des requêtes.

Guide

5. Construire une matrice de tests et conserver les preuves

La recette doit couvrir davantage qu’une connexion réussie. Testez un certificat valide avec chaque contexte prévu, les opérations autorisées, une opération volontairement interdite, un contexte erroné, une signature altérée, un certificat révoqué ou non reconnu, une clé indisponible, un challenge expiré, un rafraîchissement de session et une nouvelle authentification après expiration. Ajoutez les scénarios métier : envoi d’une facture représentative, récupération de statut et d’UPO, rejet fonctionnel, reprise après délai réseau, idempotence et montée en charge. Dans l’exemple SAP, l’équipe QA exécute dix factures comprenant devises, corrections et pièces volumineuses ; Finance rapproche chaque identifiant ERP du résultat KSeF ; la sécurité vérifie qu’aucune clé ni aucun jeton n’apparaît dans les journaux. Conservez les versions du connecteur et de la bibliothèque XAdES, les empreintes non secrètes, horodatages, identifiants de corrélation, captures de métriques et procès-verbal d’acceptation. Masquez les secrets et données personnelles. Les critères de passage peuvent être : 100 % des scénarios critiques réussis, aucun défaut majeur ouvert, droits conformes à la référence et procédure de récupération testée.

Guide

6. Organiser le parallèle, le canari et la surveillance

Une exécution en parallèle est une pratique de réduction du risque, pas une durée imposée par l’administration. Commencez par le non-production, puis activez en production le chemin certificat pour un canari contrôlé : une entité, un connecteur ou une tranche de flux dont l’échec est rapidement détectable et récupérable. Évitez d’envoyer deux fois la même facture ; le parallèle doit comparer les parcours d’authentification ou répartir des flux identifiés, avec garde-fous d’idempotence. Surveillez séparément les succès d’authentification, erreurs de signature, refus de contexte ou de permission, renouvellements de session, latence, taux d’envoi accepté, files d’attente et rapprochement ERP-KSeF. Définissez des alertes et un tableau de bord avant le canari. Le responsable intégration pilote l’activation, Finance confirme la continuité des résultats, l’exploitation traite les alertes et la sécurité surveille l’usage de la clé. Un exemple de plan est : semaine 1 inventaire et droits ; semaines 2 à 3 enrôlement et développement ; semaine 4 recette ; semaine 5 canari ; semaine 6 généralisation, selon vos contraintes. Ce calendrier interne ne constitue pas une règle officielle.

Guide

7. Décider la bascule et encadrer le retour arrière

Réunissez un comité go/no-go avec des critères objectifs : certificat de type 1 actif, permissions validées dans chaque contexte, tests critiques réussis, supervision opérationnelle, équipe d’astreinte informée, capacité de vidage des files et preuve que le chemin jeton n’est plus une dépendance cachée. Pendant une courte fenêtre de gel interne, évitez les changements ERP sans rapport avec la migration. Activez le certificat par configuration, observez un volume convenu, puis étendez progressivement. Un retour temporaire au jeton KSeF ne peut être envisagé qu’avant la fin de sa prise en charge et seulement si l’ancien secret reste valide et protégé. Déclenchez-le sur des seuils écrits, par exemple des échecs d’authentification persistants, une file dépassant la capacité de rattrapage ou une anomalie de rapprochement ; un incident métier sans lien avec l’authentification ne justifie pas forcément ce retour. Le directeur de mise en production décide, l’exploitation exécute, Finance évalue l’impact et la sécurité contrôle l’usage du secret. Après le 1er janvier 2027, ce chemin ne constitue plus une solution de repli : la récupération doit alors corriger le parcours certificat.

Guide

8. Retirer les secrets de jeton et éviter les erreurs fréquentes

Une fois la période d’observation achevée et les preuves approuvées, désactivez le chemin jeton, retirez l’ancien secret des coffres, variables, pipelines et procédures, puis révoquez ou supprimez le jeton KSeF selon le mécanisme disponible. Vérifiez les journaux d’accès au coffre et effectuez une recherche ciblée dans les configurations pour repérer les copies ; ne mettez jamais la valeur du secret dans un ticket ou un rapport. Conservez la preuve de retrait, le numéro de changement, la date, le propriétaire et la validation de l’exploitation. Les erreurs courantes sont de croire à une conversion automatique, de choisir un certificat Offline de type 2 pour l’API, de considérer le certificat comme porteur de droits, de confondre le jeton système KSeF avec les JWT temporaires d’accès ou de rafraîchissement, ou de supprimer l’ancien secret avant que le canari soit démontré. Autre piège : réussir l’authentification mais omettre les refus de permission, l’expiration de session ou la protection de la clé. Le retrait doit être irréversible seulement après décision formelle et capacité de fonctionnement prouvée.

Guide

9. Choisir le logiciel et lancer les prochaines actions

Évaluez l’ERP, le middleware ou l’éditeur sur des preuves : prise en charge du certificat KSeF de type 1 et de XAdES-BES, parcours POST /auth/challenge et AuthTokenRequest, gestion distincte des jetons temporaires, sélection du contexte, intégration à un coffre de clés, journalisation sans secrets, métriques, reprise et tests automatisés. Demandez une démonstration avec un refus de permission et une expiration de session, pas seulement un envoi nominal. Exigez la liste des versions supportées, le modèle de responsabilité, les délais de correction et la possibilité d’exporter les preuves. Pour démarrer, nommez sous cinq jours un propriétaire métier et un responsable technique, terminez l’inventaire et la référence des droits, confirmez le parcours d’enrôlement XAdES, puis planifiez développement, recette, canari et retrait avec des jalons datés. Le risque résiduel doit être accepté par le décideur désigné, notamment si une dépendance tierce n’est pas encore certifiée. Cette démarche fournit une base pratique de migration et de décision ; elle ne remplace pas un avis juridique, fiscal ou de sécurité adapté à votre organisation.

Checklist

Nommer le propriétaire métier, le responsable technique, le décideur de bascule et les équipes de support.

Inventorier chaque connecteur, contexte, coffre, pipeline et procédure qui utilise un jeton KSeF.

Faire approuver une référence datée des permissions nécessaires pour chaque flux ERP ou API.

Obtenir un certificat KSeF de type 1 Authentication par le parcours d’enrôlement approprié.

Protéger la clé privée dans un coffre ou service de signature avec accès minimal et audit.

Implémenter POST /auth/challenge, AuthTokenRequest signé en XAdES-BES et la gestion des jetons temporaires.

Exécuter la matrice de tests positive, négative, métier, charge, expiration et reprise sans exposer de secret.

Déployer un canari surveillé avec seuils de succès, garde-fous d’idempotence et preuves de rapprochement.

Faire approuver le go/no-go et limiter tout retour au jeton à une mesure temporaire avant le 1er janvier 2027.

Après validation, supprimer ou révoquer l’ancien jeton et rechercher ses copies dans toutes les configurations.

Questions fréquentes

Quand les jetons KSeF cessent-ils d’être pris en charge ?

Les jetons KSeF et les certificats peuvent être utilisés depuis le 1er février 2026. À compter du 1er janvier 2027, seuls les certificats KSeF restent utilisables pour l’authentification concernée. Ne fondez pas le plan de continuité sur une grâce supplémentaire qui n’est pas annoncée officiellement.

Peut-on convertir automatiquement un jeton KSeF en certificat ?

Non. Ce sont des objets différents et aucun mécanisme automatique de conversion ne doit être supposé. Le certificat doit être obtenu par le parcours prévu, puis le connecteur doit implémenter l’authentification XAdES et valider ses permissions côté KSeF.

Quel type de certificat faut-il pour un ERP ou une API ?

Utilisez un certificat KSeF de type 1 Authentication. Le certificat de type 2 Offline sert à confirmer l’identité de l’émetteur et l’intégrité des factures dans les modes offline24, indisponibilité et urgence ; il ne permet pas d’authentifier une session API.

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

Non. Il constitue une preuve d’identité et ne contient pas de contexte d’entreprise. La demande de connexion précise le contexte ; KSeF contrôle alors qu’au moins une permission active autorise l’identité concernée à agir dans ce contexte.

Le certificat remplace-t-il les jetons JWT d’accès et de rafraîchissement ?

Non. Le certificat et sa clé servent au parcours initial d’authentification. Une fois celui-ci accompli, l’API fournit des jetons temporaires, notamment d’accès et de rafraîchissement, que le client doit gérer pour la session sans les confondre avec l’ancien jeton système KSeF.

Comment obtenir les données nécessaires à l’enrôlement du certificat ?

La documentation officielle indique que les données d’enrôlement ne peuvent être obtenues qu’après une authentification XAdES, et non avec un jeton KSeF. Il faut donc identifier à l’avance l’identité habilitée et le moyen XAdES disponible pour accomplir cette étape.

Comment tester sans interrompre la facturation de l’ERP ?

Validez d’abord le parcours en non-production, puis utilisez un canari de production clairement délimité. Comparez les indicateurs et les rapprochements sans dupliquer les factures, conservez un chemin de retour temporaire avant l’échéance et généralisez seulement après satisfaction des seuils convenus.

Quand peut-on supprimer l’ancien secret du jeton KSeF ?

Après une bascule prouvée : scénarios critiques réussis, canari stable, permissions confirmées, surveillance active, files rapprochées et approbation go/no-go documentée. Retirez alors les copies dans les coffres, pipelines et procédures, puis conservez une preuve de suppression ou de révocation.

Réglementation, formats et termes clés

Commission européenneEN 16931Directive 2014/55/UEfacture électronique structuréeMigration des jetons KSeF vers les certificats pour ERP et APIPologne

À lire aussi

Sources officielles

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