Passkeys bez mgły

Cztery role i jedna ważna granica

W typowym przepływie WebAuthn uczestniczą: usługa, klient i authenticator. „Klientem” jest zwykle przeglądarka z systemem operacyjnym. „Authenticatorem” może być Windows Hello, menedżer passkeys telefonu, Microsoft Authenticator albo fizyczny klucz FIDO2.

Osiem pojęć, których nie warto sklejać

WebAuthn

Webowe API i protokół używania poświadczeń klucza publicznego. Może zastąpić hasło albo działać jako kolejny składnik — samo słowo WebAuthn nie gwarantuje „passwordless”.

Passkey

W WebAuthn Level 3: poświadczenie wykrywalne przez klienta (discoverable credential). Authenticator potrafi odnaleźć je dla RP ID bez listy credential IDs przesłanej przez serwer. W3C: discoverable credential

Passwordless

Logowanie bez hasła współdzielonego z usługą. Lokalny PIN, kod blokady urządzenia lub biometria mogą nadal odblokowywać użycie passkey; nie są przez to hasłem do witryny.

Authenticator

Komponent zarządzający poświadczeniem i wykonujący operację kryptograficzną. Może być platformowy (telefon, komputer, aplikacja) albo przenośny (security key).

RP ID i origin

RP ID to domenowy zakres credential, np. example.com. origin obejmuje schemat, host i port, np. https://login.example.com. Serwer sprawdza oba w odpowiednich miejscach.

Credential ID

Nieprzezroczysty identyfikator rekordu poświadczenia. Pomaga odnaleźć klucz publiczny, ale sam nie jest sekretem ani dowodem logowania.

UP / UV

User Presence mówi „ktoś wykonał gest”, np. dotknął klucza. User Verification mówi „authenticator lokalnie zweryfikował osobę”, np. PIN-em lub biometrią. UP nie zastępuje UV.

Attestation / assertion

Attestation może opisać pochodzenie i właściwości authenticatora podczas rejestracji. Assertion to świeży, podpisany dowód używany przy logowaniu. Attestation nie potwierdza tożsamości naturalnej osoby.

Co dokładnie dzieje się przy „Utwórz passkey”

Rejestracja dopisuje nowy publiczny klucz do istniejącego konta. Najbardziej ryzykowny moment nie polega na generowaniu pary, lecz na odpowiedzi na pytanie: kto ma prawo dodać temu kontu nowy authenticator? Dlatego usługa powinna wymagać świeżego, silnego uwierzytelnienia przed enrolmentem.

1. serwer RP Tworzy jednorazowy challenge

   Serwer wiąże losowe wyzwanie z sesją, kontem, zamierzoną operacją, dozwolonym originem, RP ID i czasem wygaśnięcia. W3C zaleca co najmniej 16 bajtów entropii. W3C §13.4.3

2. skrypt RP Wywołuje navigator.credentials.create()

   Opcje wskazują RP, nieprzezroczysty user.id, dozwolone algorytmy oraz wymagania, np. credential wykrywalny i userVerification: "required".

3. przeglądarka / client Sprawdza zakres domeny

   Przeglądarka nie pozwala dowolnej stronie zażądać credential dla cudzej domeny. Pokazuje systemowy wybór: lokalny authenticator, menedżer passkeys, telefon lub klucz sprzętowy.

4. authenticator Potwierdza UP/UV i generuje parę

   Potwierdza obecność użytkownika. Jeśli polityka wymaga UV, lokalnie sprawdza PIN, blokadę urządzenia lub biometrię; w pokazanym dalej wariancie passwordless ustawiono userVerification: "required". Tworzy nowy credential związany z RP ID. Klucz prywatny pozostaje pod jego kontrolą; publiczny wróci do RP.

5. przeglądarka / client Buduje odpowiedź rejestracyjną

   clientDataJSON niesie m.in. typ webauthn.create, challenge i faktyczny origin. attestationObject niesie authenticator data, credential ID i publiczny klucz oraz — zależnie od polityki — attestation.

