Microsoft Conditional Access guide: stop MFA-træthed

Hvis jeres brugere får MFA-prompter hele tiden, begynder de at trykke “godkend” på autopilot. Samtidig ser vi flere angreb med token-tyveri, hvor en stjålet session kan omgå MFA. Microsoft Conditional Access er måden, I gør adgangskontrol stram – uden at gøre hverdagen langsom. Her får I en praktisk opskrift på regler, enheder og undtagelser, der kan driftes i en SMB.

• Skær ned på unødige MFA-prompter: kræv MFA ved risiko, ny lokation og ukendte enheder – ikke “altid, for alle”.
• Stop de nemme omgåelser: kræv compliant device (Intune) til mail og SharePoint – især på mobil.
• Gør token-tyveri sværere: brug phishing-resistent MFA (FIDO2/passkeys) til admins og nøglepersoner.
• Hold forretningen kørende: brug “break-glass” konti og tydelige undtagelser, så I ikke låser jer selv ude.
• Dokumentér til ledelse/cyberforsikring: log, test og genbesøg regler hver måned.

Hvorfor Conditional Access er jeres digitale dørmand

MFA alene er ikke en plan, hvis I giver adgang fra enhver enhed og enhver placering. Conditional Access (i Microsoft Entra ID) sætter betingelser for adgang: hvem logger ind, hvad de prøver at åbne, hvilken enhed de bruger, og hvorfra. I praksis kan I flytte sikkerhed fra “brugeren skal huske at gøre det rigtige” til “systemet håndhæver det rigtige”.

Microsofts egen sikkerhedskommunikation peger på, at token-tyveri og stjålne sessioner fylder mere, netop fordi MFA kan omgås, når angriberen allerede har en aktiv session. Det ændrer prioriteringen: I skal i højere grad sikre sessionen og enheden – ikke kun login-øjeblikket.

Før → Efter #1
Før: “MFA for alle, altid” → mange prompts → MFA fatigue og flere fejlgodkendelser.
Efter: “MFA ved højere risiko + stærkere krav til admins” → færre prompts i normal drift, men højere sikkerhed ved afvigelser.

Sådan undgår I MFA-træthed uden at sænke sikkerheden

MFA-træthed opstår typisk af to årsager: (1) I kræver MFA ved hvert login, også når intet er unormalt, og (2) I har ikke skelnet mellem almindelige brugere og privilegerede roller.

Brug beslutningsregler, ikke mavefornemmelser

• Lav friktion i “kendt, sund” kontekst: Kendt brugermønster + compliant device + forventet land = færre prompts.
• Høj friktion ved afvigelser: Ukendt land, ny enhed, risikabel login-adfærd eller admin-rolle = kræv stærkere metode.
• Segmentér: Administrationskonti, økonomi/HR og eksterne samarbejdspartnere får strammere regler end resten.

Tjekliste: Microsoft Conditional Access guide til en SMB (50–300 brugere)

Brug tjeklisten som minimums-baseline. Den kan typisk implementeres med Microsoft 365 Business Premium (afhængigt af jeres licensmix og Entra ID-funktioner).

Politik	Gælder for	Kontroller (krav)	Hvad I tjekker
1) Blokér legacy authentication	Alle brugere	Block	Finder I stadig POP/IMAP/SMTP AUTH i brug? Skift til moderne auth eller specifikke undtagelser.
2) Kræv MFA til alle brugere	Alle brugere (med undtagelser styret)	Require MFA	Undtag kun break-glass og servicekonti med alternative kontroller.
3) Kræv phishing-resistent MFA til admins	Privilegerede roller	Require authentication strength (FIDO2/passkey)	Har alle admins en fysisk nøgle/passkey? Er SMS/voice stadig tilladt til admin-roller?
4) Kræv compliant device til M365-data	Exchange, SharePoint, OneDrive, Teams	Require device to be marked as compliant	Er iOS/Android med i Intune? Blokerer I adgang fra “tilfældige” mobil-klienter?
5) Stram adgang uden for DK/EU (lokationspolitik)	Alle eller udvalgte grupper	Block eller require step-up MFA	Har I defineret “named locations”? Har I en proces for rejse-undtagelser?
6) Session controls	Web-adgang til M365	Sign-in frequency / persistent browser session	Bliver brugere logget af for ofte? Justér per app/gruppe, ikke globalt.

Fejl der koster mest i Conditional Access (og hvordan I undgår dem)

1) Ingen break-glass konti

Hvis Conditional Access fejler, kan I låse hele tenant’en. Opret mindst to break-glass konti, udeluk dem fra CA-politikker, og beskyt dem med lange adgangskoder og offline opbevaring. Test logon kvartalsvist og log alle brug af kontoen.

2) “Compliant device” uden en realistisk Intune-plan

Hvis I slår compliant-krav til, men ikke har defineret Intune compliance policy (PIN, kryptering, OS-version, jailbreak/root-detektion), ender I med enten for mange blokeringer eller for svage krav.

Før → Efter #2
Før: Mobil adgang til mail fra private telefoner uden styring → data kan blive liggende i ukontrollerede apps og backups.
Efter: Intune + compliance + Conditional Access → firmadata kræver godkendt app/enhed, og adgangen kan lukkes på minutter ved tab/fratrædelse.

