E-Invoice Finder
Menu
Pays Logiciels Échéances Guides Checker Vérifier obligation
ENFRDEPLNL
Pologne · incident de sécurité KSeF

Réagir à un certificat KSeF compromis

Isolez une clé privée KSeF compromise, révoquez le bon certificat, recherchez un usage abusif et remplacez les identifiants dans vos ERP.

Résumé pratique :
  • • Périmètre : l’inventaire doit relier chaque série à une fonction et à ses emplacements réels.
  • • Risque : les zones sans télémétrie restent incertaines même après le blocage technique.
  • • Action : la reprise doit s’appuyer sur une chaîne de confiance reconstruite et vérifiable.
Voir le rapport PologneSources officielles
Dernière vérification : 31 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

Qualifier l’alerte et fixer le niveau de gravité

Ouvrez un dossier horodaté et désignez trois rôles : responsable de l’incident, propriétaire métier KSeF et responsable technique. Une copie avérée de clé privée de production, sa publication ou son accès par un tiers justifient généralement une priorité élevée. Un poste infecté, un équipement perdu ou un export inexpliqué sont aussi sérieux, sans prouver qu’une facture a été émise abusivement. Évaluez la fiabilité de l’alerte, la durée d’exposition, l’étendue des déploiements, la fonction du certificat et les anomalies observées. Comme repère recommandé — non comme délai légal KSeF — consignez les faits et stoppez la diffusion dans les 15 premières minutes ; dans l’heure, identifiez série, type, propriétaire et systèmes, puis choisissez une révocation saine et un plan de continuité. Ne retardez pas une révocation justifiée pour achever l’attribution, mais ne révoquez jamais d’après un simple nom de fichier.

Guide

Identifier le certificat exact, son type, son propriétaire et ses déploiements

Constituez une fiche unique : numéro de série, propriétaire, validité, type 1 Authentication ou type 2 Offline, environnement, entité, dépositaire et emplacements. Un certificat KSeF sert à l’identité et à l’authentification ; il ne transporte ni autorisations KSeF ni contexte d’entreprise. Le type 1 authentifie une session API. Le type 2 vérifie l’émetteur des factures offline24, d’indisponibilité ou d’urgence ; il n’authentifie pas une session API. Interrogez les métadonnées avec POST /certificates/query lorsque possible et relevez l’état Active, Blocked, Revoked ou Expired. Rapprochez-les des ERP, middlewares, coffres ou HSM, serveurs, secrets CI/CD, secours, postes, sauvegardes et copies prestataires. Le ministère indique une validité maximale de deux ans, mais l’expiration ne remplace pas l’intervention. Chaque propriétaire de déploiement doit confirmer l’usage et la dernière rotation : un alias tel que « ksef-prod » n’identifie jamais suffisamment le certificat.

Guide

Contenir l’exposition et préparer une révocation depuis un environnement sain

Ces mesures relèvent des bonnes pratiques d’intervention, non d’une obligation technique propre à KSeF. Isolez les hôtes touchés, interrompez les tâches utilisant la clé, bloquez sa réplication et limitez les accès. Ne déplacez pas la clé suspecte pour l’examiner et ne révoquez pas depuis un poste potentiellement compromis. Utilisez un équipement sain et une identité autorisée ; faites vérifier série et type par une seconde personne. La documentation CIRFMF précise que seul le propriétaire peut révoquer son certificat pour compromission de clé, fin d’usage ou changement organisationnel. S’il est indisponible, suivez la procédure interne d’identité et d’administration KSeF, sans emprunter les identifiants d’un tiers. Selon le ministère, les entreprises distribuant des certificats d’entité doivent tracer téléchargement, remise, usage et révocation : récupérez ce registre. Évaluez séparément les jetons, mots de passe et comptes techniques partageant éventuellement la voie d’exposition.

Guide

Comprendre la révocation officielle et ce qu’elle ne résout pas

La voie documentée est POST /certificates/{certificateSerialNumber}/revoke, avec le numéro de série et un motif facultatif. Conservez opérateur, approbation, heure, série, motif non sensible et réponse. La procédure officielle indique qu’une demande valide bloque automatiquement le certificat dans KSeF, indépendamment de la publication sur une liste de révocation : une attente de CRL ne maintient donc pas utilisable un certificat correctement révoqué. Contrôlez ensuite les métadonnées et gardez la preuve du nouvel état ; si la réponse est ambiguë, faites escalader plutôt que répéter les appels. Le certificat révoqué est irrécupérable et doit être remplacé. En revanche, la révocation ne retire pas les droits KSeF du propriétaire, n’annule pas ses autres certificats, ne prouve aucun abus et ne supprime aucune copie de clé ou configuration. Elle ne renouvelle pas non plus jetons, secrets de coffre, mots de passe ou identifiants d’intégration. Traitez habilitations et secrets connexes séparément, selon les éléments recueillis.

