Baza wiedzy

CRU JSFP — logowanie prywatnym Profilem Zaufanym. Czy tak powinno być?

Praktyczne wyjaśnienie dla JSFP: jak odróżnić konto jednostki od osobistego uwierzytelnienia użytkownika, jak rozmawiać z pracownikami o Profilu Zaufanym i dlaczego wspólny dostęp podważa rozliczalność procesu.

Aktualizacja: 28 czerwca 2026 r.18 min czytania

Stan opracowania: 28 czerwca 2026 r.

Najkrótsza odpowiedź: logowanie do CRU JSFP powinno identyfikować konkretną osobę fizyczną działającą w imieniu jednostki. Oficjalne materiały Ministerstwa Finansów opisują model konta jednostki oraz indywidualnych kont użytkowników, a nie wspólnego Profilu Zaufanego „na urząd”.

W wielu jednostkach sektora finansów publicznych pojawia się praktyczny problem: czy pracownik ma logować się do CRU JSFP swoim prywatnym Profilem Zaufanym? A jeśli nie chce tego robić, czy można „założyć Profil Zaufany na urząd” i przekazać login oraz hasło kilku osobom?

To nie są pytania czysto techniczne. Dotykają bezpieczeństwa, odpowiedzialności, ochrony danych i zwykłego zaufania pracowników do sposobu organizacji pracy. Profil Zaufany kojarzy się przecież z narzędziem osobistym, używanym także do spraw prywatnych.

Trzeba więc rozdzielić dwie rzeczy: osobiste uwierzytelnienie użytkownika oraz działanie w imieniu jednostki. To, że system rozpoznaje konkretną osobę, nie oznacza jeszcze, że ta osoba działa „prywatnie”. Oznacza tylko, że da się wiarygodnie ustalić, kto faktycznie wykonał czynność w systemie.

Co potwierdzają oficjalne materiały MF

W oficjalnych materiałach Ministerstwa Finansów dotyczących CRU JSFP powtarza się ten sam model organizacyjny:

  • o konto jednostki występuje kierownik danej jednostki albo jego reprezentant,
  • każda jednostka, której plan finansowy jest obciążany umowami objętymi obowiązkiem, powinna co do zasady mieć własne konto jednostki,
  • po założeniu konta jednostki nadaje się uprawnienia pracownikom,
  • wniosek o konto użytkownika może złożyć tylko sam użytkownik,
  • założenie konta użytkownika albo nadanie mu uprawnień do konta jednostki wymaga weryfikacji przez administratora tej jednostki.

To nie jest jeszcze przepis zapisany jednym zdaniem: „nie wolno używać wspólnego loginu”. Jest to jednak bardzo wyraźny model działania systemu opisany przez MF: konto jednostki plus zidentyfikowani użytkownicy przypisani do tej jednostki.

Wniosek z oficjalnych źródeł: skoro MF przewiduje konto jednostki, osobny wniosek o konto użytkownika składany osobiście oraz nadawanie uprawnień konkretnym pracownikom, to wspólny dostęp „dla całego działu” byłby sprzeczny z celem tego modelu, czyli z identyfikacją i rozliczalnością działań.

Profil Zaufany nie jest kontem urzędu

Oficjalna strona Profilu Zaufanego wskazuje, że jest to środek identyfikacji elektronicznej, dzięki któremu użytkownik potwierdza swoją tożsamość w internecie i loguje się do systemów administracji publicznej. Z samej konstrukcji tego narzędzia wynika więc, że służy ono identyfikacji konkretnej osoby.

To ważne rozróżnienie: pracownik nie „oddaje” jednostce swojego prywatnego Profilu Zaufanego. Pracownik wykorzystuje osobisty środek identyfikacji elektronicznej po to, aby system mógł potwierdzić, kto wykonuje czynność służbową.

Najprościej można to ująć tak:

Pracownik nie publikuje umów prywatnie. Potwierdza swoją tożsamość osobistym środkiem identyfikacji, ale działa w systemie jako osoba uprawniona do wykonywania czynności w imieniu jednostki.

Konto jednostki to nie to samo co logowanie osoby

W praktyce trzeba rozdzielić dwa poziomy organizacyjne.

Konto jednostki

Powiązane z daną JSFP.

To w ramach tego konta jednostka realizuje obowiązek publikacji informacji o umowach, zarządza uprawnieniami i porządkuje odpowiedzialność za proces.

