Poland · KSeF security incident

KSeF certificate compromise and revocation runbook

Contain a compromised KSeF private key, revoke the right certificate, investigate possible misuse and replace credentials safely across ERP integrations.

Quick verdict:
  • • Triage unit: correlate one serial number with its cryptographic purpose and every installation.
  • • Exposure breadth and missing telemetry determine residual risk after blocking.
  • • Restore service only from newly generated keys in verified deployments.
Last checked: 31 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

Triage the alert and set an appropriate severity

Start a time-stamped incident record and appoint an incident lead, a KSeF business owner and a technical owner. Recommended practice is to treat confirmed copying or public exposure of a production private key as high severity; credible access by an unauthorised person, malware on its host, an unexplained export or loss of a device holding it also warrants urgent containment. A false-positive scanner alert, an inaccessible backup or a certificate nearing expiry may justify investigation without immediately declaring misuse. Record what was observed, by whom, when, and whether the key could sign offline invoices or authenticate to KSeF. In the first 15 minutes, stop further distribution and preserve volatile evidence; within the first hour, identify the serial number, type and deployments, choose a clean authorised revocation route, and assess invoicing continuity. These are incident-response targets, not statutory KSeF deadlines. Do not delay a justified revocation merely to finish attribution, but do not revoke a look-alike certificate based only on a filename. Severity should reflect exposure confidence, privilege path, production use, duration, deployment breadth and signs of suspicious invoice activity.

Guide

Identify the exact certificate, type, owner and deployments

Build a one-line identity record before acting: certificate serial number, subject or owner, validity dates, Type 1 Authentication or Type 2 Offline, environment, legal entity, custodian and known locations. The certificate is an identity and authentication mechanism; it does not itself carry KSeF permissions or a company context. Access still depends on the identity and permissions involved. Type 1 authenticates an API session, while Type 2 supports issuer verification for invoices produced in offline24, system-unavailable or emergency modes and does not authenticate an API session. That distinction changes both exposure analysis and continuity planning. Query certificate metadata through the official POST /certificates/query endpoint where available and note whether status is Active, Blocked, Revoked or Expired. Reconcile this with the ERP, middleware, HSM or vault, CI/CD secrets, integration servers, disaster-recovery environment, laptops and integrator copies. The Ministry says certificates may be valid for no more than two years, but expiry is not a substitute for response. Ask each deployment owner to confirm use and last rotation; never infer the serial solely from a friendly alias.

Guide

Contain exposure and use a clean revocation path

Recommended containment is broader than the KSeF endpoint. Isolate affected hosts or workloads from networks where practical, suspend jobs that can use the secret, block further secret synchronisation and restrict administrator access. Preserve snapshots and logs before rebuilding. Do not copy the suspect private key into a new tool to inspect it, and do not submit the revocation from a possibly compromised workstation. Use a clean managed device and an authorised KSeF route, with a second person checking the serial and certificate type. CIRFMF documentation states that only the certificate owner can revoke it, for private-key compromise, end of use or organisational change. If the owner is unavailable, escalate through the organisation's documented identity and KSeF administration process rather than improvising with another person's credentials. The Ministry also says organisations distributing entity certificates must maintain accountability for download, handover, use and revocation; retrieve that custody record now. Isolate related tokens or API credentials for separate assessment rather than assuming certificate revocation contains them. Capture approval, exact request time, operator, serial, optional reason and response without placing private material in the ticket.

Guide

Understand revocation mechanics—and its limits

The official technical route is POST /certificates/{certificateSerialNumber}/revoke, using the certificate serial number and an optional reason. The official revocation procedure says a valid request automatically blocks the certificate in KSeF independently of publication on a certificate revocation list. Therefore, do not claim that a CRL publication delay leaves a valid revocation usable in KSeF. Confirm the API response, then query metadata and retain evidence of the changed state; if confirmation is ambiguous, escalate rather than repeatedly submitting requests. Once revoked, the certificate cannot be used again and a new certificate is required. Revocation does not remove the owner's KSeF permissions, invalidate their other certificates, establish whether the key was abused, or clean copied keys and configuration from systems. It also does not rotate tokens, passwords, vault access or integration credentials. Review permissions separately if the identity should lose access, and list every related secret for individual containment. Avoid revoking all certificates belonging to an owner unless the evidence supports that scope: an affected Type 2 certificate and an unaffected Type 1 certificate are separate credentials with different functions.

