Poland · certificate custody and vendor risk

KSeF certificate private-key custody and provider handover

Decide who controls KSeF certificate private keys, audit ERP provider access, and build a safe onboarding and exit handover.

Quick verdict:
  • Scope: map every certificate, associated key, permitted operator, workload and legal entity before choosing custody.
  • Largest risk: an uncontrolled exportable key can let an authorised holder act under the organisation’s identity without useful accountability.
  • First action: require a documented key-generation ceremony and evidence showing where the key resides and whether it can be exported.
Last checked: 10 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

1. Start with the custody decision and threat model

Treat custody as a control, evidence and recovery decision. Map every legal entity, workload, environment and person or service needing authentication. Model key copying, support-bundle leakage, staff departure, vault failure and abrupt provider exit; assign detection, containment and recovery. Official fact: a KSeF certificate carries identity, not permissions, which KSeF checks server-side. Recommended control: separate business authority, technical custody and monitoring, with dual approval for export or recovery. Provider, customer or shared custody may be appropriate when evidence matches risk. Do not make a personal certificate a shared integration credential: official guidance restricts its download and use to that person.

Guide

2. Separate the certificate, private key and permissions

A certificate is issued against a certificate signing request (CSR). The CSR contains the public key; its associated private key is generated with the CSR, is required for signing and should be secured under organisational policy. KSeF does not send or download that private key. Official documentation permits RSA 2048 or EC NIST P-256 and recommends EC. Authentication and Offline are separate types and cannot be combined. Authentication supports API authentication; commercial software needs KSeF certificate functionality including XAdES-BES. Offline supports QR issuer verification and cannot authenticate. Certificates last no more than two years. Application and download have been available through KSeF API 2.0 and the Taxpayer Application since February 2026.

Guide

3. Compare three operating models before selecting custody

Customer-held custody keeps the key in customer infrastructure and lets the ERP request signing; it limits provider possession but puts availability and recovery on the customer. Provider-held custody simplifies managed operation but demands tenant isolation, administrator controls, logs and exit terms. Shared control uses a customer-selected HSM, KMS or vault with narrow provider access, balancing oversight and serviceability. Compare exportability, administrator reach, entity isolation, availability, recovery time, log quality, revocation capability and exit effort. Official guidance allows company-certificate distribution while making the company responsible for accountability around download, transfer, use and revocation; it does not prescribe a commercial model. Score each option against the threat model and document residual risk.

Guide

4. Build a secure lifecycle from CSR generation to routine use

Approve the entity, certificate type, purpose, environment, owner and expiry first. Generate the key in its intended protected boundary where feasible, create the CSR there and submit only the CSR. Bind the issued certificate to the key, test its Authentication or Offline purpose, and inventory the certificate, workload and custodian. Recommended safeguards include non-exportable keys, HSM/KMS/vault storage, dual control, access logs and protected recovery material. These are risk-based recommendations, not explicit statutory KSeF requirements. Never email keys or attach them to tickets. If export is unavoidable, approve it, restrict recipients, use a secure channel and delete temporary copies. Rehearse rotation before expiry and prove recovery meets its target.

Guide

5. Demand due-diligence evidence and a usable contract/RACI

Ask for evidence, not “keys are encrypted.” Request key-boundary and tenant diagrams, XAdES-BES support, generation/deletion procedures, export settings, privileged-access approvals, customer-specific signing logs, assurance summaries, recovery tests, incident commitments and subcontractor roles. Redacted evidence should still prove operation. The contract and RACI should assign request, CSR/key generation, use approval, KSeF permission administration, monitoring, rotation, revocation, incident response and exit deletion. Define response/recovery targets, log retention, emergency contacts and evidence rights. Escrow and continuity terms are recommended commercial controls, not statutory KSeF requirements. Reject “vendor manages certificates” unless it explains exportability, administrator access, action attribution and emergency authority.

Guide

6. Control onboarding and provider-change handover