Konto użytkownika

Powiązane z konkretną osobą.

To zidentyfikowany użytkownik składa własny wniosek, uzyskuje uprawnienia i wykonuje czynności w systemie w zakresie przydzielonej mu roli.

Właśnie dlatego poprawny model nie polega na tworzeniu anonimowego dostępu „dla referatu”, ale na przypisaniu ról konkretnym użytkownikom działającym w ramach konta jednostki.

Czy można założyć wspólny „Profil Zaufany na urząd”?

Nie jest to właściwe ani bezpieczne rozwiązanie. Taki pomysł podważałby sam sens osobistego uwierzytelnienia.

W praktyce szczególnie ryzykowne są następujące rozwiązania:

  • jeden login do Profilu Zaufanego lub innego środka identyfikacji dla całego działu,
  • udostępnianie hasła przełożonemu albo współpracownikom,
  • przekazywanie kodów SMS lub innego potwierdzenia logowania,
  • zostawianie aktywnej sesji do użycia przez inną osobę,
  • logowanie się przez jednego pracownika po to, by inny „tylko coś kliknął”,
  • używanie dostępu osoby, która zmieniła stanowisko albo zakończyła pracę.

Przy takim modelu ślad audytowy przestaje być wiarygodny. Formalnie czynność może być przypisana do jednej osoby, ale faktycznie wykona ją ktoś inny. To problem dla jednostki, kierownika jednostki i samych pracowników.

Dlaczego wspólny dostęp jest złym pomysłem

W systemie takim jak CRU JSFP trzeba być w stanie odtworzyć:

  • kto się zalogował,
  • kto przygotował dane,
  • kto opublikował wpis,
  • kto zaktualizował dane,
  • kto poprawił błąd,
  • kiedy wykonano czynność,
  • czy osoba miała do tego uprawnienie.

Jeżeli kilka osób korzysta z jednego dostępu, odpowiedzi na te pytania stają się niewiarygodne. Z punktu widzenia kontroli, bezpieczeństwa i rozliczalności to ryzyko organizacyjne, a nie tylko „drobna niedogodność techniczna”.

Co, jeśli pracownik nie chce używać prywatnego Profilu Zaufanego

Jednostka nie powinna zaczynać od presji, ale od jasnego wyjaśnienia zasad. Pracownik powinien wiedzieć, że:

  • nie przekazuje pracodawcy loginu, hasła ani kodów autoryzacyjnych,
  • użycie Profilu Zaufanego służy wyłącznie potwierdzeniu tożsamości przy czynności służbowej,
  • zakres odpowiedzialności wynika z roli i procedury jednostki, a nie z samego faktu logowania,
  • nie każdy pracownik merytoryczny musi mieć bezpośredni dostęp do CRU JSFP.

Jeżeli mimo to pracownik odmawia, jednostka powinna szukać rozwiązań organizacyjnych, a nie obchodzić model bezpieczeństwa systemu.

  • można wyznaczyć inną osobę do bezpośredniej obsługi CRU JSFP,
  • można ograniczyć liczbę użytkowników logujących się bezpośrednio do systemu centralnego,
  • pracownicy merytoryczni mogą przygotowywać dane poza CRU JSFP, a publikacji mogą dokonywać wyznaczeni użytkownicy,
  • jeżeli aktualna konfiguracja logowania udostępnia więcej niż jeden środek identyfikacji elektronicznej, warto sprawdzić, czy pracownik może użyć innej akceptowalnej metody,
  • przy integracji przez API część pracy może zostać przeniesiona do systemu wewnętrznego jednostki.

Nie należy natomiast rozwiązywać odmowy przez wspólny login, pożyczanie tożsamości albo korzystanie z dostępu innej osoby.

Czy każdy pracownik merytoryczny musi logować się do CRU JSFP

Niekoniecznie. W wielu jednostkach rozsądniejszy jest model, w którym:

  • pracownicy merytoryczni przygotowują dane o umowie,
  • właściwe komórki weryfikują kwalifikację, wartość i jawność,
  • publikacji dokonuje ograniczona liczba wyznaczonych użytkowników,
  • aktualizacje przechodzą przez uporządkowany obieg.

