Opsæt break-glass-konti i Microsoft 365, krav, undtagelser, overvågning og testplan

18. januar 2026

Når en admin bliver låst ude af Microsoft 365, sker det sjældent på et “godt” tidspunkt. Typisk er det efter en ændring i Conditional Access, et MFA-problem, eller en fejl i en risikopolitik. Det er her break-glass konti redder dagen.

Tænk på dem som nøgleboksen i receptionen. Den skal findes, fungere, og kun bruges, når alt andet fejler. Resten af tiden skal den være beskyttet og overvåget.

For danske SMV’er, også i miljøer med it-support og driftspartner (MSP), er det en lav indsats med høj effekt for it-sikkerhed.

Hvad break-glass konti er, og hvornår de må bruges

Arkitekturdiagram med Entra ID, Conditional Access, MFA, normal admin og to break-glass konti Arkitektur med adskillelse mellem normal admin og emergency access, skabt med AI.

En break-glass konto (også kaldet “emergency access account”) er en cloud-only admin-konto i Microsoft Entra ID, som kan logge ind, selv hvis jeres normale sikkerhedspolitikker spærrer alt andet.

Microsoft anbefaler mindst to sådanne konti, så én ikke bliver et single point of failure. Det står også i Microsofts egen vejledning om emergency access accounts i Entra ID.

Typiske scenarier hvor break-glass skal bruges:

  • Fejlkonfigureret Conditional Access, der blokerer alle admins.
  • MFA-krav som rammer “alle brugere”, inkl. service og admin.
  • Identity Protection risikopolitik, der låser jer ude pga. falsk positiv.
  • Et kompromitteret admin-login, hvor I skal ind og stoppe blødningen nu.

Brug dem ikke til daglig drift. Det gør dem sværere at overvåge, og det øger risikoen for misbrug.

Risiko : Hvis break-glass konti er “for pæne” og bruges ofte, bliver de en genvej. Genveje bliver over tid en svaghed.

Krav til opsætning: to nød-konti, stærk adgang og ren adskillelse

Tjekliste med krav og undtagelser for break-glass konti Tjekliste over krav og undtagelser, skabt med AI.

Kravene handler om to ting: adgang når alt brænder, og kontrol når intet brænder.

Praktisk baseline for break-glass konti:

  • Præcis 2 konti . Navngiv dem tydeligt (fx EA-Admin-01 , EA-Admin-02 ).
  • Cloud-only (ikke synkroniseret fra AD, ikke knyttet til en person).
  • Permanent Global Administrator . Ingen PIM her, nødkontoen skal virke uden afhængigheder.
  • Phishing-resistent MFA . FIDO2 eller passkeys er oplagt, og matcher retningen i Microsofts MFA-krav. Se også Microsofts plan for mandatory MFA i Entra.
  • Stærk adgangskode (selv med MFA). Gem den i en godkendt vault, og overvej en fysisk backup i en forseglet kuvert.
  • Separat “break-glass” enhed (PAW, privileged access workstation) eller en kontrolleret nødbærbar. Ingen privat mobil som eneste faktor.
  • Ingen daglig mailbrug . Mange vælger at lade dem være uden mailbox og licens for at reducere angrebsfladen.

Det sidste punkt kræver disciplin. Hvis kontoen har mailbox, kan den blive mål for phishing. Hvis den ikke har mailbox, skal alarm- og notifikationsflow være endnu skarpere.

Anbefaling : Læg kontiene i en særskilt gruppe (fx “Emergency Access”), og dokumentér ejerskab, formål og godkendelsesflow. Hos NetDK ser man ofte, at dokumentationen mangler, især i SMV’er omkring århus og lystrup, hvor drift og sikkerhed deles mellem få hænder.

Alternativ for små teams : Hvis I kun er 1 til 2 admins, så fastlæg en “to-personers regel” på brug (leder + admin), og placer legitimationsoplysninger i en vault, som kræver godkendelse fra to personer.

Conditional Access-undtagelser: det svære er at gøre dem sikre, men ikke blokerede

Break-glass konti skal normalt være undtaget fra de politikker, der kan låse jer ude. Det lyder som et kompromis, men formålet er netop at have en sidste vej ind.

Start med en principfast tilgang:

  • Lav en Entra-gruppe “Emergency Access”.
  • Ekskludér gruppen fra brede CA-politikker.
  • Overvåg alt, der har med gruppen at gøre.