At onboarding, verify entity and type, approve custody, conduct the CSR ceremony, inventory the result and test an authorised flow with logs. Do not transfer a key merely because a form requests one; consider remote signing or controlled vault access. Record any company-certificate distribution, recipient, purpose, method and revocation owner. At provider change, prefer a new key and certificate. Limit overlap, prove successor continuity, disable old integration, revoke the old certificate when appropriate, remove obsolete permissions separately and obtain provider/subcontractor deletion evidence. An “exit certificate” is a recommended deletion attestation, not an official KSeF certificate type. Acceptance requires successful successor authentication, failed incumbent access, preserved audit history and controlled rollback.

Guide

7. Prepare incident response without confusing revocation and permissions

Official MCU guidance says certificate access deserves bank-credential-level care and warns that a holder may act in the company’s name. Prepare for suspected copying, unauthorised signing, lost personal custody, provider compromise and vault outage. Preserve evidence, identify affected workloads, restrict use, inspect activity and decide whether to revoke and replace. Revocation does not automatically remove KSeF permissions: the certificate carries identity while KSeF checks permissions server-side. Permission removal likewise does not prove revocation or destruction of key copies. Execute both paths when needed. Record the timeline, logs, affected entities, containment and replacement ceremony. Test primary-vault failure and an unreachable provider against measurable containment and recovery targets.

Guide

8. Implement with measurable acceptance tests and avoid common mistakes

Implement in stages: inventory keys and certificates; classify Authentication versus Offline use; choose custody per workload; close RACI and contract gaps; rotate uncontrolled credentials; then test recovery and exit. Authentication must work from the authorised workload with XAdES-BES and fail elsewhere. Export testing must prove non-exportability or document an exception. Logs must identify actor and approver. Recovery must meet its target without exposing key material. Exit must remove incumbent access while preserving continuity. Avoid treating possession as permission, sharing personal certificates, authenticating with Offline certificates, assuming KSeF supplies the key, emailing keys, retaining unknown copies, rotating without testing or revoking without reviewing permissions. This is practical information, not legal, tax or cybersecurity advice; confirm the model with responsible specialists.

Guide

Practical question summary

For KSeF certificate and private-key custody for ERP providers: Most KSeF questions are about who must use the system, whether current accounting software is ready, how authentication works, how corrections are handled, whether ecommerce or ERP needs API integration, and how accountants access invoice data. This guide focuses on those operational decisions.

Guide

Decision framework for businesses

For KSeF certificate and private-key custody for ERP providers: A KSeF-ready workflow should show who creates invoices, who submits them, who monitors status, who handles rejection or correction, how invoices are archived and how the accountant sees the records.

Guide

How to use this guide

Use this guide to decide whether KSeF certificate and private-key custody for ERP providers affects your Poland workflow and which evidence is still missing. Start with KSeF authentication, structured invoice submission, invoice status handling, then test submit a KSeF invoice and simulate an API rejection before comparing software.

Guide

Data and terms to prepare

For KSeF certificate and private-key custody for ERP providers, the important terms are KSeF certificate and private-key custody for ERP providers, Poland, KSeF authentication, structured invoice submission, invoice status handling, corrections and rejections, accounting or ecommerce integration. Clean these fields in customer, supplier, tax and accounting records before rollout; otherwise validation and support issues appear during daily invoicing.

Guide

Software proof to request

For KSeF certificate and private-key custody for ERP providers, ask vendors to show show KSeF authentication, submission status, corrections, permissions and accounting export using your examples. The demo should cover submit a KSeF invoice, simulate an API rejection, create a correction, verify user permissions and explain who handles errors, corrections, archive access and accountant handoff for KSeF authentication, structured invoice submission, invoice status handling.

Guide

Evidence before rollout

Keep official links, screenshots, test invoices and the decision reason for KSeF certificate and private-key custody for ERP providers. For KSeF certificate and private-key custody for ERP providers, the implementation file should prove how KSeF authentication, structured invoice submission, invoice status handling, corrections and rejections were checked, not just that a tool was selected.

Guide

Decision checkpoint

Do not close KSeF certificate and private-key custody for ERP providers until someone can explain KSeF certificate and private-key custody for ERP providers in Poland, name the workflow owner, show one tested invoice scenario and describe how the team avoids choosing software for Poland before proving the real KSeF certificate and private-key custody for ERP providers workflow.

