E-Invoice Finder
Menu
Countries Compare software Deadlines Guides Checker Check obligation
ENFRDEPLNL
Poland · certificate architecture and governance

KSeF certificate limits, naming and multi-entity ownership

Design KSeF certificates across companies and ERP workloads: live limits, ownership, naming, context permissions, key custody and acceptance tests.

Quick verdict:
  • • Scope credentials by operational consequence, not certificate count alone.
  • • Untracked key distribution turns targeted revocation into a group-wide incident.
  • • Start by reconciling serials, custodians and expiry dates against the owner inventory.
Get Poland readiness reportOfficial sources
Last checked: 5 August 2026Based on official sourcesClear summaryBusiness guidance, not legal advice
Official sources prioritized
Last-checked dates visible
Free checker, no signup required

What you need to know

Guide

Identity versus entity context

Officially, a KSeF certificate carries its authenticated owner's identity. It contains no KSeF permissions and is not assigned to a company context; KSeF evaluates permissions server-side for the context requested. The same certificate may therefore work across entities where its owner is authorized and fail elsewhere. Certificate-management endpoints concern the authenticated owner and expose that owner's same certificate set regardless of login context. As a recommended governance control, document credential owner separately from legal entity, workload and granted role. IAM should approve the context map, while finance confirms entity scope. Acceptance means every inventory record names one authenticated owner, every intended context has separate permission evidence, and no architecture diagram suggests that possession of the credential grants company access.

Guide

Live limit discovery and capacity headroom

The official technical guide recommends GET /certificates/limits before enrollment. It returns the maximum certificates the owner may hold, current active count and whether another request may be submitted. Treat this live response as authoritative; never hard-code a number because limits can change and apply to the authenticated owner. The platform owner should retain a timestamped response before rollout and rotation. Reserving capacity for replacement is a practical governance control, not a KSeF rule: express internal headroom as a policy variable. Acceptance requires a fresh successful call, evidence that submission is allowed and documented capacity for the next planned rotation. If submission is unavailable, stop automation, reconcile inventory and escalate rather than repeatedly retrying or deleting an active credential without an approved impact assessment.

Guide

Company versus person ownership model

Official guidance distinguishes company certificates issued to a legal entity from person certificates belonging to an individual. A company certificate is not tied to one employee; the company must record its download, distribution, use and revocation. A legal entity may request multiple company certificates, subject to live limits. A person certificate belongs to that individual, and only that person may request, download and use it. The models produce different attribution in KSeF. Recommended governance should name an accountable company custodian without treating that employee as the credential owner. Avoid broad, uncontrolled sharing; authorize named workloads and log every key handoff. Never transfer a person credential. Acceptance requires ownership type, authenticated owner, custodian, approved systems, key location, distribution log and revocation contact for every credential.

Guide

Practical certificate naming and inventory convention

POST /certificates/enrollments requires certificateName, type and CSR, with optional validFrom. The name later appears in metadata and can be found through POST /certificates/query with status, expiry, type and serial. Official guidance prescribes no enterprise naming convention; a pattern is a recommended governance control. Use a purpose-specific, non-secret name such as PL01-PROD-ERP-AR-2026R1, combining entity or portfolio, environment, workload, purpose and rotation generation. Do not include personal data, passwords or key locations. For a credential spanning entities, use a neutral portfolio code and keep the context list in controlled inventory. The service owner should enforce uniqueness. Acceptance means query results match one inventory row by name and serial, with owner, type, environments, contexts, workload, custodian, validity, status and replacement reference recorded.

Guide

Multi-entity and workload architecture decision criteria

