Passkeys bliver standard i Entra: SMS og voice udfases 1. februar 2027

En passkey er en login-nøgle der ligger på jeres enhed (telefon, computer eller en fysisk sikkerhedsnøgle) og låses op med fingeraftryk, ansigt eller pinkode. Den kan ikke phishes, fordi der ikke er en kode at aflure eller sende videre til en falsk side. Den erstatter både adgangskode og SMS-kode i ét trin.

Fra 1. september 2026 gør Microsoft passkeys til standarden i Entra ID (Microsofts identitetsplatform, tidligere Azure AD). To ting sker automatisk i jeres tenant:

• •Passkeys aktiveres for brugere der i dag er sat op med SMS eller voice. I skal ikke selv slå funktionen til.
• •Registreringskampagnen sættes til Microsoft-styret (Microsoft-Managed). Det betyder at brugere bliver bedt om at oprette en passkey, næste gang de logger ind med MFA.

Brugeren kan springe prompten over og fortsætte med sin nuværende metode indtil videre. Det er en opfordring, ikke en tvang, på denne dato. Men det er startskuddet: Microsoft flytter alle mod passkeys, og den næste dato har rigtige konsekvenser.

Fra 1. februar 2027 kan Microsofts egne SMS- og voice-koder ikke længere bruges som MFA-metode (multifaktor-godkendelse, altså det ekstra trin ud over adgangskoden). Det er her det bliver alvor.

Har I brugere der udelukkende bekræfter sig med en SMS-kode eller et automatisk opkald fra Microsoft, mister de deres login-metode den dag. Uden en anden registreret metode kan de ikke komme ind, og så ringer de til jer eller helpdesk.

Det rammer typisk to grupper: medarbejdere uden en smartphone med Authenticator-app, og servicekonti eller delte konti hvor nogen engang satte et telefonnummer op som eneste metode. Dem skal I finde nu, ikke i januar 2027.

Her er en vigtig skelnen mange overser. At registrere og logge ind med en passkey virker på gratis-niveauet af Entra ID. Det koster ikke noget ekstra, og alle jeres brugere kan bruge det.

At kræve at brugerne bruger en passkey (eller en anden phishing-resistent metode), er en anden sag. Det gøres med authentication strengths i Conditional Access, og Conditional Access kræver Entra ID P1.

Sådan følger Entra ID-niveauet med de gængse planer:

Kører I på Business Basic eller Standard, kan jeres brugere altså godt oprette passkeys, men I kan ikke tvinge det igennem med en politik. Vil I kunne dokumentere at kun phishing-resistent login giver adgang til jeres data, skal I op på mindst Business Premium eller tilkøbe Entra ID P1 separat. Det er endnu et konkret eksempel på hvad licensniveauet reelt afgør.

NIS2 (EU's netværks- og informationssikkerhedsdirektiv) kræver i Artikel 21 en række tekniske sikkerhedsforanstaltninger, og multifaktor-godkendelse er eksplicit nævnt. Tilsynsmyndighederne og branchen peger i stigende grad på phishing-resistent MFA som den standard I bør ramme, fordi SMS-koder kan snydes med phishing og SIM-swap.

Det er præcis dét passkeys leverer. En passkey opfylder Microsofts indbyggede krav om phishing-resistent MFA, sammen med Windows Hello for Business og certifikat-baseret login. Så Microsofts skift falder sammen med den retning NIS2 alligevel skubber jer i.

For en dansk SMV der arbejder mod NIS2 eller D-mærket er der to pointer:

• •Passkeys er den nemme vej til at kunne dokumentere phishing-resistent adgang. I flytter fra en metode der kan phishes til en der ikke kan.
• •Dokumentationen kræver håndhævelse, og håndhævelse kræver P1. At brugerne *kan* bruge passkeys er ikke nok til en revisor. I skal kunne vise en politik der *kræver* det, og den politik er Conditional Access.

Sådan hænger licens og compliance sammen i praksis: den tekniske mulighed er gratis, men den dokumenterbare kontrol ligger bag P1-licensen.

Deadline nummer to (1. februar 2027) er den der kan gøre ondt. Sådan kommer I klar i god tid:

Nogle organisationer kan ikke undvære en kode på telefonen. Det gælder for eksempel medarbejdere uden en firmatelefon med app, eller brancher hvor SMS er den eneste realistiske metode for en del af staben.

Det er stadig muligt efter 1. februar 2027, men ansvaret flytter til jer. Microsoft holder op med at levere selve SMS'en og opkaldet, og I skal i stedet koble jeres egen teleudbyder på gennem Microsoft Security Store. Sætter I ikke det op, forsvinder metoden for de brugere.

Mit råd er at behandle SMS som en overgangsløsning I aktivt afvikler, ikke en permanent tilstand. Retningen fra både Microsoft og NIS2 er tydelig: væk fra koder der kan phishes, hen mod passkeys. Jo før I flytter hovedparten af brugerne, jo mindre bøvl har I med Security Store-opsætning og undtagelser.

Kobl det gerne sammen med jeres SSPR-arbejde, hvor Microsoft fra 7. september 2026 også kun godkender selvbetjent nulstilling ud fra metoder brugeren selv har registreret. Det er den samme bevægelse mod registrerede, phishing-resistente metoder.

Kilder: Microsoft Learn: Passkeys by default og udfasning af SMS og voice, Microsoft Learn: FAQ om udfasningen, Microsoft 365 Message Center MC1426371, Microsoft Learn: authentication strengths og licenskrav.