Korrekt säkring av Microsoft 365: Conditional Access, MFA-undantag och break-glass-konton i den dagliga driften

Den som vill säkra Microsoft 365 på riktigt kommer inte undan Conditional Access (åtkomstbaserade policyer i Entra ID, tidigare Azure AD) och Multifaktorautentisering (MFA, alltså inloggning med minst två faktorer). I många företag aktiveras MFA och de första Conditional Access-reglerna snabbt – och först då börjar arbetet: undantag måste motiveras, nödbehörigheter organiseras tydligt och driftsprocesser utformas så att säkerhet inte blir en supportlavin.

I praktiken misslyckas ”M365 absichern” sällan på grund av den grundläggande tekniken, utan på vardagsproblem: servicekonton för gränssnitt, legacy-protokoll, fältpersonal utan pålitligt mobilnät, administratörer med för vida rättigheter, eller en incident där just skyddsåtgärden blockerar IT:s åtkomst. Detta inlägg kategoriserar hur Conditional Access, MFA-undantag och break-glass-konton samverkar – och hur ni driver det hela så att det förblir tillförlitligt även efter go-live.

Varför Conditional Access är hävstången – och varför MFA inte räcker ensam

MFA minskar risken för stulna lösenord avsevärt, men MFA är inget komplett åtkomstkoncept. Conditional Access (CA) avgör kontextberoende, under vilka villkor en åtkomst tillåts: t.ex. endast från hanterade enheter, endast från vissa länder, endast med riskbaserad bedömning eller endast med specifika klientappar. Det är det avgörande steget mot Zero Trust (säkerhetsmodell där ingen åtkomst som standard litas på utan kontinuerligt prövas).

Typiska skäl till varför MFA ensam inte räcker i Microsoft 365:

• Token istället för lösenord: Modern autentisering arbetar med tokens (tidsbegränsade åtkomstbiljetter). Ett stulet token kan kringgå MFA om CA inte kräver ytterligare villkor (t.ex. enhetsstatus eller sessionstyrning).
• Adminrisk: Administrativa konton är särskilt attraktiva. Utan CA-regler för adminåtkomster (t.ex. endast från administratörsarbetsstationer eller endast med phishing-resistent MFA) förblir den största angripbara ytan öppen.
• ”Tillåtet” blir för brett: Om CA inte skiljer mellan appar, dataklasser och åtkomsttyper blir säkerheten snabbt antingen för slappt eller för RESTriktiv – båda leder till problem.

Den operativa kärnan är därför: CA som policylager, MFA som en byggsten däri, plus ett välordnat undantagshanteringssystem och pålitliga nödåtkomstvägar.

Arkitekturöversikt: Vad Conditional Access i Entra ID faktiskt styr

För IT-ledning och drift är det viktigt att inte förstå CA som ”en policy”, utan som en beslutskedja. Entra ID utvärderar signaler vid varje inloggning och tillämpar policies. Viktiga signaler är:

• Identitet: Användare, grupper, roller (t.ex. privilegierade roller som Global Administrator).
• Målresurs: Molnapp (Exchange Online, SharePoint/OneDrive, Teams, men även tredjepartsleverantörer via Enterprise App).
• Klienttyp: Webbläsare, moderna klienter, mobila appar samt „Legacy Authentication“ (äldre protokoll utan moderna tokens, t.ex. äldre IMAP/POP/SMTP-autentiseringsvarianter).
• Enhetsstatus: „Compliant“ eller „hybrid joined“ (hanterad enhet, typiskt via Intune eller domänanslutning med enhetsstatus).
• Nätverk/Plats: Named Locations (definierade IP-intervall), länder/regioner, riskindikatorer.
• Sessionsvillkor: Session Lifetime, App-Enforced RESTrictions, Continuous Access Evaluation (kontinuerlig omvärdering vid riskhändelser).

Ur driftssynpunkt beror kvaliteten på er CA‑konfiguration i hög grad på om dessa signaler är tillförlitliga. Ett Named Location är bara så bra som er IP‑adresshygien. „Compliant“ är bara så bra som er enhetshantering och definitionen av compliance. Och riskbedömningen är bara användbar om ni också arbetar med de events som följer därav.

Microsoft 365 richtig absichern mit Conditional Access: Ein praxistaugliches Policy-Set

Istället för en „stor“ regel fungerar i vardagen ett set av få, tydligt avgränsade Policies bättre. Det minskar sidoeffekter och förenklar felsökning vid incidenter. Ett beprövat grundmönster består av:

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