Guide

Investigate possible misuse and preserve evidence

Create a defensible timeline from the earliest plausible exposure to confirmed revocation or blocking. Preserve KSeF and application logs, API gateway records, vault audit events, operating-system and endpoint telemetry, deployment history, administrator actions, certificate distribution records, invoice queues and acknowledgements. Hash exported evidence, store it read-only and record who collected it. Search by certificate serial, owner identity, source address, client ID, workload, unusual time and invoice identifiers, while recognising that logging fields differ by architecture. Finance should compare submitted, accepted, rejected, corrected and offline invoices against ERP source records, customer and amount baselines, and expected operators. Security should inspect for key export, persistence, lateral movement and access to dependent secrets. An absence of anomalies in retained logs reduces but does not eliminate concern, especially where retention is short or attribution is incomplete. Preserve rejected requests too; they can reveal attempts. Decide whether legal, privacy, insurer, customer or law-enforcement escalation is needed under your organisation's rules and facts. This is recommended incident practice, not evidence that KSeF imposes a particular notification or response deadline.

Guide

Issue a clean replacement and deploy it in stages

Generate a new private key through a trusted process; do not reuse the old key, clone the compromised image or import suspect configuration wholesale. Request a new certificate of the required type and document its owner, serial, validity and approved purpose. Store the private key according to organisational security policy, preferably in controlled key storage that limits export, records access and supports separation of duties. Inventory-driven deployment is safer than a bulk search-and-replace: update one integration or signer at a time, verify the expected serial, then remove the old reference and residual copies from that component. Test Type 1 API authentication separately from Type 2 offline signing and issuer verification because success in one says nothing about the other. Start with a non-production or low-risk validation where the operating model allows, then canary a production connection, observe acknowledgements and expand. Prepare rollback to a known clean replacement configuration—not to the revoked key. Rotate vault credentials, service-account secrets, deployment tokens or administrator passwords when evidence shows they may share the exposure path. Finish by reconciling every inventory row as replaced, retired, unreachable or formally accepted risk.

Guide

Maintain continuity for authentication and offline certificates

The continuity plan depends on certificate function. If a Type 1 Authentication certificate is revoked, API sessions or integrations relying on it need another valid, authorised authentication method before automated submission resumes. Tokens remain usable alongside certificates from 1 February 2026 under current Ministry guidance, but certificates are the intended remaining method from 1 January 2027. Do not switch casually to an existing token: first identify its owner, permissions, storage, exposure relationship and planned retirement, then contain and rotate it if necessary. A separately controlled Type 1 certificate may provide cleaner continuity. For a compromised Type 2 Offline certificate, stop using it to mark or sign new offline24, system-unavailable or emergency invoices and deploy a replacement to each authorised offline issuer. That certificate cannot authenticate an API session, so replacing it will not restore an API login failure. Keep finance in control of queues: prevent duplicate submission, preserve original issue times and references, and reconcile acknowledgements when service resumes. Test a normal authentication transaction and an offline issuer-verification case independently before declaring recovery. Any temporary manual route should have named approval, transaction limits and end time.

Guide

Worked scenarios and common mistakes

Scenario one: an ERP integration host is infected and its Type 1 key is exportable. Isolate the host, identify the precise serial and owner, revoke through a clean authorised path, investigate API and invoice activity, generate a fresh key, rebuild the host and stage the new certificate. Review the owner's permissions separately; revocation alone does not remove them. Scenario two: a laptop used for emergency invoicing is lost with a Type 2 key. Revoke that serial, investigate custody and offline invoices, replace the offline certificate and validate issuer verification; do not expect this action to terminate API sessions. Scenario three: a public repository contains a certificate file but no confirmed private key. Preserve the commit and access history, determine whether private material or passwords were ever present, identify deployments and use risk-based containment; a certificate's public portion alone is not equivalent to private-key compromise. Common errors are revoking by alias, waiting for CRL publication, deleting logs during rebuild, reusing the old key, rotating only the ERP while leaving disaster-recovery copies, removing permissions instead of revoking, or assuming revocation proves that no fraudulent invoice was issued.

