Fakturownia data breach - what should you do?

On September 29, 2026, Fakturownia reported that it had detected unauthorized access to its servers the previous day. According to the operator, the access may have covered account and counterparty data, some invoices, password hashes, and tokens generated by Fakturownia. The extent of the breach is still being established.

Change your password, secure the linked email account, enable two-step verification, and check account users and the bank details shown on invoices. According to information shared with us, Fakturownia announced in a September 29 customer email that it would invalidate all API tokens on October 1, 2026. If you use integrations, prepare to update them.

The guidance below reflects information available on September 29, 2026. Fakturownia states that its KSeF integration was not breached and that KSeF certificates remain safe. Nevertheless, as a precaution, we also recommend rotating the KSeF tokens and certificates used in Fakturownia rather than relying solely on those assurances.

Zaufana Trzecia Strona describes material it received indicating access to Fakturownia's systems. However, the amount of stolen data claimed by the person who contacted the publication must be distinguished from the verified extent of the incident.

What is known about the breach?

What did Zaufana Trzecia Strona establish?

What should you do first?

How should you prepare for API tokens to be invalidated on October 1?

Does the incident affect KSeF?

How should you check payments and messages?

What obligations might your company have?

Do you need to switch software?

Frequently asked questions

The operator says a vulnerability in the system was exploited. It reports cutting off unauthorized access, launching new servers, starting to rotate service keys and passwords, and investigating the incident with external specialists. It also says it notified Poland's Central Bureau for Combating Cybercrime (CBZC), CERT Polska, and the President of the Personal Data Protection Office (UODO). September 28 is the detection date; the statement does not establish when unauthorized access began.

The potentially affected information includes all users' accounts and their counterparties' data. This does not yet confirm that every person's complete data set was exposed. It is useful to distinguish the categories:

On September 29, Adam Haertle of Zaufana Trzecia Strona described contact with a person using the name Fingerprint. According to the author, that person sent the publication three screenshots which its editorial team considered evidence of access to Fakturownia's systems. The description covers an application directory, part of a customer list, and a list of files indicating an exported database.

The person also claimed to have obtained 6 TB of invoices. Zaufana Trzecia Strona explicitly said it could not verify that information. The 6 TB figure therefore remains a claim by the attacker reported by the publication, not a confirmed measure of the breach.

For users, the relevant point is the scope of the material described: it concerns the application server and customer data, so an access review should also cover integrations and tokens. The precise data affected for any particular company still needs to be established by the operator. The Z3S report also does not specify which invoices issued during 2023 itself may have been exposed.

A password hash is a value calculated from a password. Obtaining it may enable attempts to guess the password, but does not automatically reveal the password itself. The statement does not explain how these hashes were protected. The separately listed application system keys and passwords are not the same as customers' login passwords.

For documents, Fakturownia refers to invoices issued “before 2023.” At the same time, it says that, to its knowledge, invoices issued “after 2023” were not leaked. The status of 2023 itself remains ambiguous in this description. Use the operator's subsequent information to establish the scope affecting your documents.

Fakturownia states that no data was deleted from its systems and that the breach did not affect payment card data. The fact that documents remain in the system does not, however, rule out access to their contents or the use of that information in fraud.

Open your account using a familiar address or your own bookmark. An alarming message with a button to “secure your account” may itself be a phishing attempt. Then take the following steps:

1. Set a new, unique Fakturownia password. If you used the old password elsewhere, change it in every one of those services. A password manager makes it easier to maintain a separate password for each service.

2. Secure the email account linked to your account. Fakturownia recommends changing that password too. Check account recovery and two-step verification settings, because email is often used to reset passwords for other applications.

3. Enable two-step verification in Fakturownia. Review the user list and investigate any unfamiliar access. Also agree with your administrator how to end suspicious sessions; changing the password alone does not confirm that they have been closed.

4. Compare the bank account saved in the settings with your company's correct account, and check the details on current invoices. If you find a discrepancy, establish which documents have already reached recipients and contact them through a familiar channel.

In a company with several users, each person should secure their own access. A single password change by the owner does not replace a review of the other accounts.

According to information shared with us about a Fakturownia customer email dated September 29, 2026, the operator announced that it would invalidate all API tokens on October 1, 2026. This is an announced change to API access, separate from changing an account password and rotating system keys.

An API token allows a connected application to use an account without a person entering a password each time. Once the token is invalidated, the application cannot perform operations requiring it until valid credentials are supplied. This may stop invoice retrieval, invoice transfers, or automations using that connection.

