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

Limites, nommage et gouvernance multi-entités des certificats KSeF

Structurez les certificats KSeF par société et flux ERP : limites en direct, identité, nommage, droits de contexte, clés et tests.

Résumé pratique :
  • • Périmètre : gouverner l’identité certifiée séparément des entités desservies.
  • • Risque clé : une mutualisation opaque amplifie l’incident et complique la révocation.
  • • Première action : désigner le dépositaire et inventorier les usages avant tout enrôlement.
Voir le rapport PologneSources officielles
Dernière vérification : 5 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

Identité du propriétaire et contexte d’entité : deux notions distinctes

Fait officiel : le certificat KSeF contient l’identité authentifiée de son propriétaire. Il ne contient aucune permission KSeF et n’est pas affecté au contexte d’une société. Le système contrôle les droits côté serveur au moment de l’opération. Un même certificat peut donc être présenté dans plusieurs contextes d’entité si son propriétaire y détient effectivement les permissions nécessaires. Les API de gestion des certificats se rapportent, elles aussi, au propriétaire authentifié : elles exposent le même ensemble de certificats de ce propriétaire, quel que soit le contexte utilisé lors de la connexion. En gouvernance, tenez une matrice propriétaire–entité–flux–permission afin de ne pas confondre identité et autorisation. Le responsable sécurité relie chaque secret à son propriétaire, tandis que le responsable KSeF valide les contextes admis. Croire qu’une clé « de la société A » ouvre automatiquement A serait une erreur : seule la décision serveur fait foi.

Guide

Découvrir la limite en direct et conserver une marge de capacité

Fait officiel : avant toute demande, le guide technique recommande d’appeler GET /certificates/limits. La réponse indique le nombre maximal de certificats que le propriétaire peut détenir, le nombre actuellement actif et si une nouvelle demande peut être déposée. Cette réponse est l’autorité opérationnelle ; ne codez aucune limite numérique dans l’ERP, un tableur ou un contrat, car elle peut évoluer. Contrôle recommandé : interroger l’endpoint avant le déploiement, avant chaque vague de rotation et après toute émission ou révocation importante. Le service IAM consigne la date, l’environnement et la réponse, puis alerte si la capacité ne couvre plus le prochain renouvellement. Réservez une marge pour remplacer une clé avant de retirer l’ancienne ; sa taille relève de votre analyse de risque, pas d’une règle officielle. Critère mesurable : aucune campagne ne démarre sans lecture récente des limites et preuve que toutes les demandes planifiées, y compris les remplacements, sont recevables.

Guide

Certificat de société ou certificat personnel : choisir le bon propriétaire

Faits officiels : un certificat délivré à une personne morale n’est pas lié à un salarié précis ; la société doit tracer son téléchargement, sa distribution, son utilisation et sa révocation. Une personne morale peut demander plusieurs certificats de société, sous réserve des limites alors applicables. À l’inverse, un certificat personnel appartient à l’individu : lui seul peut le demander, le télécharger et l’utiliser. Les deux modèles produisent une attribution différente dans KSeF. Le choix doit donc partir du besoin de responsabilité : un service ERP durable se prête généralement mieux à une identité de société gouvernée par l’entreprise, tandis qu’une action réellement personnelle peut justifier le certificat de l’individu. Ce sont des critères pratiques, non une prescription universelle. Désignez un dépositaire et un remplaçant pour chaque certificat de société, sans partage large de clé ; interdisez la copie d’un certificat personnel dans un coffre d’équipe. L’inventaire doit nommer propriétaire, dépositaire, utilisateurs autorisés et motif du modèle retenu.

Guide

Convention pratique de nommage et inventaire exploitable

Fait officiel : POST /certificates/enrollments exige notamment certificateName, et le nom choisi réapparaît ensuite dans les métadonnées. POST /certificates/query permet de retrouver les certificats avec, entre autres, leur nom, statut, expiration, type et numéro de série. En revanche, les sources officielles n’imposent aucune convention de nommage d’entreprise. Une règle comme « PROD-PL01-VENTES-ERP-2026-R1 » est donc un contrôle de gouvernance recommandé, jamais une obligation KSeF. Utilisez des segments stables : environnement, entité interne, finalité, système, millésime et révision. N’insérez aucun secret dans certificateName. L’inventaire précise aussi propriétaire, dépositaire, coffre, expiration, type, contextes, permissions attendues et procédure de révocation. Évitez deux clés simplement nommées « ERP », impossibles à distinguer pendant un incident. Critère mesurable : chaque résultat de /certificates/query se rapproche d’une ligne unique d’inventaire par numéro de série, sans certificat orphelin ni doublon ambigu.

