Klucz U2F – co to jest i jak działa?

Klucz U2F to sprzętowy drugi składnik uwierzytelniania oparty na kryptografii klucza publicznego. Podczas logowania podpisuje wyzwanie przysłane przez serwis, ale robi to wyłącznie dla domeny zapisanej w momencie rejestracji, więc podstawiona strona logowania nie otrzyma ważnego podpisu. To ta jedna właściwość, weryfikacja domeny po stronie urządzenia, odróżnia klucz sprzętowy od kodu z SMS-a i od kodu z aplikacji uwierzytelniającej.

Dla firmy oznacza to coś bardzo konkretnego. Kod jednorazowy da się wyłudzić i przepisać w czasie rzeczywistym. Podpisu z klucza sprzętowego nie da się przenieść na cudzą domenę. Poniżej najpierw mechanika samego standardu i sposób korzystania z klucza. W drugiej części to, co interesuje osobę odpowiedzialną za bezpieczeństwo w firmie. Od kogo zacząć, jakie błędy najczęściej przekreślają projekt i jak sprawdzić, że uwierzytelnianie naprawdę broni kont.

Co to jest klucz bezpieczeństwa U2F i jak chroni logowanie przed phishingiem

Klucz U2F wiąże sprzętowy token z konkretną domeną i konkretną usługą. Przy rejestracji urządzenie generuje parę kluczy: publiczny trafia do serwisu, prywatny zostaje w pamięci urządzenia i nigdy jej nie opuszcza. Przy każdym logowaniu serwis wysyła wyzwanie, a klucz odsyła podpis, który da się zweryfikować tylko kluczem publicznym zapisanym przy tej jednej domenie.

Dla atakującego jest to bariera nie do obejścia w standardowym phishingu. Sklonowana strona ma inny adres niż oryginał, przeglądarka przekazuje ten adres do klucza, a klucz nie znajduje dla niego zarejestrowanych poświadczeń. Nie ma tu momentu, w którym użytkownik mógłby, nawet chcąc, przekazać coś nadającego się do ponownego użycia.

Fizyczne potwierdzenie obecności to druga warstwa. Podpis powstaje dopiero po dotknięciu sensora, więc złośliwe oprogramowanie nie zdoła użyć podłączonego klucza w tle, bez wiedzy pracownika, do dowolnej liczby operacji.

• Czym jest: sprzętowy token, który potwierdza jednocześnie tożsamość użytkownika i autentyczność strony.
• Dlaczego blokuje phishing: U2F jest powiązany z domeną, fałszywy adres nie otrzyma akceptowanego podpisu.
• Praktyczny przykład: link z SMS-a podszywającego się pod bank lub pod firmowy portal nie wywoła poprawnego podpisu.
• Czego nie robi: nie zastępuje ochrony stacji roboczej. Klucz działa w warstwie uwierzytelniania, nie chroni przed złośliwym oprogramowaniem, które już działa na sprzęcie.

Jak działa uwierzytelnianie U2F krok po kroku

Cały proces logowania z kluczem sprowadza się do wymiany wyzwania i podpisu, a użytkownik widzi z tego tylko jedno dotknięcie. Rejestracja odbywa się raz: urządzenie tworzy parę kluczy dla danego serwisu, publiczny zapisuje serwis, prywatny zostaje w bezpiecznym układzie w kluczu.

1. Podajesz login i hasło, serwis rozpoznaje konto i przechodzi do drugiego składnika.
2. Serwer generuje wyzwanie powiązane z domeną i z bieżącą sesją.
3. Podłączasz klucz do portu albo zbliżasz go przez NFC, przeglądarka przekazuje wyzwanie razem z informacją o adresie strony.
4. Dotykasz sensora. Potwierdzasz w ten sposób obecność, więc nikt nie użyje klucza zdalnie i bez Twojej zgody.
5. Klucz podpisuje wyzwanie kluczem prywatnym przypisanym do tej domeny.
6. Serwis weryfikuje podpis kluczem publicznym i dopuszcza logowanie.