Before October 1, work with your administrator or integration provider to list the applications using Fakturownia and assign someone to update each connection. Follow Fakturownia's instructions on when to generate a new token. This also matters if you have already replaced a token after the incident: you need to confirm whether it will remain valid after the announced operation.

If you already use the Fakturownia integration in KSeFGPT, select the correct company after replacing the token, open Integrations, and select Edit on the relevant card. Paste the new token, use Test connection in the form, and save the change. The Fakturownia connection guide explains the details.

After restoring the connection, check which operations completed successfully and which need to be retried. Before submitting an invoice to KSeF again, check its existing status and KSeF number to avoid issuing a second copy of a document the system has already accepted.

Do not send tokens in support tickets, messages, or screenshots. A successful test confirms that the supplied credentials work; it is not a security audit of the account.

Fakturownia states that the incident did not affect data held within its Integrations and add-ons, including certificates for Poland's National e-Invoicing System, KSeF. At the same time, it lists possible access to tokens generated by Fakturownia itself. These statements concern different credentials and should not be treated as referring to the same thing.

After an incident of this kind, we recommend a cautious approach to trust: if you used KSeF tokens or certificates in Fakturownia, rotate them. Revoke the credentials used there and replace them with new ones. A new certificate should also have a new private key. This is our precautionary recommendation, made despite the operator's assurances about certificate security.

A Fakturownia API token, a KSeF token, and a KSeF certificate require separate management. Replacing the Fakturownia API token alone does not replace the rotation of KSeF credentials. Work with your administrator or integration provider to identify every place where they are used, update the credentials, and check the connections. Revoking old credentials may interrupt integrations that rely on them until they are updated.

Bankier.pl, in a PAP report updated on September 29 at 21:00, also quotes a Ministry of Finance statement. According to that report, the Ministry's verification found no breach of KSeF security and no leak of data in its possession.

The information about KSeF does not establish the extent of access to copies of documents held by a private provider. Follow Fakturownia's findings concerning your particular account and invoices.

Knowing a genuine counterparty, amount, or invoice number can make a fake payment demand more convincing. Possessing a bank account number does not mean someone has taken over online banking, but transaction details may help a fraudster impersonate a familiar company.

For example, a message might refer to a specific invoice and demand an urgent transfer to a “new account following the incident.” This illustrates the risk; it does not describe a confirmed event. Confirm the change by calling your counterparty on a number you knew before receiving the message. Do not use a number first provided in that request.

Do not give passwords, verification codes, BLIK codes, or card details to someone who contacts you about the incident. If a caller claims to be your bank, end the call and dial its official number yourself. A sender address that looks correct does not, by itself, establish that a message is safe.

In Poland, you can forward a suspicious text message to CERT Polska on 8080, as Fakturownia recommends. If you have already sent money to a suspicious account, contact your bank immediately through its official channel and keep the messages and transfer confirmation. Whether the funds can be recovered depends on the circumstances.

The owner or account administrator should gather information about access and integrations. Accounting can check bank details and unusual payment instructions. The person responsible for data protection should establish the scope of the data and the company's role. Record the actions taken and the issues awaiting a response from the provider.

If your company is the controller of personal data affected by the breach, assess and document the risk to individuals' rights and freedoms. Poland's Personal Data Protection Office, UODO, explains that a breach must be reported to the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it is unlikely to result in such a risk. The deadline does not automatically start when a news report is published.

If you act as a processor, notify the controller without undue delay. A controller that does not yet have all the information can make an initial notification using the findings available. Fakturownia's notification does not replace your company's own assessment of its obligations.

Where there is a high risk, there may also be a duty to inform the affected individuals, subject to the exceptions in the GDPR, known in Poland as RODO. This is a separate assessment from notification to the authority. Make it with the person responsible for data protection, based on the circumstances of the individuals concerned.

Switching software does not undo the exposure of copied data. First secure access, clarify the extent of the incident, and review payments. Decide whether to continue using the provider based on its information, your company's needs, and the terms for handling your documents.

If you choose another tool, plan to retain your archive, review permissions, and disable connections you no longer need. Removing an integration's configuration from one application does not necessarily invalidate its token with the issuer. It therefore does not replace the access review agreed with your administrator.

These guides can help with further access checks and document handling:

Configure the Fakturownia integration, including after replacing an API token.

Delete an integration in KSeFGPT when you no longer need the connection.

Give your accountant access to KSeF invoices to review the scope of their access.

Handle an invoice for a purchase you did not make when a received document raises concerns.