Guide

Décider l’architecture par entité, flux et rayon d’impact

Fait officiel : une seule identité certifiée peut techniquement intervenir dans plusieurs contextes lorsque son propriétaire y est autorisé ; le certificat lui-même n’accorde toujours aucun droit. La séparation par société n’est donc pas une exigence intrinsèque du certificat. Elle peut néanmoins réduire le rayon d’impact d’une fuite, simplifier la révocation, distinguer les journaux et éviter qu’une panne de rotation n’affecte tous les flux. Décidez avec une matrice entité–charge de travail : criticité, support, rotation, séparation, coffre et dépendance au prestataire. Un hub ERP peut employer un certificat par flux critique ou groupe de contextes homogènes ; des clés sans objectif ajoutent de la complexité. L’architecte approuve chaque mutualisation et documente l’effet d’une compromission. Critères mesurables : aucun secret de production ne sert en test ; chaque flux possède un propriétaire et un scénario de remplacement ; la compromission d’une clé a une liste d’entités et d’opérations explicitement bornée et validée.

Guide

Enrôlement, CSR et clé privée : une chaîne à ne pas rompre

Faits officiels : la demande ne peut être faite qu’au nom du demandeur. Les données renvoyées par GET /certificates/enrollments/data doivent être recopiées exactement dans la demande PKCS#10 (CSR). L’authentification par jeton système ne permet pas d’obtenir ces données : une authentification signée/XAdES est requise. POST /certificates/enrollments reçoit certificateName, le type, le CSR et, facultativement, validFrom ; le traitement est asynchrone et renvoie referenceNumber. La clé privée est créée avec le CSR : récupérer plus tard le certificat émis ne recrée jamais une clé perdue. Générez donc la paire dans le coffre cible, bloquez son export si possible et ne la sauvegardez que par une procédure contrôlée. Type 1 « Authentication » sert à l’authentification ; Type 2 « Offline » signe les codes de vérification de l’émetteur hors ligne et ne peut pas authentifier. Ils sont séparés et ne se combinent pas dans un certificat. Conservez referenceNumber, preuve d’approbation, empreinte, numéro de série et résultat d’installation ; ne journalisez jamais la clé privée.

Guide

Permissions côté serveur et tests négatifs dans chaque contexte

Fait officiel : KSeF évalue les permissions côté serveur ; posséder le certificat ne prouve donc pas le droit d’émettre, consulter ou administrer dans une entité donnée. Le métier définit les opérations attendues, puis l’intégration les teste dans chaque contexte. Un succès isolé ne valide pas les autres. Ajoutez des tests négatifs : émission sans droit, consultation interdite, contexte erroné et permission retirée. Le résultat attendu est un refus explicite, sans repli vers une autre société ni réutilisation silencieuse d’une session. Cela révèle les erreurs de routage d’un ERP multi-sociétés et les caches d’autorisation dangereux. Critères mesurables : 100 % des couples entité–opération de la matrice ont un résultat attendu et observé ; tous les cas sans droit sont refusés ; les journaux identifient propriétaire, contexte demandé, opération, décision serveur et corrélation technique sans exposer de secret. Toute divergence bloque la mise en production.

Guide

Déploiement, rotation, révocation et preuves : exemple réaliste

Fait officiel : un certificat est valable au maximum deux ans, mais sa date réelle doit être lue dans ses métadonnées. Exemple recommandé : un groupe exploite un ERP pour PL-Ventes et PL-Services avec deux charges de travail critiques. Avant le déploiement, IAM consulte /certificates/limits, obtient l’approbation des deux responsables KSeF, génère les clés dans deux emplacements séparés et enregistre les referenceNumber. Après émission, l’équipe rapproche /certificates/query avec l’inventaire, exécute les tests et conserve les preuves. Bien avant l’expiration, elle vérifie à nouveau la capacité, crée le remplacement, mène un chevauchement contrôlé, bascule, surveille les erreurs et révoque l’ancien certificat après validation. En cas de fuite ou de départ du dépositaire, le runbook prévoit suspension du flux, révocation, analyse des journaux et réémission. Critères mesurables : aucune clé hors coffre approuvé, alerte d’expiration testée, exercice de révocation chronométré, ancien numéro de série absent des connexions après clôture et inventaire réconcilié après chaque changement.

Guide

Critères fournisseur, erreurs fréquentes et prochaines actions

