E-Invoice Finder
Menu
Countries Compare software Deadlines Guides Checker Check obligation
ENFRDEPLNL
Poland · KSeF credential operations

KSeF certificate inventory, expiry monitoring and rotation

Inventory KSeF certificates, monitor expiry and rotate ERP credentials safely with overlap tests, owner evidence, rollback and controlled revocation.

Quick verdict:
  • Scope: manage each credential by system, purpose and accountable owner.
  • Risk: an unnoticed deadline or misplaced key can interrupt critical invoice flows.
  • Action: prove the replacement in production-like conditions before retiring its predecessor.
Get Poland readiness reportOfficial sources
Last checked: 2 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

Certificate lifecycle and outage risk

Treat a KSeF certificate as a time-limited identity credential, not as a permission record or a complete business identity. KSeF checks permissions server-side, so replacing a certificate does not itself grant an ERP, employee or service provider authority to act for a company. Operational failure usually occurs elsewhere: the certificate expires unnoticed, the private key is unavailable, a connector loads the wrong credential, or teams revoke the old certificate before the replacement is proven. Map the lifecycle from request and secure key generation through deployment, monitoring, replacement and final revocation. Assign a service owner for invoice continuity, a credential owner for issuance and custody, and an application owner for each deployment. Keep compromise response separate from routine expiry rotation: suspected key exposure calls for containment and rapid revocation decisions, while planned rotation can use a tested transition and rollback path.

Guide

Build and own the certificate inventory

Create one controlled register covering every production, contingency and test certificate used by the organization. Record a unique human-readable name, certificate serial number, Type 1 or Type 2, status, valid-from and expiry dates, legal entity or operating scope, environment, connector or device, technical deployment location, business service, issuer/request reference, and named business, security and technical owners. Add the change ticket, last successful test, next review date and replacement link. For example, “PL-ERP-PROD-AUTH-01” should map to the production ERP connector and its evidence, while “PL-OFFLINE-SIGN-01” maps to the controlled offline invoicing component. Never store the private key, passphrase or retrievable secret value in this register; point only to an approved secret-manager or HSM reference where suitable. Reconcile the register against official certificate query results and deployed configurations, with discrepancies assigned and dated rather than left as informal notes.

Guide

Official types, validity and status model

The Ministry distinguishes two separately issued certificate types. Type 1 Authentication is used to authenticate to KSeF. Type 2 Offline confirms issuer identity and invoice integrity for offline24, system-unavailability and emergency modes; it cannot authenticate an API session. Do not substitute one for the other or assume that rotating one automatically rotates the other. Ministry guidance says a KSeF certificate is valid for no longer than two years from its creation date or a taxpayer-selected valid-from date. The official API documentation describes POST /certificates/query for active and historic metadata, with filters including Active, Blocked, Revoked and Expired status, expiry, name, type and serial number. Use those records as a reconciliation source, not as proof that every application has loaded the correct private key. The certificate establishes identity; server-side permission checks remain a separate control that must also succeed.

Guide

Expiry monitoring and escalation

Calculate alert dates from each recorded expiry and the time your organization realistically needs to approve, issue, deploy and verify a replacement. The Ministry does not prescribe a universal alert window, so set internal thresholds according to system criticality, change freezes, owner availability and supplier lead time. A practical dashboard shows days remaining, type, service, owner, replacement status and blockers, with progressively stronger escalation to the application owner, finance operations, security and service management. Monitor both the official metadata and the credential actually configured in each workload; a new certificate in KSeF does not prove that an ERP is using it. Evidence should include dated query output or metadata, alert delivery, owner acknowledgement and ticket status. Test the alert route periodically, and define an exception process for certificates approaching expiry without a ready, tested successor.

Guide

Plan new-certificate enrollment and overlap

Rotation means requesting and deploying a new certificate; do not design around an invented renewal endpoint or assumed automatic renewal. Since February 2026, requests and downloads are available through the KSeF 2.0 API and Taxpayer Application. The documented API flow is to check GET /certificates/limits, obtain enrollment data with GET /certificates/enrollments/data, generate a PKCS#10 CSR and private key, submit the name, type, CSR and optional validFrom to POST /certificates/enrollments, poll GET /certificates/enrollments/{referenceNumber}, then retrieve through POST /certificates/retrieve. Generate and protect the key according to organizational policy, preferably with dual control for sensitive production issuance. Choose an internal overlap long enough to deploy, observe and roll back, but label it as an operational choice rather than a KSeF mandate. Confirm API limits, approvers, maintenance windows, vendor procedures and the exact old/new certificate mapping before starting.

Guide

Deploy and test Authentication rotation

For Type 1, stage the replacement in the ERP connector, middleware or integration platform without placing key material in source control, logs, chat or support tickets. Verify the certificate serial and intended environment at import, preserve the previous configuration for a controlled rollback, and use a change plan that identifies who can switch traffic. Test authentication first, then perform an authorized end-to-end KSeF operation representative of the service, such as opening the expected session and processing a controlled invoice flow. Confirm that server-side permissions produce the expected result; certificate success alone does not validate authorization. Capture timestamps, connector version, selected serial number, session outcome, representative transaction result and monitoring evidence, but redact secrets. Where multiple instances or regions exist, verify each one rather than assuming a configuration rollout reached the full fleet. Keep the old certificate available only for the approved transition period.