Jeśli strona jest podstawiona, podpis nie zgadza się z domeną i logowanie się nie kończy sukcesem. Operacja kryptograficzna odbywa się wewnątrz urządzenia, więc żaden sekret nie trafia ani do przeglądarki, ani do systemu operacyjnego, ani do serwisu.

Etap	Co się dzieje	Efekt
Rejestracja	Generowanie pary kluczy, klucz publiczny zapisany po stronie serwisu	Klucz prywatny pozostaje w urządzeniu i nie da się go odczytać
Logowanie	Serwer wysyła wyzwanie, użytkownik podłącza klucz przez USB lub NFC	Urządzenie podpisuje wyzwanie po potwierdzeniu dotykiem
Weryfikacja	Serwis sprawdza podpis kluczem publicznym	Autoryzacja tylko dla prawidłowej domeny i sesji

Scenariusz mobilny wygląda tak samo: przykładasz klucz do telefonu i potwierdzasz dotknięciem. Znika przy tym cała klasa pomyłek związanych z przepisywaniem kodów, z najgroźniejszą włącznie, czyli wpisaniem kodu na stronie, która tylko wygląda jak firmowy portal.

U2F, FIDO2 i WebAuthn: czym się różnią i co to zmienia w firmie

U2F jest standardem drugiego składnika, FIDO2 z interfejsem WebAuthn idzie dalej i pozwala zrezygnować z hasła. W U2F najpierw wpisujesz hasło, a klucz potwierdza obecność. W FIDO2 klucz może być główną metodą logowania, odblokowywaną PIN-em lub odciskiem palca, a hasło przestaje istnieć jako element do wyłudzenia.

Dla organizacji różnica jest praktyczna, nie akademicka. Dopóki hasło zostaje w procesie, zostaje też podatność na jego ponowne użycie w innych systemach. Tryb bezhasłowy usuwa ten składnik, ale wymaga wsparcia WebAuthn we wszystkich istotnych systemach, co w środowisku ze starszymi aplikacjami wewnętrznymi rzadko jest spełnione od razu.

• U2F pozostaje drugim krokiem obok loginu i hasła, integruje się szybko i szeroko.
• FIDO2 z WebAuthn obsługuje logowanie bezhasłowe oraz silne uwierzytelnianie wieloskładnikowe.
• Oba warianty chronią przed phishingiem, bo oba weryfikują domenę.
• Urządzenia obsługujące jednocześnie U2F i FIDO2 pozwalają wdrożyć drugi składnik teraz i przechodzić na tryb bezhasłowy stopniowo, tam gdzie systemy są na to gotowe.

Rozsądna kolejność to najpierw objęcie kluczem wszystkich kont wysokiego ryzyka w modelu drugiego składnika, potem migracja wybranych systemów do trybu bezhasłowego. Odwrotna kolejność zwykle kończy się długim projektem, w trakcie którego konta administracyjne dalej stoją na haśle i kodzie z aplikacji.

Gdzie działają klucze sprzętowe: serwisy, przeglądarki i systemy

Wsparcie dla kluczy sprzętowych jest dziś standardem w usługach, w których firmy trzymają najwięcej wrażliwych danych. Obsługują je Google, Microsoft, Facebook, Amazon i Dropbox, a także narzędzia deweloperskie GitHub i GitLab, gdzie przejęte konto daje dostęp do kodu i do potoków wdrożeniowych.

• Przeglądarki: Chrome, Firefox, Edge, Safari i Opera obsługują WebAuthn oraz U2F.
• Systemy: Windows, macOS, Linux, Android i iOS współpracują z kluczami przez przeglądarki i systemowe interfejsy.
• Polska: wsparcie pojawiło się w dużych portalach, natomiast w bankowości elektronicznej jest wciąż ograniczone.

