Sikring af Microsoft 365: Conditional Access, MFA‑undtagelser og break‑glass‑konti i praksis

Den, der vil sikre Microsoft 365 korrekt, kommer ikke uden om Conditional Access (adgangsafhængige politikker i Entra ID, tidligere Azure AD) og Multi-Faktor-Authentifizierung (MFA, altså login med mindst to faktorer). I mange virksomheder er MFA og de første Conditional-Access-regler hurtigt aktiveret – og så starter arbejdet først: Undtagelser skal begrundes, nødadgange organiseres ordentligt, og driftsprocesser skal udformes, så sikkerhed ikke bliver en supportlavine.

I praksis fejler “M365 sikre” sjældent på den grundlæggende teknik, men på hverdagsemner: servicekonti til interfaces, legacy-protokoller, feltpersonale uden pålideligt mobilnet, administratorer med for brede rettigheder, eller en hændelse hvor netop den beskyttelsesforanstaltning blokerer IT’s adgang. Dette indlæg giver overblik over, hvordan Conditional Access, MFA-undtagelser og Break-Glass-Accounts spiller sammen – og hvordan I driver det, så det forbliver pålideligt efter Go-live.

Hvorfor Conditional Access er løftestangen – og hvorfor MFA alene ikke er nok

MFA reducerer risikoen ved stjålne adgangskoder markant, men MFA er ikke et fuldstændigt adgangskoncept. Conditional Access (CA) beslutter kontekstafhængigt, under hvilke betingelser en adgang må tillades: f.eks. kun fra administrerede enheder, kun fra bestemte lande, kun med risikobaseret vurdering eller kun med bestemte klientapps. Det er det afgørende skridt i retning af Zero Trust (sikkerhedsmodel hvor ingen adgang som standard stoles på, men løbende vurderes).

Typiske grunde til, at MFA alene i Microsoft 365 ikke rækker:

• Token i stedet for adgangskode: Moderne autentificering arbejder med tokens (tidsbegrænsede adgangsbilletter). Et stjålet token kan omgå MFA, hvis CA ikke kræver yderligere betingelser (f.eks. enhedsstatus eller sessionsstyring).
• Admin-risiko: Administrative konti er særligt attraktive mål. Uden CA-regler for adminadgange (f.eks. kun fra admin-workstations eller kun med phishing-resistent MFA) efterlades den største angrebsflade åben.
• ”Tilladt” er for bredt: Hvis CA ikke skelner mellem apps, dataklasser og adgangstyper, bliver sikkerheden hurtigt enten for slappet eller for RESTriktiv – begge dele skaber problemer.

Det operationelle kernepunkt er derfor: CA som politiklag, MFA som en byggesten i dette lag, plus et klart undtagelsesstyringssystem og robuste nødveje.

Arkitekturoversigt: Hvad Conditional Access i Entra ID faktisk styrer

For IT-ledelse og drift er det vigtigt ikke at forstå CA som “en politik”, men som en beslutningskæde. Entra ID vurderer ved hvert login signaler og anvender politikker. Vigtige signaler er:

• Identitet: Brugere, grupper, roller (f.eks. privilegerede roller som Global Administrator).
• Målressource: Cloud-app (Exchange Online, SharePoint/OneDrive, Teams, men også tredjepart via Enterprise App).
• Klienttype: Browser, moderne klienter, mobile apps samt „Legacy Authentication“ (ældre protokoller uden moderne tokens, f.eks. ældre IMAP/POP/SMTP-auth-varianter).
• Enhedsstatus: „Compliant“ eller „hybrid joined“ (administreret enhed, typisk via Intune eller domænetilknytning med enhedsstatus).
• Netværk/placering: Named Locations (definerede IP-ranges), lande/regioner, risikoindikatorer.
• Sessionsbetingelser: Session Lifetime, App-Enforced RESTrictions, Continuous Access Evaluation (løbende revurdering ved risikohændelser).

Set fra driftsvinklen afhænger kvaliteten af jeres CA-Konfiguration i høj grad af, om disse signaler er pålidelige. Et Named Location er kun så godt som jeres IP-adresshygiejne. „Compliant“ er kun så godt som jeres enhedsadministration og definitionen af compliance. Og risikovurderingen er kun hjælpsom, hvis I også arbejder med de events, den genererer.