6. serwer RP Weryfikuje, a dopiero potem zapisuje

   Sprawdza challenge, typ, origin, rpIdHash, flagi UP/UV, algorytm, strukturę i politykę attestation oraz unikalność credential ID. Po sukcesie zapisuje klucz publiczny i metadane. Pełna procedura: W3C §7.1.

Logowanie: świeży podpis, nie powtórka starego kodu

1. serwer RP Wysyła nowy challenge

   W przepływie username-first może także wysłać listę credential IDs. Przy passkey wykrywalnym może pominąć allowCredentials; wtedy authenticator pokaże konta pasujące do RP ID.

2. skrypt RP Wywołuje navigator.credentials.get()

   Przeglądarka przekazuje wyzwanie do właściwego authenticatora i pokazuje systemowy interfejs wyboru.

3. authenticator Znajduje credential i potwierdza UP/UV

   Passkey jest wyszukiwany według RP ID. Authenticator potwierdza obecność; jeżeli polityka wymaga UV, użytkownik odblokowuje użycie lokalnym PIN-em lub biometrią. Przy preferred odpowiedź może legalnie mieć UV=0, więc serwer sprawdza faktyczną flagę, nie samo żądanie.

4. authenticator Podpisuje kontekst

   Podpis obejmuje authenticator data i skrót client data. W tych danych znajdują się m.in. hash RP ID, flagi UP/UV, challenge, origin i typ operacji.

5. serwer RP Odtwarza warunki i sprawdza podpis

   Odnajduje zapisany publiczny klucz po credential ID, wiąże odpowiedź z właściwym kontem, porównuje challenge, origin, rpIdHash i flagi, a następnie weryfikuje podpis.

6. serwer RP Zużywa challenge i tworzy sesję

   Sesja powstaje dopiero po pełnym sukcesie. Ten sam challenge nie może posłużyć ponownie. Pełna procedura: W3C §7.2.

credential ID wybiera rekord, ale dopiero poprawny podpis dowodzi kontroli nad prywatnym kluczem. Licznik podpisów może być sygnałem klonowania lub awarii, lecz przy passkeys wielourządzeniowych nie jest samodzielnym dowodem ataku.

Dlaczego passkey opiera się phishingowi

Odporność nie zależy od tego, czy użytkownik dostrzeże literówkę w domenie. Powstaje z technicznego związania credential i podpisu z właściwym verifierem.

1. Każdy RP otrzymuje osobną parę kluczy.
2. Klient wymusza relację origin–RP ID.
3. Authenticator wiąże credential z RP ID i podpisuje jego hash.
4. Faktyczny origin i challenge trafiają do podpisywanego kontekstu.
5. Serwer odrzuca nieoczekiwany origin, hash RP ID albo zużyty challenge.

NIST nazywa ten mechanizm verifier name binding. Kody OTP i odpowiedzi przepisywane ręcznie nie są według NIST phishing-resistant, ponieważ oszust może przechwycić lub przekazać kod do prawdziwego serwera w czasie rzeczywistym. NIST §3.2.5

„Gdzie jest klucz?” ma więcej niż dwie odpowiedzi

Public-key credential w WebAuthn może być wykrywalny lub niewykrywalny, ale passkey w terminologii WebAuthn Level 3 jest credentialem wykrywalnym. Pozostałe osie są niezależne: miejsce i mobilność klucza, rodzaj authenticatora oraz sposób użycia z innego urządzenia. W3C: passkey / discoverable credential

W WebAuthn flagi BE (Backup Eligible) i BS (Backup State) rozróżniają możliwość oraz aktualny stan backupu. BE=1 nie dowodzi, że credential został już zsynchronizowany. W3C §6.1.3

Jak dodać passkey „w przeglądarce”

Przepływ uniwersalny