Dla firmy ważniejsze od listy serwisów jest jedno pytanie: czy dostawca tożsamości potrafi wymusić klucz sprzętowy jako jedyną dopuszczalną metodę dla wybranej grupy kont. Jeżeli tak, wdrożenie da się przeprowadzić centralnie. Jeżeli nie, kończy się na rejestrowaniu kluczy przez chętnych, co nie zmienia poziomu ryzyka w organizacji.

Warto też sprawdzić dostępy omijające logowanie przez dostawcę tożsamości: panele hostingu, konsole chmurowe, dostęp do kopii zapasowych i konta u rejestratorów domen. To zwykle one zostają na samym haśle, gdy reszta środowiska jest już zabezpieczona.

Jak używać klucza U2F: rejestracja, interfejsy i utrata dostępu

Klucza używasz na trzy sposoby: rejestrujesz go w ustawieniach konta, potwierdzasz nim logowania dotknięciem i trzymasz sprawny egzemplarz zapasowy. Rejestrację wykonuje się osobno w każdym serwisie i za każdym razem warto od razu dodać oba egzemplarze, zamiast odkładać zapasowy na później.

Interfejs dobiera się do sprzętu, na którym ludzie faktycznie pracują. USB-A pasuje do starszych stacji roboczych, USB-C do nowszych laptopów i telefonów, NFC pozwala potwierdzać logowania zbliżeniowo na smartfonie. W środowisku mieszanym najbezpieczniejszym wyborem jest model łączący USB-C z NFC, bo obsługuje zarówno komputer, jak i telefon służbowy.

Utrata klucza nie musi oznaczać utraty dostępu, jeśli procedura była przygotowana wcześniej. Kolejność działań jest prosta: użyj klucza zapasowego, a jeśli go nie masz, sięgnij po zapisane kody odzyskiwania. Zgubiony egzemplarz trzeba natychmiast wyrejestrować ze wszystkich kont, na których był aktywny, bo dopóki tego nie zrobisz, pozostaje ważnym poświadczeniem.

• Trzymaj klucz zapasowy w innym miejscu niż podstawowy, na przykład w sejfie, nie w tej samej torbie.
• Testuj zapasowy egzemplarz okresowo. Klucz, o którym wiadomo, że gdzieś jest, ale nikt go nie próbował użyć, nie jest zabezpieczeniem.
• Kody odzyskiwania przechowuj poza skrzynką pocztową, której te kody dotyczą.
• Producenci nie tworzą duplikatów kluczy. Usługi obiecujące odtworzenie zawartości urządzenia to sygnał ostrzegawczy.

Dlaczego kody SMS i aplikacje uwierzytelniające nie wystarczają

Kod jednorazowy można wyłudzić i użyć w czasie rzeczywistym, a podpisu z klucza sprzętowego nie można. To cała różnica i to jest powód, dla którego organizacja z wdrożonym uwierzytelnianiem dwuskładnikowym opartym na SMS-ach lub aplikacji TOTP wciąż traci konta w kampaniach phishingowych.

Mechanizm ataku wygląda tak. Pracownik dostaje wiadomość z linkiem do strony logowania, która wygląda jak firmowy portal albo jak panel dostawcy poczty. Strona nie jest zwykłą kopią, tylko serwerem pośredniczącym: wszystko, co pracownik wpisze, jest natychmiast przekazywane do prawdziwego serwisu, a wszystko, co odpowie prawdziwy serwis, wraca do pracownika. Kiedy więc poda login i hasło, atakujący loguje się nimi w tej samej chwili. Prawdziwy serwis wysyła kod SMS albo prosi o kod z aplikacji, a fałszywa strona wyświetla to samo pytanie. Pracownik przepisuje kod, a serwer pośredniczący podaje go dalej, zanim kod zdąży wygasnąć. Efektem jest ważna sesja po stronie atakującego, często utrwalona ciasteczkiem sesyjnym, które pozwala wracać na konto bez ponownego uwierzytelniania.