Guide

Enquêter sur les usages possibles et préserver les preuves

Établissez une chronologie de la première exposition plausible au blocage confirmé. Préservez journaux KSeF et ERP, passerelle API, audits du coffre, télémétrie des terminaux, déploiements, actions administratives, registre de remise, files et accusés. Recherchez série, propriétaire, sources, clients applicatifs, horaires et identifiants de factures. Finance compare factures transmises, acceptées, rejetées, corrigées ou hors ligne aux écritures ERP, montants, destinataires et opérateurs attendus. Sécurité recherche export de clé, persistance, mouvement latéral et accès aux secrets dépendants. L’absence d’anomalie réduit l’inquiétude sans démontrer l’absence d’abus, surtout avec une rétention courte ; conservez aussi les requêtes rejetées. Décidez des escalades vers juridique, protection des données, assureur ou autorités selon les faits et règles de l’organisation. Cette recommandation ne crée ni délai de notification KSeF ni conseil juridique.

Guide

Créer un remplacement propre et le déployer par étapes

Générez une nouvelle clé par un processus de confiance ; ne réutilisez ni l’ancienne clé, ni une image compromise, ni une configuration reprise sans contrôle. Demandez le type requis et consignez propriétaire, série, validité et finalité. Stockez la clé selon la politique de sécurité de l’organisation, idéalement dans un dispositif contrôlé limitant l’export, journalisant les accès et séparant les responsabilités. Déployez depuis l’inventaire : mettez à jour un connecteur, vérifiez la série, testez, puis retirez ancienne référence et copies résiduelles. Commencez si possible hors production ou sur un flux à faible risque, poursuivez par un canari, observez les accusés puis élargissez. Le retour arrière doit utiliser une configuration saine du remplacement, jamais la clé révoquée. Renouvelez coffres, comptes de service, jetons de déploiement ou mots de passe si leur voie d’exposition est commune ou incertaine.

Guide

Maintenir la facturation selon le type Authentication ou Offline

La continuité dépend de la fonction. Après révocation d’un type 1 Authentication, les intégrations concernées nécessitent une autre méthode valide et autorisée avant de reprendre. Les jetons restent utilisables avec les certificats depuis le 1er février 2026, mais les orientations actuelles prévoient les certificats comme méthode restante au 1er janvier 2027. Ne basculez pas automatiquement vers un jeton : contrôlez propriétaire, droits, stockage, lien avec l’incident et retrait prévu, puis isolez-le ou renouvelez-le si nécessaire. Un type 1 séparé et sain peut offrir une continuité plus maîtrisée. Pour un type 2 Offline compromis, arrêtez son usage pour les nouvelles factures offline24, d’indisponibilité ou d’urgence et remplacez-le chez chaque émetteur. Il ne rétablit pas une connexion API. Finance prévient les doublons et rapproche les accusés. Testez indépendamment authentification normale et vérification hors ligne. Toute solution manuelle temporaire doit avoir responsable, limites transactionnelles et échéance interne.

Guide

Appliquer le plan à des scénarios concrets et éviter les erreurs courantes

Scénario 1 : un serveur ERP infecté héberge une clé exportable de type 1. Isolez-le, confirmez série et propriétaire, révoquez depuis une voie saine, analysez appels et factures, créez une clé, reconstruisez puis redéployez progressivement ; examinez les droits séparément. Scénario 2 : un portable d’urgence est perdu avec un type 2. Révoquez sa série, examinez garde et factures hors ligne, remplacez le certificat et validez la vérification ; aucune session API n’est ainsi fermée. Scénario 3 : un dépôt public contient le certificat public, sans clé privée confirmée. Préservez commit et accès, recherchez anciennes versions, mots de passe ou archives, puis adaptez le confinement : la partie publique seule n’équivaut pas à une clé compromise. Erreurs fréquentes : révoquer par alias, attendre la CRL, effacer les journaux pendant la reconstruction, réutiliser la clé, oublier le secours ou le prestataire, retirer des droits sans révoquer, ou croire que la révocation établit l’historique des usages.

Guide

Choisir les bons contrôles logiciels et organiser les prochaines actions