Microsoft 365 korrekt sikre med Conditional Access: Et praktisk regelsæt

I stedet for en „stor“ regel fungerer i dagligdagen et sæt af få, klart afgrænsede Policies bedre. Det reducerer sideeffekter og gør fejlsøgning under et Incident enklere. Et afprøvet grundmønster består af:

1) Baseline für alle Nutzer: MFA erzwingen, Legacy blocken

For normale brugerkonti er baseline: MFA påkrævet, og Legacy Authentication blokeres. Legacy er her ikke „altmodisch“, men teknisk problematisk: Disse protokoller understøtter ofte ikke moderne MFA-challenges og er derfor et klassisk indgangspunkt for password spraying.

Vigtigt: Bloker ikke Legacy „på et tidspunkt“, men planlæg en overgangsfase med måling. Undersøg via Sign-in Logs, hvilke clients stadig bruger Legacy. I virksomheder afhænger der ofte multifunktionsprintere, Scan-to-Mail eller ældre mailclients i specialmiljøer af dette.

2) Admin-Policy: deutlich strenger als die Baseline

Privilegerede roller bør have deres egen Policy: Adgang kun fra definerede admin-endpoints (f.eks. „compliant“ og evt. separat Admin-Workstation-strategi), MFA med høj sikkerhed (phishing-resistent, f.eks. FIDO2/Passkey eller certifikat-baseret), og så vidt muligt begrænsninger for risikable lande/placeringer. Selv hvis ikke alle virksomheder straks indfører en fuld Privileged-Access-Architektur (PAM, altså privilegeret Zugriffsmanagement), er denne sondring værdifuld med det samme: En kompromitteret Adminkonto er et andet skadesrum end en kompromitteret Nutzerkonto.

3) Policy für externe Zusammenarbeit und Gäste

Gæsteadgange (B2B Collaboration) skaber ofte uventede dataveje: Gæster downloader filer fra SharePoint, arbejder i Teams eller får adgang til projektportaler. Fastlæg her bevidst, om gæster kun må logge ind med MFA, om bestemte apps er udelukket, og hvor længe sessions er gyldige. Til projektarbejde er en kortere session-levedygtighed ofte fornuftig for at reducere risikoen for „glemte Logins“.

4) Policy für sensible Datenpfade: Gerät oder Sitzung absichern

Hverdagen rummer forskellige beskyttelsesbehov: En salgsmedarbejder må måske læse e-mails fra enhver enhed, men ikke uden en administreret enhed downloade store datamængder fra SharePoint. Sådanne forskelle modelleres ikke ved en pauschal „erlaubt/verbietet“, men via CA-kombinationer: „Adgang tilladt, hvis Gerät compliant“ eller „Adgang kun per Browser med begrænset Sitzung“. Det er mindre hårdt end komplet blokering – og alligevel effektivt.

MFA-Ausnahmen: Wo sie realistisch sind – und wie man sie kontrolliert

MFA-undtagelser er ikke et tegn på svaghed, så længe de er bevidst udformede og driftsmæssigt kontrollerede. Uden kontrollerede undtagelser opstår skyggeløsninger: Brugere omgår processer, Admins slår regler hastigt fra, og før eller siden bliver regelsamlingen uigennemskuelig.

Vigtigt er sondringen: En MFA-undtagelse er sjældent „MFA aus“, men ofte „MFA anders“ eller „Adgang kun under andre betingelser“. Typiske undtagelseskategorier:

Ausnahmefall 1: Nicht-interaktive Zugriffe und Schnittstellen

Mange procesnære softwareløsninger integrerer M365-tjenester: e-mail-afsendelse, kalenderadgang, SharePoint-filarkiv, Teams-notifikationer eller Graph-API-adgang. Sådanne integrationer bør ikke køre via brugerkonti med deaktiveret MFA. Bedre er teknisk adgang via app-registreringer (applikation i Entra ID) med klare rettigheder og secret-/certifikatlivscyklus. Det er ikke en „MFA-Ausnahme“, men en anden autentificeringsform, der er mere auditerbar.