Powiadomienia push mają dodatkową słabość, bo przenoszą decyzję na zmęczonego człowieka. Atakujący, który zna hasło, może wywoływać żądania zatwierdzenia wielokrotnie, aż ktoś kliknie „zatwierdź”, żeby telefon przestał wibrować. Ekran logowania pokazujący numer do dopasowania ogranicza ten scenariusz, ale nie usuwa problemu pośredniczącej strony logowania.

Klucz sprzętowy przerywa ten łańcuch w jednym punkcie: podpis jest wystawiany dla adresu, który przeglądarka przekazała urządzeniu. Serwer pośredniczący działa pod własną domeną, więc dostaje podpis bezużyteczny dla prawdziwego serwisu, albo nie dostaje niczego. Nie pomaga też pośpiech ani nieuwaga pracownika, bo nie istnieje ciąg znaków, który mógłby przepisać w złe miejsce. Odporność wynika z konstrukcji protokołu, nie z czujności użytkownika, i to jest jedyna forma odporności, na której da się oprzeć politykę bezpieczeństwa w dużej organizacji.

Metoda drugiego składnika	Odporność na phishing	Wygoda dla użytkownika	Koszt i złożoność wdrożenia	Dla kogo
Kod SMS	Niska. Kod da się wyłudzić i przekazać dalej w czasie ważności, dochodzi ryzyko przejęcia numeru	Wysoka, nie wymaga instalacji niczego	Najniższa złożoność, ale koszt bieżący rośnie z liczbą wysyłek	Ostateczność, gdy serwis nie oferuje nic lepszego
Aplikacja TOTP	Niska do średniej. Odporna na podsłuch i przejęcie numeru, nieodporna na stronę pośredniczącą	Średnia, wymaga telefonu i przepisania kodu	Niska, konfiguracja po stronie użytkownika, bez kosztu sprzętu	Konta o niższym ryzyku, systemy bez wsparcia dla FIDO
Powiadomienie push	Niska do średniej. Podatna na zmęczenie zatwierdzaniem, dopasowanie numeru poprawia sytuację częściowo	Wysoka, jedno kliknięcie	Średnia, wymaga aplikacji dostawcy tożsamości i zarządzania nią	Szeroka populacja pracowników jako etap przejściowy
Klucz sprzętowy U2F lub FIDO2	Wysoka. Podpis powiązany z domeną, brak danych możliwych do przepisania	Wysoka po przyzwyczajeniu, logowanie to jedno dotknięcie	Najwyższa. Zakup sprzętu, rejestracja, ewidencja i obsługa utraty	Administratorzy, zarząd, dostęp do systemów krytycznych, docelowo cała organizacja

Wniosek dla firmy nie brzmi „natychmiast wyłącz wszystko poza kluczami”. Brzmi: uporządkuj metody według odporności i przypisz najsłabsze do kont o najniższym ryzyku, a nie do administratorów domeny.

Wdrożenie kluczy sprzętowych w firmie: od czego zacząć

Zaczyna się od kont, które atakujący przejmuje z najgorszym skutkiem, nie od tych, których jest najwięcej. Kolejność jest niemal zawsze ta sama. Najpierw administratorzy dostawcy tożsamości i domeny, potem administratorzy infrastruktury i chmury. Dalej zarząd oraz osoby z dostępem do finansów. Na końcu konta z dostępem do danych osobowych i do systemów, których przestój zatrzymuje działalność.

Ta kolejność ma prostą logikę. Konto administratora dostawcy tożsamości pozwala zresetować uwierzytelnianie wszystkim pozostałym, więc dopóki stoi na kodzie z aplikacji, poziom ochrony całej organizacji jest równy poziomowi ochrony tego jednego konta. Podobnie z dostępem do poczty osób decyzyjnych, bo to skrzynka pocztowa jest najczęściej punktem odzyskiwania haseł do reszty usług.