Exigez de l’ERP, du middleware ou du coffre un inventaire par série, type, propriétaire, entité, environnement et déploiement. Évaluez stockage non exportable ou contrôlé, accès par rôle, double validation, journaux résistants à l’altération, alertes, rotation testable et séparation type 1/type 2. Demandez au fournisseur d’afficher la série, d’expliquer le chevauchement ancien/nouveau, de démontrer un basculement progressif sans doublon et de tester la signature hors ligne indépendamment de l’API. Préférez démonstrations et traces aux affirmations générales. Attribuez ensuite chaque action à sécurité, finance, fiscalité, IT, achats ou intégrateur, avec des dates internes fondées sur le risque, jamais présentées comme des délais KSeF. Surveillez échecs d’authentification, états, volumes, contreparties atypiques et rapprochements hors ligne. Clôturez après vérification de la couverture du remplacement, suppression des secrets résiduels, retrait des contournements, conservation des preuves et acceptation des incertitudes. Terminez par un retour d’expérience et un exercice sans impact production.

Checklist

Ouvrir un dossier horodaté et nommer les responsables incident, métier KSeF et technique.

Relever le numéro de série exact, le type 1 ou 2, le propriétaire, l’état et la validité.

Cartographier la clé dans les ERP, middlewares, coffres, hôtes, sauvegardes et chez les prestataires.

Isoler les composants touchés tout en préservant journaux, instantanés, files et traces de garde.

Faire confirmer le périmètre et révoquer le bon numéro depuis un environnement sain et autorisé.

Vérifier l’état par requête de métadonnées puis examiner séparément droits, certificats et jetons associés.

Comparer les traces KSeF, ERP, passerelle et sécurité avec l’activité de facturation attendue.

Générer une clé neuve et obtenir le certificat adapté sans reprendre d’artefact suspect.

Déployer selon l’inventaire et tester indépendamment authentification API et vérification hors ligne.

Surveiller la reprise, retirer les solutions temporaires et formaliser le retour d’expérience.

Questions fréquentes

Comment révoquer un certificat KSeF ?

La documentation officielle prévoit POST /certificates/{certificateSerialNumber}/revoke avec le numéro de série exact et un motif facultatif. Seul le propriétaire du certificat peut effectuer la révocation. Utilisez une voie saine et autorisée, conservez la réponse puis interrogez les métadonnées pour confirmer l’état.

La révocation d’un certificat KSeF prend-elle effet immédiatement ?

La procédure officielle indique qu’une demande de révocation valide bloque automatiquement le certificat dans KSeF, indépendamment de la publication sur la CRL. Il faut néanmoins conserver la réponse et vérifier l’état, car une erreur de série, d’autorisation ou de requête ne constitue pas une révocation valide.

Révoquer le certificat retire-t-il les droits KSeF de son propriétaire ?

Non. Le certificat sert à l’identité ou à l’authentification et ne porte pas lui-même les autorisations ni le contexte d’une société. Si l’identité ne doit plus accéder à KSeF, examinez et modifiez ses droits séparément, sans supposer que ses autres certificats sont automatiquement annulés.

Quelle différence entre un certificat Authentication et un certificat Offline compromis ?

Le type 1 Authentication peut authentifier une session API et concerne donc directement les intégrations connectées. Le type 2 Offline vérifie l’émetteur pour les factures offline24, d’indisponibilité ou d’urgence ; il ne permet pas d’ouvrir une session API. L’enquête, les tests et la continuité doivent suivre cette fonction.

La révocation prouve-t-elle que la clé privée a été utilisée abusivement ?

Non. Elle empêche l’usage ultérieur du certificat révoqué, mais ne démontre ni n’écarte un usage antérieur. Délimitez la fenêtre d’exposition possible et rapprochez les journaux KSeF, ERP, coffre, passerelle et terminaux avec les factures attendues, en signalant les lacunes de conservation.

Peut-on utiliser un jeton pendant le remplacement du certificat ?

Éventuellement, après une analyse distincte. Les orientations actuelles permettent encore les jetons depuis le 1er février 2026, mais visent les certificats comme méthode restante au 1er janvier 2027. Vérifiez propriétaire, droits, stockage et exposition du jeton, limitez son usage temporaire et prévoyez son retrait.

Comment remplacer un certificat sans interrompre toute la facturation ?

Préparez l’inventaire, créez une nouvelle clé, obtenez le bon type de certificat et validez-le hors du flux principal. Déployez ensuite par lots ou en canari, avec finance aux commandes des files et accusés. N’utilisez jamais le certificat révoqué comme solution de retour arrière et contrôlez les doublons.

Quels critères imposer à un ERP ou à un coffre de secrets KSeF ?

Exigez au minimum l’affichage de la série, du type, du propriétaire, de la validité et des déploiements. Les fonctions utiles incluent stockage contrôlé, journalisation, alertes, double approbation, contrôle d’état, rotation progressive et tests séparés pour l’authentification API et la vérification d’émetteur hors ligne.

Réglementation, formats et termes clés

Commission européenneEN 16931Directive 2014/55/UEfacture électronique structuréeCompromission et révocation urgente d’un certificat KSeFPologne

À lire aussi

Sources officielles

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