För vanliga användarkonton är baslinjen: MFA krävs, och Legacy Authentication blockeras. Legacy är här inte „gammaldags“, utan tekniskt problematisk: dessa protokoll stöder ofta inte moderna MFA‑challenges och är därför en klassisk ingångspunkt för password spraying.

Viktigt: blockera Legacy inte „någon gång“, utan planera en övergångsfas med mätning. Kontrollera via Sign-in Logs vilka klienter som fortfarande använder Legacy. I företag hänger ofta multifunktionsskrivare, Scan-to-Mail eller äldre e‑postklienter i specialmiljöer på det.

2) Admin-Policy: deutlich strenger als die Baseline

Privilegierade roller bör få en separat Policy: åtkomst endast från definierade Admin‑endheter (t.ex. „compliant“ och eventuellt en separat Admin‑Workstation‑strategi), MFA med hög säkerhet (mot phishing, t.ex. FIDO2/Passkey eller certifikatbaserat), och om möjligt begränsningar för riskfyllda länder/platser. Även om inte alla företag omedelbart inför en fullständig Privileged‑Access‑Architektur (PAM, alltså privilegierat åtkapshantering) är denna skiljning omedelbart värdefull: ett komprometterat Adminkonto är en annan skadeyta än ett komprometterat användarkonto.

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

Gäståtkomst (B2B Collaboration) skapar ofta oväntade datapassager: gäster laddar ner filer från SharePoint, arbetar i Teams eller når projektportaler. Fastställ här medvetet om gäster endast får logga in med MFA, om vissa appar ska undantas och hur länge sessioner är giltiga. För projektarbete är ofta en kortare sessionstid lämplig för att minska risken för „glömda inloggningar“.

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

I vardagen finns olika skyddsbehov: en säljare kan kanske läsa e‑post från vilken enhet som helst, men inte utan en hanterad enhet ladda ner stora mängder data från SharePoint. Sådana skillnader uttrycker ni inte genom kategoriskt „tillåtet/förbjudet“, utan genom CA‑kombinationer: „åtkomst tillåten om enhet är compliant“ eller „åtkomst endast via webbläsare med begränsad session“. Det är mindre absolut än fullständig blockering – och ändå effektivt.

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

MFA‑undantag är inte ett tecken på svaghet så länge de är genomtänkta och driftmässigt kontrollerade. Utan kontrollerade undantag uppstår skugglösningar: användare kringår processer, admins stänger regler i panik, och till slut är policiesamlingen inte längre spårbar.

Viktigt är distinktionen: ett MFA‑undantag är sällan „MFA aus“, utan ofta „MFA anders“ eller „åtkomst endast under andra villkor“. Typiska undantagskategorier:

Ausnahmefall 1: Nicht-interaktive Zugriffe und Schnittstellen

Många processnära mjukvarulösningar integrerar M365-tjänster: e-postleverans, kalenderåtkomst, SharePoint-filarkivering, Teams-notiser eller Graph-API-åtkomst. Sådana integrationer bör inte köras via användarkonton med avaktiverad MFA. Bättre är teknisk åtkomst via appregistreringar (applikation i Entra ID) med tydliga behörigheter och secret-/certifikatlivscykel. Det är inget ‚MFA-undantag‘, utan en annan autentiseringsform som är mer granskbar.

Driftskonsekvenser: secrets måste roteras, certifikat löper ut och behörigheter måste återcertifieras. När ni planerar integrationer, definiera ägarskap (vem förnyar certifikat/secrets) och övervakning (t.ex. varningar före utgångsdatum). Annars blir ’säker‘ appautentisering en oplanerad driftstörning.

Undantagsfall 2: Enheter utan modernt inloggning (t.ex. skannrar, skrivare, rumsystem)

Detta ger upphov till de klassiska diskussionerna om SMTP-relä, scan-to-mail eller rumsbrevlådor. Den felaktiga lösningen är nästan alltid ‚ett användarkonto utan MFA‘. Bättre är tekniska vägar som inte är beroende av interaktiv inloggning: centralt mailrelä med IP-RESTriktion, certifikats- eller connector-baserade lösningar, eller separata systembrevlådor med snäva behörigheter. Avgörande är: enheten kan inte hantera MFA själv, därför måste designen säkras i transport- och nätvägen.

Undantagsfall 3: Nödoperation och begränsad tillgänglighet

Fälttjänst, produktion eller skiftarbete har situationer utan mobilmottagning eller utan privata mobiltelefoner. Här är det värt att tidigt överväga alternativa MFA-metoder: hårdvarutoken, FIDO2-säkerhetsnycklar, eller Windows Hello for Business (enhetsbunden inloggning). ‚Tillfälligt avaktiverad MFA‘ är operativt lockande, men skalar dåligt och är svårt att granska.

