Administrator ma poprawne konto, właściwą rolę i zna hasło. Mimo to nie może wejść do panelu zarządzania. Próbuje Microsoft Authenticatora — metoda jest odrzucana. Kod TOTP też nie działa. SMS nie spełnia polityki. Drugi administrator ma dokładnie ten sam problem. W tym momencie phishing-resistant MFA, wdrożone po to, żeby chronić najbardziej uprzywilejowane konta, przestaje być wyłącznie mechanizmem bezpieczeństwa. Staje się problemem ciągłości dostępu.
Taki scenariusz nie wynika zwykle z awarii passkeys. Najczęściej źródłem blokady jest kolejność wdrożenia: organizacja najpierw wymusza określoną authentication strength, a dopiero później odkrywa, że część administratorów nie ma zarejestrowanej żadnej metody, która tę siłę uwierzytelnienia spełnia.
W środowiskach Microsoft Entra jest to szczególnie łatwe do przeoczenia. Polityka Conditional Access może wymagać wbudowanej siły Phishing-resistant MFA, podczas gdy administrator ma skonfigurowane tylko hasło, powiadomienia push, OTP albo SMS. Z punktu widzenia użytkownika „MFA przecież działa”. Z punktu widzenia polityki — nie działa, ponieważ nie każde MFA jest odporne na phishing.
Dlaczego zwykłe MFA nie wystarcza po włączeniu phishing-resistant MFA
Najważniejsze rozróżnienie dotyczy tego, co dokładnie potwierdza metoda logowania.
Kod SMS, kod TOTP czy klasyczne zatwierdzenie powiadomienia w aplikacji może potwierdzić posiadanie dodatkowego składnika, ale nie wiąże kryptograficznie procesu uwierzytelnienia z właściwą usługą. Użytkownik może zostać przekierowany na fałszywą stronę, wpisać hasło i kod, a atakujący może przekazać dane do prawdziwego serwisu praktycznie w czasie rzeczywistym.
Passkey działa inaczej. Opiera się na standardach FIDO2, WebAuthn i CTAP oraz parze kluczy kryptograficznych. Klucz prywatny pozostaje po stronie urządzenia lub klucza sprzętowego, a serwer przechowuje klucz publiczny. Poświadczenie jest związane z konkretną domeną — fałszywa witryna nie może po prostu poprosić o podpis przeznaczony dla prawdziwej usługi.
To właśnie ten mechanizm daje odporność na klasyczny phishing poświadczeń.
W Microsoft Entra polityka wymagająca phishing-resistant MFA może być spełniana m.in. przez obsługiwane konfiguracje:
- passkey/FIDO2,
- Windows Hello for Business lub odpowiednie poświadczenie platformowe,
- Microsoft Entra Certificate-Based Authentication skonfigurowane jako uwierzytelnienie wieloskładnikowe.
Problem zaczyna się wtedy, gdy organizacja utożsamia komunikat „użytkownik ma MFA” z komunikatem „użytkownik ma phishing-resistant MFA”. To nie są równoważne stany.
Przykład z praktyki jest prosty. Administrator loguje się od dwóch lat przez hasło i Microsoft Authenticator. Security team tworzy Conditional Access dla ról administracyjnych i ustawia Require authentication strength: Phishing-resistant MFA. Konto nadal ma MFA, ale dotychczasowy sposób logowania nie spełnia nowej polityki. Jeśli administrator wcześniej nie zarejestrował passkey, Windows Hello for Business albo właściwego certyfikatu, dostęp zostaje zablokowany.
Co gorsza, taka sytuacja może objąć jednocześnie kilka osób, jeżeli politykę przypisano bezpośrednio do ról, takich jak:
- Global Administrator,
- Conditional Access Administrator,
- Privileged Role Administrator,
- Security Administrator,
- Authentication Administrator,
- Exchange Administrator,
- SharePoint Administrator,
- User Administrator.
Najbardziej niebezpieczny błąd to objęcie polityką wszystkich administratorów i uruchomienie jej od razu w trybie On, bez wcześniejszego testu w trybie Report-only i bez konta awaryjnego.
Zabezpieczenie jest wtedy technicznie poprawne. Operacyjnie — źle wdrożone.
Jak wymusić passkeys, nie odcinając własnego zespołu administracyjnego
Wdrożenie powinno zaczynać się nie od przełącznika „Require phishing-resistant MFA”, lecz od inwentaryzacji metod uwierzytelnienia administratorów.
Najpierw trzeba ustalić, kto rzeczywiście wykonuje zadania uprzywilejowane, jakimi kontami i z jakich urządzeń. Osobne konto administracyjne używane tylko do zarządzania tenantem jest łatwiejsze do zabezpieczenia niż zwykłe konto pracownika, które jednocześnie odbiera pocztę, otwiera dokumenty i posiada Global Administratora.
Drugi krok to przygotowanie metod zgodnych z przyszłą polityką.
Microsoft Entra obsługuje obecnie zarówno passkeys synchronizowane, jak i passkeys związane z urządzeniem, w tym poświadczenia znajdujące się na kluczach bezpieczeństwa FIDO2 oraz w obsługiwanych rozwiązaniach platformowych. Sam mechanizm passkeys jest dostępny również w Microsoft Entra ID Free, natomiast możliwość zbudowania całego modelu Conditional Access zależy już od posiadanych licencji i funkcji środowiska.
Przy kontach administratorów decyzja „synchronizowany czy device-bound” nie powinna być przypadkowa.
Synced passkey jest wygodniejszy. Poświadczenie może być dostępne na kilku urządzeniach użytkownika poprzez obsługiwany ekosystem synchronizacji. Zmniejsza to ryzyko, że utrata jednego telefonu lub laptopa natychmiast odetnie użytkownika od konta.
Ta wygoda jest jednocześnie ograniczeniem. Organizacja częściowo uzależnia wtedy odporność procesu odzyskiwania od sposobu zabezpieczenia ekosystemu, który synchronizuje poświadczenia.
Device-bound passkey daje administratorowi bezpieczeństwa większą kontrolę nad miejscem przechowywania klucza. Typowym przykładem jest fizyczny klucz FIDO2. Minusem jest logistyka: klucz można zgubić, zostawić w domu albo uszkodzić.
Dlatego administrator uprzywilejowany nie powinien dostać jednego klucza FIDO2 i instrukcji „proszę go nie zgubić”. Sensowny model zakłada co najmniej dwie niezależne ścieżki dostępu spełniające wymaganą siłę uwierzytelnienia — na przykład podstawowy klucz sprzętowy i drugi klucz przechowywany oddzielnie albo urządzenie z odpowiednio skonfigurowanym Windows Hello for Business.
Trzeci element to Temporary Access Pass, jeżeli organizacja korzysta z Microsoft Entra i potrzebuje kontrolowanego sposobu bootstrapowania metod passwordless. TAP pozwala użytkownikowi przejść proces rejestracji właściwego poświadczenia bez obchodzenia docelowej polityki przez pozostawienie na stałe słabszego MFA.
Dopiero później należy budować Conditional Access.
Bezpieczna kolejność wygląda następująco:
- Wyznaczyć pilotażową grupę administratorów.
- Włączyć dla nich odpowiednie metody passkey/FIDO2.
- Zarejestrować poświadczenia i faktycznie wykonać nimi logowanie.
- Sprawdzić logowania z typowych urządzeń administracyjnych.
- Utworzyć politykę wymagającą phishing-resistant MFA.
- Uruchomić ją najpierw w Report-only.
- Przejrzeć wyniki i ustalić, które konta zostałyby zablokowane.
- Dopiero po usunięciu problemów przełączyć politykę na On.
Tryb Report-only bywa traktowany jako formalność. To błąd. W przypadku polityk obejmujących administratorów jest to jeden z najtańszych sposobów znalezienia problemu, zanim problem zamieni się w blokadę tenantu.
Trzeba też sprawdzić nakładanie się kilku polityk Conditional Access. Jeżeli podczas jednego logowania użytkownika obejmują dwie lub trzy polityki, nie wybiera on sobie najłagodniejszej. Musi spełnić warunki wynikające z całego zestawu obowiązujących zasad.
Praktyczny przykład: jedna polityka wymaga zgodnego urządzenia, druga określonej lokalizacji, a trzecia phishing-resistant MFA. Administrator z poprawnym passkey nadal może nie wejść do środowiska, jeżeli urządzenie nie spełnia wymogu zgodności.
To właśnie takie kombinacje najczęściej komplikują diagnostykę.
Break-glass nie jest obejściem bezpieczeństwa. Jest elementem projektu
Najgorszy moment na tworzenie konta awaryjnego przypada pięć minut po tym, jak ostatni Global Administrator przestaje się logować.
Emergency access account, często nazywany kontem break-glass, musi istnieć wcześniej i musi być przetestowany. Microsoft wprost zaleca wyłączanie kont awaryjnych z polityk Conditional Access, które mogłyby doprowadzić do całkowitego lockoutu.
Nie oznacza to stworzenia administratora z hasłem zapisanym w Excelu.
Dobre konto awaryjne powinno:
- mieć odpowiednio wysokie uprawnienia do odzyskania kontroli nad środowiskiem,
- być używane wyłącznie w sytuacji awaryjnej,
- nie służyć do codziennej administracji,
- posiadać niezależną ścieżkę uwierzytelnienia,
- być wyłączone z polityk, których awaria lub błędna konfiguracja może odciąć zwykłych administratorów,
- podlegać monitoringowi logowania,
- uruchamiać alert natychmiast po użyciu,
- być okresowo testowane.
Najczęściej pomijany jest ostatni punkt. Konto break-glass, którego nikt nie sprawdzał od półtora roku, jest tylko założeniem. Mogło zostać objęte nową polityką, zmieniły się jego metody uwierzytelnienia, wygasło poświadczenie albo procedura dostępu znajduje się w systemie, do którego bez Entra ID również nie da się wejść.
Test awaryjny powinien więc sprawdzać cały łańcuch, nie tylko istnienie użytkownika.
Drugi problem to utrata urządzenia z passkey. W przypadku administratora nie można opierać odzyskiwania na procedurze typu „zadzwoń do helpdesku, a ktoś zresetuje MFA”, jeżeli ten sam helpdesk nie ma prawa zmieniać metod uprzywilejowanemu administratorowi albo jego pracownicy również zostali objęci problematyczną polityką.
Należy z góry określić:
- kto może unieważnić utracone poświadczenie,
- kto wystawia Temporary Access Pass,
- jak potwierdzana jest tożsamość administratora,
- kto może przywrócić dostęp, gdy podstawowy zespół IAM jest niedostępny,
- jak szybko można przeprowadzić taką procedurę poza standardowymi godzinami pracy.
Dla dużej firmy różnica między „mamy passkeys” a „mamy proces awaryjnego dostępu” jest ogromna. Pierwsze opisuje metodę techniczną. Drugie mówi, czy firma będzie w stanie administrować środowiskiem podczas incydentu.
Polskie organizacje mają dodatkowy powód, żeby traktować ten temat poważnie. Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa wdrażająca wymagania NIS2 weszła w życie 3 kwietnia 2026 r. i znacząco rozszerzyła grupę podmiotów kluczowych i ważnych. Sama NIS2 wskazuje stosowanie uwierzytelnienia wieloskładnikowego lub ciągłego tam, gdzie jest ono odpowiednie do ryzyka. Nie oznacza to jednak, że regulator wymaga bezrefleksyjnego zablokowania każdego konta administracyjnego jednym typem passkey. Kontrola bezpieczeństwa musi pozostać proporcjonalna i operacyjnie wykonalna.
W praktyce dojrzałe wdrożenie powinno mieć dwa cele jednocześnie: atakujący nie może łatwo wyłudzić poświadczenia, ale organizacja nie może utracić kontroli nad systemem po zgubieniu jednego klucza albo błędnej zmianie Conditional Access.
Najbardziej irytująca cecha passkeys w środowisku firmowym nie wynika z samej kryptografii. Problemem jest fragmentacja ekosystemu: różne przeglądarki, systemy operacyjne, polityki urządzeń, mechanizmy synchronizacji i modele kluczy sprzętowych potrafią zachowywać się inaczej. Test wykonany na Windows 11 z Edge nie dowodzi jeszcze, że procedura zadziała identycznie na zapasowym MacBooku, telefonie administratora i stacji uprzywilejowanego dostępu.
Dlatego testować trzeba konkretne kombinacje urządzenia, systemu, przeglądarki i metody logowania, a nie samo pole wyboru w panelu administratora.
W przypadku środowisk o podwyższonych wymaganiach bezpieczeństwa pomocne jest również zewnętrzne sprawdzenie konfiguracji IAM, polityk dostępu i scenariuszy awaryjnych przed wymuszeniem nowych metod dla wszystkich kont uprzywilejowanych. Więcej informacji na: https://sajo.pl
FAQ
Czy passkey automatycznie oznacza MFA?
Nie należy patrzeć wyłącznie na liczbę ekranów podczas logowania. Passkey może spełniać wymagania wieloskładnikowego uwierzytelnienia dzięki połączeniu posiadania urządzenia lub klucza z lokalną weryfikacją użytkownika, np. PIN-em lub biometrią. O tym, czy konkretna metoda spełnia wymaganą authentication strength, decyduje jednak konfiguracja platformy i polityki.
Czy Microsoft Authenticator wystarczy przy polityce Phishing-resistant MFA?
Nie każda metoda Authenticatora spełnia phishing-resistant MFA. Klasyczne zatwierdzanie powiadomień czy kody OTP nie są tym samym co passkey. Trzeba sprawdzać konkretną metodę uwierzytelnienia, a nie sam fakt posiadania aplikacji.
Czy SMS powinien zostać jako awaryjny drugi składnik administratora?
Nie jako metoda spełniająca wymaganie phishing-resistant MFA. SMS może występować w innych procesach, jeśli polityka organizacji na to pozwala, ale nie powinien być traktowany jako równoważny passkey lub FIDO2 dla dostępu uprzywilejowanego.
Czy wystarczy jeden klucz FIDO2 na administratora?
Technicznie administrator może działać z jednym kluczem. Operacyjnie to słaby projekt. Utrata lub uszkodzenie klucza natychmiast tworzy incydent dostępności. Dla kont uprzywilejowanych lepiej zapewnić drugą niezależną metodę spełniającą wymaganą siłę uwierzytelnienia.
Czy konto break-glass trzeba wyłączyć ze wszystkich zabezpieczeń?
Nie. Powinno być wyłączone przede wszystkim z tych polityk, które mogą spowodować lockout, ale jednocześnie musi być bardzo ściśle monitorowane, używane wyłącznie awaryjnie i chronione niezależnym mechanizmem dostępu. „Brak Conditional Access” nie powinien oznaczać „brak kontroli”.
Jak często testować konto awaryjne?
Nie ma jednej częstotliwości odpowiedniej dla każdej organizacji, ale test raz w roku jest zwykle zbyt rzadki przy aktywnie zmienianych politykach IAM. Rozsądny rytm operacyjny to test co kwartał oraz dodatkowo po większej zmianie Conditional Access, metod uwierzytelnienia lub modelu ról.
Co zrobić, jeżeli wszyscy administratorzy zostali już zablokowani?
Najpierw użyć wcześniej przygotowanego konta emergency access i wyłączyć lub skorygować politykę powodującą blokadę. Jeżeli organizacja nie ma działającego konta awaryjnego ani administratora pozostającego poza zakresem problematycznej polityki, odzyskanie dostępu może wymagać eskalacji przez procedury wsparcia dostawcy i potwierdzenia własności środowiska. To właśnie scenariusz, którego projekt IAM powinien nie dopuścić.
Pierwsze działanie przed wymuszeniem passkeys jest więc konkretne: nie włączaj jeszcze polityki dla wszystkich administratorów. Najpierw sprawdź, czy co najmniej dwa niezależne konta uprzywilejowane mają przetestowaną metodę spełniającą phishing-resistant MFA oraz czy działa osobne konto emergency access wyłączone z polityki mogącej spowodować lockout. Dopiero kiedy te trzy ścieżki dostępu zostały faktycznie sprawdzone podczas logowania, przełącz Conditional Access z Report-only na On.
