Sådan sætter du MFA op i Microsoft 365, uden at låse brugerne ude (trin for trin)

14. januar 2026

MFA føles tit som en simpel knap: slå til, og så er man “sikker”. I praksis er Microsoft 365 MFA mere som at skifte låsecylinder, mens døren stadig bliver brugt. Gør man det for hårdt og for hurtigt, står en direktør eller bogholder uden adgang kl. 08:02.

Målet er klart: højere it-sikkerhed uden driftsstop. Her får I en praktisk opskrift til SMV’er, inklusive break-glass konti, pilot-udrulning, do’s & don’ts og recovery, så I ikke ender med et lockout-scenarie. (Og ja, i 2026 ændrer menupunkter sig løbende, så der er også alternative søgestier.)

Overblik før I starter: vælg den rigtige metode (Security Defaults eller Conditional Access)

Illustration af MFA rollout med IT-admin, brugere med authenticator-apps og tjekliste Illustration af kontrolleret MFA-udrulning med tjekliste og skjold, skabt med AI.

I Microsoft-miljøet er “per-user MFA” den klassiske fælde. Den kan virke hurtig, men den giver ofte dårlig kontrol, rod i undtagelser og flere support-sager.

I 2026 er den mest stabile model for de fleste SMB’er:

  • Security Defaults : hurtigt, enkelt, færre valg.
  • Conditional Access (CA) : mere kontrol, bedre til pilot og gradvis udrulning.

Microsoft beskriver de to tilgange her: Turn on MFA by using security defaults or Conditional Access.

Praktisk tommelfingerregel:

  • Har I få brugere og få særkrav, start med Security Defaults.
  • Har I flere lokationer, særlige enheder, admins, eller vil I styre det pænt, brug Conditional Access.

Planen der forhindrer lockouts: grupper, pilot og recovery på papir

Før I rører policies, beslut tre ting. Det er jeres “sikkerhedssele”.

Tjekliste (kort og realistisk)

  • Definér en pilotgruppe (5 til 15 personer, inkluder 1 til 2 it-admins).
  • Aftal et vindue til udrulning, og hvem der tager it-support på dagen.
  • Skriv en recovery-proces i 10 linjer: hvem gør hvad, hvis en bruger mister telefonen.

I NETDK ser vi typisk, at virksomheder i århus og lystrup får den roligste overgang, når pilot og recovery er skrevet ned, før første policy aktiveres. Det samme gælder, uanset branche.

Break-glass konti: jeres reserve-nøgle (mindst 2)

Illustration af break-glass nødkonto, pengeskab og Conditional Access-flow Illustration af nødkonto og adgangspolitik, skabt med AI.

En break-glass konto er som en reserve-nøgle i en forseglet kuvert. Man håber aldrig, den skal bruges. Men den skal virke, når alt andet fejler.

Microsofts officielle anbefalinger til nødadgang er samlet her: Manage emergency access admin accounts.

Anbefaling (SMV-standard)

  • Opret mindst 2 break-glass konti.
  • Brug meget stærke passwords (lange passphrases), gemt i et fysisk pengeskab eller en password vault med streng adgang.
  • Sæt tydelige regler: kontiene bruges kun ved incident, og logges i en hændelsesrapport.
  • Undgå at knytte dem til daglig mail eller Teams, de skal være “kolde” konti.

Undtagelser uden at skyde jer selv i foden
Hvis break-glass konti undtages fra MFA-krav (ofte nødvendigt for at kunne logge ind ved metode-fejl), så gør undtagelsen:

  • tidsbegrænset i praksis (genbesøg fast, fx kvartalsvis),
  • meget snæver (kun de to konti),
  • dokumenteret (hvorfor, hvornår, hvem godkendte).

Permanente undtagelser, der aldrig bliver kigget på igen, ender næsten altid som et hul.

Trin for trin: opsæt Microsoft 365 MFA med Conditional Access (uden lockout)

Illustration af trinvis portal-navigation med Planlæg, Pilot, Udrulning, Overvågning Illustration af trinvis opsætning og udrulningsfaser, skabt med AI.

Nedenstående flow passer til de fleste SMB’er på microsoft 365, når man vil rulle MFA ud kontrolleret.

1) Find de rigtige menuer (UI ændrer sig, brug søgning)

Gå til Microsoft Entra admin center (entra.microsoft.com).

I 2026 kan menuer flytte sig. Brug derfor også søgefeltet øverst, og søg på:

  • “Conditional Access”
  • “Authentication methods”
  • “Sign-in logs”

Typiske stier (kan variere):

  • Protection → Conditional Access
  • Protection → Authentication methods
  • Monitoring → Sign-in logs