Exigez du fournisseur ERP ou intégrateur une démonstration, pas une promesse générale. Il doit appeler les limites en direct, préserver exactement les données d’enrôlement dans le CSR, gérer le traitement asynchrone par referenceNumber, distinguer strictement Type 1 et Type 2, stocker les clés sans export incontrôlé et afficher le contexte d’entité utilisé. Il doit aussi rapprocher /certificates/query, alerter sur l’expiration et prouver les refus. Refusez toute conception qui fixe une limite, place les droits dans le certificat, combine les deux types, prétend recréer la clé privée ou partage largement une clé de société. Prochaines actions : nommer les responsables IAM, métier et ERP ; dresser la matrice propriétaire–entité–flux ; lire les limites ; définir le nommage ; puis exécuter un pilote avec rotation et révocation. Acceptation mesurable : toutes les preuves sont exportables, chaque exception a un responsable et une échéance, zéro secret apparaît dans les tickets ou journaux, et aucun flux critique ne passe en production tant qu’un test de contexte échoue. Ces informations sont pratiques et ne constituent ni un avis juridique ni un conseil fiscal.

Checklist

Attribuer à chaque certificat un propriétaire juridique, un dépositaire opérationnel et un remplaçant nommé.

Cartographier chaque entité, charge de travail, opération KSeF et permission attendue avant de choisir la mutualisation.

Appeler GET /certificates/limits avant le déploiement et chaque rotation, sans enregistrer de plafond numérique en dur.

Définir une convention certificateName par environnement, entité interne, finalité, système et révision.

Générer la clé privée dans le coffre cible et recopier exactement les données d’enrôlement dans le CSR PKCS#10.

Utiliser une authentification signée/XAdES, et non un jeton système, pour obtenir les données d’enrôlement.

Créer séparément les certificats Type 1 d’authentification et Type 2 Offline selon leur usage réel.

Tester les autorisations et les refus dans chaque contexte d’entité prévu, puis archiver les résultats.

Réconcilier régulièrement /certificates/query avec l’inventaire par numéro de série, statut, type et expiration.

Répéter une rotation et une révocation de bout en bout, mesurer le délai et vérifier l’arrêt de l’ancien certificat.

Questions fréquentes

Combien de certificats KSeF peut-on détenir ?

Ne reprenez pas un nombre interne ou ancien. Appelez GET /certificates/limits : l’endpoint indique le maximum applicable, le nombre actif et si une nouvelle demande est possible. Vérifiez-le avant émission ou rotation et gardez une marge adaptée.

Un certificat peut-il servir pour plusieurs sociétés polonaises ?

Oui, si son propriétaire possède les permissions dans chaque contexte. Le certificat n’est attaché à aucune société et n’accorde aucun droit. Une séparation peut néanmoins limiter le rayon d’impact, isoler les rotations et clarifier l’exploitation ; documentez ce choix.

Faut-il un certificat par entité dans un ERP multi-sociétés ?

Ce n’est pas une règle officielle. Évaluez criticité, responsables, permissions, coffre, rotation et impact d’une compromission. La mutualisation réduit les objets ; la séparation facilite souvent isolement et révocation. Testez toujours chaque contexte indépendamment.

Comment nommer un certificat KSeF ?

KSeF exige certificateName sans prescrire de convention d’entreprise. Le format environnement–entité interne–finalité–système–année–révision est une recommandation. Le nom distingue l’usage sans secret, puis est rapproché du numéro de série via /certificates/query.

Qui est propriétaire d’un certificat de société ?

La personne morale en est propriétaire ; aucun employé particulier ne l’est. La société trace téléchargement, distribution, utilisation et révocation avec un dépositaire responsable. Un certificat personnel appartient à l’individu, seul autorisé à le demander, télécharger et utiliser.

Le certificat contient-il les droits KSeF ?

Non. Il authentifie son propriétaire ; KSeF contrôle les permissions côté serveur dans le contexte demandé. Un certificat valide peut recevoir un refus. La recette couvre les opérations autorisées et interdites dans chaque entité, notamment après retrait d’une permission.

Peut-on récupérer une clé privée perdue après l’émission ?

Non. La clé privée naît avec la paire et le CSR ; télécharger le certificat ne la reconstitue pas. Si elle est perdue ou compromise, révoquez et remplacez. Générez-la dès l’origine dans un coffre adapté à la charge de travail.

Quelle réserve prévoir pour la rotation ?

Il n’existe aucune réserve officielle universelle. Dimensionnez-la selon les flux critiques, remplacements simultanés et délais, puis vérifiez /certificates/limits avant chaque campagne. Prouvez qu’un nouveau certificat peut être émis avant le retrait de l’ancien.

Réglementation, formats et termes clés

Commission européenneEN 16931Directive 2014/55/UEfacture électronique structuréeLimites, nommage et gouvernance multi-entités 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.