1. Zaloguj się do usługi dotychczasową metodą i otwórz Bezpieczeństwo / Metody logowania.
2. Wybierz Utwórz passkey, Dodaj klucz dostępu albo funkcjonalny odpowiednik.
3. W oknie przeglądarki lub systemu wybierz miejsce: menedżer synchronizowany, ten komputer/telefon, inne urządzenie albo security key.
4. Potwierdź operację lokalną blokadą urządzenia: PIN-em, twarzą lub odciskiem.
5. Nazwij credential po stronie usługi tak, by później rozpoznać urządzenie.
6. Sprawdź, czy masz drugi niezależny authenticator albo świadomie zaprojektowane recovery.

Przykład: Chrome i Google Password Manager na Androidzie

1. Na stronie obsługującej passkeys wybierz utworzenie klucza.
2. W systemowym oknie wybierz Create / Utwórz i potwierdź blokadą ekranu.
3. Credential zostanie zapisany w Google Password Manager i może synchronizować się na urządzenia zalogowane do tego samego konta Google.
4. Zarządzaj nim w aplikacji Passwords albo w Chrome: Settings → Google Password Manager → Passkeys. Etykiety zależą od wersji.

Google wymaga na Androidzie wersji 9 lub nowszej i blokady ekranu. Google Chrome Help

Przykład: iPhone i iCloud Keychain

1. W ustawieniach konta na obsługiwanej stronie wybierz utworzenie passkey i naciśnij Continue.
2. Potwierdź Face ID, Touch ID lub kodem urządzenia.
3. Credential pojawi się w aplikacji Passwords i zsynchronizuje przez iCloud Keychain, jeśli ta funkcja i 2FA Apple Account są włączone.
4. Usuniesz go w Passwords → Passkeys → konto → Edit → Delete Passkey; pamiętaj też o usunięciu rejestracji po stronie usługi, jeśli nie propaguje się automatycznie.

Apple: passkeys na iPhonie

Przykład: prywatne konto Microsoft

1. Otwórz account.live.com/proofs/manage i wybierz Add a new way to sign in or verify.
2. Wybierz Face, Fingerprint, PIN, or Security Key, a następnie kontynuuj tworzenie.
3. W systemowym oknie wybierz Microsoft Password Manager lub innego providera, lokalny Windows Hello, telefon albo fizyczny security key.
4. Potwierdź lokalnie i sprawdź nową metodę na stronie zabezpieczeń konta.

To przepływ konta konsumenckiego. Nie należy utożsamiać go z dedykowanym Passkey in Microsoft Authenticator dla kont Entra work/school. Microsoft Support: create and save a passkey

Przykład: fizyczny security key

1. Rozpocznij dodawanie passkey w witrynie i wybierz Inne opcje / Security key.
2. Podłącz klucz USB, zbliż NFC albo użyj odpowiedniego transportu.
3. Podaj PIN klucza, jeśli jest wymagany, i dotknij sensora.
4. Zarejestruj drugi zapasowy klucz i trzymaj go w innym bezpiecznym miejscu.

Przykład: QR z telefonu na komputer

1. Na komputerze wybierz Use a passkey from another device / Telefon lub tablet.
2. Zeskanuj QR zwykłym aparatem telefonu i potwierdź bliskość, Bluetooth oraz połączenie sieciowe, gdy platforma o to poprosi.
3. Odblokuj passkey na telefonie biometrią lub PIN-em.

Rezultat: telefon podpisał logowanie; passkey nie został przeniesiony na komputer. Nie skanuj niespodziewanego QR otrzymanego w wiadomości — inicjuj ten przepływ samodzielnie z ekranu logowania.

Microsoft Authenticator: passkey to nie starsze phone sign-in

Dokumentacja dedykowanego providera Passkey in Microsoft Authenticator dotyczy Entra, czyli kont organizacyjnych. Dla prywatnego konta Microsoft oficjalny kreator może użyć Windows Hello, security key, telefonu lub dostawcy systemowego; samo skanowanie QR aplikacją Authenticator nie dowodzi, że klucz zapisano właśnie w niej.

Warunek zerowy: administrator Entra

