Conditional Access Microsoft 365: 4 regler I skal have

“Vi har MFA” er ikke længere en garanti mod konto-overtagelse i Microsoft 365. AiTM-phishing og token theft kan give angriberen en gyldig session, selv når nogen trykker “Godkend”. Conditional Access gør adgang afhængig af enhed og kontekst – ikke kun bruger + MFA. Resultatet er færre kompromitterede konti og mere dokumenterbar adgangskontrol.

• Stop de gamle indgangsveje: Blokér legacy authentication, så “gamle” mailprotokoller ikke omgår moderne login-kontrol.
• Gør MFA til en minimumsbarriere: Kræv MFA for alle brugere – og mål undtagelser, ikke succeser.
• Brug Microsofts risikosignaler: Blokér eller kræv ekstra kontrol ved risky sign-ins, så mistænkelige logins ikke bliver “normale”.
• Gør enheden til dørmand: Kræv compliant device via Intune, så stjålne tokens fra private enheder ikke giver adgang.
• Undgå selvlåsning: Indbyg break-glass og test i report-only før håndhævelse.

Hvorfor MFA kan omgås – og hvad Conditional Access lukker

MFA løser primært problemet “stjålet adgangskode”. Men flere angreb går efter sessionen i stedet. I praksis ser vi to mønstre:

1. AiTM-phishing: Brugeren logger ind på en falsk side. Angriberen “sidder i midten” og får et token, der kan genbruges.
2. Token theft: Session cookies stjæles fra en browser på en ikke-administreret enhed (typisk privat pc). Antivirus stopper ikke nødvendigvis dette, fordi der ikke kræves klassisk malware.

Hvis I vil have et konkret billede af token theft-problemet, så læs vores indlæg om, hvorfor antivirus ikke er nok mod moderne angreb: Blog 5 om token theft/AI.

Før → Efter #1
Før: “MFA er slået til, så alle enheder kan logge på.”
Efter: “Kun administrerede, compliant enheder må logge på – stjålne tokens fra private enheder bliver afvist.”

Sådan vælger I licensniveau: hvorfor Business Premium ofte er prisen værd

Conditional Access kræver typisk Microsoft Entra ID P1 (ofte via Microsoft 365 Business Premium eller enterprise-planer). For mange SMB’er er det den mest direkte vej til at få “identitet + enhed + kontekst” i samme kontrolpunkt.

Beslutningsregel: Hvis I har fjernarbejde, konsulenter, BYOD, eller compliance-krav, så er “kun MFA” sjældent nok. Budgettet skal i stedet holdes op mod konsekvensen ved et kompromitteret M365-login (mail, OneDrive, SharePoint og Teams). Hvis licensbudgettet fylder i jeres planlægning, så se vores indlæg om prisstigninger og budgettering: Blog 10 om budget/licenser.

Tjekliste: 4 Conditional Access-politikker vi prioriterer i praksis

Her er en “minimumspakke” til Conditional Access i Microsoft 365, som kan udrulles trinvis. Målet er at reducere risikoen for konto-overtagelse uden at gøre hverdagen unødigt tung.

Politik	Hvad den gør	Hvad I tjekker før I håndhæver	Typisk scope
1) Blokér legacy authentication	Lukker for ældre login-protokoller, der ikke kan bruge moderne kontroller.	Find brugere/systemer der stadig bruger gammel mail-klient, scan for SMTP/IMAP/POP-forbrug, planlæg erstatning (moderne klient/app password-udfasning).	Alle brugere. Start med report-only 3–7 dage.
2) Kræv MFA for alle (basispolitik)	Sikrer at login kræver mindst to faktorer.	Hvem har undtagelser? Er admin-konti dækket? Er “break glass” konti ekskluderet og sikret særskilt?	Alle brugere, alle cloud-apps (typisk).
3) Blokér eller step-up ved risky sign-ins	Reagerer på mistænkelige logins baseret på risikosignaler.	Definér handling: blokér ved høj risiko, step-up ved medium. Aftal supportflow når legitime brugere rammes.	Alle brugere – start med pilotgruppe (IT + nøglebrugere).
4) Kræv compliant device (Intune)	Kun enheder der lever op til jeres compliance (opdateringer, kryptering m.m.) får adgang.	Intune enrollment på plads? Compliance policies: BitLocker/FileVault, OS-version, jailbreak/root, Defender-status. Plan for gæsteadgang og mobile enheder.	Start med Office 365 (Exchange/SharePoint/Teams), udvid derefter til alle apps.

Hvad betyder “compliant device” i praksis?

Det er en simpel kontrol: “Må denne enhed overhovedet bruges til at logge på?” Typiske minimumskrav vi ser give effekt i SMB:

• Diskkryptering: BitLocker på Windows / FileVault på macOS.
• Opdateringsniveau: minimum OS-version og sikkerhedsopdateringer.
• Enheden er tilmeldt og styret (Intune) – ikke en privat, ukendt pc.
• Basic endpoint-sundhed (fx Defender aktiv) hvis jeres setup understøtter det.

