MFA, czyli uwierzytelnianie wieloskładnikowe, opiera się na prostej zasadzie: samo hasło nie wystarcza. Po wpisaniu loginu i hasła użytkownik musi jeszcze potwierdzić swoją tożsamość drugim składnikiem. Może to zrobić w aplikacji mobilnej, kluczem sprzętowym, kodem SMS albo przez zewnętrznego dostawcę MFA, takiego jak Duo, RSA, Ping czy inne rozwiązanie używane w firmie.

Autor: 6 min czytania

Dlaczego Microsoft zmienia sposób integracji zewnętrznego MFA?

Microsoft ogłosił, że External MFA w Microsoft Entra ID jest już ogólnie dostępne. To ważna zmiana dla organizacji, które nie chcą rezygnować z dotychczasowego dostawcy MFA, ale planują nadal korzystać z centralnych mechanizmów bezpieczeństwa Entra ID, takich jak Conditional Access czy polityki dostępu.

Czym były Custom Controls w Conditional Access?

Do tej pory wiele organizacji integrowało zewnętrzne MFA przez mechanizm Conditional Access Custom Controls. W uproszczeniu działało to jak przekierowanie. Użytkownik logował się do aplikacji Microsoft 365. Entra ID sprawdzał politykę Conditional Access i widział, że wymagane jest dodatkowe potwierdzenie. Następnie był przekierowywany do zewnętrznego dostawcy MFA, np. Duo albo RSA. Po zatwierdzeniu logowania wracał do Microsoftu. Dla użytkownika końcowego wyglądało to poprawnie. Widział znany ekran MFA, zatwierdzał logowanie i dostawał dostęp. Problem polegał na tym, że od strony architektury bezpieczeństwa Custom Controls nie były pełnoprawną metodą MFA w Entra ID.

Dlaczego Custom Controls stały się problemem?

Custom Controls były mechanizmem preview i posiadały pewne ograniczenia. Microsoft wskazuje, że nie działały spójnie we wszystkich scenariuszach, m.in. z Privileged Identity Management, Intune device enrollment, Self-Service Password Reset, sign-in frequency controls czy automatyzacją Microsoft Entra ID Protection wymagającą MFA.

Mówiąc prościej: użytkownik mógł faktycznie potwierdzić logowanie drugim składnikiem, ale Entra ID nie zawsze traktowało ten proces tak samo, jak natywne Microsoft MFA.  Tworzyło to różnice w raportowaniu, egzekwowaniu polityk i obsłudze bardziej zaawansowanych scenariuszy bezpieczeństwa.

Czym jest External MFA w Microsoft Entra ID?

External MFA to nowy, wspierany model integracji zewnętrznych dostawców MFA z Microsoft Entra ID. Najważniejsza różnica polega na tym, że zewnętrzne MFA jest obsługiwane jako metoda uwierzytelniania w Entra ID, a nie jako osobny mechanizm przekierowania przez Custom Controls. External MFA działa w oparciu o OpenID Connect. Dla administratora oznacza to konieczność skonfigurowania zaufania między Entra ID a zewnętrznym dostawcą MFA. W praktyce potrzebne są dane takie jak Application ID, Client ID i Discovery URL. To identyfikatory techniczne i adresy, dzięki którym Entra ID wie, z jakim dostawcą rozmawia i czy odpowiedź pochodzi z zaufanego źródła.

Co zmienia się dla użytkownika końcowego?

Dla zwykłego użytkownika zmiana jest prawie niewidoczna. Nadal może zobaczyć ten sam ekran Duo, RSA lub innego dostawcy MFA. Wciąż zatwierdza logowanie w znany sposób. Różnica leży po stronie administratorów i architektury bezpieczeństwa. External MFA pozwala na zachowanie dotychczasowego dostawcy MFA, ale wpina go w Entra ID w bardziej uporządkowany i wspierany sposób. To ważne szczególnie w dużych organizacjach, które mają już wdrożone zewnętrzne MFA globalnie i nie chcą nagle migrować wszystkich użytkowników na Microsoft Authenticator.

Do kiedy trzeba przejść z Custom Controls na External MFA?

Microsoft wskazuje, że Custom Controls są wygaszane. Od września 2026 roku nie będzie można dodawać nowych ani edytować istniejących Custom Controls, a pełne wycofanie mechanizmu zaplanowano na początek 2027 roku. W komunikatach Microsoftu pojawia się również data 30 września 2026 jako kluczowy termin związany z przejściem na nowy model. Oznacza to, że organizacje używające Custom Controls nie powinny traktować migracji jako odległego tematu. To projekt, który trzeba zaplanować, przetestować i wdrożyć etapami.

Co powinien sprawdzić administrator Entra ID?

Pierwszy krok to sprawdzenie, czy w Conditional Access istnieją polityki używające Custom Controls. Następnie warto ustalić, których aplikacji, grup użytkowników i dostawców MFA dotyczą. Kolejnym krokiem powinno być potwierdzenie, czy obecny dostawca MFA wspiera External MFA dla Microsoft Entra ID. Dopiero potem warto skonfigurować External MFA dla małej grupy testowej, uruchomić politykę Conditional Access z wymaganiem „Require multifactor authentication” i przeanalizować logowania. Migracji nie należy robić jednorazowo dla całej organizacji. Błąd w konfiguracji MFA może odciąć użytkowników od poczty, Teamsów, SharePointa, portalu Azure, a w najgorszym przypadku także od kont administracyjnych.

Dlaczego to ważne z punktu widzenia bezpieczeństwa?

External MFA nie jest tylko zmianą techniczną. To uporządkowanie sposobu, w jaki Entra ID współpracuje z zewnętrznymi dostawcami MFA. Stary model Custom Controls działał, ale był ograniczony i nie dawał pełnej spójności z nowoczesnymi mechanizmami bezpieczeństwa Microsoftu. Nowy model pozwala nadal korzystać z Duo, RSA czy innych rozwiązań, ale w taki sposób, żeby Entra ID zachowało centralną kontrolę nad decyzją dostępową. Dla organizacji oznacza to mniej wyjątków, mniej mechanizmów preview i lepszą integrację z Conditional Access. Dla administratorów – jasny sygnał, że trzeba sprawdzić stare polityki. Dla bezpieczeństwa – większą przewidywalność tego, kiedy i jak MFA faktycznie chroni dostęp do aplikacji.