Grupa	Dlaczego w tej kolejności	Minimum na starcie
Administratorzy tożsamości, domen i chmury	Przejęcie tych kont pozwala obejść zabezpieczenia wszystkich pozostałych	Dwa klucze na osobę, wymuszone politykami, bez metody zapasowej niższej klasy
Zarząd i osoby z dostępem do finansów	Cel ataków na płatności i podszycia pod przełożonego, wysoka wartość skrzynki pocztowej	Dwa klucze na osobę, klucz obejmuje pocztę i systemy finansowe
Dostęp do systemów krytycznych i danych osobowych	Przestój lub wyciek uderza bezpośrednio w działalność i w obowiązki regulacyjne	Klucz na koncie roboczym oraz osobne poświadczenia do zadań administracyjnych
Pozostali pracownicy	Skala, dłuższy czas wdrożenia i szkoleń	Etapowo, po ustabilizowaniu procesu rejestracji i wsparcia

Dwa klucze na osobę to nie luksus, tylko warunek działania całej konstrukcji. Przy jednym egzemplarzu każdy zgubiony, uszkodzony albo zostawiony w domu klucz zamienia się w zgłoszenie do działu wsparcia i w presję, żeby „na chwilę” wyłączyć wymóg. Ta chwila jest właśnie tym, czego szuka atakujący. Drugi klucz, zarejestrowany na tych samych kontach i przechowywany w innym miejscu, sprawia, że utrata pierwszego jest zdarzeniem administracyjnym, a nie awarią dostępu.

Procedura zgubionego klucza powinna być spisana i mieć jasnego właściciela. Sensowna wersja minimalna wygląda tak. Pracownik zgłasza utratę tego samego dnia, a dział IT natychmiast wyrejestrowuje utracony egzemplarz ze wszystkich kont. Użytkownik loguje się kluczem zapasowym, dostaje nowy klucz podstawowy, a stary numer seryjny znika z ewidencji. Do tego jasna zasada, kto może dopuścić tymczasową metodę zastępczą, na jak długo i za czyją zgodą, bo bez tej zasady decyzję podejmie osoba pod presją zadzwonionego telefonu.

Rejestracja i wycofywanie kluczy muszą być częścią procesu zatrudniania i rozstawania się z pracownikiem, tak samo jak wydanie laptopa. Potrzebna jest ewidencja: kto ma jaki egzemplarz, o jakim numerze seryjnym, na jakich kontach jest zarejestrowany i kiedy sprawdzano zapasowy. Bez tej ewidencji nie da się odpowiedzieć na najprostsze pytanie audytowe, czyli ile aktywnych kluczy jest zarejestrowanych na koncie, które opuściła osoba odchodząca z firmy.

Typowe błędy wdrożeń

Słabsza metoda zapasowa zostawiona jako furtka potrafi przekreślić całe wdrożenie. Firma kupuje klucze, rejestruje je administratorom, ogłasza podniesienie poziomu bezpieczeństwa, a w konfiguracji konta dalej działa opcja „nie mam klucza, wyślij kod SMS”. Atakujący nie będzie próbował złamać kryptografii. Wybierze tę opcję, bo została mu udostępniona, i cały poziom ochrony konta spada do poziomu najsłabszej dopuszczonej metody. Wdrożenie ma sens dopiero wtedy, gdy dla kont uprzywilejowanych klucz jest jedyną dopuszczalną metodą, a rolę awaryjną pełni drugi klucz i kody odzyskiwania złożone w kontrolowanym miejscu.

Drugi błąd to pominięcie ścieżki resetu hasła. Konto może wymagać klucza przy logowaniu, a jednocześnie pozwalać zresetować hasło. Wystarczy link odebrany w poczcie albo odpowiedź na pytanie pomocnicze. Po takim resecie logujesz się już bez klucza. Reset poświadczeń jest równie wrażliwy jak samo logowanie, więc powinien podlegać tym samym wymaganiom. Dotyczy to również sposobu, w jaki dział wsparcia weryfikuje tożsamość osoby dzwoniącej z prośbą o pomoc.

