Felsöka MFA i Microsoft 365 (2026)

Uppdaterad: 1 juli 2026

För att felsöka MFA-problem i Microsoft 365 börjar du alltid i Entra ID Sign-in logs: filtrera på användaren, hitta den misslyckade inloggningen och läs fältet Authentication Details. Där står den exakta orsaken (nekad prompt, tidsgräns, blockering via Conditional Access eller registreringsproblem). I den här guiden går vi igenom de fem vanligaste MFA-felen som IT-helpdesk möter 2026, hur du löser dem inom 10 minuter och hur du slipper återställa MFA för samma användare vecka efter vecka.

Jag har själv suttit med det här ganska många gånger under det senaste året, och det är förvånande hur ofta samma tre orsakskoder dyker upp. Så, låt oss gå igenom dem systematiskt.

Nummermatchning i Microsoft Authenticator är obligatoriskt sedan 8 maj 2023 och kan inte längre stängas av. Användare måste skriva in en tvåsiffrig kod, inte bara trycka "Godkänn".
Använd Entra ID Sign-in logs (Authentication Details) för att se den exakta MFA-orsakskoden istället för att gissa utifrån användarens beskrivning.
Temporary Access Pass (TAP) är rätt återställningsmetod 2026. Det ersätter engångskoder via SMS och tillåter användaren att registrera en ny Authenticator utan att lämna arbetsflödet.
Konfigurera minst två MFA-metoder per användare (Authenticator plus FIDO2 eller Windows Hello) för att eliminera cirka 80 % av "jag har bytt telefon"-ärendena.
Conditional Access-blockeringar visas som "Access blocked" med orsakskoden 53003. Kontrollera policy-namnet i Sign-in logs innan du återställer MFA.
Global Administrator kan bevilja en 1 till 8 timmars TAP; för långlivade återställningar krävs Privileged Authentication Administrator-rollen.

Innan du rör en enda inställning, öppna Microsoft Entra ID Sign-in logs och sök på användarens UPN. Sortera på tid, öppna den senaste misslyckade posten och gå till fliken Authentication Details. Där ser du varje MFA-steg som en rad: "Primary authentication", "Microsoft Authenticator - Number match required", "Authentication requirement satisfied by claim in token" och så vidare.

Fältet Result detail ger orsakskoden. Här är de sex koder som helpdesk möter dagligen:

50074: Strong Authentication required. Användaren har inte slutfört MFA-prompten.
50076: Due to a configuration change made by your administrator, MFA is required.
50158: External security challenge not satisfied. Ofta Conditional Access som kräver hybrid join eller efterlevnad.
53003: Access blocked because of Conditional Access policy.
500121: Authentication failed during strong authentication request. Klassiskt "användaren tryckte Neka" eller att Authenticator inte hann svara i tid.
65001: Application requires user consent (visas ibland i MFA-flöden mot äldre appar).

Skriv upp orsakskoden i ärendet innan du gör något annat. Det halverar tiden till lösning och du kan söka i Microsofts dokumentation exakt istället för att prova blint. För bulk-analys kan du använda KQL i Log Analytics:

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != 0
| where UserPrincipalName == "[email protected]"
| project TimeGenerated, AppDisplayName, ResultType, ResultDescription, Status, MfaDetail, ConditionalAccessStatus
| order by TimeGenerated desc

Nummermatchning: varför Authenticator-prompten ser annorlunda ut

Sedan 8 maj 2023 kräver Microsoft nummermatchning för alla push-notiser i Microsoft Authenticator, och 2026 kan detta inte längre stängas av. Istället för att bara trycka "Godkänn" ser användaren en tvåsiffrig kod i inloggningsfönstret som måste skrivas in i appen.

Den vanligaste helpdesk-frågan är: "Authenticator visar bara en textruta där jag ska skriva ett nummer, vart tog Godkänn-knappen vägen?" Svaret är att det är avsiktligt. Det är säkerhetsfunktionen som skyddar mot MFA fatigue-attacker.

Om användaren inte ser ett nummer i inloggningsfönstret beror det oftast på att push-notisen har fastnat i telefonens notifikationscenter. Be dem öppna Authenticator manuellt, så finns en pågående prompt högst upp. Om appen fortfarande inte visar prompten kontrollera att push-notiser är aktiverade i telefonens inställningar och att Authenticator-appen är uppdaterad till version 6.7.9 eller senare (Android) respektive 6.8.0 eller senare (iOS). Från och med februari 2026 stödjer Authenticator även "additional context" som visar vilken app användaren försöker logga in på och från vilken plats. Aktivera detta via Entra ID → Security → Authentication methods → Microsoft Authenticator.

Varför fungerar inte Microsoft Authenticator?

De sex vanligaste orsakerna till att Microsoft Authenticator slutar fungera för en användare, i den ordning de bör kontrolleras:

