E-Invoice Finder
Menu
Countries Compare software Deadlines Guides Checker Check obligation
ENFRDEPLNL
Poland · 2026 access-control checklist

How to govern KSeF certificates, tokens and permissions

Control KSeF certificates, tokens and permissions with a practical 2026 checklist for software setup, rotation, offline invoicing and staff or vendor access.

Quick verdict:
  • Ban shared secrets from email, support tickets and implementation spreadsheets.
  • Treat a still-valid certificate as unsafe when ownership or custody changes.
  • Make rotation and offline recovery pass-or-fail release gates.
Get Poland readiness reportOfficial sources
Last checked: 25 July 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

1. Start with four separate control questions

Review KSeF access as four controls: identity, authentication, current permission and software capability. A certificate may authenticate successfully while the permissions register blocks an operation; a permitted user may still fail because the ERP cannot handle the credential securely. Map real workloads such as batch submission, Taxpayer Application use, accountant access and offline issuing. • Record the legal entity, environment, identity, method, owner and expected operations. • Scope shared services and vendors separately for every NIP. • Report certificate validity, permissions and tested software readiness as distinct statuses. • Check current Ministry material and refer legal or tax interpretation to an appropriate adviser.

Guide

2. Distinguish certificate, token and permissions

The Ministry of Finance describes a KSeF certificate as an authentication method. Type 1 proves identity for interactive or batch API use; effective rights are evaluated from the NIP or PESEL identity and KSeF permissions register, not embedded in the certificate. A token instead contains its declared permissions. Tokens may be used from 1 February 2026 but are due to disappear from 1 January 2027. • Inventory certificates, tokens and permissions separately. • Treat token migration as an integration change: establish suitable identity-based rights, test authentication and retire the token. • Do not read certificate possession as authority to perform every KSeF operation.

Guide

3. Choose Type 1 or Type 2 by the actual flow

Type 1 supports interactive and batch API authentication. Type 2 separately marks issuer identity for invoices produced in offline24, KSeF system-unavailability and emergency modes. One certificate cannot cover both types, so a business needing API access and offline issuance needs separate credentials. Offline readiness also requires suitable issuer-verification-link handling and a tested recovery process. • Match each certificate to its documented flow. • Store offline keys securely rather than on ordinary user devices. • Test that software rejects the wrong certificate type. • Rehearse offline creation, link handling, subsequent processing and evidence capture with synthetic invoices.

Guide

4. Assign identity, ownership and custody

A personal certificate can only be requested, downloaded and used by that individual. Do not copy it to a shared server for colleagues or a supplier. For a company certificate, name a business owner, technical custodian and approver for issuance, renewal and revocation. Record the NIP or PESEL identity and expected workload. Keep separate inventory, storage, permissions, logs and incident decisions for each NIP, even when one ERP or accountant serves several companies. • Never create a generic team identity by sharing a personal credential. • Define who may request, download, install, back up and revoke company certificates. • Require vendors to name authorised operators and an offboarding contact.

Guide

5. Build a least-privilege access matrix

Build the matrix around operations and identities rather than broad departments. Cover viewing, issuing, receiving, permission administration, integration support and offline work. Give each employee, accountant, vendor operator or service only the rights needed for an approved entity and workload. For example, an issuing integration should not automatically administer users, and help-desk staff should see redacted logs rather than secrets. • Record identity, entity, operation, reason, approver and review date. • Separate permission administration from invoice processing where practicable. • Time-limit temporary access and verify its removal. • Reconcile the matrix with the KSeF register and application roles. • Test a prohibited action to prove denial.

Guide

6. Control the full credential lifecycle

Keep one inventory with each credential's non-secret identifier, type, identity, entity, environment, workload, owner, custodian, storage location, issue and expiry dates, dependencies and status. Do not record the secret value. Certificates can be requested and downloaded through the KSeF 2.0 API or Taxpayer Application from February 2026 after suitable authentication, and their maximum validity is two years. Use a managed secret store, key vault, HSM or equivalent protection. Rotate before expiry: issue, install, test, cut over, observe and remove or revoke the predecessor. Review earlier after role changes, vendor exit or suspected exposure. • Alert owners before expiry. • Reconcile inventory with deployed systems. • Evidence permission withdrawal, revocation and application removal separately.

Guide

7. Run five acceptance scenarios and retain evidence

Test the production-intended design with synthetic records and retain the version, environment, non-secret certificate identifier, expected result, timestamp and reviewer. Request redacted traces, KSeF responses, configuration evidence and audit logs rather than screenshots alone. • Scenario 1 — Type 1: prove interactive and batch authentication with XAdES-BES, one allowed operation and one denied operation. • Scenario 2 — Permission change: remove a right while the certificate remains valid and confirm denial. • Scenario 3 — Rotation: install a replacement without source-code changes, cut over and confirm failure or removal of the predecessor. • Scenario 4 — Offline: use the appropriate Type 2 identity marker, issuer-verification link and documented recovery path for a synthetic invoice. • Scenario 5 — Offboarding and isolation: remove a test operator and prove it cannot act for the intended or a neighbouring NIP. Retain approvals, before-and-after permissions, signed-request results, denial events, invoice artefacts and administrator logs for the relevant scenario.

Guide

8. Avoid common mistakes and prepare incident response