Undantagsfall 4: Automatiserade jobb med användarkontext

Vissa äldre system startar jobb ’som användare‘, till exempel för SharePoint-uppladdningar eller rapporter. Ur ett modernt perspektiv är det riskfyllt eftersom det blandar roller och åtkomsträttigheter. Om avlösning inte är möjlig omedelbart, arbeta med mellansteg: begränsade servicekonton, tydliga Named Locations, starka lösenords-/secret-policyer och konsekvent loggning. Och: planera migrationen till appidentiteter som ett separat arbetsuppdrag, inte som ’någon gång senare‘.

Hur man dokumenterar, godkänner och avvecklar undantag

Undantag är i drift endast acceptabla om de har en livscykel. I praktiken har en lättviktig metod visat sig fungera väl — utan byråkrati men ändå revisionssäker:

1. Motivering i en mening: Vilken affärs- eller driftfunktion hänger på detta (t.ex. ‚Scan-to-Mail till plats X‘)?
2. Teknisk klassificering: Vilken app/protokoll, vilka konton, vilka datavägar?
3. Kompenserande kontroller: Vad begränsar risken (IP-RESTriktion, minimalt nödvändiga rättigheter, övervakning)?
4. Utgångsdatum: Varje undantag får ett granskningsdatum. Utan granskning tas det bort eller godkänns på nytt.
5. Ägare: Vem är ansvarig om det krånglar eller om undantaget löper ut?

Det gör inte undantagen ‚bra‘, men de blir hanterbara. Och det är i vardagen skillnaden mellan en robust M365-säkerhetsgrund och en policydjungel.

Break-Glass-konton: Nödåtkomst utan säkerhetshål

Break-Glass-konton är nödkonton för åtkomst till tenant när ordinarie admininloggningar inte fungerar – till exempel på grund av felkonfiguration i Conditional Access, driftstopp hos en MFA-leverantör eller en identitetsincident. Syftet är tydligt, men implementeringen har typiska fallgropar: ett Break-Glass-konto som aldrig testas hjälper inte i en nödsituation. Ett Break-Glass-konto som är för lättillgängligt är ett attraktivt angreppsmål.

Vad Break-Glass inte är

• Inte ett dagligt administratörskonto: Det får inte användas i normal drift.
• Ingen behållare för undantag: Det ersätter inte en korrekt Conditional Access-design.
• Inte ”vi har ett, det räcker”: Utan process, test och larm är det bara en teoretisk plan.

Grundprinciper för Break-Glass i drift

En praktisk konfiguration utgår från tre mål: åtkomlig i nödfall, svår att angripa i normal drift och väl spårbar.

• Minst två konton: Redundans mot utelåsning, felhantering eller komprometterade inloggningsuppgifter.
• Starkt skyddade: Långa, slumpmässiga lösenord; inga e‑postvidarebefordringar; ingen användning för appar/integrationer.
• Specifikt undantaget från Conditional Access – men snävt: Typiskt är ett undantag från vissa CA‑policyer så att man i nödfall inte spärras ute av egna regler. Samtidigt bör andra säkerhetsmekanismer gälla: larm vid användning, RESTriktiva roller, separat förvaring av inloggningsuppgifterna.
• Loggning och larm: Varje inloggning måste utlösa en omedelbar signal (SIEM/SOC eller åtminstone e‑post/Teams‑larm till ett incident‑postfack). Break‑Glass‑användning är per definition en säkerhetshändelse.

En central punkt: avgör medvetet om Break‑Glass ska hanteras med eller utan MFA. Många organisationer låter det vara utan MFA för att kunna agera vid MFA‑fel. Då måste dock de kompensatoriska kontrollerna vara särskilt noggranna (förvaring, åtkomst till lösenordet, larm, regelbunden rotation). Alternativt kan man utrusta Break‑Glass med hårdvarubaserad MFA (t.ex. FIDO2) som är oberoende av mobilnät. Det viktiga är inte en ”rätt” ideologi, utan en nödfallsprocedur som faktiskt fungerar i er kontext.

Rollout‑realitet: Så undviker ni utelåsningar och toppar i supporten

Många CA‑/MFA‑utrullningar misslyckas inte tekniskt utan organisatoriskt: för snabbt, för brett, utan telemetri och utan en tydlig supportprocess. En stabil utrullning arbetar i vågor och med mätpunkter.

Steg 1: Skapa synlighet (innan ni blockerar)

Använd sign‑in‑loggar och analyser för att ta reda på: Vilka appar används? Vilka klienter är ”legacy”? Vilka platser/IP‑intervall är verkliga? Vilka användare har särskilt många inloggningsproblem? Utan dessa data är varje policy ett blindflyg.