Telefonens tid är fel. TOTP-koder är tidssynkroniserade. Om telefonens klocka avviker mer än 30 sekunder från Microsofts servrar misslyckas verifieringen. Be användaren aktivera "Automatisk tid" i telefonens inställningar.
Push-notiser blockerade. På iOS blockeras Authenticator ibland av Fokus-lägen; på Android av batterioptimering. Be användaren undanta Authenticator från Doze/App Standby.
Appen inte uppdaterad. Versioner före 6.6 stödjer inte nummermatchning på ett tillförlitligt sätt.
Ny telefon utan att flytta konton. Authenticator-konton följer inte automatiskt med i telefonsäkerhetskopior om molnbackup inte aktiverats innan bytet.
Konto återställdes men Authenticator kopplades inte upp igen. Se avsnittet om TAP nedan.
Region/IP blockeras av Conditional Access. Push går inte fram om användaren är i ett blockerat land. Det visas som timeout, inte som "nekad".

Ärligt talat, punkt 1 är den jag oftast missar på fredagseftermiddagar. Verifiera från PowerShell om användaren har en giltig Authenticator-registrering:

Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All"

Get-MgUserAuthenticationMethod -UserId "[email protected]" |
    ForEach-Object {
        [PSCustomObject]@{
            Method = $_.AdditionalProperties['@odata.type'] -replace '#microsoft.graph.', ''
            Id     = $_.Id
        }
    } | Format-Table -AutoSize

Om microsoftAuthenticatorAuthenticationMethod saknas i utdatan har användaren ingen aktiv Authenticator. Då hjälper det inte att felsöka appen, användaren måste registrera på nytt.

Hur återställer jag MFA för en användare?

Rätt sätt att återställa MFA 2026 är inte längre att klicka "Require re-register MFA" i den gamla per-user MFA-portalen (den portalen är på väg ut). Gör istället så här:

Öppna Entra admin center → Users → välj användare → Authentication methods.
Klicka Delete på den metod som inte fungerar (t.ex. gammal Authenticator-registrering på förlorad telefon).
Klicka Revoke MFA sessions för att tvinga användaren att göra MFA på nytt vid nästa inloggning.
Utfärda en Temporary Access Pass (se nedan) så användaren kan registrera en ny metod utan att ringa dig igen.

För helpdesk-personal räcker rollen Authentication Administrator för vanliga användare, men för administratörskonton krävs Privileged Authentication Administrator. Delegera aldrig Global Administrator för denna uppgift, principen om minsta behörighet gäller. Om ni felsöker låsta AD-konton parallellt, se vår guide om AD-kontoutlåsning och Event 4740. Utlåsning i lokal AD orsakar ibland fantomartade MFA-timeouts när Entra Connect Password Hash Sync är påslagen (jag har själv jagat en sådan i timmar).

Temporary Access Pass (TAP): modern återställning

Temporary Access Pass är en tidsbegränsad engångskod som ersätter både lösenord och MFA under registreringen av en ny stark autentiseringsmetod. Aktivera policyn en gång i Entra ID → Protect & secure → Authentication methods → Temporary Access Pass och ge helpdesk-gruppen möjligheten att utfärda.

För att utfärda en TAP via PowerShell:

Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All"

$properties = @{
    startDateTime      = (Get-Date).ToUniversalTime().ToString("o")
    lifetimeInMinutes  = 60
    isUsableOnce       = $false
}

New-MgUserAuthenticationTemporaryAccessPassMethod `
    -UserId "[email protected]" `
    -BodyParameter $properties

Utdatan innehåller ett fält temporaryAccessPass. Det är den 8-siffriga koden som användaren använder på inloggningssidan. Sätt isUsableOnce till $true för engångsanvändning (rekommenderat vid onboarding), och $false när användaren behöver logga in flera gånger under installationen (t.ex. konfigurera både Authenticator och FIDO2).

Conditional Access blockerar inloggning

När Sign-in logs visar orsakskod 53003 är MFA-appen oskyldig. Inloggningen är blockerad av en Conditional Access-policy. Öppna posten i Sign-in logs, gå till fliken Conditional Access och notera exakt vilken policy som utlöste blockeringen samt vilka villkor som matchade (plats, enhetsplattform, applikation, användarriskklassificering). Vanliga fallgropar 2026:

Named locations utan uppdatering. IP-adresser för kontorets nya SD-WAN har inte lagts till i "Trusted locations". Användaren tvingas till MFA från kontoret trots att policyn avsåg att undanta trafik därifrån.
Kräver kompatibel enhet på icke-hanterad enhet. Personliga BYOD-enheter faller på "Require compliant device" om Intune-registrering inte är obligatorisk. Överväg "Require app protection policy" istället.
Riskbaserad MFA loopar. Om Identity Protection klassar användaren som "high risk" och policyn kräver password change plus MFA, kan användaren fastna om lösenordet redan bytts men risk inte manuellt rensats.

