En liten innstilling kan svekke et ellers godt MFA-oppsett.

I Microsoft Entra ID finnes det fortsatt miljøer der brukere kan huske multifaktorautentisering på en «trusted device». Tanken er forståelig: færre MFA-varsler, mindre friksjon og færre henvendelser til brukerstøtte.

Men sett fra et admin-perspektiv er dette egentlig ikke en fullverdig modell for enhetstillit. Det er mer en bekvemmelighetsfunksjon for økter. Hvis enheten er delt, ikke administrert, stjålet eller brukt fra en mer risikabel situasjon, kan husket MFA redusere verdien av neste innloggingskontroll.

LinkedIn-lenken jeg sjekket pekte til en artikkel om å deaktivere husket MFA på trusted devices. Temaet er verdt å skrive om, men den viktigste lærdommen er denne:

Reduksjon av MFA-prompts bør styres med Conditional Access og øktpolicy, ikke med gamle tenant-brede bekvemmelighetsvalg.

Miljø

Dette gjelder Microsoft Entra ID-miljøer som bruker MFA og Conditional Access.

Typiske miljøer hvor dette er relevant:

• hybrid eller skybasert Microsoft 365;
• skoler, kommuner og distribuerte organisasjoner;
• brukere som bytter mellom administrerte og ikke-administrerte enheter;
• administratorer som prøver å balansere sikkerhet og prompt fatigue.

Hva jeg ville sjekket først

Først ville jeg sjekket om tenant fortsatt tillater at brukere husker MFA på enheter.

I Microsoft Entra admin center bør man se på:

1. Protection > Multifactor authentication > Additional cloud-based multifactor authentication settings.
2. Innstillingen for å huske multifaktorautentisering på trusted devices.
3. Conditional Access-policyer som allerede styrer sign-in frequency eller persistent browser sessions.
4. Sign-in logs for gjentatte prompts, risikable innlogginger og bruk fra ikke-administrerte enheter.

Poenget er å ikke endre en brukermerket autentiseringsinnstilling uten først å forstå hvordan dagens økter og prompts faktisk styres.

Beslutningen

Jeg ville ikke brukt husket MFA-enhet som hovedmetode for å redusere prompts.

En bedre modell er:

• bruk Conditional Access til å styre når økter kan være vedvarende;
• bruk sign-in frequency til å styre når brukeren må autentisere på nytt;
• bruk device compliance eller hybrid join når enhetstillit faktisk betyr noe;
• bruk risikosignaler der det er tilgjengelig;
• hold nød-/break-glass-kontoer utenfor vanlige brukerpolicyer.

Dette gir mer kontroll enn en bred remembered-device-innstilling.

Løsningen

En trygg utrulling kan se slik ut:

1. Gå gjennom dagens MFA remember-device-innstilling.
2. Finn hvilke brukere eller grupper som påvirkes.
3. Gå gjennom eksisterende Conditional Access session controls.
4. Opprett eller juster en Conditional Access-policy for øktlevetid.
5. Pilotér med en liten gruppe.
6. Følg med på sign-in logs og tilbakemeldinger fra brukerstøtte.
7. Deaktiver husket MFA på trusted devices hvis Conditional Access dekker brukeropplevelsen godt nok.

I Conditional Access er to kontroller spesielt relevante:

• Sign-in frequency — hvor ofte brukeren må gjøre en interaktiv innlogging på nytt.
• Persistent browser session — om nettleserøkten kan være vedvarende etter at nettleseren lukkes og åpnes igjen.

Hva som blir bedre

Poenget er ikke å gi brukerne flere prompts.

Poenget er at prompts blir styrt av policy.

I stedet for å stole på en remembered MFA-avkrysning, kan administratorer si:

• administrerte enheter kan få en smidigere opplevelse;
• ikke-administrerte enheter kan utfordres oftere;
• risikable økter kan avbrytes;
• sensitive apper kan ha strengere øktkontroll;
• endringer kan piloteres, måles og rulles tilbake.

Det er lettere å forklare og lettere å revidere.

Hva du bør passe på

Ikke deaktiver husket MFA globalt uten å vurdere brukeropplevelsen.

Se spesielt etter:

• flere MFA-prompts etter endringen;
• delte enheter;
• nettleserøkter i Edge, Chrome og mobilapper;
• unntak for break-glass-kontoer;
• servicekontoer eller eldre autentiseringsavhengigheter;
• konflikter mellom flere Conditional Access-policyer.

Husk også at dette ikke erstatter device compliance. Hvis sikkerhetsbeslutningen avhenger av om enheten er administrert, bør enhetstilstand brukes i Conditional Access.

Relaterte lenker