One owner credential may span company contexts where KSeF grants that owner the required permissions, but it is not a group-wide authorization token. Choose sharing or separation by scoring blast radius, key distribution, attribution, outage coupling, supplier boundaries, rotation cadence and live capacity. A centralized ERP service with uniform custody may justify one credential across permitted entities; separate vendors, environments or high-risk workloads often favor separate certificates. Separation can narrow exposure from a stolen key, enable targeted revocation and decouple change windows, although authorization remains server-side. Keep production and test secrets separate. The architecture owner should approve an owner, entity, workload, environment and certificate matrix. Acceptance requires a written rationale for each shared credential, named permitted systems, demonstrated isolation from excluded workloads and a feasible rotation path under current limits.

Guide

Enrollment, CSR and private-key workflow

A request is made only in the applicant's own name. Authenticate with a signed/XAdES method and call GET /certificates/enrollments/data; system-token authentication cannot obtain enrollment data. Copy the returned values exactly into the PKCS#10 CSR. Generate the private key with the CSR inside approved storage, then submit certificateName, type, CSR and optional validFrom to POST /certificates/enrollments. Processing is asynchronous and returns referenceNumber, which operations must retain and monitor. Type 1 Authentication and Type 2 Offline are separate and cannot be combined: Type 1 authenticates, while Type 2 signs offline issuer-verification codes and cannot authenticate. Certificates are valid no more than two years. Retrieving an issued certificate cannot recreate a lost private key. Acceptance includes exact CSR comparison, protected key generation, retained reference, confirmed type, successful retrieval and a recovery test that never assumes KSeF stores the private key.

Guide

Server-side permissions and negative context tests

KSeF checks authorization server-side after a certificate establishes owner identity. A valid credential may authenticate yet receive a permission denial for an entity or operation; treat that as an expected boundary, not a certificate defect. For every intended context, execute a representative ERP operation with the intended Type 1 credential and preserve owner, context, result and timestamp. Also test one excluded entity and one disallowed operation; both must be denied and logged without exposing key material. Repeat after permission changes. Test Type 2 only for offline issuer-code signing, and require authentication attempts with it to fail. IAM signs off permissions, ERP owns technical handling and finance validates entity choice. Acceptance is 100% success for approved cases, 100% denial for excluded cases and alerts that distinguish authentication failure from authorization denial.

Guide

Rollout, rotation and revocation evidence

Make rollout an evidence-producing change: capture live limits, approve the matrix, enroll the correct type, reconcile issuance through /certificates/query and validate custody. For example, a group runs centralized receivables for PL01 and PL02 plus a separate PL02 warehouse. One Type 1 certificate may serve receivables in both permitted contexts, while a separate warehouse certificate limits blast radius and supports independent revocation. Inventory should record names, serials, status, expiry, owners, custodians, contexts and replacement links. During rotation, allow an approved overlap, test both entities with the new key, switch traffic, prove the old serial is unused, revoke it and retain query evidence. If custody is uncertain, follow the incident revocation runbook; retrieval cannot restore a lost key. Acceptance requires complete reconciliation, expiry monitoring, tested rollback, revocation proof and zero traffic on the retired serial after cutoff.

Guide

Supplier acceptance criteria, mistakes and next actions

Require an ERP supplier to demonstrate owner-aware certificate management. It should show live /certificates/limits handling without a hard-coded cap, asynchronous reference tracking, /certificates/query reconciliation, separate Type 1 and Type 2 paths, protected key use, context selection, permission-denial handling and serial-level logs. Common mistakes include assuming a credential carries company access, binding the owner certificate list to login context, combining types, using system-token authentication for enrollment data, changing CSR values, uncontrolled company-key sharing, transferring a person credential and rotating without headroom. Next, appoint a service owner, build the matrix and inventory, query capacity, choose the ownership model and run a pilot. Acceptance requires expected outcomes for every approved and denied case, actionable API errors, no private key in logs or exports, evidence of one rotation and revocation, and disclosure of manual steps. Practical information only, not legal or tax advice.

Checklist

Assign one accountable service owner and record the authenticated owner and custodian for every certificate.

Build an owner, entity, workload, environment and permission matrix before selecting a sharing model.

Call GET /certificates/limits immediately before enrollment or rotation and retain the timestamped response.

