KSeF Certificate vs Token: Why We Built Biurko on Certificates
A token carries permissions inside it. A certificate proves identity and nothing else. You cannot add the second offline QR code (KOD II) with a token, and you cannot even request a certificate while authenticated with one. In June 2026 Poland's Ministry of Finance proposed keeping tokens permanently. Our decision has not changed, and here is why.

When we designed the authentication layer for Biurko in 2025, there were two roads. The easy one: paste a token, store it, ship a working KSeF integration in a week. The hard one: build full KSeF certificate support, including XAdES-BES signing, private key storage, and expiry tracking.
We took the hard road. It cost us several weeks and one instructive failure against the Ministry's KSeF demonstration service, which I will get to.
Quick context for readers outside Poland. KSeF (Krajowy System e-Faktur) is Poland's mandatory national e-invoicing system. Every VAT invoice between businesses goes through it. This is not tax advice; I am a SaaS founder, not a tax adviser. This is a record of an engineering decision.
A token and a certificate are not two flavours of the same thing
The common assumption is that these are simply two login options and you pick whichever is more convenient. That is not what they are.
The Ministry of Finance draws the line clearly: a token carries the taxpayer's permissions, declared at the moment it is generated. A KSeF certificate is purely a means of authentication, comparable to a qualified electronic signature, and carries no permissions at all (KSeF certificates, ksef.podatki.gov.pl).
| Token | KSeF certificate | |
|---|---|---|
| What it is | an alphanumeric string | a key pair plus a certificate issued by the Ministry |
| Permissions | baked in at generation | resolved by KSeF after login |
| Validity | until 31 Dec 2026 under current rules (the Ministry has proposed keeping them) | up to 2 years |
| Offline invoicing | not supported | an Offline-type certificate is needed for the second QR code (KOD II) |
| Requesting a certificate | not possible | possible |
| Security model | bearer secret | private key plus XAdES-BES signature |
That last row is the whole argument. A token behaves like a password: whoever holds it is you. A certificate behaves like a signature: KSeF issues a challenge, you sign it with a private key, and the key never travels.
Four reasons we never shipped token support
1. The private key never has to leave our system. A token must be handed to KSeF on every session open. A certificate does not; the challenge is signed locally. If you are running a SaaS holding credentials for hundreds of companies, that is not a cosmetic difference.
2. The Offline-type certificate is needed anyway. Adding the second QR code (KOD II) to an invoice issued in offline mode requires a separate KSeF certificate of the Offline type. The two types are generated independently and are distinguished by an "uwierzytelnianie" (authentication) or "offline" note in the CN attribute (ksef.podatki.gov.pl). If we have to handle certificates for offline mode regardless, maintaining a parallel token path is duplicated work.
3. A token cannot request a certificate. Authenticating with a token does not let you apply for a KSeF certificate. Build your entire process on tokens and you will still have to come back to Profil Zaufany (Poland's Trusted Profile e-ID), a qualified signature, or a qualified seal to obtain one. It is a dead end by design.
4. Accounting firms. A token has a permission scope wired to one specific entity. An accounting office with 80 clients means 80 tokens to generate, store, and rotate. A certificate identifies the person, and KSeF resolves which companies that person may act for after login. For a firm serving many companies, that is a fundamentally different data model.
The mistake worth writing down
Our first test seeder generated a self-signed certificate and tried to authenticate with it against the Ministry's KSeF demonstration service. KSeF rejected it outright. The certificate has to be issued by KSeF itself, after you authenticate with Profil Zaufany, a qualified electronic signature, or a qualified electronic seal. There is no shortcut and no bring-your-own-CA.
We lost two days to that. It is why the default first connection a company makes in Biurko goes through Profil Zaufany (you can also supply your own KSeF certificate), and the certificate is ordered from the Ministry afterwards. Sequence matters.
Worth knowing: authenticating with a certificate requires XAdES-BES signing, so an application connecting to the KSeF 2.0 API has to be able to produce it. In other words, the certificate is only as useful as the software you point it at.
June 2026: the Ministry proposes to keep tokens
On 9 June 2026 the Ministry of Finance held its first public consultation after the partial KSeF rollout. It proposed that tokens remain available beyond 31 December 2026, with a validity window of 1 to 365 days and a new permission allowing automatic renewal (consultation summary, ksef.podatki.gov.pl).
Read that carefully. It is a consultation proposal, not enacted law. Under the current rules KSeF tokens expire on 31 December 2026, and no regulation keeping them has been adopted, so moving to a KSeF certificate is the safer choice. Before you make an operational decision, check the current notices on ksef.podatki.gov.pl.
Does this undermine our choice? No, for a boring reason: none of the four arguments above was "because tokens are going away". Token expiry was a side effect of our reasoning, not an input to it. The Offline-type certificate is still the only route to the second QR code (KOD II). A token still cannot request a certificate. The security model is still different.
If tokens had disappeared, we would have been right by accident. If they stay, we are right for the correct reason.
The trade-offs vendors do not advertise
Honestly: certificates are not a free lunch.
You have to store a private key somewhere. We encrypt it at the application layer. That is a responsibility a token simply does not hand you.
Certificates expire. Two years maximum. Someone has to watch that, so we built advance expiry warnings and a visible connection status in the panel.
A personal certificate works across contexts. If an accountant holds permissions for five companies, her certificate authenticates her in all five, not one. Convenient, and it demands genuine discipline in how permissions are granted inside KSeF. A token's narrower scope is a real advantage here.
XAdES-BES is real work. A token is pasted in 30 seconds. Certificates required us to handle PEM and P12 formats, validate that the key matches the certificate, and verify the NIP (Polish tax ID) embedded in it. The customer sees none of this, which is the point.
One sentence: a token is faster to start with, a certificate is better to live with, and you need it if you want the second QR code (KOD II) on offline invoices.
Checklist for your own company
Find out how you authenticate to KSeF today. If it is a token, establish who generated it and what permissions were baked in.
Verify that your accounting software supports a KSeF Authentication-type certificate at all. If it does not, you will not be able to keep it connected to KSeF once tokens expire.
Order an Offline-type certificate if you want a real fallback for a KSeF outage or a lost internet connection, with the second QR code (KOD II) on the offline invoice.
Map who inside your company actually holds KSeF permissions. A certificate does not grant them, it consumes them.
Put the certificate expiry date in a calendar. Two years maximum, and renewal does not happen on its own.
Track Ministry announcements about tokens. Status today: a proposal, not a rule.
Conclusion
Choosing between a certificate and a token is not a choice between new and old. It is a choice between a credential that carries permissions and a credential that proves identity and adds the second QR code to offline invoices. For a product that has to keep working when KSeF itself does not, the second is the better fit.
Biurko has had certificate handling built in since day one: requesting, storage, expiry monitoring, and, for accountants, a free seat in every client company and one-click switching between companies. You never need to know what XAdES-BES is. Create a free account at biurko.io and connect your first company to KSeF.
FAQ
What is the difference between a KSeF certificate and a KSeF token? A token carries the permissions assigned when it was generated. A KSeF certificate proves the identity of a person or entity only; permissions are resolved by KSeF after login. A certificate also has an expiry date (up to two years) and is needed for the second QR code (KOD II) in offline mode.
Do KSeF tokens stop working on 31 December 2026? Under the current rules KSeF tokens expire on 31 December 2026. At consultations on 9 June 2026 the Ministry of Finance proposed keeping them, but no regulation has been adopted yet, so moving to a KSeF certificate is the safer choice. Check ksef.podatki.gov.pl before planning around it.
Can I request a KSeF certificate while logged in with a token? No. Token authentication does not permit a certificate application. You need Profil Zaufany, a qualified electronic signature, or a qualified electronic seal.
How many types of KSeF certificate are there? Two. The Authentication type authenticates you to the system. The Offline type adds the second QR code (KOD II) to invoices in offline mode. They are issued separately and one certificate cannot cover both uses.
Can a foreign company use its own certificate? Companies holding a foreign certificate without a Polish NIP or PESEL can register its fingerprint using the ZAW-FA form (the KSeF authorisation notification filed with the tax office), which enables access to the system. Confirm the current procedure with your Polish tax adviser.
Tags
Previous article
Your First KSeF E-Invoice: A 10-Point Checklist
Next article
Automatic KSeF Resubmission After an Outage: How Biurko Handles It