Steg 2: Pilotgrupper med verkliga specialfall

Piloterna bör inte bara vara ”IT och några frivilliga”. Ta medvetet in randfall: fältpersonal, produktionsanläggningar, projektdeltagare med gäståtkomst, och minst en avdelning med typiska tredjepartsverktyg. Målet är inte harmoni utan att tidigt hitta de verkliga fallgroparna.

Steg 3: Fastställ helpdesk‑playbooks

Wenn MFA erzwungen wird, steigen Tickets an: Gerätewechsel, verlorene Telefone, neue Mitarbeitende, Konto gesperrt nach zu vielen Versuchen. Legen Sie fest, was der First-Level lösen darf (z. B. MFA-Reset nach Identitätsprüfung) und wann eskaliert wird. Ohne Playbooks eskaliert alles – und die Admins werden zum Flaschenhals.

Schritt 4: Technische Nacharbeiten als eigenes Backlog

CA macht versteckte technische Schulden sichtbar: veraltete Mailclients, nicht dokumentierte Scanner, Skripte mit Passwort im Task Scheduler, oder Integrationen, die noch Basic Auth nutzen. Planen Sie diese Nacharbeiten als sichtbare Arbeitspakete ein. Sonst bleiben sie als „dauerhafte Ausnahme“ hängen.

Typische Fehlerbilder aus dem Betrieb – und wie man sie schneller einordnet

Im Alltag zählen schnelle Hypothesen. Einige Muster kommen immer wieder:

„Plötzlich geht Outlook nicht mehr“

Häufige Ursachen: Legacy-Client, altes Profil, oder ein CA-Block wegen fehlendem Gerätezustand. Prüfen Sie: Client-Typ im Sign-in Log, angewendete CA-Policy, und ob das Gerät als compliant geführt wird. Der operative Fix ist selten „Policy aus“, sondern „Client modernisieren“ oder „Geräteverwaltung sauberziehen“.

„Service XY kann keine E-Mails mehr senden“

Oft steckt eine Umstellung von SMTP-Authentifizierung, eine geänderte Relay-Policy oder eine neue CA-Regel dahinter, die unbeabsichtigt auch technische Konten erfasst. Hier hilft ein klarer Architekturentscheid: Versand über Relay/Connector statt Benutzerlogin, mit IP-RESTriktion und Logging (Nachvollziehbarkeit im Incident).

„Admin kommt nicht mehr in den Tenant“

Das ist der Moment, für den Break-Glass gedacht ist. Wenn der Break-Glass-Zugang ebenfalls nicht funktioniert, fehlt meist ein getesteter Notfallpfad oder die Ausnahme wurde falsch gebaut. Deshalb: Nutzung regelmäßig üben (mit Dokumentation, wer wann testet, und wie der Alarm aussieht).

„Zu viele Ausnahmen – niemand blickt durch“

Das ist ein Governance-Problem. Konsolidieren Sie Policies, definieren Sie ein Review-Ritual (z. B. monatlich 30 Minuten), und entfernen Sie Ausnahmen, die keine Owner/keinen Zweck mehr haben. Technisch ist das nicht glamourös, aber es ist der Unterschied zwischen kontrollierbarer Sicherheit und historisch gewachsenen Sonderrechten.

Monitoring und Nachvollziehbarkeit: Was Sie wirklich brauchen

CA und MFA erzeugen viele Events. Wenn Sie alles sammeln, ertrinken Sie; wenn Sie nichts auswerten, merken Sie Probleme zu spät. Praktisch sinnvoll sind drei Ebenen:

• 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.

Den viktigaste ledningsbeslutet är ofta inte „MFA ja/nej“, utan: Har vi tid och resurser för efterarbetet (att avveckla legacy, modernisera integrationer, stabilisera enhetshanteringen)? Utan detta arbete hamnar säkerhetsvinsten bakom förväntningarna – eller blir driften onödigt tung.

Slutsats: Säkerhet vinner när nödfall och undantag är en del av systemet

Att säkert skydda Microsoft 365 innebär att driva Conditional Access som ett centralt styrningslager – inte som en engångskonfiguration. MFA är obligatoriskt, men den egentliga driftkvaliteten uppstår genom tydliga undantag (med utgångsdatum, Owner och kompensatoriska kontroller) och genom Break-Glass-konton som testas, övervakas och organisatoriskt inordnas. Den som ser dessa tre element tillsammans reducerar kontorisker, uppnår revisionsbarhet utan overhead och förhindrar att säkerhetsregler vid en incident blir en egen motståndare.

Diskutera projekt eller moderniseringsprojekt med Net-Base.