INFORMATICS

Awaria systemu uwierzytelniania Profilem Zaufanym – pierwsze poważne problemy po starcie obowiązkowego KSeF 2.0

2 lutego 2026 r. – zaledwie drugi dzień roboczy po uruchomieniu obowiązkowego Krajowego Systemu e-Faktur (KSeF 2.0) – przyniósł tysiącom polskich przedsiębiorców niemiłą niespodziankę. Od około godziny 10:00 masowo zaczęły pojawiać się doniesienia o niemożności zalogowania się do KSeF za pomocą najpopularniejszej metody, czyli Profilu Zaufanego.

Co dokładnie się stało?

Użytkownicy zgłaszali:

• komunikat „nieoczekiwany błąd”,
• całkowity brak odpowiedzi strony pz.gov.pl / login.gov.pl,
• brak możliwości potwierdzenia tożsamości przez bankowość elektroniczną,
• komunikat o osiągnięciu limitu zapytań (nawet przy pierwszej próbie logowania).

Problem nie dotyczył samego silnika KSeF – faktury wysyłane innymi metodami (certyfikat kwalifikowany, token, pieczęć elektroniczna) w większości przypadków przechodziły. Źródłem awarii okazał się system uwierzytelniania oparty na Profilu Zaufanym.

Oficjalne stanowisko Ministerstwa Cyfryzacji i resortu finansów

Już przed południem 2 lutego 2026 r. pojawił się komunikat:

„W związku z bardzo dużym zainteresowaniem logowaniem do systemu KSeF 2.0 mogą występować czasowe utrudnienia w logowaniu do Profilu Zaufanego. Prowadzone są działania stabilizacyjne. Jeśli to możliwe, skorzystaj z alternatywnych metod identyfikacji lub spróbuj ponownie za chwilę. Przepraszamy za utrudnienia.”

Resort cyfryzacji wprost wskazał przyczynę – nagły, bardzo wysoki ruch spowodowany startem powszechnego obowiązku korzystania z KSeF.

Dlaczego akurat Profil Zaufany „padł” jako pierwszy?

Profil Zaufany jest najpopularniejszą i najłatwiej dostępną metodą logowania do KSeF (nie wymaga zakupu certyfikatu kwalifikowanego ani generowania tokena). W poniedziałkowy poranek 2 lutego bardzo duża liczba przedsiębiorców – zwłaszcza tych, którzy zwlekali z pierwszymi fakturami do początku lutego – próbowała jednocześnie wejść do systemu. Serwery uwierzytelniające nie wytrzymały obciążenia.

Dodatkowo Profil Zaufany obsługuje logowanie do wielu innych e-usług publicznych (PUE ZUS, ePUAP, mObywatel, e-dowód itp.), co dodatkowo spotęgowało problem.

Jakie masz alternatywy 2 lutego 2026?

Najlepsze rozwiązanie na najbliższe godziny/dni – jeśli posiadasz certyfikat kwalifikowany lub pieczęć elektroniczną – skorzystaj z nich. Jeśli nie – poczekaj 1–3 godziny i próbuj ponownie (największe natężenie ruchu zazwyczaj mija po 13:00–15:00).

Co dalej z KSeF i uwierzytelnianiem?

Eksperci zgodnie podkreślają, że dzisiejsza sytuacja to typowy efekt „pierwszego dnia po wakacjach” w skali całego kraju. Podobne przeciążenia występowały m.in. przy starcie PUE ZUS, e-dowodu czy masowego logowania do Twój e-PIT.

Ministerstwo Finansów i COI zapowiadają dalsze działania stabilizacyjne. W perspektywie najbliższych tygodni najrozsądniejszym ruchem dla większości firm będzie:

• przejście na certyfikaty typu 2 KSeF (wystarczą do logowania i wystawiania faktur offline),
• nadanie uprawnień pracownikom/księgowym już teraz,
• przygotowanie procedur awaryjnych na wypadek podobnych sytuacji w przyszłości.