Taki model zmniejsza liczbę osób, które muszą bezpośrednio korzystać z osobistego uwierzytelnienia w systemie centralnym, a jednocześnie wzmacnia kontrolę nad jakością danych.

Czy pracownik ponosi osobistą odpowiedzialność za publikację

Za organizację realizacji obowiązku CRU JSFP odpowiada kierownik jednostki. To jednostka powinna rozpisać role, terminy, ścieżkę weryfikacji danych oraz zasady aktualizacji wpisów.

Pracownik logujący się do systemu może wykonywać czynność techniczną, ale nie oznacza to automatycznie, że samodzielnie odpowiada za całą kwalifikację prawną, finansową i jawnościową umowy. Dlatego procedura wewnętrzna powinna wskazywać:

  • kto przygotowuje dane,
  • kto sprawdza ich kompletność,
  • kto potwierdza wartość umowy,
  • kto ocenia wyłączenia i ograniczenia jawności,
  • kto zatwierdza publikację,
  • kto technicznie publikuje albo aktualizuje wpis.

Praktyczna zasada: osoba publikująca nie powinna być pozostawiona sama z odpowiedzialnością za decyzje, których faktycznie nie podejmuje. Logowanie ma identyfikować wykonawcę czynności, ale organizacja procesu musi jasno rozdzielać odpowiedzialność merytoryczną, finansową i techniczną.

Czy potrzebna jest zgoda pracownika

Samo wykonywanie zadań służbowych w CRU JSFP nie sprowadza się zwykle do „zgody na użycie prywatnego konta” w potocznym sensie, bo pracownik nie przekazuje jednostce swojego Profilu Zaufanego. Jednostka powinna jednak bardzo jasno wykonać obowiązki informacyjne i organizacyjne.

W praktyce warto poinformować pracownika co najmniej o tym:

  • jakie dane są przetwarzane przy dostępie do systemu,
  • w jakim celu są przetwarzane,
  • kto jest administratorem danych,
  • jaki jest zakres jego zadań w systemie,
  • jak długo utrzymywane będą uprawnienia,
  • co dzieje się z dostępem po zmianie stanowiska albo zakończeniu zatrudnienia.

Ze względu na kwestie pracownicze, RODO i bezpieczeństwo informacji każda jednostka powinna zweryfikować ten obszar również we własnym stanie faktycznym i własnych regulacjach wewnętrznych.

Co powinna zrobić jednostka przed uruchomieniem pracy w CRU JSFP

Najlepiej przygotować prostą, ale konkretną procedurę dostępu do CRU JSFP. Powinna ona odpowiadać na najważniejsze pytania organizacyjne:

  • kto odpowiada za konto jednostki,
  • kto składa wniosek o konto jednostki,
  • kto pełni rolę administratora jednostki,
  • kto może wnioskować o konto użytkownika i uprawnienia,
  • jakie role występują w procesie,
  • czy pracownik merytoryczny musi logować się do CRU JSFP, czy tylko przygotowuje dane,
  • jak działa zastępstwo,
  • jak odbiera się dostęp po zmianie stanowiska,
  • że nie wolno udostępniać loginów, haseł ani kodów autoryzacyjnych,
  • jak wygląda ścieżka weryfikacji danych przed publikacją,
  • co zrobić przy błędzie, korekcie albo aktualizacji wpisu.

Najważniejsze jest to, aby pracownicy nie odbierali tego jako żądania „oddania prywatnego Profilu Zaufanego”, lecz jako element osobistego uwierzytelnienia przy realizacji czynności służbowej.

Kiedy integracja API może ograniczyć problem

Nie każda jednostka musi organizować pracę w modelu ręcznego logowania wielu pracowników do systemu centralnego. Jeżeli jednostka wdroży lokalny system ewidencji umów z integracją do CRU JSFP przez API, część pracy może być wykonywana wewnątrz jej własnego środowiska.

W takim modelu pracownicy merytoryczni przygotowują dane lokalnie, a bezpośredni kontakt z CRU JSFP może zostać ograniczony do węższej grupy użytkowników albo do kontrolowanego procesu integracyjnego. Nie zastępuje to procedury wewnętrznej, ale może istotnie zmniejszyć skalę problemu organizacyjnego.

