Token vs. certificate: not the same thing in new packaging
If you're new to the Polish system: every business invoicing in Poland must submit structured invoices through KSeF (Krajowy System e-Faktur), the government's central e-invoicing platform. The rollout is staged — large taxpayers from February 1, 2026, everyone else from April 1, 2026, and the smallest businesses from January 1, 2027. Your software talks to KSeF via API, and that connection has to be authenticated.
Two mechanisms exist today, and they're architecturally very different.
A token is an access key that carries the taxpayer's permissions inside it, declared at the moment of generation. It never expires on its own, and once generated, whoever holds it can act in KSeF within the permissions baked into it.
A KSeF certificate is purely an identity credential — conceptually closer to a qualified electronic signature. Permissions aren't embedded; the system checks them at every login based on the tax identifier (NIP or PESEL) recorded in the certificate. Change an employee's permissions and the certificate stays valid — KSeF simply applies the new scope.
The timeline:
Date What happens November 1, 2025 Certificate applications open February 1, 2026 KSeF 2.0 launches — certificates and tokens run in parallel December 31, 2026 Last day tokens work under the rules in force January 1, 2027 Certificates become the only authentication method
Where this stands in August 2026: the timeline above follows the rules currently in force. On June 9, 2026 the Ministry of Finance proposed keeping tokens in KSeF permanently, with a validity of 1 to 365 days. That is a consultation proposal, not a regulation: no bill has been published, so December 31, 2026 remains the date on the books. We covered what the proposal actually changes separately. One thing holds either way: offline modes require a certificate, and a token will not do that job.
Since February 2026, you apply for a certificate via the KSeF 2.0 API or the official Taxpayer Application, after authenticating with a Polish trusted profile (Profil Zaufany), a qualified electronic signature, or — for companies — a qualified electronic seal.
Why we didn't build token support "just for now"
Honestly? It was tempting. Token integration is technically trivial — attach a key to your requests and you're in. Certificates demand far more: an XAdES-BES signature flow for API authentication, private key management, expiry tracking. The Ministry's technical documentation makes it clear this is a different order of complexity.
But we ran the opportunity cost. Building token support meant weeks of engineering on a mechanism with a published shutdown date. Then a forced migration of every customer — in Q4 2026, exactly when accounting offices hit peak season and KSeF faces its heaviest load since the mandate began. The worst possible moment to ask users to "generate a new credential and reconfigure your integration from scratch."
There was a second, bigger argument: without a type 2 certificate, there are no offline modes. And offline modes aren't an exotic edge case — they're the core business-continuity safeguard in the whole system.
The type 2 certificate: something tokens never could do
The Ministry of Finance issues two certificate types, generated separately:
Type 1 (authentication) — logging into KSeF, in both interactive and batch sessions. The functional successor to today's token.
Type 2 (offline) — required to stamp an invoice with a code confirming the issuer's identity in the special modes: offline24, offline during system unavailability, and emergency mode.
Type 2 is genuinely new capability. When KSeF has scheduled downtime, or your internet drops on invoicing day, an invoice issued offline with QR verification codes generated from a type 2 certificate is fully valid — you just submit it to the system within the statutory deadline. A token never enabled this and never will.
Biurko has supported both types since our first integration release: type 1 handles login, type 2 signs offline invoices, and verification links plus QR codes are generated automatically under the hood. The user sees one message: "KSeF unavailable — invoice issued in offline24 mode, we'll submit it automatically once the system is back."
Mini-case: an outage at 4:40 PM on a Friday
One of our early pilot customers — a sole proprietor in IT services, the classic last-minute invoicer — hit a KSeF interface outage right before a weekend. With a token-based tool, he'd have stared at a connection error. In Biurko, the invoice went out in offline24 mode with verification codes, the client received a PDF with QR codes instantly, and the document flowed into KSeF automatically once availability was restored. Zero action required.
What this decision cost us (the honest part)
So this doesn't read like "our decision was brilliant and painless":
Onboarding got harder. With a token, users pasted a string. With a certificate, they first authenticate with KSeF (Profil Zaufany, qualified signature, or qualified seal for companies), file an application, and download the credential. We built a step-by-step wizard inside Biurko, but let's be real — it's more clicks than pasting a token.
Certificates expire. Maximum validity is 2 years from issuance or a chosen start date. An expired certificate halts the integration. We had to build expiry monitoring and advance notifications — for accounting offices managing dozens of tax IDs, that's a dedicated module, not a side feature.
The learning curve was real. XAdES-BES, key management, NIP/PESEL permission contexts — our first weeks of development were slower than the token route would have been.
Even so, we're migrating exactly nobody — and we won't have to, whichever way the token question lands. If the current rule holds, our customers face no change on January 1, 2027. If tokens stay under new terms, they still face none, because a type 2 certificate remains the only path to offline modes. That was the entire bet.
What to do in 2026 — a checklist for token-based integrations
Find out what your integration runs on. If your invoicing software connects to KSeF with a token, the date on the books is still December 31, 2026. The Ministry's proposal may lift it, but until there is a regulation, plan as if it stands.
Ask your vendor for a concrete migration plan. Specifically: do they support certificate type 1 and type 2, and since when.
Obtain your certificate early. Apply through the KSeF 2.0 Taxpayer Application after authenticating with Profil Zaufany or a qualified signature. Don't wait for December.
Running a company (not a sole proprietorship)? Get a qualified electronic seal. A certificate issued on the company's NIP requires seal-based authentication, and procurement takes time.
Plan certificate governance. Separate certificates for the owner, the accounting team, and each sales system mean revoking one doesn't paralyze the rest.
Track the expiry date. Certificates last at most 2 years — set a renewal reminder or use a tool that watches it for you.
Bottom line
KSeF tokens were a bridge solution. The rules in force close that bridge on December 31, 2026, and the Ministry of Finance has proposed keeping tokens permanently on a short validity — no legislation has settled it yet. Either way, certificates aren't just a new login method: they're the only path to offline invoicing modes and a cleaner access-management model.
With Biurko there's no migration to plan, because our KSeF integration has run on certificates — type 1 and type 2, with automatic expiry monitoring — since day one. Start a free 14-day trial at biurko.io and enter 2027 with zero technical debt.
FAQ
When do KSeF tokens stop working?
Under the rules in force, until December 31, 2026 — from January 1, 2027 certificates would be the only authentication method for Poland's e-invoicing system. On June 9, 2026 the Ministry of Finance proposed keeping tokens permanently, with a validity of 1 to 365 days; that is a consultation proposal, not a regulation. During the transition (from February 1, 2026) both run in parallel, and offline modes stay reserved for certificates.
What is a KSeF certificate?
A KSeF certificate is an electronic identity credential used to authenticate with Poland's national e-invoicing system, similar in concept to a qualified signature. Unlike tokens, it carries no embedded permissions — KSeF checks the holder's current permissions at each login based on their NIP or PESEL identifier.
What's the difference between type 1 and type 2 certificates?
Type 1 certificates authenticate you in KSeF for interactive and batch API sessions. Type 2 certificates are required to stamp invoices issued in offline modes (offline24, system unavailability, emergency mode) with identity-verification codes. They're issued separately — one certificate can't cover both uses.
How do foreign-owned companies in Poland get a KSeF certificate?
The company applies via the KSeF 2.0 API or Taxpayer Application after authenticating with a qualified electronic seal issued on the company's Polish NIP. The certificate is valid for up to 2 years, and the company can issue multiple certificates for different teams or systems.
What happens if I'm still on a token in 2027?
As the law stands today, token-based authentication stops working on January 1, 2027 and your invoicing software loses its KSeF connection. If the Ministry's proposal becomes law, tokens keep working but on a validity counted in days and still without offline modes. Since penalties for KSeF non-compliance apply from January 1, 2027 either way, holding a certificate early beats betting on a rule change.