• Configure authentication session management with Conditional Access
• Configure Microsoft Entra multifactor authentication settings
• How Microsoft Entra multifactor authentication works

Siste tanke

Husket MFA på enheter er praktisk, men praktisk bør ikke bli selve sikkerhetsmodellen.

For de fleste moderne Microsoft 365-miljøer er Conditional Access session controls et bedre sted å styre denne balansen.

Microsoft oppdaterte Microsoft Entra What’s new-siden for juni 2026 med en nyttig identitetsendring: registreringskampanjer støtter nå passnøkler (FIDO2) som autentiseringsmetode.

Den praktiske betydningen er enkel. Administratorer kan bruke en registreringskampanje for å oppfordre brukere under innlogging til å registrere en passnøkkel, i stedet for å stole kun på e-postpåminnelser, brukerstøtteinstruksjoner eller engangskommunikasjon.

Microsoft beskriver dette som General Availability. Den første utrullingsopplevelsen er optimalisert for brukere som er i en passnøkkelprofil uten restriksjoner.

Hvorfor administratorer bør bry seg

Passnøkler er en av de renere veiene mot phishing-sikker autentisering i Microsoft Entra ID. Det vanskelige er ikke bare å aktivere metoden. Det vanskelige er å få faktiske brukere til å registrere seg i stor skala uten å gjøre utrullingen til manuell jakt.

Denne endringen flytter deler av adoptasjonsarbeidet inn i innloggingsflyten.

For mange Microsoft 365-miljøer er det nyttig fordi passnøkkelprosjekter ofte blir sittende fast mellom tre team:

• identitetsadministratorer aktiverer metoden
• endepunktteam håndterer plattformberedskap
• brukerstøtte håndterer veiledning og unntak

En registreringskampanje fjerner ikke behovet for planlegging, men den gir administratorer en mer kontrollert måte å presse adoptasjon på når forutsetningene er klare.

Hva jeg ville sjekket først

Jeg ville ikke slått dette på bredt før jeg sjekket grunnleggende ting.

Først, gå til Microsoft Entra admin center > Protection > Authentication methods og se gjennom passnøkkel-/FIDO2-konfigurasjonen. Bekreft hvem som er i scope, om restriksjoner er konfigurert, og om målgruppen faktisk er klar til å registrere seg.

Deretter sjekk registreringskampanjekonfigurasjonen under authentication methods-opplevelsen. Nøkkelspørsmålet er ikke bare «kan brukere registrere seg?». Det er «hvilke brukere bør oppfordres nå, og hvilke brukere trenger en annen vei?»

For en første utrulling ville jeg startet med en pilotgruppe som representerer vanlige brukere, delt-enhet-brukere hvis relevant, og noen supportansatte. Det gir bedre tilbakemelding enn å teste kun med administratorer.

Praktisk utrulling / valideringstrinn

Et trygt utrullingsmønster kan se slik ut:

1. Bekreft at passnøkkel/FIDO2 er aktivert for en liten pilotgruppe.
2. Bekreft at brukerne er i en passnøkkelprofil som samsvarer med Microsofts nåværende registreringskampanjeatferd.
3. Aktiver registreringskampanjen for pilotgruppen.
4. Be pilotbrukere logge inn normalt og dokumenter registreringsprompt-opplevelsen.
5. Valider vellykket registrering i brukerens authentication methods.
6. Gå gjennom innloggingslogger og støttebilletter for friksjon før du utvider.
7. Utvid etter avdeling, sted eller brukertype i stedet for å aktivere for alle samtidig.

Det jeg liker med denne endringen, er at den støtter en målt utrulling. Den tvinger ikke administratorer til å gjøre passnøkler til et stort-bang-prosjekt.

Hva du bør passe på

Microsofts notat sier at den første utrullingsopplevelsen er optimalisert for brukere i en passnøkkelprofil uten restriksjoner. Hvis passnøkkelkonfigurasjonen din bruker restriksjoner, test nøye før du antar samme brukeropplevelse.

Registrering er heller ikke det samme som håndheving. En kampanje kan hjelpe brukere med å registrere passnøkler, men Conditional Access og authentication strength-policyer bestemmer fortsatt hvor phishing-sikker autentisering kreves.

Jeg ville også forberedt et kort notat til brukerstøtte før utvidelse. Brukere kan spørre hva en passnøkkel er, om de trenger en telefon, om Windows Hello er involvert og hva de skal gjøre hvis registrering mislykkes.

Offisielle Microsoft-kilder

• Hva er nytt i Microsoft Entra
• Oppfordre brukere til å sette opp Microsoft Authenticator med registreringskampanje
• Passnøkler i Microsoft Entra ID