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 on the demo environment, 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 open-ended (until 31 Dec 2026 under the original plan) up to 2 years Offline invoicing not supported type 2 certificate is mandatory 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 type 2 certificate is mandatory anyway. Marking an invoice with a QR code in offline mode requires a separate KSeF type 2 certificate. 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 offline24 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 multi-company panel, 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 KSeF demo environment. 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 first connection a company makes in Biurko goes through Profil Zaufany, and the certificate request comes afterwards. Sequence matters.
Worth knowing: you cannot log into the Ministry's own free tools with a KSeF certificate. A type 1 certificate works in commercial applications integrated with the KSeF 2.0 API, because using it requires implementing XAdES-BES signing. In other words, the certificate is only as useful as the software you point it at.
June 2026: the Ministry now wants 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. Until an amended regulation is published, the original schedule stands and tokens end on 31 December 2026. 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 type 2 certificate is still the only route to offline24. A token still cannot request a certificate. The security model is still different.
If tokens had disappeared, we would have been right by accident. Since they are staying, 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 and log every authentication event. 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 it is non-negotiable if you want to invoice offline.
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 type 1 certificate at all. If it does not, offline24 mode is closed to you.
Generate a type 2 certificate if you want a real fallback for a KSeF outage or a lost internet connection.
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 unlocks offline invoicing. For a product that has to keep working when KSeF itself does not, only one of those qualifies.
Biurko has had certificate handling built in since day one: requesting, storage, expiry monitoring, and a multi-company panel for accounting firms. 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 required for offline invoicing.
Do KSeF tokens stop working on 31 December 2026? That was the original schedule. Following the 9 June 2026 consultation, the Ministry of Finance proposed keeping tokens as a permanent login method with a 1 to 365 day validity. This remains a proposal rather than law, so 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. Type 1 authenticates you to the system. Type 2 marks invoices with a verification QR code 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.