2) Forbered grupper (pilot først)

Opret to Entra-grupper:

  • “MFA-Pilot”
  • “MFA-AlleBrugere” (til senere)

Hold break-glass konti udenfor disse grupper, og dokumentér hvorfor.

3) Vælg metoder (gå efter app og phishing-resistente valg)

Under Authentication methods, sørg for at de metoder I vil tillade, faktisk er aktiveret.

Praktisk anbefaling:

  • Primær: Authenticator-app
  • Sekundær: FIDO2 key eller anden stærk metode til nøglepersoner
  • SMS kun som fallback, hvis I ikke kan komme udenom det

4) Opret en CA-policy i “Report-only” (test uden at blokere)

I Conditional Access:

  • Users : vælg gruppen “MFA-Pilot”
  • Cloud apps : start med “All cloud apps”, eller målret først de vigtigste (Exchange, SharePoint, Teams)
  • Grant : “Require multifactor authentication”
  • Enable policy : start i Report-only

Det her er jeres tørkørsel. I kan se effekten, før brugerne mærker den.

Hvis I vil sikre admins særskilt, så følg Microsofts vejledning: Require MFA for administrators with Conditional Access.

5) Valider i sign-in logs, og ret fejl før I aktiverer

Kig i Sign-in logs efter:

  • brugere der fejler pga. “MFA required” men ikke kan registrere
  • gamle mail-klienter eller services, der ikke understøtter moderne login
  • uventede blokeringer fra andre policies

Når pilot kører stabilt i nogle dage, skifter I policy fra Report-only til On .

6) Udrulning til resten (gradvist, ikke alt på én gang)

Skift “Users” fra pilotgruppen til “MFA-AlleBrugere”, eller lav en ny policy til den store gruppe.

Hold fokus på princippet: ingen store spring. Det er sådan man undgår, at hele huset ringer samtidig.

Do’s & don’ts: de typiske fejl der låser folk ude

Do : Hav mindst 2 break-glass konti, test dem fast (fx hvert kvartal).
Do : Brug pilot, og start i Report-only.
Do : Kræv mindst to registrerede metoder for nøglebrugere (app + backup-metode).
Do : Dokumentér recovery, inkl. hvem der må nulstille MFA.

Don’t : Lav permanente undtagelser “indtil videre”. De bliver sjældent fjernet.
Don’t : Slå MFA til for alle uden pilot, især ikke hvis I har ældre klienter.
Don’t : Bland per-user MFA og Conditional Access tilfældigt, vælg én styringsmodel.

Hurtig fejlfinding (når det går galt i hverdagen)

Bruger kan ikke registrere MFA
Tjek om CA kræver MFA før registrering er muligt, og om brugeren mangler tilladte metoder. Bed brugeren prøve igen på stabilt net og opdatere Authenticator-app.

Conditional Access blokerer uventet
Se Sign-in logs for “Failure reason”. Ofte er det en anden policy (fx lokationskrav) der rammer. Sæt policy i Report-only midlertidigt for at isolere fejlen.

Mistet telefon
Brug recovery-processen: verificér identitet, nulstil MFA-metoder, og få brugeren til at registrere ny metode. Sørg for at brugeren har en backup-metode næste gang.

Ændring af telefonnummer
Undgå at gøre SMS til eneste vej. Hvis SMS bruges, opdatér nummeret, og få brugeren over på app som primær metode.

Kort FAQ til IT-ansvarlige

Skal alle have MFA?
Ja, for normale brugere og især admins. Det reducerer konto-overtagelser markant.

Security Defaults eller Conditional Access?
Security Defaults er fint til simple miljøer. Conditional Access passer bedre, når I vil styre pilot, undtagelser og admins mere præcist.

Hvad med resten af sikkerheden?
MFA står ikke alene. Kombinér med backup (test gendannelse), opdateret antivirus på endpoints og en korrekt sat firewall . Det er samlet set, der giver robust it-sikkerhed.

Hvem skal eje processen?
En ansvarlig (IT-ansvarlig eller ekstern partner) der både kan ændre policies og håndtere it-support på udrulningsdagen.

Konklusion

Microsoft 365 MFA virker bedst, når det rulles ud som en kontrolleret ændring, ikke som et hurtigt “on”. Brug pilot, start i Report-only, hold undtagelser få og tidsstyrede, og hav mindst to break-glass konti med klare regler. Så får I bedre it-sikkerhed uden at låse forretningen ude.

Når setup’et er på plads, giver det også ro til at arbejde videre med it-løsninger som backup, antivirus og firewall, uden at MFA bliver en daglig brandøvelse.