Podsumowanie – krótka rada dla przedsiębiorców

Dzisiejsza awaria to nie wina KSeF samego w sobie, lecz klasyczne przeciążenie najpopularniejszej ścieżki uwierzytelniania. System e-fakturowania działa, ale „bramka wejścia” (Profil Zaufany) nie nadąża za zainteresowaniem.

Jeśli możesz – zaloguj się certyfikatem kwalifikowanym. Jeśli nie możesz – uzbrój się w cierpliwość i odświeżaj stronę co 10–15 minut. A najlepiej – już dziś zaplanuj migrację na certyfikaty KSeF 2.0 – to najpewniejsza metoda na najbliższe miesiące i lata.

Trzymamy kciuki, żeby awaria szybko minęła i żeby poniedziałek 2 lutego 2026 nie zapisał się w pamięci jako „dzień, w którym Polska nie mogła się zalogować do własnych faktur”. 😅

Metody wyłączenia trybu offline dla windowsa 10 pro

Metoda 1: Za pomocą Edytora zasad grupy (gpedit.msc)

1. Naciśnij Win + R, wpisz gpedit.msc i naciśnij Enter.
2. Przejdź do: Konfiguracja komputera > Szablony administracyjne > Składniki systemu Windows > Pliki offline.
3. Kliknij dwukrotnie Włącz pliki offline.
4. Wybierz Wyłączone, kliknij OK.
5. Uruchom ponownie komputer, aby zmiany weszły w życie.

Metoda 2: Za pomocą Rejestru (regedit)

1. Naciśnij Win + R, wpisz regedit i naciśnij Enter.
2. Przejdź do: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CSC.
3. Jeśli klucza Parameters nie ma, utwórz go (kliknij prawym > Nowy > Klucz).
4. W Parameters utwórz wartość DWORD o nazwie FormatDatabase, ustaw jej wartość na 1.
5. Uruchom ponownie komputer.

Metoda 3: Przez Panel sterowania

1. Otwórz Panel sterowania > Centrum synchronizacji.
2. Kliknij Zarządzaj plikami offline.
3. W zakładce Ogólne kliknij Wyłącz pliki offline i potwierdź.
4. Uruchom ponownie komputer.

Po wyłączeniu trybu offline zmapowane zasoby (np. z QNAP) nie będą już buforowane lokalnie. Jeśli używasz konkretnego dysku, możesz też wyłączyć synchronizację dla niego indywidualnie w jego właściwościach (kliknij prawym na dysku w Eksploratorze > Właściwości > Ustawienia plików offline > odznacz opcje).

Error Translation:

Error: Problem: cannot install the best update candidate for package remi-release-8.3-1.el8.remi.noarch - nothing provides redhat-release >= 8.10 needed by remi-release-8.10-2.el8.remi.noarch (adding "--skip-broken" will skip uninstallable packages, or "--nobest" will use not only the best candidates)

Explanation and Solution Translation:

The error you encountered during yum update indicates an issue with the REMI repository, which is attempting to update the remi-release package to version 8.10-2.el8.remi.noarch. This version requires the dependency redhat-release >= 8.10, which is not available on your CentOS 8 system. This is a common issue when an external repository (e.g., REMI) expects a newer system version that is not available in CentOS 8, especially after its End of Life (EOL) in December 2021.

Below are the steps to resolve this issue:

Causes of the Error

1. CentOS 8 EOL: CentOS 8 no longer receives updates, and its repositories have been moved to vault.centos.org. Newer package versions from the REMI repository may require dependencies unavailable in CentOS 8's archived repositories.
2. Version Mismatch of remi-release: The package remi-release-8.10-2.el8.remi.noarch is designed for a newer system version (e.g., CentOS Stream 8 or RHEL 8.10), which your system does not meet.
3. Conflicting Repositories: If you have additional repositories enabled, they may cause conflicts.

Solutions

Option 1: Use --nobest or --skip-broken

As suggested by the error message, you can use the --nobest or --skip-broken options to bypass problematic packages:

• Try with --nobest:
  bash

   

  sudo yum update --nobest -y

   

   
  The --nobest option allows installing non-latest package versions, which may bypass dependency issues.
• Try with --skip-broken:
  bash

   

  sudo yum update --skip-broken -y

   

   
  The --skip-broken option skips packages that cannot be installed due to missing dependencies.

Note: These options are temporary workarounds, as they may leave your system with outdated or skipped packages.

Option 2: Disable the REMI Repository

If you don’t need packages from the REMI repository, you can temporarily disable it during updates:

• Disable the REMI repository:
  bash

   

  sudo yum update --disablerepo=remi -y

   

   
  This allows updating the system without considering the REMI repository.
• Check enabled repositories:
  bash

   

  yum repolist

   

   
  Ensure CentOS repositories (e.g., baseos, appstream) point to vault.centos.org.

Option 3: Manually Install an Older Version of remi-release

If you need the REMI repository, you can install an older, CentOS 8-compatible version of the remi-release package:

• Remove the problematic version:
  bash

   

  sudo yum remove remi-release

   

   
• Download and install an older version of remi-release: For example, remi-release-8.3-1.el8.remi.noarch.rpm:
  bash

   

  wget https://rpms.remirepo.net/enterprise/8/remi/x86_64/remi-release-8.3-1.el8.remi.noarch.rpm

  sudo rpm -Uvh remi-release-8.3-1.el8.remi.noarch.rpm

   

   
• Clear the YUM cache:
  bash

   

  sudo yum clean all

  sudo rm -rf /var/cache/yum/*

   

   
• Try updating again:
  bash

   

  sudo yum update -y

   

   

Option 4: Migrate to CentOS Stream 8

Since CentOS 8 is no longer supported, the REMI repository may require a newer system version, such as CentOS Stream 8, which still receives updates. Consider migrating:

• Migrate to CentOS Stream:
  bash

   

  sudo dnf install centos-release-stream

  sudo dnf swap centos-linux-repos centos-stream-repos

  sudo dnf distro-sync -y

   

   

Note: Migrating to CentOS Stream converts the system to a rolling release model, which may affect stability in production environments.

• Update the system after migration:
  bash

   

  sudo dnf update -y

   

   

Option 5: Manually Edit Repository Files

If the issue stems from conflicts in the REMI repository configuration, you can manually adjust it:

• Open the REMI repository file:
  bash

   

  sudo nano /etc/yum.repos.d/remi.repo

   

   
• Ensure the repository points to the correct version: Verify that the baseurl in the [remi] or [remi-safe] section points to the appropriate CentOS 8 version, e.g.:
  ini

   

  [remi]

  name=Remi's RPM repository for Enterprise Linux 8

  baseurl=https://rpms.remirepo.net/enterprise/8/remi/$basearch/

  enabled=1

  gpgcheck=1

  gpgkey=https://rpms.remirepo.net/RPM-GPG-KEY-remi

   

   
• Save changes and clear the cache:
  bash

   

  sudo yum clean all

  sudo yum update -y

   

   

Additional Notes

• Backup: Before making changes, back up your system or at least the /etc/yum.repos.d/ directory:
  bash

   

  sudo cp -r /etc/yum.repos.d /etc/yum.repos.d.bak

   

   
• Check DNS: Ensure your server can resolve domain names (e.g., rpms.remirepo.net):
  bash

   

  ping rpms.remirepo.net

   

   
  If it fails, add DNS servers to /etc/resolv.conf:
  ini

   

  nameserver 8.8.8.8

  nameserver 8.8.4.4

   

   
• Alternative to CentOS 8: Due to CentOS 8’s EOL, consider switching to Rocky Linux or AlmaLinux, which are fully compatible with RHEL 8 and community-supported.

Verification

After applying one of the solutions, verify if the update works:

If the error persists, provide the contents of /etc/yum.repos.d/remi.repo or the exact error message, and I’ll help analyze it further.