Trzeci błąd dotyczy kont serwisowych i technicznych, które nie mają właściciela wśród ludzi. Konta integracyjne, współdzielone konta administracyjne i dostępy używane przez skrypty wypadają poza projekt, bo nikt nie może do nich „dotknąć klucza”. Nie znaczy to, że można je zostawić na haśle w pliku konfiguracyjnym. Wymagają własnego rozwiązania: uwierzytelniania certyfikatami lub tokenami o krótkim czasie życia, ograniczenia uprawnień, rejestrowania użycia i przypisania właściciela. Bez tego kilka pominiętych kont serwisowych daje dostęp szerszy niż konta większości pracowników.

• Brak procedury na odejście pracownika: klucze zostają zarejestrowane na kontach osób, które już nie pracują, a konta pozostają aktywne razem z nimi.
• Wdrożenie tylko na najważniejszym systemie: pozostałe aplikacje logują się tym samym hasłem, więc atakujący po prostu wybiera inne drzwi.
• Brak testu przed ogłoszeniem sukcesu: konfiguracja bywa poprawna w polityce i nieegzekwowana w rzeczywistości, na przykład dla starszych klientów pocztowych.
• Brak komunikacji z pracownikami: ludzie, którym nikt nie wyjaśnił zasady, tworzą własne obejścia, zwykle gorsze niż to, co wdrożono.

Jak sprawdzić, czy uwierzytelnianie faktycznie działa

Jedynym wiarygodnym dowodem jest test, w którym ktoś próbuje obejść wdrożone mechanizmy. Wpis w polityce mówi o zamiarze. Dopiero próba pokazuje, czy istnieje ścieżka logowania, o której nikt nie pamiętał. Starszy protokół pocztowy pomijający drugi składnik, aplikacja z własną bazą użytkowników, wyjątek nadany kiedyś jednej osobie i nigdy niecofnięty.

Kontrolowana kampania phishingowa odpowiada na najważniejsze pytanie z tego obszaru, czyli co się dzieje, gdy pracownik jednak kliknie. Interesujący jest tu nie odsetek kliknięć, tylko to, czy po kliknięciu i po podaniu poświadczeń atakujący uzyskuje działającą sesję. Właśnie to weryfikują testy socjotechniczne prowadzone jako symulacja realnego scenariusza, łącznie ze stroną pośredniczącą. Gdy konto chroni klucz sprzętowy, ścieżka kończy się na odrzuconym podpisie. Z raportu widać, które konta przeszły test dzięki technologii, a nie dzięki temu, że akurat nikt nie kliknął. Kontrolowaną kampanię phishingową prowadzi się w ramach red teamingu, gdzie po przejęciu poświadczeń sprawdza się także, jak daleko atakujący zajdzie w środowisku i czy ktokolwiek to zauważy.

Druga warstwa weryfikacji dotyczy samych aplikacji i konfiguracji, a nie ludzi. Testy penetracyjne pokazują, czy mechanizm uwierzytelniania da się obejść od strony technicznej. Furtką bywają błędy w obsłudze sesji i punkty końcowe interfejsów programistycznych pomijające drugi składnik. Bywa nią też procedura resetu hasła albo konta serwisowe z nadmiarowymi uprawnieniami. To są dokładnie te obszary, które wypadają poza projekt wdrożenia kluczy i pozostają niesprawdzone.

Jeśli pytanie brzmi szerzej, czyli czy zarządzanie tożsamością i dostępem w firmie jest spójne, właściwym narzędziem jest audyt bezpieczeństwa IT. Audyt porządkuje inwentarz kont uprzywilejowanych, konfrontuje politykę z rzeczywistą konfiguracją i wskazuje systemy pominięte we wdrożeniu, zanim znajdzie je ktoś inny.

