Conditional Access Entra ID: ryd op i 5 baselines

Hvis jeres Conditional Access Entra ID består af 30–50 regler med undtagelser, har I sandsynligvis både huller og unødige blokeringer. Det giver falsk tryghed: brugerne kommer ind, når de ikke bør – og bliver afvist, når de skal arbejde. Målet her er enkelt: skær ned til et lille sæt baselines, der kan forklares, testes og dokumenteres.

• Reducér risikoen fra miskonfigurationer: konsolidér til 5 baselines og fjern modstridende Conditional Access policies.
• Luk de farlige undtagelser: begræns “exclusions” til konkrete break-glass-konti og kontrollerede driftsbehov.
• Undgå nedetid pga. 2026-håndhævelse: auditér “All resources”-politikker og test app-flows i “What If” før ændringer rammer jer.
• Stop moderne MFA bypass (token theft): kræv compliant enhed og (hvis I har P2) brug risk-baserede betingelser.
• Gør NIS2-audit lettere: brug sign-in logs som bevis for, hvem der fik adgang, fra hvor, og på hvilke vilkår.

Hvorfor opstår “policy overload” i Conditional Access?

De fleste SMB’er starter fornuftigt: én regel for MFA og én for legacy authentication. Efter et par år kommer særbehovene: en VIP der rejser, en gammel app, en leverandør, en servicekonto. Resultatet bliver “policy overload”, hvor regler overlapper og undtagelser bliver permanente. CyberCX (2025) peger netop på policy overload og dårlig håndtering af undtagelser som typiske årsager til sikkerhedsbrud.

Samtidig er identitet en top-angrebsvektor. Microsofts Digital Defense Report (2025) fremhæver, at MFA stopper mange simple angreb, men at angribere i stigende grad går efter token theft for at komme udenom. Det presser jer mod mere konsekvent Conditional Access-gennemførsel.

Sådan rammer 2026-ændringer jeres apps og undtagelser

Microsoft strammer håndhævelsen af Conditional Access i 2026. Ifølge Microsoft Entra Blog (2026) og 4sysops (2026) vil MFA/enhedskrav blive gennemtvunget for visse OIDC/directory scopes, selv om en ressource tidligere var ekskluderet i jeres policy. EPC Group (2026) advarer om, at man bør auditere “All resources”-politikker, ellers risikerer man nedetid i integrationer og tredjepartsapps.

Praktisk konsekvens: Hvis I i dag “løser” en app ved at ekskludere en enkelt cloud-app eller en bestemt ressource, kan det stoppe med at virke. Cloudbrothers (2025) beskriver også, hvordan single-resource exclusions kan give bypass-muligheder via ældre API-veje, og anbefaler at undgå den type undtagelser.

Tjek hurtigt jeres risiko for app-nedetid

1. Find policies målrettet “All resources”. Notér krav (MFA, compliant device) og hvilke undtagelser der findes.
2. Gennemgå undtagelser pr. policy. Hvis I ser “hele IT-afdelingen”, “alle VIPs” eller “alle servicekonti”, så er den for bred.
3. Test app-flows i Conditional Access “What If”. Brug realistiske brugere og scenarier (ekstern enhed, mobil, hjemmefra).
4. Kontrollér sign-in logs. Se hvilke policies der report-only ville have blokeret/krævet MFA, før I håndhæver.

Kilder: Microsoft Entra Blog (2026), 4sysops (2026), EPC Group (2026), Cloudbrothers (2025).

Tjekliste: 5 baselines der typisk er nok i Entra ID

“Less is more” virker i Conditional Access, fordi I kan teste og dokumentere et lille sæt regler. Brug baselines nedenfor som udgangspunkt, og lav kun ekstra policies, når der er et klart, afgrænset behov.

Baseline	Hvem	Håndhæv	Det kigger I efter i logs
1) Blokér legacy authentication	Alle brugere (inkl. servicekonti, hvis muligt)	Block	Forsøg på POP/IMAP/SMTP AUTH eller ældre klienter. Fjern undtagelser, eller flyt til moderne auth.
2) MFA for alle brugere	Alle brugere	Require MFA	Hvor mange sign-ins rammer undtagelser? Hvis undtagelser er > få navngivne konti, er den for bred.
3) Admin-beskyttelse	Alle admin-roller	Require MFA + stærkere metode (fx phishing-resistent) + strammere session	Admin-sign-ins fra ukendte enheder/lokationer. Prioritér blokering eller step-up.
4) Kræv compliant device for M365	Brugere med adgang til følsomme data	Require device to be marked as compliant	Afvisninger pga. non-compliant: er det reelle problemer eller manglende onboarding/Intune-tilmelding?
5) Risk-baseret adgang (P2)	Alle (eller mindst højrisko-grupper)	Ved høj risiko: blokér eller kræv password reset + MFA	Sign-in risk/user risk events. Brug dem til at stoppe token theft dynamisk.

Beslutningsregler, før I laver policy #6

• Kan behovet løses med målgruppe-segmentering? Opret en gruppe og lad baseline gælde, frem for en ny policy med undtagelser.
• Er undtagelsen midlertidig? Lav en særskilt “Exception”-policy med udløbsdato og ejer.
• Skaber I en bypass-vej? Undgå single-resource exclusions og brede exclusions (Cloudbrothers, 2025).
• Kan I teste den? Hvis I ikke kan beskrive testcases i “What If”, er den for uklar.