Vår guide om Microsoft Intune-enrollment täcker efterlevnadsvillkoren i detalj. Kör alltid What If-verktyget i Conditional Access innan du ändrar en policy. Det simulerar utfallet för en specifik användare, app och plats utan att påverka produktion.

FIDO2-nycklar och passkeys 2026

FIDO2-säkerhetsnycklar (t.ex. YubiKey 5C NFC) och plattformspasskeys (Windows Hello, iOS/macOS Passkeys, Android Passkeys) är den starkaste metoden 2026. De är phishing-resistenta enligt NIST SP 800-63B och kan inte fångas av AiTM-attacker. Registrera minst en FIDO2-nyckel per privilegierat konto som backup för Authenticator.

Aktivera passkey-registrering i Entra ID → Authentication methods → Passkey (FIDO2) och tillåt både USB och NFC. För plattformspasskeys på iOS 17+ och macOS Sonoma+ är registrering nu inbyggd i Microsoft Authenticator-appen. Användaren väljer "Add sign-in method → Passkey" och lagringen sker i iCloud Keychain. Vanliga helpdesk-frågor:

"Jag ser inte alternativet att lägga till en säkerhetsnyckel." Kontrollera att FIDO2-policy tillåter användarens grupp och att AAGUID-listan inte är för restriktiv (om Attestation är påslaget).
"Nyckeln fungerar på Windows men inte i webbläsaren." Firefox på macOS hade problem med hybrid transport fram till version 128. Uppdatera eller använd Edge/Safari.
"Kan inte registrera passkey på delad dator." Windows Hello passkeys är per-konto, inte per-enhet. De fungerar inte i Shared PC-läge.

Registreringskampanj och backup-metoder

Det bästa MFA-ärendet är det som aldrig når helpdesk. Aktivera Registration Campaign under Authentication methods → Microsoft Authenticator för att tvinga användare som fortfarande använder SMS eller röstsamtal att uppgradera till Authenticator. Konfigurera samtidigt att varje användare måste ha minst två metoder registrerade: Authenticator som primär plus FIDO2-nyckel eller Windows Hello som backup. Det här eliminerar ungefär 80 % av "jag har bytt telefon"-ärendena, eftersom användaren kan logga in med backupmetoden och registrera ny Authenticator själv.

Om ni fortfarande använder legacy per-user MFA (den gamla portalen på account.activedirectory.windowsazure.com), planera migreringen. Microsoft har annonserat att portalen tas ur bruk under Q4 2026. Kör migreringsverktyget i Entra ID → Security → Authentication methods → Manage migration och sätt läget till "Migration Complete" när alla policyer flyttats till Authentication methods-modellen.

För helpdesk-processer som helhet, inklusive hur ni loggar MFA-ärenden konsekvent, se vår Outlook-felsökningsguide. Samma triage-mallar fungerar utmärkt för MFA-ärenden.

Vanliga frågor

Varför fungerar inte Microsoft Authenticator efter att jag bytte telefon?

Authenticator-konton följer inte automatiskt med i telefonens vanliga säkerhetskopiering. Du måste ha aktiverat molnbackup i Authenticator innan bytet. Om du inte gjort det, be helpdesk om en Temporary Access Pass, ta bort den gamla registreringen i Entra ID och registrera Authenticator på nytt på den nya telefonen.

Kan jag stänga av nummermatchning i MFA?

Nej. Sedan 8 maj 2023 är nummermatchning obligatoriskt för alla Microsoft Authenticator-push-notiser och kan inte längre stängas av. Eventuella undantag skapade före det datumet respekteras inte längre av tenantpolicyn.

Vad är Temporary Access Pass och när ska jag använda det?

Temporary Access Pass (TAP) är en tidsbegränsad kod som ersätter både lösenord och MFA under registrering av en ny stark autentiseringsmetod. Använd det vid onboarding, förlorade telefoner och kontoåterställning istället för att tillfälligt stänga av MFA.

Hur ser jag exakt varför en MFA-inloggning misslyckades?

Öppna Entra ID Sign-in logs, hitta den misslyckade posten och läs fliken Authentication Details. Där listas varje autentiseringssteg och resultat. Kontrollera Result detail-koden: 53003 betyder Conditional Access-blockering, 500121 betyder nekad eller timeout av MFA-prompten.

Kan användare kringgå MFA?

Inte via legitima flöden i en korrekt konfigurerad tenant. Kontrollera att inga användare finns med i "Exclude"-listan för Conditional Access-MFA-policyn och att Security Defaults eller CA täcker alla molnappar. Använd Named Locations bara för att välja MFA-frekvens, inte för att helt undanta trafik.