Set an internal headroom policy based on live capacity and the next replacement need, never a hard-coded KSeF limit.

Adopt purpose-specific certificate names and reconcile each name and serial through POST /certificates/query.

Use signed/XAdES authentication to obtain enrollment data and copy every returned value exactly into the CSR.

Generate and protect the private key with the CSR; test recovery without assuming KSeF can recreate a lost key.

Keep Type 1 Authentication and Type 2 Offline certificates separate in issuance, storage and test paths.

Prove approved contexts succeed and excluded entities and operations are denied by server-side permission checks.

Capture rotation, cutoff, zero-use and revocation evidence, then reconcile the complete owner inventory again.

FAQ

How many KSeF certificates can a company have?

Do not rely on a fixed number. The official GET /certificates/limits endpoint returns the authenticated owner's current maximum, active count and whether another request may be submitted. Query it before enrollment and rotation, retain the response and plan internal headroom around live capacity. A legal entity may request multiple company certificates, subject to those current limits.

Can one KSeF certificate work for multiple companies?

Yes, one certificate can be used in different entity contexts where its authenticated owner has the necessary KSeF permission. The certificate is not assigned to a company context and carries no permissions itself. Sharing may reduce administration, but separate certificates can reduce blast radius, simplify targeted revocation and decouple suppliers or workloads; document the decision for each case.

Should each ERP company or workload have its own certificate?

Not automatically. Score key custody, distribution, attribution, outage coupling, rotation windows, supplier separation and available capacity. A centrally controlled workload may safely span permitted contexts, while isolated vendors or sensitive functions may warrant distinct credentials. Whatever model you choose, keep entity permissions explicit and test both allowed and denied contexts.

Does a KSeF certificate contain or grant permissions?

No. Officially, it identifies the authenticated owner; KSeF checks that owner's permissions server-side for the selected context and operation. Installing a valid certificate therefore does not authorize every company. Maintain permission evidence separately, handle authorization denial distinctly from authentication failure and retest after any permission change.

How should we name KSeF certificates?

KSeF requires certificateName, and the name appears in metadata searchable through /certificates/query, but official guidance does not mandate an enterprise convention. A useful governance pattern combines a non-secret portfolio or entity code, environment, workload, purpose and rotation generation. Keep the authoritative context list and owner details in inventory, not solely in the name.

Who owns and may use company and person certificates?

A company certificate is issued to the legal entity and is not tied to one employee; the company must control download, distribution, use and revocation. A named custodian may operate that control but does not become the credential owner. A person certificate belongs to that individual, and only that person may request, download and use it.

Can one certificate be both Type 1 and Type 2?

No. Type 1 Authentication and Type 2 Offline are separate and cannot be combined. Type 1 is used to authenticate to KSeF. Type 2 signs offline issuer-verification codes and cannot authenticate. Issue, label, store and test each type separately so an offline-signing credential is never treated as an authentication credential.

What must happen if the private key is lost or a certificate approaches expiry?

The private key is created with the CSR, and downloading the issued certificate cannot recreate a lost key. Follow the incident or rotation runbook: check live limits, enroll a replacement with a newly protected key, test all approved contexts, cut over, verify the old serial is unused and revoke when appropriate. KSeF certificates are valid for no more than two years.

Key regulations, formats and terms

PolandKSeFKrajowy System e-FakturPolish Ministry of Financepodatki.gov.plstructured invoiceAPI authenticationinvoice correctionsaccounting softwareVATSMEecommerceEuropean CommissioneInvoicingEN 16931Directive 2014/55/EUstructured electronic invoiceVAT automationcross-border tradeKSeF certificate limits, naming and multi-entity ownership

Poland — Country hub

Poland

Open country hub →

Use the country hub to see every related deadline, checklist, format guide and software comparison for this market.

Continue reading

Official sources

We prioritize official government and EU sources where available and keep last-checked dates visible for mandate-sensitive pages.