3) Undtagelser, der bliver permanente

“Mid­lertidig undtagelse” bliver ofte til “for evigt”. Sæt udløb på undtagelser via proces: hvem godkender, hvor længe, og hvad er exit-kriteriet (fx enheden er enrolled i Intune).

Hvordan vælger I mellem “compliant device” og app-beskyttelse på mobil?

På mobil handler valget om, hvor meget I må styre – og hvor kritiske data er.

• Intune MDM (enhedsstyring): I kan håndhæve enheds-krav (kryptering, OS-krav, jailbreak) og lave fuld “wipe” ved behov. Velegnet til firmatelefoner og nøglepersoner.
• Intune MAM (app-beskyttelse): I styrer kun firmadata inde i Outlook/Teams/Office-apps (fx kopier/indsæt, lokal lagring), uden at “overtage” hele telefonen. Velegnet til BYOD, hvor privatliv vægter.

Praktisk tommelfingerregel: Hvis brugeren har adgang til regnskab, HR, kundekontrakter eller admin-funktioner, så kræv MDM + compliant device. For almindelig mail/Teams på private telefoner kan MAM ofte være nok, men kombiner med Conditional Access, så kun godkendte apps får adgang.

Sådan tester og dokumenterer I reglerne, så de kan driftes

Conditional Access er ikke “sæt og glem”. Gør det driftsklart med faste kontroller:

1. Lav en pilotgruppe (IT + 5–10 power users) og rull regler ud gradvist.
2. Brug report-only på nye politikker, indtil I kan se konsekvenserne i loggene.
3. Gennemgå sign-in logs ugentligt i starten: hvilke apps, klienttyper og lokationer bliver ramt?
4. Dokumentér formål, scope, undtagelser og rollback-plan pr. politik.
5. Mål “støj”: antal supporthenvendelser og hyppigste blok-årsager. Justér én ting ad gangen.

Hvis I samtidig vil styrke den samlede posture i Microsoft 365, kan I samle arbejdet under jeres IT-sikkerhed-spor, så drift, logging og enheder hænger sammen.

FAQ om Microsoft Conditional Access

Hvad er Conditional Access i Microsoft 365?

Conditional Access er adgangsregler i Microsoft Entra ID, der bestemmer, om et login må gennemføres, og hvilke krav der skal opfyldes (fx MFA, compliant device, placering). Det bruges til at styre adgang til Microsoft 365 og andre apps.

Hvad er en god Microsoft Conditional Access guide til at stoppe MFA-træthed?

Start med tre ting: (1) blokér legacy authentication, (2) kræv MFA for alle, og (3) kræv phishing-resistent MFA for admins. Tilføj derefter “compliant device” for M365-data, så I ikke kun sikrer login, men også enheden.

Hvilke brugere skal have phishing-resistent MFA (FIDO2/passkeys)?

Minimum: alle med administrative roller i Entra/M365, samt brugere med adgang til økonomi/HR eller kritiske systemer. Hvis I kun vælger én gruppe, så vælg admins først.

Skal vi kræve “compliant device” for Exchange og SharePoint?

Ja, hvis I vil reducere risikoen ved token-tyveri og ukontrollerede enheder. Gør det gradvist: pilot → hele virksomheden. For BYOD kan I alternativt starte med Intune MAM + krav om godkendte apps, men planlæg en vej til compliant device for nøglepersoner.

Hvordan laver vi geofencing i Microsoft 365 uden at blokere rejser?

Lav en named location for Danmark/EU og brug den til at kræve “step-up” (stærkere MFA) uden for området, frem for hård blokering. Til rejser: lav en tidsbegrænset undtagelse, der udløber automatisk, og kræv compliant device i perioden.

Hvad er de mest almindelige fejl i Entra ID sikkerhedsindstillinger?

Tre klassikere: for brede undtagelser, ingen break-glass, og at “compliant device” aktiveres før Intune compliance policy er defineret. Ret dem i den rækkefølge.

Kræver Conditional Access Microsoft 365 Business Premium?

I mange SMB-scenarier ja, fordi I typisk også vil bruge Intune compliance og mere avanceret adgangskontrol. Tjek jeres licenser før I designer reglerne, så I ikke bygger en politikpakke I ikke kan håndhæve.

Sådan kommer I i gang i næste uge (konkrete skridt)

1. Kortlæg jeres apps og brugergrupper: admins, økonomi/HR, standardbrugere, eksterne.
2. Opret 2 break-glass konti, dokumentér opbevaring, og test logon.
3. Slå “block legacy authentication” til og verificér, at intet forretningskritisk bruger POP/IMAP/SMTP AUTH.
4. Rul “Require MFA” ud med pilotgruppe først og ret de 3 største støjkilder (client type, undtagelser, session).
5. Indfør phishing-resistent MFA til admins (FIDO2/passkey) og fjern svage metoder for den gruppe.
6. Definér Intune compliance policy (PIN, kryptering, OS-minimum, jailbreak/root) og aktiver “Require compliant device” for Exchange/SharePoint.
7. Gennemgå sign-in logs ugentligt i 4 uger og lås undtagelser med udløb og godkendelsesflow.