Guide

Choose stronger controls and close the incident

Use the incident to test whether software and operating controls reduce the next response time. Require a searchable inventory by serial, type, owner, entity, environment and deployment; non-exportable or tightly controlled key storage; role-based access and dual control for issuance and revocation; immutable audit logs; alerting on key access and certificate-state changes; tested rotation; independent handling of Type 1 and Type 2; and rapid product-specific support. Ask ERP and middleware vendors whether the serial is visible, whether certificate rollover can occur without stopping all invoicing, how concurrent old and new configurations behave, and whether offline signing can be tested separately. Prefer evidence from a demonstration and logs over a generic security claim. Assign unresolved actions to named owners in security, finance, tax, IT, procurement and the integrator, with risk-based internal dates rather than invented KSeF deadlines. Monitor authentication failures, certificate queries, invoice volumes, unusual counterparties and offline reconciliation after recovery. Close only when replacement coverage and residual-secret removal are verified, evidence is retained, continuity workarounds are withdrawn and leadership accepts any remaining uncertainty. Record lessons, update the custody process and rehearse revocation with certificate serials that cannot affect production.

Checklist

Open a time-stamped incident record and appoint incident, KSeF business and technical owners.

Record the exact serial, Type 1 or Type 2 function, owner, status and validity dates.

Map every ERP, middleware, vault, host, backup and integrator deployment of the key.

Isolate affected workloads and preserve logs, snapshots, queues and custody evidence.

Revoke the confirmed serial from a clean authorised path and retain the response.

Query certificate metadata to verify state, then assess permissions and other credentials separately.

Search KSeF, ERP, gateway and security records for suspicious access or invoice activity.

Generate a new key and certificate; never reuse the revoked key or suspect configuration.

Deploy by inventory and test API authentication and offline issuer verification independently.

Monitor recovery, remove temporary workarounds and complete a documented post-incident review.

FAQ

How do we revoke a KSeF certificate?

The official technical guide specifies POST /certificates/{certificateSerialNumber}/revoke with the exact serial number and an optional reason. Only the certificate owner can revoke it. Submit from a clean authorised path, retain the response and query certificate metadata to confirm the resulting state.

What happens after a KSeF certificate is revoked?

A valid revocation request automatically blocks it in KSeF independently of CRL publication, and the revoked certificate cannot be reused. You must generate a new key and obtain a new certificate where that function is still needed. Copied key files should still be located and removed.

Does certificate revocation remove the owner's KSeF permissions?

No. A certificate identifies or authenticates; it does not carry the owner's permissions or a company context. Review and change KSeF permissions separately when the person or identity should no longer have access, and assess other certificates held by that owner on their own evidence.

How does an Authentication certificate incident differ from an Offline certificate incident?

Type 1 Authentication can be used to authenticate an API session, so exposure may affect connected integrations. Type 2 Offline supports issuer verification for offline24, system-unavailable and emergency invoices; it does not authenticate API sessions. Investigation, replacement tests and continuity measures must match the type.

Does revocation prove that the private key was misused?

No. Revocation limits further use of that certificate but neither proves nor disproves earlier misuse. Establish the plausible exposure window and compare KSeF, ERP, gateway, vault and endpoint records with expected invoice activity, while documenting gaps in logging or retention.

Can we use a token while replacing a compromised certificate?

Possibly, but only after a separate risk assessment. Current guidance allows tokens alongside certificates from 1 February 2026, while certificates are intended to remain from 1 January 2027. Confirm the token's owner, permissions, storage and exposure, impose temporary limits, and plan its removal rather than treating it as automatically safe.

How can we rotate KSeF certificates without stopping invoicing?

Prepare an inventory, issue the correct replacement type from a new key, test outside the main production flow, and deploy in controlled stages with finance monitoring queues and acknowledgements. Use a separately trusted credential only where authorised. Never make the revoked key the rollback path, and guard against duplicate submissions.

Which certificate details should our ERP or credential tool expose?

At minimum, require serial number, certificate type, owner, validity, current environment, deployment locations and last rotation. Stronger tools add controlled key storage, access and change logs, alerting, dual approval, status checks, staged rollover and separate tests for API authentication and offline issuer verification.

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 compromise and emergency revocation

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.