Jędrzej Boguszyński

Microsoft wyznaczył jasny kierunek: tradycyjne hasła oraz dwuskładnikowe uwierzytelnianie oparte na SMS-ach i połączeniach głosowych odchodzą do lamusa. Od 1 września 2026 roku Passkeys staną się natywną metodą uwierzytelniania w Entra ID, a od 1 lutego 2027 roku obsługa tych przestarzałych metod zostanie całkowicie wyłączona.

Wraz z wycofaniem przestarzałych metod uwierzytelniania Microsoft wymusi także korzystanie z passkeys w aplikacji Microsoft Authenticator. Oznacza to, że tradycyjne komunikaty push wymagające przepisania cyfr przestaną być domyślną metodą działania aplikacji (mimo że Microsoft nie komunikuje tego jeszcze wprost). Jeżeli zarządzasz tożsamościami w Entra ID, mogłeś już zauważyć, że po zalogowaniu z użyciem MFA, portal wymusza konfigurację passkey, mimo że masz już ustawiony drugi składnik. To jest właśnie główna przyczyna.

Passkeys nie są już tylko opcjonalną funkcją do wdrożenia „na kiedyś”. To fundamentalna zmiana architektury bezpieczeństwa i całej strategii Microsoftu. W tym wpisie dowiesz się, dlaczego Passkeys stały się nowym standardem, jak krok po kroku wdrożyć je w organizacji i na co uważać z poziomu security. Zapraszam do lektury!

Dlaczego Microsoft wymusza migracje?

Microsoft podjął tę decyzję ze względu na nasilające się ataki phishingowe w dobie AI, która znacząco ułatwia atakującym przygotowanie wiarygodnych treści czy podszywanie się pod konkretne osoby. Klasyczne wiadomości SMS, połączenia głosowe, a nawet kody OTP z aplikacji Authenticator są podatne na ataki typu Adversary-in-the-Middle (AiTM). Atakujący przy użyciu wyspecjalizowanych (często darmowych) narzędzi oraz wsparcia ze strony AI mogą w łatwy sposób przechwycić te poświadczenia i wykorzystać je do uzyskania dostępu do konta użytkownika. Coś, co miało nam zapewnić pełną ochronę, w ciągu kilku lat stało się przestarzałe i nieskuteczne.

Dlaczego Passkeys to najbezpieczniejsza opcja autentykacji?

Passkeys są bezpieczniejsze od tradycyjnych metod dwuskładnikowego uwierzytelniania z kilku kluczowych przyczyn:

• Kryptografia klucza publicznego zamiast współdzielonego sekretu: Entra ID przechowuje wyłącznie klucz publiczny. Klucz prywatny nigdy nie opuszcza bezpiecznego modułu na urządzeniu użytkownika (TPM, Secure Enclave czy fizycznego klucza FIDO2). Dla mniej technicznych osób warto dodać, że proces ten przypomina działanie zamka i unikalnego klucza: serwer wystawia „zamek”, a Twoje urządzenie dopasowuje do niego jedyny właściwy „klucz prywatny”. Dzięki temu nikt postronny nie jest w stanie zalogować się na konto, a złamanie takiej architektury bez użycia komputerów kwantowych jest praktycznie niemożliwe.
• Klucz przechowywany lokalnie: Tak jak wspomniałem wyżej, klucz prywatny znajduje się bezpośrednio na urządzeniu, z którego użytkownik się loguje (np. na komputerze), albo musi znajdować się w jego fizycznym zasięgu (gdy logujemy się na komputerze, używając passkey z telefonu przez Bluetooth).
• Przypisanie do domeny (Domain Binding): Klucz passkey jest kryptograficznie powiązany z konkretnym adresem (np. login.microsoftonline.com). Jeżeli użytkownik trafi na fałszywą stronę stworzoną przez przestępców, przeglądarka po prostu nie wyśle poświadczeń, ponieważ domena nie będzie się zgadzać. Daje to automatyczną blokadę phishingową.
• Wygoda użytkownika: Logowanie sprowadza się najczęściej do użycia biometrii (Windows Hello, Face ID, Touch ID) lub przyłożenia klucza sprzętowego. Brak konieczności pamiętania haseł i przepisywania kodów cyfrowych znacząco podnosi komfort pracy.

Możliwości stosowania Passkeys