Common failures include treating expiry as the only risk, assuming certificates contain permissions, sharing personal certificates, reusing one credential for both types, or hard-coding tokens. Never put a private key or token in email, tickets, source code or shared spreadsheets, and never copy production secrets into testing. For loss, disclosure or unexplained activity, contain the service, preserve logs, identify the identity and entities, review permissions, revoke the affected credential where appropriate, withdraw rights, reissue cleanly and retest. Examine affected submissions before restoring service. • Keep emergency contacts and revocation authority available. • Monitor failures, unusual times, unexpected NIPs and administrator changes. • Record each containment action without exposing secret values.

Guide

9. Set decision criteria and next actions

Approve only when identity, permissions, certificate types and ownership are documented for every flow. Software should prove Type 1 handling, XAdES-BES, secure installation, rotation, denial tests and useful logs. Where offline invoicing applies, require separate Type 2 and issuer-verification-link evidence. Ask vendors for a live scenario demonstration, supported key locations, audit samples, multi-entity controls and clear incident and offboarding duties. Next, appoint an owner, complete the inventory and matrix, remove shared credentials, schedule the five tests and plan token replacement before 1 January 2027. Recheck current official documentation before implementation. • Reject secrets in code or unmanaged files. • Record unresolved control gaps with a decision-maker and remediation date. • Sign off ‘valid’, ‘permitted’ and ‘tested’ separately.

Checklist

List every certificate and token by non-secret identifier, identity, entity, environment, workload and owner.

Map Type 1 requirements separately from Type 2 offline, unavailability and emergency requirements.

Reconcile approved access with the KSeF permissions register and each application’s local roles.

Remove shared personal credentials and assign accountable custody for company certificates.

Store private keys and tokens in approved protected facilities, never email, tickets, code or spreadsheets.

Set issuance approval, expiry alerts, rotation lead times, revocation authority and emergency contacts.

Test XAdES-BES authentication, an allowed operation and a denied operation in the intended software stack.

Prove offline issuer-verification-link handling and recovery with a separate Type 2 certificate where needed.

Withdraw KSeF rights, application access and deployed credentials during staff or vendor offboarding.

Replace remaining token integrations and retain tested evidence before token support ends on 1 January 2027.

FAQ

What is the difference between a KSeF certificate and a token?

A KSeF certificate authenticates an identity. With a Type 1 certificate, effective permissions are evaluated separately against the NIP or PESEL identity and the KSeF permissions register. A token instead contains the permissions declared for it. Official information says tokens may be used from 1 February 2026 but are due to disappear from 1 January 2027, so integrations should be migrated and retested rather than assuming the two methods behave identically.

Which KSeF certificate type do I need?

Use the intended flow to decide. Type 1 supports authentication for interactive and batch API sessions. Type 2 separately marks issuer identity for invoices produced in offline24, KSeF system-unavailability and emergency modes. One certificate cannot serve both types. An organisation operating both API and offline flows therefore needs separate credentials, ownership records, storage controls and acceptance tests.

Who can request and download a KSeF certificate?

From February 2026, certificates can be requested and downloaded through the KSeF 2.0 API or Taxpayer Application after suitable authentication. A personal certificate can only be requested, downloaded and used by that individual. Company certificates require an internal process that defines who is authorised to request them, who controls the private key, who approves deployment and who can revoke or replace them.

Does the two-year certificate validity guarantee continued KSeF access?

No. Two years is the maximum certificate validity, not a guarantee that current access will continue for that period. Permissions linked to the authenticated identity may change, a certificate may be revoked, application access may be disabled, or software may cease to handle the credential correctly. Track expiry, permissions and technical readiness as separate controls and test again after material changes.

Where should KSeF private keys and tokens be stored?

Use an organisation-approved secret store, key vault, HSM or equivalent protected facility appropriate to the application and risk. Restrict access, prevent export where practicable, log use and keep production material out of developer laptops and test systems. Never paste a private key or token into source code, email, support tickets or shared spreadsheets. Inventory metadata should identify the secret’s managed location without copying its value.

How should employee, accountant and software-vendor access be managed?

Assign rights to identified people or controlled services for named entities and operations, with a business owner and approver. Avoid shared personal certificates and do not give a vendor broad administrative rights merely for convenience. Time-limit temporary access, separate invoice work from permission administration where practicable, review the KSeF register against contracts and application roles, and require evidence that access cannot cross into another client or group entity.

What should happen when an employee leaves or a provider contract ends?

Trigger offboarding from the agreed end time, not from the next periodic review. Withdraw relevant KSeF permissions, disable local and vendor accounts, remove deployed credentials, revoke or replace affected certificates or tokens where custody or exposure warrants it, and check recent logs. Confirm the result with a denied-access test and record who completed each step. Preserve required business evidence, but do not retain secret copies.

What proof should a KSeF software demo provide for API and offline use?

For API use, require successful Type 1 authentication, XAdES-BES evidence, an authorised operation, a deliberately denied operation, redacted request traces and useful audit logs. Also test certificate replacement without embedding a new key in code. If offline invoicing is in scope, require a separate Type 2 flow, issuer-verification-link handling and recovery evidence for a synthetic invoice. Tie every result to the proposed software version, environment and responsibility model.

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 tradePoland KSeF certificate, token and permissions governance checklist

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.