Guide

Deploy and test Offline rotation

Rotate Type 2 independently because its purpose and proof differ from API authentication. Install the new Offline certificate only in components that create or validate invoices under offline24, system-unavailability or emergency procedures. Use representative documents and verify that the issuer identity and invoice-integrity mechanism uses the expected new serial number. Then exercise the organization’s controlled return-to-KSeF process, including reconciliation and evidence capture, without claiming that the Type 2 certificate authenticated an API session. Test clocks, certificate validity at the relevant time, queue handling and all signing nodes or fallback devices. The owner should record which business scenarios were covered, who approved the result and where non-secret artifacts are retained. If the same platform handles online authentication and offline issuance, require explicit configuration labels and separate tests so Type 1 and Type 2 cannot be silently swapped.

Guide

Cutover, revocation, rollback evidence and common mistakes

Cut over only after success criteria are signed off: every target has the new credential, intended KSeF actions succeed, monitoring is clean and rollback has been rehearsed or directly inspected. Watch authentication failures, offline processing exceptions, queues and invoice outcomes after the switch. The owner may revoke the old certificate through POST /certificates/{certificateSerialNumber}/revoke; once revoked, it cannot be reused. Revoke after proof and the approved observation period, unless compromise requires a faster response. Retain the change record, approvals, non-secret certificate metadata, tests, observations, rollback decision and revocation result. Common mistakes include treating a certificate as a permission, rotating only one cluster node, logging a private key, assuming issuance equals deployment, using Type 2 for an API session, inventing automatic renewal, revoking too early, or leaving an old credential active indefinitely. If validation fails, restore the known-good configuration, protect invoice continuity and investigate before attempting another cutover.

Guide

Software decision criteria and next actions

Assess KSeF ERP connectors and certificate-management software against observable controls, not a generic “certificate supported” claim. Ask whether the product inventories serial, type, status, validity, owner and deployment; queries official metadata; alerts accountable teams; prevents secret exposure; supports secret managers or HSMs where appropriate; distinguishes Authentication from Offline workflows; handles multi-instance rollout; and produces exportable audit evidence. Require a demonstration of replacement, rollback, post-cutover monitoring and controlled revocation using your architecture. Clarify who generates and downloads keys, what vendor support can see, how failed deployments are recovered and how access is removed when staff or suppliers change. Next, reconcile the current estate, assign missing owners, rank certificates by expiry and service impact, open replacement tickets for the highest risks, and run one documented rotation rehearsal. Use a Poland readiness review if responsibilities, permission design or connector behavior remain unclear. These practices are operational guidance, not legal, tax or security advice.

Checklist

Reconcile every deployed KSeF credential with official query metadata and the owned register.

Assign business, application and credential owners with named escalation routes.

Record serial, type, status, validity, environment, service and deployment location without private keys.

Set risk-based expiry alerts and test that acknowledgements reach accountable teams.

Check certificate limits and obtain current enrollment data before creating the CSR.

Generate and store each new private key under approved custody and dual-control procedures.

Document the operational overlap, success criteria, maintenance window and rollback trigger.

Test Type 1 authentication, authorization and a representative connector transaction end to end.

Test Type 2 issuer identity and invoice integrity in each applicable offline operating mode.

Monitor the cutover, retain redacted evidence and revoke the predecessor only after approval.

FAQ

How long is a KSeF certificate valid?

The Polish Ministry of Finance says a KSeF certificate is valid for no longer than two years from creation or from a taxpayer-selected valid-from date. Record the actual dates returned for each certificate rather than projecting an expiry from a general rule.

Does KSeF automatically renew certificates?

Do not assume automatic renewal. Operationally, treat renewal as enrollment and deployment of a new certificate, followed by testing, observation and controlled retirement of the previous one. The official API documentation describes enrollment and retrieval, not an automatic renewal endpoint.

Does a new certificate carry the old certificate’s KSeF permissions?

A certificate carries identity, not KSeF permissions or company context. KSeF evaluates permissions server-side, so validate the relevant authorization separately when testing the replacement credential and connector workflow.

Can an Offline certificate authenticate an ERP API session?

No. Type 2 Offline is for confirming issuer identity and invoice integrity in offline24, system-unavailability and emergency modes. API authentication requires a separately issued Type 1 Authentication certificate.

How can we rotate without an invoice outage?

Prepare the replacement early, stage it securely, define an internal overlap and rollback plan, then test the intended end-to-end flow before retiring the predecessor. Verify every connector instance and monitor session, queue and invoice outcomes through the cutover.

When should the old certificate be revoked?

For planned expiry rotation, revoke after the new deployment has passed agreed tests and observation, subject to your risk policy. A compromise is different: contain exposure and assess prompt revocation rather than waiting for the routine overlap plan. Revocation is irreversible.

What belongs in a KSeF certificate register?

Include name, serial, type, status, validity, environment, service, deployment, entity or operating scope, owners, enrollment reference, test evidence and replacement relationship. Store only a secret-system reference, never the private key, passphrase or other recoverable secret.

Will KSeF tokens remain an alternative to certificates?

The Ministry’s current overview says tokens coexist with certificates from 1 February 2026, but only certificates remain from 1 January 2027. Confirm the latest official position when planning migration and ensure software can evidence which credential mechanism each workload actually uses.

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 inventory, expiry monitoring and rotation

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.