Checklist

Inventory every KSeF certificate, private-key location, legal entity, workload, type, owner and expiry date.

Document who generates each key pair and retain evidence that KSeF receives the CSR, not the private key.

Confirm whether each key is exportable and approve any exception with a recorded business justification.

Verify Authentication and Offline certificates are separated and used only for their intended functions.

Obtain provider evidence for tenant isolation, privileged access, logging, backup, restore and secure deletion.

Assign request, custody, permission, monitoring, rotation, revocation and incident duties in a signed RACI.

Test XAdES-BES authentication from the authorised workload and rejection from an unauthorised workload.

Set rotation alerts and rehearse replacement before the certificate’s maximum two-year lifetime expires.

Prepare a provider-exit runbook using a new key, controlled overlap, old-access removal and deletion evidence.

Exercise compromise and vault-outage scenarios against measurable containment and recovery targets.

FAQ

Who should generate and hold the KSeF private key?

Choose the party and technical boundary that fit the threat model, service needs and internal capability. Generate the key where it will be protected and used where feasible, exporting only the CSR. Customer, provider or shared custody can work when access, evidence, recovery and exit are explicit.

May an ERP provider hold a company certificate’s private key?

There is no blanket answer for every arrangement. Official guidance allows company-certificate distribution while assigning the company accountability for download, transfer, use and revocation. Evaluate provider custody through technical evidence, contractual duties, tenant isolation, administrator controls and tested exit arrangements.

Can a KSeF private key be exported?

Exportability depends on generation and storage, not KSeF issuance. Software stores may allow export; HSM/KMS/vault configurations can prevent it. Prefer non-exportability where practical. Treat any necessary export as an approved, logged exception and use a secure transfer channel—not email or tickets.

What evidence should a customer request from its ERP provider?

Request key-boundary diagrams, generation/deletion procedures, export settings, privileged-access controls, sample signing logs, assurance summaries, recovery-test results, incident commitments, subcontractor details and XAdES-BES implementation evidence. The package should demonstrate operating controls rather than repeat policy claims.

What should happen to keys when changing KSeF providers?

Prefer a new key and certificate for the successor. Prove the new flow, limit overlap, disable incumbent integration, consider revocation, remove obsolete permissions separately and obtain deletion evidence from the outgoing provider and subcontractors. Preserve audit records and reconcile inventories.

Does revoking a KSeF certificate remove KSeF permissions?

No automatic equivalence should be assumed. The certificate carries identity, while KSeF checks permissions server-side. Revocation and permission removal are distinct actions and may both be required. Permission changes also do not prove key copies were destroyed.

How should backup and incident recovery be tested?

Set measurable recovery and containment targets. Test authorised signing restoration, retained key protection and auditability, blocked unauthorised use and emergency replacement. Include provider unavailability, suspected copying and primary-vault outage; record results and remediate failures.

Can one KSeF certificate support both API authentication and Offline QR verification?

No. Authentication and Offline are separate types and cannot be combined in one certificate. Authentication supports API authentication, including XAdES-BES functionality in commercial software. Offline is for QR issuer verification and cannot authenticate to KSeF.

What do businesses usually ask about KSeF?

For KSeF certificate and private-key custody for ERP providers: They ask about software readiness, API integration, authentication, corrections, accountant access and ecommerce workflows.

What is the most practical KSeF risk?

For KSeF certificate and private-key custody for ERP providers: The practical risk is late discovery that permissions, corrections or invoice status handling do not match the business process.

What should I test first for KSeF certificate and private-key custody for ERP providers?

For KSeF certificate and private-key custody for ERP providers, start with submit a KSeF invoice, simulate an API rejection, create a correction because those scenarios reveal whether the workflow is practical.

What is the main risk for KSeF certificate and private-key custody for ERP providers?

The main risk is choosing software for Poland before proving the real KSeF certificate and private-key custody for ERP providers workflow.

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 and private-key custody for ERP providers

Poland — Country hub

Continue reading

Official sources

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