Driftsfølger: Secrets skal roteres, certifikater udløber, og rettigheder skal recertificeres. Hvis I planlægger integrationer, definér ejerskab (hvem fornyer certifikater/secrets) og overvågning (f.eks. advarsler før udløb). Ellers bliver „sikker“ app-autentificering til en uplanlagt nedetid.

Ausnahmefall 2: Geräte ohne modernen Login (z. B. Scanner, Drucker, Raum-Systeme)

Her opstår de klassiske diskussioner om SMTP-relay, Scan-to-Mail eller rum-postkasser. Den forkerte løsning er næsten altid „ein Benutzerkonto ohne MFA“. Bedre er tekniske veje, der ikke er afhængige af interaktiv login: central mail-relay med IP-RESTriktion, certifikat- eller Connector-tilgange, eller adskilte systempostkasser med snævre rettigheder. Afgørende er: Enheden kan ikke håndtere MFA selv, så designet må sikres på transport- og netværksstien.

Ausnahmefall 3: Notbetrieb und eingeschränkte Erreichbarkeit

Feltservice, produktion eller skiftehold har situationer uden mobildækning eller uden private mobiltelefoner. Her er det værd at tænke tidligt på alternative MFA-metoder: hardware-token, FIDO2-sikkerhedsnøgler, eller Windows Hello for Business (enhedsbundet login). „Temporär MFA aus“ er operationelt fristende, men skalerer dårligt og er næsten umuligt at auditere.

Ausnahmefall 4: Automatisierte Jobs mit Benutzerkontext

Nogle ældre systemer starter jobs „som bruger“, f.eks. til SharePoint-uploads eller rapporter. Det er i dag risikabelt, fordi det blander roller og adgangsrettigheder. Hvis udskiftning ikke er mulig med det samme, arbejd med mellemløsninger: begrænsede servicekonti, klare Named Locations, stramme password-/secret-politikker og konsekvent logning. Og: planlæg migrationen til app-identiteter som en selvstændig arbejdspakke, ikke som „später mal“.

Wie man Ausnahmen dokumentiert, genehmigt und wieder loswird

Undtagelser er i drift kun acceptable, hvis de har en livscyklus. En letvægtsmetode, som undgår bureaukrati men stadig er revisionssikker, har vist sig praktisk nyttig:

1. Begründung in einem Satz: Hvilken forretnings- eller driftsfunktion afhænger af den (f.eks. „Scan-to-Mail an Standort X“)?
2. Technische Einordnung: Hvilke apps/protokoller, hvilke konti, hvilke dataveje?
3. Kompensierende Kontrollen: Hvad begrænser risikoen (IP-RESTriktion, mindst nødvendige rettigheder, overvågning)?
4. Ablaufdatum: Hver undtagelse får en review-dato. Uden review bliver den fjernet eller fornyet.
5. Ejer: Hvem er ansvarlig, hvis noget går galt eller hvis undtagelsen udløber?

Det gør ikke undtagelserne „gute“, men det gør dem styrbare. Og det er præcis i det daglige forskellen mellem en robust M365-sikkerhedsbasis og et vildvoksende retningslinje-setup.

Break-Glass-Accounts: Notfallzugang ohne Sicherheitsloch

Break-Glass-konti er nødadgangskonti til tenant, når normale administratoradgange ikke fungerer – for eksempel på grund af fejlkonfiguration i Conditional Access, svigt hos en MFA-udbyder eller et identity-incident. Formålet er klart, men implementeringen har typiske faldgruber: En Break-Glass-konto, der aldrig testes, hjælper ikke i en nødsituation. En Break-Glass-konto, der er for let tilgængelig, er et attraktivt angrebsmål.

Hvad Break-Glass ikke er

• Ikke en daglig administrator-konto: Den må ikke anvendes i normal drift.
• Ikke et opsamlingssted for undtagelser: Det erstatter ikke et ordentligt CA-design.
• Ikke ’vi har én, så er det fint’: Uden proces, test og alarmering er det kun en teoretisk plan.

Grundprincipper for Break-Glass i drift