Praktyczny pierwszy krok możesz wykonać bez żadnego projektu. Wypisz konta, po których przejęciu firma by stanęła. Sprawdź przy każdym z nich dwie rzeczy: jaka metoda drugiego składnika jest wymagana i jaka metoda jest dopuszczona jako zapasowa. Jeżeli w drugiej kolumnie pojawia się SMS albo kod z aplikacji, masz gotową listę zadań na najbliższy kwartał. Wynik warto potwierdzić kontrolowaną próbą phishingu, zamiast czekać na próbę niekontrolowaną.

Zakres takiej weryfikacji, czyli liczbę systemów, kont uprzywilejowanych i scenariuszy do sprawdzenia, można opisać w konfiguratorze zakresu. Gotowy opis pozwala porównać oferty wykonawców na tych samych założeniach, zamiast zestawiać dokumenty o różnej szczegółowości.

Najczęstsze pytania

Czy klucz U2F chroni przed phishingiem lepiej niż kod z aplikacji?

Tak, i wynika to z konstrukcji, a nie ze stopnia trudności ataku. Kod z aplikacji jest ciągiem znaków, który użytkownik może wpisać na dowolnej stronie, także na stronie atakującego przekazującej go dalej w czasie rzeczywistym. Klucz U2F podpisuje wyzwanie wyłącznie dla domeny zapisanej przy rejestracji, więc podstawiona witryna nie otrzyma niczego, co da się użyć w prawdziwym serwisie.

Ile kluczy powinna dostać jedna osoba w firmie?

Dwa: podstawowy i zapasowy, oba zarejestrowane na tych samych kontach i przechowywane w innych miejscach. Przy jednym egzemplarzu każda utrata kończy się przerwą w pracy i presją na tymczasowe wyłączenie wymogu, co jest najkrótszą drogą do obejścia całego wdrożenia.

Co zrobić, gdy pracownik zgubi klucz?

Zgłoszenie tego samego dnia, natychmiastowe wyrejestrowanie utraconego egzemplarza ze wszystkich kont, logowanie kluczem zapasowym i wydanie nowego klucza podstawowego wraz z aktualizacją ewidencji. Zasady dopuszczania metody tymczasowej trzeba ustalić wcześniej, razem ze wskazaniem osoby, która może ją zatwierdzić.

Czy trzeba objąć kluczami wszystkich pracowników od razu?

Nie, i próba zrobienia tego naraz zwykle wydłuża projekt. Skuteczniejsze jest objęcie w pierwszej kolejności administratorów, zarządu i dostępów do systemów krytycznych, a następnie rozszerzanie zakresu, gdy proces rejestracji, wsparcia i wymiany kluczy działa sprawnie.

Czy wdrożenie kluczy oznacza, że firma nie musi już testować odporności na phishing?

Nie. Klucz zabezpiecza konkretne konta w konkretnych systemach, a atak szuka miejsc pominiętych: kont serwisowych, ścieżek resetu hasła, starszych protokołów i aplikacji z własnym logowaniem. Kontrolowana kampania phishingowa oraz test aplikacji pokazują, czy takie luki istnieją, zanim znajdzie je ktoś z zewnątrz.

Źródła

• FIDO Alliance — specyfikacje FIDO2, CTAP i FIDO U2F — opis rodziny standardów uwierzytelniania sprzętowego oraz relacji między U2F (CTAP1), CTAP2 i FIDO2.
• Web Authentication (WebAuthn) — specyfikacja W3C — opis interfejsu WebAuthn, w tym powiązanie poświadczeń z domeną i przebieg rejestracji oraz uwierzytelniania.
• NIST SP 800-63B-4 — Digital Identity Guidelines: Authentication and Authenticator Management — klasyfikacja metod uwierzytelniania i wymagania dla uwierzytelniania odpornego na phishing, przydatne przy ustalaniu polityki dla kont uprzywilejowanych.