Najczęstsze błędy

  • założenie, że można stworzyć wspólny Profil Zaufany dla urzędu albo całego działu,
  • mylenie konta jednostki z osobistym kontem użytkownika,
  • udostępnianie loginu, hasła albo kodów autoryzacyjnych,
  • logowanie się przez jednego pracownika za innych,
  • brak formalnego wyznaczenia użytkowników i ich ról,
  • brak procedury nadawania i odbierania uprawnień,
  • zmuszanie wszystkich pracowników merytorycznych do bezpośredniego logowania bez analizy, czy to konieczne,
  • brak wyjaśnienia pracownikom, jakie dane są przetwarzane i po co,
  • pozostawianie rozliczalności „samemu systemowi”, bez wewnętrznego podziału odpowiedzialności.

Najbardziej ryzykowny błąd: wspólny login może wydawać się wygodny, ale w praktyce podważa bezpieczeństwo i rozliczalność całego procesu. W systemie jawnościowym to zły punkt wyjścia już na etapie organizacji pracy.

Podsumowanie

Logowanie do CRU JSFP z użyciem osobistego Profilu Zaufanego pracownika może być prawidłowe, jeżeli pracownik został wyznaczony do działania w systemie, działa w imieniu jednostki i nie udostępnia nikomu swojego środka uwierzytelnienia.

Oficjalne materiały MF opisują model działania oparty na koncie jednostki oraz indywidualnych kontach użytkowników. Z tego modelu wynika, że wspólny dostęp „na urząd”, pożyczanie tożsamości albo traktowanie Profilu Zaufanego jak technicznego konta działu nie jest dobrą ani bezpieczną praktyką.

Najważniejsza zasada: osobisty środek identyfikacji potwierdza tożsamość osoby, ale sama czynność w CRU JSFP wykonywana jest w imieniu jednostki. Nie warto zamieniać tego mechanizmu w anonimowy dostęp wspólny, bo wtedy znika rozliczalność, dla której ten model został zbudowany.

Źródła i podstawy prawne

Artykuł został przygotowany na podstawie przepisów i oficjalnych materiałów dotyczących CRU JSFP aktualnych na 28 czerwca 2026 r. Najważniejsze źródła to:

  1. Ustawa z dnia 27 sierpnia 2009 r. o finansach publicznych - tekst jednolity Dz.U. 2025 poz. 1483, w szczególności art. 34a, art. 34b i art. 34d.
  2. Ustawa z dnia 4 grudnia 2025 r. - Dz.U. 2025 poz. 1844, która określa aktualny model stosowania przepisów dotyczących CRU JSFP.
  3. Rozporządzenie z dnia 30 marca 2026 r. w sprawie Centralnego Rejestru Umów Jednostek Sektora Finansów Publicznych - Dz.U. 2026 poz. 440.
  4. Oficjalna strona Ministerstwa Finansów poświęcona CRU JSFP.
  5. Najczęściej zadawane pytania MF dotyczące CRU JSFP, w tym odpowiedzi o koncie jednostki i roli kierownika jednostki albo jego reprezentanta.
  6. System teleinformatyczny CRU JSFP oraz materiały szkoleniowe MF, w szczególności prezentacja webinarowa dotycząca składania wniosków o konta, która wskazuje na model konta jednostki, konta użytkownika i osobistego złożenia wniosku przez użytkownika.
  7. Oficjalna strona Profilu Zaufanego, która opisuje Profil Zaufany jako środek identyfikacji elektronicznej służący do potwierdzania tożsamości i logowania do systemów administracji publicznej.

Zastrzeżenie: materiał ma charakter informacyjny i organizacyjny. Nie stanowi indywidualnej opinii prawnej ani instrukcji technicznej Ministerstwa Finansów. Wnioski dotyczące niewłaściwości wspólnego loginu są wnioskiem organizacyjnym z oficjalnego modelu kont i z zasad rozliczalności, a nie dosłownym cytatem z jednego przepisu. Każda jednostka powinna dostosować zasady dostępu do CRU JSFP do własnej struktury organizacyjnej, regulaminu pracy, polityki bezpieczeństwa i ochrony danych.

Chcesz uporządkować model dostępu do CRU JSFP w swojej jednostce?

Możemy pomóc rozpisać role, procedurę nadawania uprawnień, ścieżkę weryfikacji danych i bezpieczny obieg pracy tak, aby ograniczyć liczbę bezpośrednich użytkowników systemu centralnego i zwiększyć rozliczalność procesu.