If your Polish entity runs on KSeF (Krajowy System e-Faktur, Poland's mandatory national e-invoicing system), you have almost certainly been told the same thing for the past year: authorisation tokens expire on 31 December 2026, and from 1 January 2027 only KSeF certificates will work. Integration roadmaps were built around that date.
That statement is now out of date. Following the first round of post-launch consultations, the Ministry of Finance changed direction and proposed keeping tokens. Most vendor blogs still repeat the old deadline, and the ones that caught the news are being read as "migration cancelled."
Neither is correct. Below: what the Ministry actually said, what the legal status of the change is, what happens to tokens if it goes through, and what a token will never be able to do regardless.
What the Ministry of Finance actually said
On 9 June 2026 the Ministry of Finance held open consultations following the partial rollout of KSeF. The summary was published on the ministry's portals (official announcement, ksef.podatki.gov.pl).
Three concrete points came out of it:
Tokens are to become one of the permanent login methods for KSeF, available after 31 December 2026. The stated reasons: how widely they are used, their security profile, and day-to-day convenience.
Tokens will get a validity period of 1 to 365 days. Today a token has no predefined lifetime and works until it is revoked.
A new permission will allow automatic token renewal inside the system, subject to prior consent from the account owner.
This was the first meeting in a planned series. Comments can still be submitted to konsultacje.ksef@mf.gov.pl, and further sessions will be announced (KSeF consultations page).
Why this is not law yet
Worth saying plainly, because it has already blurred online.
A consultation summary signals direction of work. It is not a legal act. Until the change lands in a regulation and is published in the Journal of Laws (Dziennik Ustaw), the binding legal position is unchanged: tokens are a transitional mechanism and the target authentication method is the KSeF certificate.
The practical takeaway for anyone planning an implementation: plan for two scenarios, not for a headline.
Scenario A: the change is adopted. Tokens stay, but with a validity window of up to 365 days.
Scenario B: the change is dropped or delayed. Tokens expire on the original schedule, and on 1 January 2027 you cannot authenticate without a certificate.
In both scenarios the same decision is safe: issue a KSeF certificate now. Under Scenario A you lose nothing. Under Scenario B you protect your ability to invoice at all. The asymmetry is obvious.
Keep the surrounding calendar in view. KSeF has been mandatory since 1 February 2026 for the largest VAT payers and since 1 April 2026 for all other active VAT payers. The smallest taxpayers, with monthly sales up to PLN 10,000, join on 1 January 2027. That is also when administrative penalties under Article 106ni of the VAT Act start applying. Legal basis: the act of 5 August 2025 (Dz.U. 2025 poz. 1203).
A token after the change is no longer "set and forget"
Assume the proposal passes in full. Tokens survive. Here is the part that gets lost in the headlines.
Today's token is a string with no expiry. You paste it into your ERP once and it works until you revoke it. A token after the change is a credential with a lifetime capped at 365 days. That is not cosmetic. It changes the operating model.
What it means in practice:
Somebody has to track expiry dates. A token that expires mid-month stops invoice submission.
The integration must handle renewal, not just hold a static secret in a config file.
Automatic renewal will be possible, but it requires a separate permission and owner consent. Somebody has to configure it and document it.
Now scale that. An accounting firm serving 200 clients, each authenticating with their own token, ends up with 200 expiry dates to manage per year. That is not an IT problem. It is a process problem, and it ends with a client calling on 3 January to say they cannot issue an invoice.
Which is why the recommendation for accounting firms has not changed since June: authenticate as the firm, not as the client. Issue one KSeF certificate against the firm's NIP (Polish tax ID), or use a qualified electronic seal, and have the client grant the firm permissions inside KSeF. Collecting tokens from clients by email and SMS is not just a security exposure. It guarantees you repeat the same work every year.
What a token will never do
Regardless of how the consultations end, several token limitations are structural, not calendar-driven.
A token cannot support offline invoicing. An invoice issued in offline24 or emergency mode must carry a QR code generated with a certificate dedicated to offline invoicing. A token cannot produce one. If KSeF has an outage or your connectivity drops and you hold no certificate, you simply cannot issue a compliant invoice. An invoice issued in offline24 mode must be submitted to KSeF no later than the next business day.
A token is a bearer credential. Whoever holds it acts on your behalf, within the permissions baked into it. There is no second factor and no binding to an identity. A certificate confirms identity, and permissions are verified on the KSeF side. Two different security models.
A token carries its permissions inside it. Change the scope of permissions and you must generate a new token and swap it across every integration. A certificate does not require this, because permissions are managed separately.
A token cannot be used to request a certificate. Authenticating with a token does not let you apply for a KSeF certificate. For that you need Profil Zaufany (Poland's Trusted Profile e-ID), a qualified electronic signature, or a qualified electronic seal. So if the plan is to "quickly grab a certificate in December using the token," that plan does not work.
Token vs KSeF certificate
Token KSeF certificate Function authentication + embedded permissions identity authentication Validity today unlimited; per MF proposal 1–365 days up to 2 years, renewable Offline24 / emergency mode no yes (offline invoicing certificate) Permission change requires a new token permissions managed separately Can request a certificate no n/a Cost free free
Checklist: do this in July, not in December
Check what your system actually authenticates with. Not what your vendor supports. What is in your configuration right now: token, certificate, or seal.
Issue a KSeF certificate if you do not have one. It is free, valid for up to 2 years, and requires login via Profil Zaufany, a qualified signature, or a qualified seal. Certificates are available in the KSeF 2.0 Taxpayer Application and through the API.
Issue a separate certificate for offline invoicing. Without it you cannot invoice during a KSeF outage or a connectivity failure.
Inventory every active token and its owner. One sheet, one accountable person. An hour now saves a working day later.
Define a renewal and revocation policy. Who renews, when, on what trigger, and who is notified.
Foreign-owned entities: check ZAW-FA. If your group already holds a qualified certificate issued abroad, registering it via the ZAW-FA form can shorten the whole exercise.
Watch for further MF announcements. The 9 June proposal opened a consultation cycle. It did not close it.
More on the integration itself: [SLUG-KSEF-API-INTEGRATION]. On outage handling: [SLUG-OFFLINE24-EMERGENCY-MODE].
Bottom line
"Tokens die on 31 December" was true for a year and stopped being true in June. "The migration is cancelled" was never true. The real situation is duller and more demanding: tokens will probably stay, but with an expiry date, and everything that matters operationally, meaning offline mode, security, and permission management, still hangs on the certificate.
Biurko has been certificate-first from day one. It tracks expiry dates and warns you before access dies. A multi-company panel with role-based access lets an accounting firm operate on its own certificate instead of harvesting tokens from clients.
Create a free account at biurko.io and connect your KSeF certificate before the calendar does it for you.
FAQ
Will KSeF tokens stop working on 31 December 2026? Under the Ministry of Finance proposal from 9 June 2026, tokens are to remain available after that date. This is a consultation proposal, not binding law. Until the change is published in the Journal of Laws, it is safer to plan a migration to certificates anyway.
How long will a KSeF token be valid after the changes? The proposal sets a validity window of 1 to 365 days, plus a new permission allowing automatic token renewal inside the system with prior owner consent. Today a token runs indefinitely until it is revoked.
Can I issue an offline invoice using a token? No. Invoices issued in offline24 or emergency mode need a QR code generated with a certificate dedicated to offline invoicing. Tokens cannot produce one. This is the single biggest operational limitation of the token method.
Can I request a KSeF certificate while authenticated with a token? No. Token authentication does not allow you to apply for a KSeF certificate. You need Profil Zaufany, a qualified electronic signature, or a qualified electronic seal. This is why deferring the task is risky.
Does a KSeF certificate cost anything? No. The Ministry of Finance issues KSeF certificates free of charge, valid for a maximum of 2 years from issue. After that you file a new application. Do not confuse it with a qualified electronic signature, which is a commercial service.