1. W Entra admin center otwiera Entra ID → Security → Authentication methods → Policies → Passkey (FIDO2).
2. Włącza self-service i przypisuje profil do wybranej grupy, określając typy passkeys, attestation oraz ewentualne ograniczenia AAGUID.
3. Prowadzi pilotaż przed objęciem wszystkich; organizacja może świadomie ograniczyć miejsca zapisu.

Microsoft Learn: włączenie Passkey (FIDO2)

Rejestracja bezpośrednio w Authenticator

1. Zainstaluj Microsoft Authenticator, wybierz Work or school account i dodaj konto organizacyjne.
2. Otwórz konto w aplikacji i wybierz Create a passkey, a następnie ukończ wymagane MFA.
3. Jeśli aplikacja tego wymaga, najpierw ustaw blokadę ekranu urządzenia.
4. Włącz Authenticator jako systemowego providera passkeys:
   • iOS 18: Settings → General → AutoFill & Passwords;
   • iOS 17: Settings → Passwords → Password Options;
   • Android: systemowe Passwords & accounts → Additional providers → Authenticator.
5. Wróć do Authenticator, dokończ kreator i wybierz Done.
6. Sprawdź nową metodę na mysignins.microsoft.com/security-info i zarejestruj alternatywę na wypadek utraty telefonu.

Alternatywnie: Security info → Add sign-in method → Passkey in Microsoft Authenticator. Przy wymuszonym attestation Microsoft wymaga bezpośredniej rejestracji w aplikacji; przepływ cross-device nie dostarczy wtedy oczekiwanego attested passkey. Aktualne wymagania to iOS 17+ lub Android 14+; na Androidzie 14 Microsoft może zalecić przejście do Androida 15, jeśli system nie pozwala wybrać providera. Microsoft Learn: rejestracja w Authenticator

Microsoft Entra: co kończy się 1 lutego 2027

Dokładna zmiana: Microsoft wycofuje własną telekomunikacyjną dostawę SMS i połączeń głosowych w Microsoft Entra ID. Nie jest to uniwersalny zakaz SMS, nie dotyczy automatycznie prywatnych kont wszystkich dostawców i nie oznacza, że organizacja nigdy nie może kupić obsługi SMS od zewnętrznego operatora. Microsoft Learn: harmonogram wycofania

Cztery mechanizmy, które brzmią jak „migracja”, ale robią coś innego

Microsoft: system-preferred authentication

1. 1 września
   2026

   Passkeys stają się domyślnym kierunkiem

   Użytkownicy włączeni dla SMS lub voice są automatycznie obejmowani metodą passkey i kampanią rejestracji. Po ukończeniu MFA otrzymują zachętę do utworzenia passkey. Domyślnie zachętę można jeszcze odraczać.

2. 18 września
   2026

   Informacje o operatorach zewnętrznych

   Microsoft zapowiada publikację obsługiwanych dostawców telekomunikacyjnych w Security Store dla organizacji z rzeczywistą potrzebą SMS/voice.

3. 30 października
   2026

   Konfiguracja własnego providera

   Ma ruszyć ścieżka Choose Your Own Telephony Provider. Organizacja przejmuje umowę, koszty, dostępność, konfigurację i monitoring dostawy.

4. 1 lutego
   2027

   Microsoft-provided SMS i voice przestają działać

   Nie ma opt-outu od końcowego egzekwowania. Bez zewnętrznego providera użytkownik, którego jedyną metodą było SMS/voice, dostanie blokujący obowiązek rejestracji passkey przed dalszym logowaniem.

Co to oznacza dla użytkownika

• Telefon z samą możliwością odbierania SMS przestaje wystarczać w domyślnym modelu Entra.
• Jeśli Microsoft-managed SMS/voice jest jedyną metodą MFA i organizacja nie wybiera własnego operatora, przed lutym trzeba dodać metodę zastępczą; w przeciwnym razie logowanie wymusi blokującą rejestrację passkey.
• Istniejący push lub TOTP może zachować ciągłość dostępu, a własny provider może zachować telefoniczne MFA. Te warianty nie realizują jednak rekomendowanego celu phishing-resistant.
• Po terminie wymuszona rejestracja może zablokować pracę, jeśli urządzenie jest niezgodne, współdzielone, offline albo polityka organizacji wyklucza dostępnego providera.
• Passkey w Microsoft Authenticator wymaga smartfona z blokadą ekranu i zgodnej wersji systemu; nie jest dobrym jedynym rozwiązaniem dla każdej populacji.