Et praktisk setup følger tre mål: tilgængelig i nødsituationer, svær at angribe i normal drift og klart efterviseligt.

• Mindst to konti: Redundans mod udelukkelse, fejlbetjening eller kompromitterede adgangsoplysninger.
• Stærkt sikret: Lange, tilfældige adgangskoder; ingen e-mail-videresendelser; ingen brug til apps/integrationer.
• Målrettet undtaget fra CA – men snævert: Typisk er en undtagelse fra bestemte CA-politikker, så man i nødstilfælde ikke låses ude af egne regler. Samtidig bør andre sikkerhedsforanstaltninger træde i kraft: alarmer ved brug, RESTriktiv rollefordeling, adskilt opbevaring af adgangsoplysninger.
• Logning og alarmering: Hver login skal udløse et øjeblikkeligt signal (SIEM/SOC eller i det mindste e-mail/Teams-alarm til en incident-postkasse). Brug af Break-Glass er per definition en sikkerhedshændelse.

Et centralt punkt: Beslut bevidst, om Break-Glass skal drives med eller uden MFA. Mange organisationer lader det være uden MFA for at bevare handlekraft ved MFA-fejl. Så skal de kompenserende kontroller dog være særlig grundige (opbevaring, adgang til adgangskode, alarmering, regelmæssig udskiftning). Alternativt kan man udstyre Break-Glass med hardwarebaseret MFA (fx FIDO2), som er uafhængig af mobilnet. Vigtigt er ikke den ’rigtige’ ideologi, men en nødprocedure, der i jeres kontekst fungerer i praksis.

Rollout-realitet: Sådan undgår I lockouts og supporttoppe

Mange CA-/MFA-rollouts fejler ikke teknisk, men organisatorisk: for hurtigt, for bredt, uden telemetri og uden en klar supportproces. Et stabilt rollout arbejder i bølger og med målepunkter.

Trin 1: Skab synlighed (før I blokerer)

Brug Sign-in Logs og analyser til at finde ud af: Hvilke apps bruges? Hvilke clients er „legacy“? Hvilke lokationer/IP-ranges er reelle? Hvilke brugere har særligt mange loginproblemer? Uden disse data er enhver politik et skud i blinde.

Trin 2: Pilotgrupper med reelle specialtilfælde

Piloter bør ikke kun være „IT og et par frivillige“. Inkluder bevidst kanttilfælde: feltservice, produktionssteder, projektmedarbejdere med gæsteadgang og mindst én afdeling med typiske tredjepartsværktøjer. Målet er ikke harmoni, men tidlig identifikation af de reelle faldgruber.

Trin 3: Fastlæg helpdesk-playbooks

Når MFA gøres obligatorisk, stiger antallet af tickets: enhedsudskiftning, mistede telefoner, nye medarbejdere, konto spærret efter for mange forsøg. Angiv, hvad First-Level må løse (f.eks. MFA-reset efter identitetskontrol) og hvornår der skal eskaleres. Uden Playbooks eskalerer alt – og administratorerne bliver flaskehalsen.

Schritt 4: Technische Nacharbeiten als eigenes Backlog

CA gør skjult teknisk gæld synlig: forældede Mailclients, ikke-dokumenterede scannere, Skripte med Password i Task Scheduler, eller integrationer, der stadig bruger Basic Auth. Planlæg disse efterarbejder som synlige arbejdspakker. Ellers hænger de fast som en „dauerhafte Ausnahme“.

Typiske fejlscenarier fra driften – og hvordan man hurtigere klassificerer dem

I det daglige tæller hurtige hypoteser. Nogle mønstre går igen:

„Pludselig virker Outlook ikke længere“

Hyppige årsager: Legacy-Client, gammelt profil, eller en CA-blok pga. manglende enhedstilstand. Tjek: Client-Typ i Sign-in Log, anvendt CA-Policy, og om enheden er ført som compliant. Den operative fix er sjældent „Policy aus“, men „Client modernisieren“ eller „Geräteverwaltung sauberziehen“.

„Service XY kann keine E-Mails mehr senden“