Konkrete undtagelser der ofte er nødvendige:

  • Conditional Access : Ekskludér fra “Require MFA” og “Require compliant device”, hvis de kan skabe lockout. Planlæg jeres CA struktur ud fra Microsofts guide til at planlægge Conditional Access.
  • Identity Protection risk policies : Ekskludér break-glass fra sign-in risk og user risk policies, fordi de ellers kan blive blokeret ved fejl eller støj. Microsoft beskriver opsætningen i risk policies i Entra ID Protection.
  • Security Defaults og nye standarder : I januar 2026 ser man oftere nye tenants med Security Defaults slået til i en periode. Det kan udløse MFA-krav og blokeringer, som skal tænkes ind i jeres undtagelser, ellers får I en falsk tryghed.

Samtidig må undtagelsen aldrig blive en gratis adgangsbillet.

Risiko : En CA-undtagelse uden phishing-resistent MFA gør nødkontoen til et attraktivt mål.

Anbefaling : Følg Microsofts rollepraksis, især omkring globale administratorer, og hold antallet nede. Se best practices for Entra roles.

Overvågning og testplan: alarmer ved login, kvartalsvis test, dokumenteret godkendelse

Overvågning: hvad der skal alarmeres på (ikke bare logges)

Flow fra sign-in logs til alert og IT/SEC-team Overvågningsflow med alarmer og logkilder, skabt med AI.

Hvis en break-glass konto bruges, skal nogen reagere, ikke først “på mandag”. En god tommelfingerregel: alert ved hvert login , succes eller fejl.

Minimum-alarmregler (SIEM eller Entra alerting):

Signal Logkilde Handling
Login på EA-Admin-01/02 Entra sign-in logs Ring ud, start incident, bekræft ændring
Flere mislykkede logins Entra sign-in logs Blokér IP (hvis relevant), vurder angreb
Nulstilling af password/MFA-metoder Entra audit logs Godkendelse, efterkontrol, dokumentér
Rolleændringer eller nye admins Entra audit logs Verificér change request, rollback hvis tvivl

Hold det simpelt: Hvis I kun kan nå én ting, så lav “break-glass login = alarm”.

Sæt også en praktisk “driftsramme” rundt om kontiene. Break-glass konti er ikke en erstatning for backup, antivirus eller firewall. De er jeres nøgle tilbage i kontrolpanelet, ikke jeres gendannelse.

Alternativ for små teams : Hvis I ikke har SIEM, så brug mail/SMS notifikation til en fælles vagtadresse og en sekundær kanal (fx telefonkæde). Det skal stadig testes.

Kvartalsvis testplan: bevis at de virker, uden at skabe ny risiko

Tidslinje for kvartalsvis testplan af break-glass konti Kvartalsvis testforløb med klare trin, skabt med AI.

En test uden dokumentation er en fornemmelse. En test med dokumentation er et kontrolpunkt.

Kør en fast kvartalsvis plan:

  1. Forberedelse : Aftal tidspunkt, udpeg godkender (IT-chef eller sikkerhedsansvarlig).
  2. Login-test : Log ind med hver konto fra kontrolleret enhed og kendt netværk.
  3. Rollevalidering : Bekræft at Global Admin virker (fx se roller, læse CA-politikker, åbne audit logs).
  4. Dokumentation : Notér dato, hvem der testede, hvilken metode (FIDO2/passkey), og resultat.
  5. Efterkontrol : Gennemgå sign-in logs, bekræft at alerts kom frem, og luk evt. åbne sessions.

Hold testen kort, og rør ikke ved politikker under testen. Formålet er at bekræfte adgang og alarmer, ikke at “prøve nyt”.

Anbefaling : Kræv skriftlig godkendelse, også i små teams. Det skaber ro, især når presset er højt.

Konklusion

Break-glass konti er en lille opsætning, som kan afgøre om et nedbrud bliver en incident eller en katastrofe. To cloud-only konti, gennemtænkte Conditional Access-undtagelser, alert ved login , og en kvartalsvis test med dokumentation er kernen. Kombinér det med ordentlig it-sikkerhed i hverdagen, inklusive backup, antivirus og firewall, så står I stærkere. Når næste lockout rammer, er det rart at vide, at break-glass konti ikke bare findes, de virker.