Co to oznacza dla administratora

• Trzeba znaleźć nie tylko użytkowników enabled dla SMS/voice, lecz przede wszystkim tych, którzy faktycznie polegają wyłącznie na tych kanałach.
• Najpierw należy włączyć właściwe profile passkey, sprawdzić platformy, attestation, Conditional Access i recovery, a dopiero potem wygaszać stare metody.
• Frontline, urządzenia współdzielone, użytkownicy bez nowoczesnego telefonu, dostępność i procedury awaryjne wymagają osobnych ścieżek — często sprzętowych kluczy lub metod organizacyjnych.
• Jeżeli SMS pozostaje wymogiem regulacyjnym lub operacyjnym, potrzebny jest obsługiwany operator, funkcja routingu w Azure, pilotaż i nowy podział odpowiedzialności.
• Zewnętrzny provider może podtrzymać SMS/voice jako MFA, ale nie zachowuje SMS sign-in jako podstawowej metody logowania. Microsoft FAQ o providerach
• Natywne SMS/voice znikają również z SSPR; własny provider może je tam obsłużyć, ale passkey sam w sobie nie jest automatycznie projektem resetowania hasła.

Minimalny ślad WebAuthn w JavaScript

Poniższe fragmenty są ilustracyjne. Pokazują granicę przeglądarka–serwer; nie implementują parserów CBOR/COSE, kryptografii, pełnej polityki attestation, ochrony CSRF, rate limitingu ani bezpiecznego recovery.

Rejestracja

// 1. Serwer generuje i zapamiętuje challenge oraz zwraca opcje.
const optionsJSON = await fetch("/webauthn/register/options", {
  method: "POST",
  credentials: "same-origin"
}).then(requireOK).then(r => r.json());

// 2. Pola base64url muszą stać się bajtami ArrayBuffer.
const publicKey = decodeCreationOptions(optionsJSON);

// 3. To wywołanie otwiera systemowy wybór authenticatora.
const credential = await navigator.credentials.create({ publicKey });

// 4. Odpowiedź wraca do serwera; prywatnego klucza w niej nie ma.
await postJSON("/webauthn/register/finish", encodeCredential(credential));

Przykładowy rdzeń opcji dla passkey wykrywalnego i UV-required:

{
  challenge: "<losowe bajty jako base64url>",
  rp: { id: "example.com", name: "Example" },
  user: {
    id: "<nieprzezroczysty userHandle>",
    name: "anna@example.com",
    displayName: "Anna"
  },
  pubKeyCredParams: [
    { type: "public-key", alg: -7 },
    { type: "public-key", alg: -257 }
  ],
  authenticatorSelection: {
    residentKey: "required",
    userVerification: "required"
  },
  attestation: "none"
}

Logowanie

const optionsJSON = await fetch("/webauthn/authenticate/options", {
  method: "POST",
  credentials: "same-origin"
}).then(requireOK).then(r => r.json());

const publicKey = decodeRequestOptions(optionsJSON);
const credential = await navigator.credentials.get({ publicKey });

await postJSON(
  "/webauthn/authenticate/finish",
  encodeCredential(credential)
);

Puste lub pominięte allowCredentials pozwala discoverable passkey wskazać konto przez userHandle. W przepływie username-first serwer może przesłać credential IDs związane z podaną nazwą użytkownika.

Serwerowa lista warunków — nie opcjonalne „szczegóły”

Jak czytać passkeys przez NIST SP 800-63B-4

NIST ocenia cały proces i właściwości authenticatora, nie nazwę produktu. Dwa rozwiązania nazwane „passkey” mogą mieć inne UV, eksportowalność, ochronę sprzętową, attestation, sync fabric i recovery — a więc inny możliwy poziom AAL.