Passkeys możemy stosować na wiele sposobów, w zależności od tego, jak wygląda sytuacja sprzętowa w naszej firmie. Najczęstsze scenariusze to:

• Windows: W systemie Windows najwygodniej skorzystać z rozwiązania Windows Hello for Business, czyli logowania biometrycznego (skan twarzy przez kamerę lub odcisk palca) albo dedykowanego kodu PIN (którego złożoność i długość możemy skonfigurować centralnie, np. przez Microsoft Intune). Klucze prywatne są bezpiecznie przechowywane w module TPM na płycie głównej komputera.
• macOS: Na urządzeniach firmy Apple możemy wykorzystać passkeys powiązane z biometrią (Touch ID / Face ID), których klucze prywatne są bezpiecznie chronione przez sprzętowy moduł Secure Enclave. Domyślnie system zapisuje je w usłudze iCloud Keychain, co czyni je kluczami synchronizowanymi (Synced Passkey). Jeśli jednak w Entra ID zablokujemy klucze typu Synced, użytkownicy MacOS nadal będą mogli logować się biometrią, system utworzy wówczas lokalny klucz typu Device-bound, przypisany wyłącznie do tego jednego komputera.
• Android / iOS (aplikacja Microsoft Authenticator): Passkey możemy wygenerować bezpośrednio w aplikacji MS Authenticator na smartfonie. Przy pierwszym logowaniu na nowym komputerze aplikacja poprosi o zeskanowanie kodu QR z ekranu, aby sparować urządzenia. Kolejne logowania idą już sprawniej po Bluetooth, po prostu potwierdzamy tożsamość biometrią na telefonie. Jest to opcja wymagająca kilku kroków, przez co bywa nieco mniej wygodna w codziennym użytkowaniu.
• Fizyczne klucze FIDO2: Sprzętowe klucze (np. YubiKey) wpinane do portu USB lub komunikujące się przez NFC. Passkey zapisywany jest bezpośrednio w pamięci klucza. Aby się zalogować, wpinamy klucz, podajemy PIN na komputerze i dotykamy płytki na kluczu (lub używamy czytnika linii papilarnych, jeśli posiadamy model z biometrią). Aktualnie jest to najbardziej odporna na ataki metoda, choć trzeba pamiętać o zarządzaniu ryzykiem zagubienia takiego klucza przez użytkownika.

Jak uruchomić rejestrację Passkeys w Entra ID?

Pamiętaj, że modyfikacja metod uwierzytelniania w Entra ID wymaga uprawnień Global Administratora lub Authentication Policy Administratora.

Aby włączyć nową metodę, przechodzimy do portalu Entra Admin Center, a następnie do sekcji:

Protection -> Authentication methods -> Policies.

W tym miejscu możemy włączyć wybrane metody uwierzytelniania dla wskazanych grup użytkowników (lub całej organizacji). Klikamy na metodę Passkey (FIDO2), aby przejść do jej szczegółowej konfiguracji.

W sekcji Enable and target ustawiamy przełącznik Enable na pozycję On. Z kolei w zakładce Include wybieramy grupy użytkowników, dla których ta funkcja ma być dostępna, oraz przypisujemy do nich odpowiedni profil. Warto od razu wykluczyć konta, które nie powinny z niej korzystać (np. konta gości czy konta serwisowe), zrobimy to w sekcji Exclude.

Zanim zapiszemy zmiany, przechodzimy jeszcze do zakładki Configure. Musimy upewnić się, że opcja Allow self-service set-up jest zaznaczona, dzięki temu użytkownicy będą mogli samodzielnie zarejestrować swój passkey.

W tej samej zakładce konfigurujemy także typy akceptowanych kluczy. Upewnijmy się, że nasza polityka zezwala na klucze typu Device-bound (powiązane bezpośrednio ze sprzętem, takie jak fizyczne klucze FIDO2, Windows Hello for Business czy lokalny moduł Secure Enclave na komputerach Mac) oraz (jeśli tego wymaga nasza organizacja) na klucze typu Synced (synchronizowane w chmurze, np. iCloud Keychain czy Google Password Manager).

Przy kluczach typu Synced należy jednak mocno uważać. Ustawienie to pozwala użytkownikom na synchronizację passkey z ich osobistymi menedżerami haseł i kontami chmurowymi. Jeśli pracownik zsynchronizuje służbowy klucz z prywatnym kontem Apple ID lub Google, może on wyciec poprzez prywatne, niekontrolowane urządzenia, na których to konto również jest zalogowane.