Ofte ligger der en ændring i SMTP-Authentifizierung, en ændret Relay-Policy eller en ny CA-regel bag, som utilsigtet også fanger tekniske konti. Her hjælper en klar arkitekturbeslutning: afsendelse via Relay/Connector i stedet for brugerlogin, med IP-RESTriktion og Logging (Nachvollziehbarkeit im Incident).

„Admin kommt nicht mehr in den Tenant“

Det er det øjeblik, Break-Glass er tiltænkt. Hvis Break-Glass-adgangen heller ikke virker, mangler der som regel en testet nødprocedure eller undtagelsen er forkert opbygget. Derfor: øv brugen regelmæssigt (med dokumentation af, hvem der tester hvornår, og hvordan alarmen ser ud).

„Zu viele Ausnahmen – niemand blickt durch“

Det er et Governance-problem. Konsolider politikkerne, definer et review-ritual (f.eks. månedligt 30 minutter), og fjern undtagelser, der ikke længere har en Owner/ikke længere tjener et formål. Teknisk er det ikke glamourøst, men det er forskellen mellem kontrollerbar sikkerhed og historisk opståede særrettigheder.

Monitoring und Nachvollziehbarkeit: Was Sie wirklich brauchen

CA und MFA genererer mange Events. Hvis I samler alt, drukner I; hvis I ikke analyserer noget, opdager I problemer for sent. Praktisk fornuftigt er tre niveauer:

• Alarmierung auf harte Ereignisse: Break-Glass-Login, Admin-Login aus ungewöhnlichen Ländern, Block-Events auf kritischen Apps.
• Regelmäßige Reviews: Top-Blockgründe, Top-User mit MFA-Problemen, Legacy-Auth-Versuche, neue Apps/Enterprise Apps.
• Audit-Spur für Ausnahmen: Wer hat welche Ausnahme genehmigt, mit welchem Ablaufdatum, und wann wurde reviewed?

Wenn Sie bereits zentrale Logging- und Incident-Prozesse haben (SIEM, Ticketing, Change-Management), verankern Sie CA-Änderungen dort. Conditional Access ist keine „kleine Einstellung“, sondern eine produktionskritische Zugriffsschicht.

Aufwand und Verantwortlichkeiten: Wer muss was liefern?

CA-/MFA-Projekte werden unterschätzt, weil sie wie reine Konfiguration wirken. In Wahrheit sind es Schnittstellenprojekte zwischen Identität, Endgeräten, Netz und Fachprozessen. Ein sauberes Verantwortungsmodell reduziert Reibung:

• Identity-Team / Entra Admins: Policy-Design, Rollenmodell, Break-Glass, App-Registrierungen.
• Client-Management (f.eks. Intune): Compliance-definition, enhedsstatus, udrulning af Authenticator/Passkeys, enheds livscyklus.
• Netværk: IP-ranges til Named Locations, undtagelser for proxy/TLS-inspektion, lokationsflytning.
• Service-ejer for forretningsapplikationer: Integrationsstier (Graph/SMTP/SharePoint), omstilling fra Legacy-Auth, Secret-Rotation.
• Helpdesk: Standardprocesser for MFA-reset, enhedsskift, onboarding/offboarding.

Den vigtigste ledelsesbeslutning er ofte ikke „MFA ja/nej“, men: Har vi tid og ressourcer til efterarbejdet (nedbygge Legacy, modernisere integrationer, stabilisere enhedsadministration)? Uden dette arbejde forbliver sikkerhedsgevinsten under forventningerne – eller driften bliver unødigt besværlig.

Konklusion: Sikkerheden styrkes, når nødtilfælde og undtagelser er en del af systemet

Microsoft 365 korrekt sikring betyder, at Conditional Access drives som et centralt styringslag – ikke som en engangskonfiguration. MFA er obligatorisk, men den reelle driftskvalitet opstår gennem veldefinerede undtagelser (med udløbsdato, ejer og kompenserende kontroller) og gennem Break-Glass-Accounts, der testes, overvåges og er organisatorisk indlejret. Den, der tænker disse tre elementer sammen, reducerer konto-risici, opnår auditbarhed uden overhead og forhindrer, at sikkerhedsregler i et Incident bliver ens egen modstander.

Drøft projekt eller moderniseringsforløb med Net-Base.