NIST §2: Authentication Assurance Levels

Dlaczego UV zmienia klasyfikację

Posiadanie urządzenia z kluczem to „coś, co masz”. Lokalny PIN lub biometria aktywująca klucz reprezentuje odpowiednio „coś, co wiesz” albo „coś, czym jesteś”. NIST każe inspekować podpisaną flagę UV: bez niej synchronizowalny authenticator należy traktować jako single-factor. NIST Appendix B.3

Synced passkey: wygodniejszy, ale najwyżej AAL2

Synchronizacja wymaga eksportowalności chronionej reprezentacji klucza. NIST dopuszcza ją do AAL2, stawiając wymagania m.in. szyfrowaniu, ochronie konta sync fabric i lokalnemu wykonywaniu operacji kluczem. AAL3 wymaga klucza nieeksportowalnego, więc synced passkey odpada z definicji tego poziomu.

Attestation: dowód o authenticatorze, nie o człowieku

Attestation może pomóc organizacji rozpoznać model i cechy authenticatora. NIST zaleca wykorzystywanie tej możliwości w federal enterprise, lecz mówi, że jej brak nie powinien blokować synchronizowanych authenticatorów w szerokich usługach publicznych. Wymaganie attestation bez uzasadnienia może wypchnąć użytkowników do słabszych fallbacków. NIST Appendix B.3: attestation

Recovery jest częścią assurance

Silny podpis nie pomoże, jeśli napastnik może telefonicznie przekonać help desk do podpięcia nowej metody. NIST opisuje recovery jako osobny, kontrolowany proces z powiadomieniami i wymaganiami zależnymi od poziomu konta. NIST §4.2: Account Recovery

Jak przejść bezpiecznie i nie stracić dostępu

Preferowany przez Microsoft kierunek jest warstwowy: dla typowych użytkowników pierwszym wyborem ma być synced passkey, a dla administratorów i środowisk regulowanych — przede wszystkim sprzętowy klucz FIDO2; passkey w Authenticator i inne metody phishing-resistant uzupełniają tę mapę. Microsoft zaleca co najmniej dwa poświadczenia: jedno przenośne oraz jedno lokalne na regularnie używanym urządzeniu. Microsoft: wdrożenie phishing-resistant passwordless

Checklista użytkownika

• Wiem, u którego providera passkey jest zapisany i czy się synchronizuje.
• Mam co najmniej dwie realne drogi odzyskania dostępu do ważnego konta.
• Drugi authenticator nie jest przechowywany razem z pierwszym w miejscu narażonym na tę samą utratę.
• Konto providera synchronizacji ma silne MFA i aktualne recovery.
• Po utracie urządzenia usuwam credential po stronie usługi, sprawdzam listę urządzeń i unieważniam podejrzane sesje.
• Nie zatwierdzam niespodziewanego tworzenia passkey ani QR z wiadomości.

Checklista administratora

• Inwentaryzuję rzeczywiste użycie metod, populacje urządzeń oraz scenariusze niedostępności — nie tylko stan polityki.
• Rozdzielam profil dla użytkowników mobilnych, współdzielonych stanowisk, administratorów i kont awaryjnych.
• Wymagam UV tam, gdzie passkey zastępuje dwa czynniki, i sprawdzam flagę po stronie verifiera.
• Chronię dodawanie i usuwanie authenticatorów świeżym uwierzytelnieniem oraz powiadomieniem poza bieżącą sesją.
• Testuję utratę telefonu, wymianę urządzenia, brak Bluetooth/sieci, wygaśnięcie sesji i odzyskanie konta.
• Mierzę udane rejestracje i logowania, fallback do słabszych metod, zgłoszenia help desk oraz konta pozostające tylko na SMS.
• Wycofuję słabszą metodę dopiero po potwierdzonym działaniu docelowej i procedury awaryjnej.

Bootstrap, recovery i konta awaryjne