Na koniec zapisujemy całą konfigurację i przechodzimy do kolejnej metody, czyli Microsoft Authenticator.

Jeśli chcemy, aby nasi użytkownicy mogli używać Passkeys w aplikacji Authenticator, w ustawieniu Authentication mode musimy wybrać opcję Any (Push + Passwordless) lub Passwordless.

Po zapisaniu zmian cała konfiguracja jest gotowa, możemy oficjalnie ruszać z wdrożeniem i przechodzić na passkeys w naszej organizacji.

Microsoft automatycznie zachęca użytkowników do konfiguracji Passkeys, a proces ten będzie stawał się coraz bardziej intensywny w miarę zbliżania się do finalnej daty wyłączenia starych metod (1 lutego 2027 roku). Jako administratorzy Entra ID możemy samodzielnie uruchomić taką kampanię, aby sprawnie zonboardować użytkowników. Służy do tego zakładka Entra ID -> Authentication methods -> Registration campaign.

Warto jednak pamiętać, że wbudowane kampanie w Entra ID wspierają obecnie głównie aplikację Microsoft Authenticator oraz fizyczne klucze FIDO2. Jeśli zależy nam na wymuszeniu korzystania z Passkey bezpośrednio na urządzeniach końcowych (np. przez Windows Hello for Business), musimy posłużyć się systemem klasy MDM, na przykład Microsoft Intune.

Jak zrobić sprawny rollout w firmie?

Wdrożenie tej technologii wiąże się ze zmianą nawyków użytkowników i potencjalnym utrudnieniem im codziennej pracy. Może to wywołać spory backlash, dlatego warto podejść do tematu ostrożnie i podzielić cały proces na wyraźne fazy:

• Faza 1 – Pilotaż na grupie IT/Security: Najlepiej zacząć od grupy złożonej z użytkowników technicznych, którzy dobrze znają środowisko Entra ID. Przetestuj działanie kluczy na wszystkich platformach używanych w firmie. To także idealny moment na budowanie wewnętrznego know-how, dokumentacji dla Helpdesku oraz prostych instrukcji step-by-step dla użytkowników końcowych, które będą kluczowe w kolejnych etapach.
• Faza 2 – Komunikacja i jeszcze raz komunikacja: Wyślij informacje o nadchodzących zmianach wszystkimi możliwymi kanałami (e-mail, Teams, intranet), aby wiadomość dotarła do jak najszerszego grona użytkowników. Wiadomo, że i tak wielu pracowników tego nie przeczyta, ale Twój dział będzie kryty (wiem to z doświadczenia). Poinformuj użytkowników na dwa tygodnie przed startem, przypomnij na kilka dni przed rolloutem, a w trakcie procesu informuj o postępach i ewentualnych utrudnieniach. Wskaż też jasny kanał kontaktowy do zgłaszania problemów. Im większa transparentność, tym mniejszy chaos i spokojniejszy sen dla działu IT.
• Faza 3 – Rollout na małych grupach: Uruchamiaj kampanię rejestracji w Entra ID lub wymuszaj passkey przez Microsoft Intune stopniowo, pracując na niewielkich grupach użytkowników. Wielkość grup dostosuj do mocy przerobowych Twojego Helpdesku, aby w razie problemów nikt nie został bez wsparcia. Do każdej fali rozsyłaj łopatologicznie napisaną instrukcję, aby każdy był w stanie samodzielnie skonfigurować swój klucz.
• Faza 4 – Domykanie migracji i wsparcie pomigracyjne: Gdy zakończysz onboarding, upewnij się, że wszyscy użytkownicy potrafią bez problemu logować się nową metodą. Zadbaj o gotowe procedury odzyskiwania dostępu na wypadek zagubienia lub uszkodzenia urządzenia. Dopiero gdy masz 100% pewności, że proces przebiegł pomyślnie, możesz wyłączyć stare metody uwierzytelniania i zaktualizować polityki Conditional Access, wymuszając logowanie wyłącznie przez Passkeys.

Na co uważać z punktu widzenia cyberbezpieczeństwa?

Na koniec kilka kluczowych kwestii, o których trzeba pamiętać pod kątem bezpieczeństwa, infrastruktury i architektury:

• User Experience na macOS: Nie jest to stricte problem czysto technicznego bezpieczeństwa, jednak pomieszanie pojęć i złe wdrożenie może pośrednio doprowadzić do luk w ochronie (a na pewno wywoła spory stres u użytkowników i Helpdesku). MacOS domyślnie używa kluczy Synced poprzez iCloud Keychain, co w wielu organizacjach jest blokowane. W praktyce, aby uniknąć błędów i zamieszania wśród użytkowników Maców, proces rejestracji kluczy Device-bound na urządzeniach Apple najlepiej nadzorować poprzez MDM (np. Microsoft Intune) i profilami konfiguracji ograniczyć lub odpowiednio ustawić zachowanie iCloud Keychain.
• Synced Passkeys: Tak jak wspomniałem wcześniej, klucze zsynchronizowane z chmurą lub zewnętrznymi menedżerami haseł to ryzyko, które trzeba dokładnie przeanalizować. Zalecałbym zezwolenie na tę metodę uwierzytelniania tylko wtedy, gdy macie pewność, że jest ona absolutnie niezbędna w Waszej organizacji (w przeciwnym razie może ona prowadzić do incydentu bezpieczeństwa).
• Tymczasowy dostęp i odzyskiwanie konta (TAP): Jeśli użytkownik zgubi swój fizyczny klucz FIDO2 lub zmieni telefon, nie będzie mógł sam odzyskać dostępu, gdyż tradycyjne metody dwuskładnikowego uwierzytelniania (jak SMS czy połączenie głosowe) będą zablokowane. Na takie sytuacje warto włączyć w Entra ID funkcję Temporary Access Pass (TAP). Jest to generowane przez Helpdesk jednorazowe hasło o ograniczonym czasie działania, które pozwala użytkownikowi zalogować się do konta i zarejestrować nowy passkey.
• Zgubione lub skradzione urządzenie: Passkey na skradzionym laptopie czy telefonie nadal jest chroniony biometrią lub PIN-em, ale dział IT musi posiadać odpowiednią procedurę, aby taki sprzęt sprawnie wyrejestrować i zdalnie wyczyścić z danych firmowych. Najlepiej przeprowadzić to z poziomu Microsoft Intune oraz profilu użytkownika w Entra ID.
• Środowiska współdzielone: Passkeys przypisane do konkretnego urządzenia świetnie sprawdzają się na laptopach przypisanych do jednego pracownika. Przy stanowiskach współdzielonych (np. w fabrykach czy na kioskach) lokalne klucze Device-bound potrafią stworzyć chaos. W takim scenariuszu najlepiej sprawdzą się fizyczne klucze FIDO2 (np. YubiKey).
• Obsługa starych aplikacji (Legacy): Passkeys świetnie działają w systemach obsługujących nowoczesne metody uwierzytelniania (Modern Auth). Jeśli w firmie istnieją starsze aplikacje, które ich nie wspierają, warto je wcześnie namierzyć i zweryfikować możliwości integracji przed odcięciem dotychczasowych metod.
• Prywatne telefony (BYOD): Wykorzystanie prywatnych smartfonów do logowania firmowego za pomocą Passkeys bywa kuszące ze względu na brak dodatkowych kosztów sprzętowych. Trzeba jednak pamiętać, że są to urządzenia niezarządzane przez firmowy MDM (chyba że wdrażacie na nich osobne profile służbowe/MAM, co jest dobrą praktyką). Brak kontroli IT nad prywatnym sprzętem zwiększa ryzyko wycieku kluczy i wystąpienia incydentu bezpieczeństwa.
• Środowiska hybrydowe (On-premise AD / Kerberos): Jeśli Twoja firma korzysta ze środowiska hybrydowego (lokalne Active Directory powiązane z Entra ID), samo włączenie Passkeys w chmurze nie wystarczy do płynnego dostępu do zasobów lokalnych (np. udziałów sieciowych SMB, drukarek czy aplikacji opartych na Kerberosie). Aby użytkownicy logujący się Passkey mogli bezproblemowo autoryzować się w lokalnym AD bez wpisywania tradycyjnego hasła, konieczne jest wcześniejsze skonfigurowanie usługi Microsoft Entra Kerberos (lub infrastruktury Cloud Kerberos Trust).