Fejl der koster mest: undtagelser og manglende nød-adgang

1) “Exclusions” der bliver til bagdøre

Undtagelser er ofte den hurtige løsning, når noget driller. Problemet er, at de sjældent bliver rullet tilbage. CyberCX (2025) peger på “exclusion mismanagement” som en klassiker. Læg en enkel regel: Hver undtagelse skal have ejer, formål og udløbsdato. Ellers er det ikke en undtagelse – det er jeres nye standard.

2) Ingen (eller forkert) break-glass account

Hvis I rammer forkert med en policy, kan I låse jer selv ude. OneUptime (2026) fremhæver netop behovet for at bruge sign-in logs/What If og at have en nød-konto. Tommelfingerregel: mindst to break-glass-konti, ikke synkroniseret fra on-prem, beskyttet og overvåget – og kun ekskluderet fra de absolut nødvendige policies.

Sådan bruger I Conditional Access som dokumentation til NIS2

NIS2 handler ikke kun om at “have sikkerhed”. I skal kunne vise, hvordan I kontrollerer adgang. Conditional Access + sign-in logs giver et konkret spor: hvem loggede ind, hvilken app, fra hvilken kontekst, og hvilke krav der blev håndhævet.

Lav en lille “audit-pakke” I kan opdatere månedligt

• Policy-oversigt: navn, formål, scope (brugere/apps), krav, undtagelser, ejer.
• Ændringslog: hvornår blev policy ændret, og hvad var risikovurderingen?
• Bevis fra logs: 3–5 eksempler på håndhævet MFA og afviste legacy sign-ins.
• Testprotokol: “What If”-screenshots/outputs for kritiske flows efter ændringer.

Hvis I samtidig kører drift som service, kan dette være en fast del af jeres compliance-rapportering.

FAQ om Conditional Access Entra ID

Hvor mange Conditional Access policies bør vi have?

Start med 5 baselines og sigt efter under 10 i alt. Hvis I har flere, så kræv en beslutningsregel: hver ny policy skal have et unikt formål, en tydelig testcase og ingen brede undtagelser.

Hvad betyder Microsofts 2026-håndhævelse for vores integrationer?

Hvis I har undtagelser på specifikke ressourcer/apps, kan de blive mindre effektive, fordi Microsoft i 2026 strammer håndhævelsen for visse directory/OIDC-scope-kald. Auditér “All resources”-politikker og test jeres app-flows i “What If” før I håndhæver ændringer. Se Microsoft Entra Blog (2026) for detaljerne.

Kan MFA omgås, og hvad gør vi ved token theft?

Ja. Microsoft (Digital Defense Report, 2025) beskriver, at angribere i stigende grad stjæler tokens for at omgå MFA. Praktisk modtræk: kræv compliant enhed for adgang til M365-data, stram sessions for admins, og brug risk-baserede policies (kræver Entra ID P2) med “sign-in risk/user risk”.

Skal vi vælge Entra ID P1 eller P2 for Conditional Access?

P1 dækker mange baselines (MFA, device compliance, legacy blokering). P2 giver risk-baserede betingelser (Identity Protection), som er en direkte fordel mod token theft. Hvis I har mange eksterne logins, høj admin-eksponering eller compliance-pres, er P2 typisk det næste logiske skridt.

Hvordan håndterer vi servicekonti og automatisering uden at lave farlige undtagelser?

Undgå at undtage hele grupper af “servicekonti”. Segmentér pr. integration, brug så få privilegier som muligt, og lav en separat exception-policy med udløbsdato. Test konsekvensen i “What If”, og dokumentér hvorfor undtagelsen findes.

Hvad er den hurtigste måde at fejlsøge, når Conditional Access blokerer brugere?

Brug rækkefølgen: 1) Sign-in logs (hvilken policy ramte?), 2) Conditional Access “What If” (kan I genskabe scenariet?), 3) check om enhed/klient er compliant og om der bruges legacy auth. OneUptime (2026) fremhæver netop “What If” og logs som de vigtigste værktøjer.

Sådan implementerer I oprydningen uden at stoppe forretningen

1. Kortlæg alt: eksportér en liste over alle Conditional Access policies, og markér dubletter og policies uden ejer.
2. Indfør 5 baselines i “report-only” først: mål påvirkning i sign-in logs i mindst 7–14 dage.
3. Ryd op i undtagelser: giv hver undtagelse ejer + udløbsdato, og flyt midlertidige undtagelser til en særskilt exception-policy.
4. Test kritiske flows: admins, fjernarbejde, mobil, tredjepartsapps og automatisering – dokumentér tests i “What If”.
5. Håndhæv gradvist: start med admins og legacy blokering, derefter MFA for alle, derefter compliant device for følsomme grupper.
6. Byg drift ind: månedlig review af undtagelser + kvartalsvis gennemgang af policies som en del af jeres drift.

Relaterede kilder: CyberCX (2025), Check Point Research/ITAdOn (2025), Microsoft Learn (2026), Recorded Future (2026).