Temporary Access Pass (TAP) może po pozytywnej weryfikacji osoby bezpiecznie uruchomić pierwszą rejestrację albo odtworzenie dostępu. Powinien być krótko ważny i kontrolowany; przy recovery po utracie lub kompromitacji należy następnie usunąć utracony credential. Internal guest może otrzymać TAP w danym tenancie. External guest nie może dostać TAP w tenancie zasobu — może użyć TAP wydanego przez tenant macierzysty tylko przy spełnieniu jego wymagań oraz właściwym zaufaniu MFA w cross-tenant access. Microsoft: Temporary Access Pass

Przed egzekwowaniem nowych zasad organizacja powinna mieć co najmniej dwa niezależne, cloud-only konta emergency access w domenie .onmicrosoft.com, chronione metodą inną niż codzienni administratorzy — np. FIDO2 lub CBA — przechowywane oddzielnie, monitorowane przy każdym użyciu i regularnie testowane. Wyłączenie ich z blokujących zasad musi być wąskie i jawne; to bezpiecznik przed błędem konfiguracji, nie konto do codziennej pracy. Microsoft: emergency access accounts

Źródła pierwotne i zakres

Mechanizm oparto na normatywnej specyfikacji W3C WebAuthn Level 3; wymagania assurance na NIST SP 800-63B-4; instrukcje produktów i harmonogram na bieżącej dokumentacji ich dostawców. Nazwy ekranów mogą zmieniać się szybciej niż mechanizm protokołu.

1. W3C — Web Authentication: An API for accessing Public Key Credentials, Level 3, Recommendation z 25 sierpnia 2026 r.; terminologia, ceremonie, walidacja i bezpieczeństwo.
2. NIST SP 800-63B-4 — Authentication Assurance Levels; wymagania AAL1–AAL3.
3. NIST SP 800-63B-4 — Authenticator and Verifier Requirements; kryptograficzne authenticators, biometria i phishing resistance.
4. NIST SP 800-63B-4 — Appendix B: Syncable Authenticators; UV, BE/BS, attestation, sync fabric i granica AAL2.
5. NIST SP 800-63B-4 — Account Recovery; wymagania cyklu życia i powiadomień.
6. Microsoft Learn — Enable passkeys (FIDO2) in Microsoft Entra ID; profile, zakres, attestation i polityki.
7. Microsoft Learn — Register passkeys in Microsoft Authenticator; wymagania i kroki dla iOS/Android.
8. Microsoft Learn — Microsoft Authenticator authentication method; rozróżnienie passkey oraz passwordless phone sign-in.
9. Microsoft Learn — Passkeys by default and retirement of Microsoft-provided SMS and voice authentication, aktualizacja 10 sierpnia 2026 r.; daty i skutki.
10. Microsoft Learn — FAQ wycofania SMS i voice; zakres public cloud, SSPR, B2B, B2C/External ID i chmur suwerennych.
11. Microsoft Learn — Telephony providers FAQ; zakres zewnętrznego providera i brak wsparcia dla primary SMS sign-in.
12. Microsoft Learn — System-preferred authentication; wybór istniejącej metody, nie migracja poświadczenia.
13. Microsoft Learn — Deploy phishing-resistant passwordless authentication; dobór metod, pilotaż i docelowe authentication strength.
14. Microsoft Learn — Temporary Access Pass; bootstrap i odzyskiwanie dostępu.
15. Microsoft Learn — Manage emergency access accounts; konta awaryjne i ich testowanie.
16. Microsoft Learn — Register a passkey with a FIDO2 security key; przepływ sprzętowego klucza w Entra.
17. Microsoft Support — Create and save a passkey; konta konsumenckie Microsoft.
18. Google Chrome Help — Manage passkeys in Chrome; Google Password Manager i cross-device.
19. Apple — Use passkeys on iPhone; iCloud Keychain, Face ID/Touch ID i zarządzanie.
20. FIDO Alliance — Passkeys; terminologia synced i device-bound. Mechanizm bezpieczeństwa w raporcie oparto jednak na W3C, a nie opisie promocyjnym.