Før → Efter #2
Før: “Hjemme-pc kan åbne Outlook og downloade hele postkassen.”
Efter: “Hjemme-pc får blokering eller kun web-adgang, mens firma-pc får fuld adgang – samme bruger, forskellig kontekst.”

Fejl der koster tid: sådan undgår I at låse jer selv ude

De fleste udskydelser skyldes én reel frygt: selvlåsning. Den undgår I med tre konkrete greb:

1. Break-glass konto (2 stk): Cloud-only, stærke adgangskoder, ekskludér fra CA, og beskyt med meget stram overvågning og adgang (fx kun fra navngivne IP’er, hvis muligt).
2. Report-only først: Kør nye CA-politikker i report-only, gennemgå logs, og ret undtagelser før I håndhæver.
3. Segmentér scope: Start med pilotgruppe + enkelte cloud-apps. Udvid, når supportflow og undtagelser er afklaret.

Hvordan Conditional Access hjælper jer med NIS2-adgangskontrol

NIS2 handler ikke kun om at “have MFA”. Det handler om at kunne dokumentere adgangskontrol og håndhævelse. Conditional Access giver jer konkrete artefakter: politikker, scopes, logning og ændringshistorik. Det gør revision og intern kontrol mere håndgribelig.

Hvis I arbejder med NIS2, så koble CA-politikker til jeres interne kontrolpunkter: hvem må tilgå hvilke systemer, fra hvilke enheder, og hvad gør I ved afvigelser. Se også vores NIS2-indlæg for det overordnede compliance-billede: Blog 1 om NIS2. For løbende dokumentation kan I samle CA-ændringer, Intune compliance og login-logs i et fast månedligt kontrolnotat under compliance.

FAQ om Conditional Access Microsoft 365

Hvad er Conditional Access i Microsoft 365?

Conditional Access er adgangsregler i Microsoft Entra ID, der bestemmer om et login må gennemføres baseret på betingelser som brugerrolle, enhedens status (compliant), lokation og risikosignaler.

MFA vs Conditional Access: hvad er forskellen i praksis?

MFA er en kontrol ved login (“bevis du er dig”). Conditional Access er en politikmotor (“bevis det, og gør det kun under de rigtige betingelser”). Tommelfingerregel: MFA uden CA beskytter primært mod password-tyveri; CA beskytter også mod mange token-baserede scenarier ved at begrænse hvor og fra hvad der kan logges ind.

Stopper Conditional Access token theft helt?

Det kan reducere effekten markant, især når I bruger Require compliant device. Hvis et token stjæles fra en privat pc, vil angriberen typisk ikke kunne opfylde kravet om en administreret/compliant enhed, og login bliver afvist. Kombinér med risikopolitikker og stramning af sessions for høj-risiko brugere.

Skal vi altid blokere legacy authentication?

Ja, som udgangspunkt. Undtagelser bør være midlertidige og dokumenterede, fordi legacy auth ofte ikke understøtter moderne kontroller. Hvis I har systemer der bruger IMAP/SMTP, så planlæg migrering til moderne auth eller applikationsalternativer.

Hvordan kommer vi i gang med “Require compliant device” uden kaos?

Start med: (1) Intune enrollment for firma-pc’er, (2) en enkel compliance policy (kryptering + opdateret OS), (3) CA i report-only, (4) pilotgruppe, (5) udvid til Exchange/SharePoint/Teams. Hold BYOD på web-adgang i en overgang, hvis nødvendigt.

Hvilken licens kræver Conditional Access?

Typisk Entra ID P1, som ofte følger med Microsoft 365 Business Premium eller enterprise-licenser. Beslutningsregel: Hvis I vil styre adgang efter enhed og risiko, skal I budgettere for P1/Premium, ellers ender I med “MFA on/off” uden fin styring.

Hvordan tester vi, om vores Conditional Access virker?

Test tre scenarier: (1) login fra compliant firma-pc (skal virke), (2) login fra ikke-administreret pc (skal blokere/kræve begrænsning), (3) login fra usædvanlig lokation/IP (skal trigge MFA/blocked ved høj risiko). Gennemgå sign-in logs for hver test og gem resultatet som dokumentation.

Sådan ruller I Conditional Access ud de næste 10 arbejdsdage

1. Kortlæg: Træk sign-in logs og identificér legacy auth-forbrug samt de apps der bruges mest (Exchange, SharePoint, Teams).
2. Byg sikkerhedsnet: Opret 2 break-glass konti, dokumentér ejerskab og opbevar adgang sikkert.
3. Udrul i report-only: Opret politikkerne “Block legacy auth” og “Require MFA” som report-only i 3–7 dage.
4. Gør enheder klar: Tilmeld firma-enheder i Intune, læg minimum compliance (kryptering + OS-opdateringer), og ret de enheder der fejler.
5. Pilotér risky sign-ins: Aktivér risikobaseret politik for en lille gruppe, aftal hvem der håndterer false positives.
6. Håndhæv gradvist: Skift én politik ad gangen fra report-only til on, og udvid scope uge for uge.
7. Dokumentér og mål: Gem politik-snapshots, testcases og månedlig log-review som evidens til ledelse/revisor.