KSeF token or KSeF certificate: which to use
A KSeF token is a string you paste into your software, which then logs in with no human involved. A KSeF certificate is a key file your software uses to sign the authentication request. The certificate is free, valid for up to two years, and is meant to be the target method. Under the Ministry of Finance's published materials the token works until 31 December 2026 — but that same ministry proposed in June 2026 that tokens stay permanently. Here are both versions of the facts, and what to do with them.
What a KSeF token is
You generate an authentication token in Aplikacja Podatnika (the taxpayer app) after logging in with a Trusted Profile, a qualified signature, or a qualified seal. You get a string that you see only once. Afterwards the system shows its description and status, never the value again.
Your software uses it like this: it fetches a one-time challenge from KSeF, encrypts a string made of the token plus a timestamp with the system's public key, sends that back, and receives a session access token in return. The whole exchange runs without a human, which is exactly why a token suits an integration that has to work overnight.
What that means in practice:
- The token is a key to your account. Whoever holds it acts on your behalf within the granted permissions, with no second factor in the way.
- The token belongs to a NIP and a set of permissions, not to the person at the keyboard. An employee leaving does not invalidate it; only revoking it in the taxpayer app does.
- You paste it once and the integration works. That is its biggest advantage.
One small thing breaks first connections surprisingly often: a token pasted with a trailing space or newline will not authenticate. What gets encrypted is exactly what you pasted, byte for byte, so an invisible tail from copying ends in a rejected authentication. If a token "doesn't work", check the edges of the pasted value before you generate a new one.
What a KSeF certificate is
The Ministry of Finance issues KSeF certificates free of charge, valid for up to two years. You obtain one in the taxpayer app after logging in with a qualified signature, a qualified seal, or a Trusted Profile. Certificates have been downloadable since 1 November 2025 and usable in production since 1 February 2026.
Certificate authentication works differently from a token. Your software fetches the challenge, builds the authentication request document, and signs it electronically in the XAdES format — an enveloped signature, embedded in that same document. KSeF verifies the signature and matches the certificate to the taxpayer either by the subject field, when a company certificate carries the NIP, or by the certificate's fingerprint, when it is a personal one.
A qualified signature authenticates over the same path: the wire format is identical, and all that differs is who issued the certificate and what you paid for it. So if your company already has a qualified signature, it already has a route into KSeF. The practical difference: a qualified signature usually lives on a card with a non-exportable key, while a KSeF certificate is downloaded together with its key, so you can put it on a server.
The private key cannot be recovered. Lose it and you request a new certificate.
Where to do this, per environment: https://ap.ksef.mf.gov.pl for production,
https://ap-test.ksef.mf.gov.pl for TEST (fictional data, throwaway),
https://ap-demo.ksef.mf.gov.pl for DEMO (real authentication, non-production data). The KSeF 1.0
addresses are dead, so if you landed on an older guide, check the host first.
Token vs certificate: the comparison
| KSeF token | KSeF certificate | |
|---|---|---|
| How you get it | Generate it in the taxpayer app after a Trusted Profile or signature login | Submit a request in the taxpayer app, from a signature-authenticated session |
| Cost | Free | Free |
| Validity | Today open-ended, until revoked. The Ministry's June 2026 proposal introduces a 1-to-365-day term | Up to 2 years, then you request a new one |
| How it authenticates | Encrypted token plus a timestamp | XAdES signature over the authentication request |
| Unattended use | Yes, one paste | Yes, if you hold the key file on your side |
| What it can do | Issue, fetch, batch and interactive sessions within its permissions | The same, plus submitting a request for another certificate |
| What it cannot do | Request a certificate. Sign KOD II | Nothing a token can do, but it does require key handling |
| Risk | A leak is full access, with no second factor | A leaked key is the same risk, but a certificate can be revoked and has an expiry date |
| Status per the Ministry | Rule: until 31 December 2026. Proposal: it stays | The target method |
The conclusion is less dramatic than the internet suggests: both methods do the same job. They differ in setup cost, in how you renew them, and in what happens to them a year from now.
Will tokens stop working on 31 December 2026?
You have to hold two facts in your head at once here, because they contradict each other.
Fact one: the rule on the books. The Ministry of Finance's materials still say that tokens will work until the end of 2026, that KSeF certificates are being introduced alongside them, and that from 1 January 2027 only certificates remain of the two. That is what the KSeF Q&A pages say, and what dozens of articles repeat.
Fact two: the ministry itself proposed reversing it. At the first consultation after the partial KSeF rollout, on 9 June 2026, summarised on 11 June 2026, the Ministry of Finance wrote:
Jedną z propozycji Ministerstwa Finansów jest utrzymanie tokenów jako jednej z metod logowania do KSeF. Z uwagi na zainteresowanie tym narzędziem, bezpieczeństwo jego użytkowania i wygodę w codziennej pracy, Ministerstwo Finansów zaproponowało, aby tokeny były dostępne również po 31 grudnia 2026 r.
("One of the Ministry of Finance's proposals is to keep tokens as one of the ways to log in to KSeF. Given the interest in this tool, the safety of using it and its convenience in everyday work, the Ministry of Finance proposed that tokens be available after 31 December 2026 as well.")
The same summary proposes two further changes: setting "a token validity term of 1 to 365 days", and a new permission that, "with the owner's prior consent", can renew a token automatically in the system.
This is a proposal, not law. There is no amending act, no regulation, and both the public
materials and the integrator documentation still carry the old cut-off date. That is precisely why
integrators are confused: the KSeF API documentation repository has an open question dated 17 July
2026 (issue 834 in CIRFMF/ksef-api) that sets the two sources side by side and asks outright
whether a decision has been made. As of this article, there is no answer.
What to do when nobody knows the date:
- Don't migrate in a panic. Nothing stops working tomorrow, and if the proposal goes through, tokens are here to stay.
- Don't assume it will go through either. Until the rule changes, plan for 31 December 2026 and keep a plan B.
- Arrange your way out in advance — because, as you will see next, a token cannot be traded in for a certificate.
- Follow the source, not the summaries. The consultation summary page and the consultation section on ksef.podatki.gov.pl are current. Guides around the web repeat the old version for months.
The trap: a token cannot request a certificate
The Ministry of Finance puts it plainly in the documentation:
Uwierzytelnienie przy użyciu tokena systemowego KSeF nie pozwala na złożenie wniosku o certyfikat.
("Authenticating with a KSeF system token does not allow you to submit a certificate request.")
A certificate request can only be submitted from a session authenticated with a signature. A token, however broad its permissions, does not open that path.
The consequence is simple and unpleasant. If your integration runs on a token today and a token is all you have, then there is no script, command or button that performs the switch for you. Somebody at the company has to open the taxpayer app, log in with a Trusted Profile, a qualified signature or a qualified seal, and request the certificate from that session.
That sounds trivial until it meets reality. A Trusted Profile belongs to a specific person, and that person may be on holiday, may have moved to another company, may be an external bookkeeper with no KSeF permissions. A qualified signature may be on a card locked in the owner's drawer. People discover this at the worst possible moment — when they need to switch in a hurry.
The way out, done early:
- Find out today who at the company holds a Trusted Profile or qualified signature and has KSeF permissions.
- Ask that person for one login to the taxpayer app and one certificate.
- Store the certificate and key somewhere safe, and put the expiry date in the calendar.
- Leave the token working. Nobody is forcing you to switch it off, and while it works it is your fallback.
Type Authentication is not type Offline
A common mistake. KSeF issues two disjoint certificate types:
- Authentication. This is what your software logs in with. It is what this whole guide is about.
- Offline, the certificate behind KOD II — the second QR code labelled "CERTYFIKAT" on an invoice issued in offline or offline24 mode. It attests the issuer's identity on a document that circulates outside the system before it gets a KSeF number.
No single certificate can combine both functions. They differ in key usage, and KSeF enforces that on its side. If you issue offline invoices you need both: Authentication to log in, Offline for the codes. The codes themselves are covered in the separate guide on QR codes on a KSeF invoice.
What to choose today
Our position: recommend the certificate, keep the token working. That is not a convenient dodge, it is what follows from the facts above.
The certificate's case: it is free, cryptographically stronger, has an expiry date (which enforces hygiene), and it is the method the ministry calls the target. The token's case: it is one paste instead of an expedition to get a Trusted Profile, and that difference decides whether anyone finishes connecting at all. On top of that sits the biggest point of all: the rule that was meant to end tokens is now being questioned by the ministry that wrote it. Ripping out token support would be a cost incurred for a rule that may never take effect.
In practice:
- Starting from scratch with a signature or Trusted Profile at hand? Get the certificate right away. Fifteen minutes buys you two years of quiet.
- Want to connect today, in minutes? Take the token and come back for a certificate in a calmer week. Just actually come back.
- Already have a qualified signature in the company? You can authenticate with it over the same XAdES path, but check whether the key is exportable. If it lives on a card, a KSeF certificate will be easier anyway.
- Issuing offline or offline24? An Offline-type certificate is coming for you regardless, so you are making the taxpayer-app trip either way. Do both in one sitting.
How KSeF Kit stores this
KSeF Kit supports both methods: the token, and XAdES signature login — the same path a KSeF certificate and a qualified signature use. You pick the method when connecting and can change it later.
Authentication material is encrypted at rest, separately per account. When you switch methods the unused material is discarded, so an old token never sits encrypted in a row nobody reads any more. One connection exists per environment, so you can keep TEST and production side by side without mixing them up at filing time. Before you file anything, the connection test performs a real login against the chosen environment, so bad material surfaces immediately rather than on your first invoice.
In the Stripe app edition the token does not live in our database at all: it goes to Stripe's Secret Store, and only the connection status stays with us. If you would rather keep everything in-house, see self-hosting.
Whichever you pick, the rule is the same: a token and a private key are secrets of the same weight as your banking password. Don't email them, don't paste them into a spreadsheet, don't leave them in shell history.