← Back to blog

KSeF Token and Certificate: Authentication and Roles Explained

Token, qualified certificate, KSeF certyfikat, uprawnienia, and ZAW-FA. How to log in to KSeF and what to handle when connecting a .NET application. The token works only until the end of 2026.

When you connect an application to KSeF (Krajowy System e-Faktur), the first question is not "how do I send an invoice", but "how do I even log in and who is allowed to do what". Authentication, permissions (uprawnienia), and the ZAW-FA notification together decide whether your integration will work — and whether it will still work after 1 January 2027. Here is an overview of what is what.

How to Log In to KSeF

KSeF knows several authentication methods (uwierzytelnienie). Different ones are relevant for a person at a screen and for a machine.

  • Qualified electronic signature (kwalifikowany podpis elektroniczny) — belongs to a natural person. It has the legal force of a handwritten signature and is based on a qualified certificate. Used for login and signing.
  • Qualified electronic seal (kwalifikowana pieczęć elektroniczna) — identifies an organization, not a specific person. For a company this is the cleanest path: if the seal contains the entity's NIP, the company gets access on its own, without filing ZAW-FA.
  • Profil Zaufany (podpis zaufany) — a trusted profile for a natural person.
  • Token — a string that carries permissions declared at the moment it is generated. Used for machine/integration login from commercial applications.
  • KSeF certificate (certyfikat KSeF) — issued inside KSeF and is only an authentication means, similar to a qualified signature.

For connecting an application, the last two are the key ones: the token and the KSeF certificate. And that is exactly where the biggest catch is.

Token vs. KSeF Certificate: Where the Difference Is

They look interchangeable, but they are not. The difference is in where the permissions live.

A token has permissions built directly into it. You generate it with some set of rights and it carries those rights with it. That is convenient — one string and you are both logged in and authorized.

A KSeF certificate carries no permissions. It is purely a means to prove identity. Rights are handled separately, through roles inside KSeF (see below). The certificate has two functional uses: authentication for interactive and batch login over the API; and offline use — from 1 February 2026 it is needed to sign invoices issued in offline24 mode / during system unavailability / in emergency mode. The certificate is valid for a maximum of 2 years from issuance (or from a date the taxpayer chooses as the start).

This is not an academic difference. It decides how you build the application's authorization model and what happens at the turn of the year.

The Deadline You Must Not Miss: 1 January 2027

The token and the KSeF certificate coexist from 1 February 2026. But not forever:

  • Tokens work until 31 December 2026.
  • From 1 January 2027, KSeF accepts only KSeF certificates. Tokens stop working. An integration set up purely on a token will not connect to the API after New Year and will not send a single invoice.

One detail that is easy to forget: tokens from KSeF 1.0 do not work in KSeF 2.0. You have to generate them again, which is possible from 1 February 2026.

The conclusion for a long-lived .NET integration is clear: the token will help you get things running in 2026, but plan the migration to a KSeF certificate before 1 January 2027. If you leave it to the last minute, you risk your invoicing standing still over the turn of the year — exactly when the accounting period is being closed.

Roles and Permissions (uprawnienia)

Login is only half of it. The other half is who is allowed to do what.

A company that does not use a qualified seal designates a natural person to act for it in KSeF by filing a ZAW-FA notification with the tax office (on paper or electronically). A new version of ZAW-FA applies from 1 February 2026. During the mandatory period, the right to issue invoices is granted automatically based on the filed ZAW-FA.

The person designated this way — typically a director, CFO, or authorized employee — can then grant further permissions inside KSeF (issue / view / manage) to other users or to accounting software. This matters for integration: your application does not need the director to log in. It needs its own identity (a certificate) and the rights assigned to it.

Summary of when to deal with ZAW-FA and when not:

  • Company with a qualified seal (with NIP) → has access on its own, does not file ZAW-FA.
  • Company without a seal → files ZAW-FA, designates a natural person, who then delegates rights onward.

Who KSeF Actually Applies To

For authentication to make sense, it helps to know when you will even need it. Briefly, because the details deserve a separate article:

  • Issuing is mandatory from 1 February 2026 for large taxpayers (2025 revenue above PLN 200 million, roughly 4,200 entities), and from 1 April 2026 for other VAT payers. Watch out for the simplifications: micro-enterprises have no obligation until 1 January 2027, and there is a transitional relief on top of that — anyone invoicing outside KSeF up to PLN 10,000 gross per month can invoice outside the system until 31 December 2026.
  • Receiving invoices via KSeF is mandatory for all taxpayers already from 1 February 2026, even if they do not yet issue themselves.
  • An invoice to a foreign customer is still issued in KSeF (it is an invoice under Polish law); you hand it to the foreign buyer outside KSeF, for example as a PDF visualization or a shared link, because they have no access to KSeF.

It follows that you will need an identity and permissions in KSeF before you start issuing yourself — because of receiving, already from February 2026.

What to Handle When Connecting a .NET Application

Putting this into concrete integration steps:

  1. Application identity. For a production integration, aim for a KSeF certificate, not a token. Use a token at most as a stopgap for 2026 and plan for the swap before 1 January 2027 from the start.
  2. Session over the API. Initialize the session with signed XML / a certificate (or a token until the end of 2026), get a session token, and only then send structured invoices in the FA(3) format.
  3. Permissions outside the certificate. Because the certificate carries no rights, you must have roles in KSeF sorted out (via ZAW-FA and delegation). Verify that the application identity has the right to issue / view assigned before you deploy.
  4. Validity and renewal. The certificate is valid for max 2 years. Plan its renewal as a process, not a one-off — otherwise it expires mid-operation.
  5. Anti-corruption layer. Wrap the foreign SDK in your own layer so its quirks — error strings, numeric codes, session TTL — do not leak into business logic. When the SDK or schema changes, you change one place.
  6. Durable, idempotent submission. Treat every submit as a durable, idempotent unit of work: async submission → status polling → UPO confirmation. Not fire-and-forget in an HTTP request.

A note on attachments (załączniki): from 1 February 2026 you can issue an invoice with an attachment, but only after prior notification of intent. Verify the specific handling against the currently published FA(3) schema — the details here are still settling.

FAQ

What is the difference between a KSeF token and a KSeF certificate?

A token has permissions encoded in it, declared at the moment it is generated. A KSeF certificate is only an authentication means and carries no permissions — those are handled separately through roles in KSeF. The token works until 31 December 2026; from 1 January 2027 KSeF accepts only certificates.

What is ZAW-FA and when do I have to file it?

ZAW-FA is a notification to the tax office by which a company without a qualified seal designates a natural person who will act for it in KSeF. If the company uses a qualified seal with its own NIP, it gets access on its own and does not need to file ZAW-FA.

Does a token from KSeF 1.0 also work in KSeF 2.0?

No. Tokens from KSeF 1.0 do not work in KSeF 2.0 and must be generated again, which is possible from 1 February 2026. For a long-lived integration, plan the move to a KSeF certificate before 1 January 2027 anyway.

We Can Help With the Integration

We handle this in practice. Our KSeF integration runs in production — over 40,000 documents delivered at 100% — and it includes identity management, sessions, and certificate renewal. If you are connecting a .NET application and want authentication and roles built to survive the move to certificates in January 2027, get in touch.

Facing a similar problem? Get in touch.

Book a consultation