Microsoft 365 juist beveiligen: Conditional Access, MFA-uitzonderingen en Break-Glass-accounts in de praktijk

Wie je Microsoft 365 goed wil beveiligen, komt niet om Conditional Access (toegangsafhankelijke beleidsregels in Entra ID, voorheen Azure AD) en Multi-factor authenticatie (MFA, dus aanmelding met ten minste twee factoren) heen. In veel bedrijven zijn MFA en de eerste Conditional-Access-regels snel ingeschakeld – en dan begint het werk pas: uitzonderingen moeten worden onderbouwd, noodtoegangen netjes georganiseerd en operationele processen zo ingericht dat veiligheid niet verandert in een lawine aan supportmeldingen.

In de praktijk mislukt ‚M365 beveiligen‘ zelden door de fundamentele techniek, maar door alledaagse zaken: serviceaccounts voor koppelingen, legacy-protocollen, buitendienst zonder betrouwbaar mobiel netwerk, beheerders met te brede rechten, of een incident waarbij precies de beschermingsmaatregel de toegang van de IT blokkeert. Dit artikel duidt hoe Conditional Access, MFA-uitsluitingen en Break-Glass-Accounts samenwerken – en hoe u dit zodanig runt dat het ook na het Go-live betrouwbaar blijft.

Waarom Conditional Access de hefboom is – en MFA op zichzelf niet genoeg

MFA vermindert het risico van gestolen wachtwoorden aanzienlijk, maar MFA is geen volledig toegangsconcept. Conditional Access (CA) bepaalt contextafhankelijk onder welke voorwaarden toegang wordt toegestaan: bijvoorbeeld alleen vanaf beheerde apparaten, alleen uit bepaalde landen, alleen na risicobeoordeling of alleen met specifieke client-apps. Dat is de cruciale stap richting Zero Trust (beveiligingsmodel waarbij standaard geen toegang wordt vertrouwd, maar continu wordt geëvalueerd).

Typische redenen waarom MFA alleen in Microsoft 365 niet volstaat:

• Token in plaats van wachtwoord: Moderne authenticatie werkt met tokens (tijdelijk geldende toegangstickets). Een gestolen token kan MFA omzeilen als CA geen aanvullende voorwaarden afdwingt (bijv. apparaatstatus of sessiebeheer).
• Admin-risico: Administratieve accounts zijn bijzonder aantrekkelijk voor aanvallers. Zonder CA-regels voor admin-toegang (bijv. alleen vanaf admin-workstations of alleen met phishing-resistente MFA) blijft het grootste aanvalsoppervlak open.
• „Toegestaan“ is te ruim: Als CA niet onderscheidt tussen apps, dataklassen en toegangsmodaliteiten, wordt beveiliging snel óf te slap óf te RESTrictief – beide situaties veroorzaken problemen.

De operationele kern is dus: CA als beleidslaag, MFA als bouwsteen daarin, plus een degelijk uitzonderingsbeheer en betrouwbare noodprocedures.

Architectuuroverzicht: wat Conditional Access in Entra ID daadwerkelijk aanstuurt

Voor IT-leiding en operatie is het belangrijk CA niet als „één beleid“ te zien, maar als een beslissingsketen. Entra ID evalueert bij elke aanmelding signalen en past policies toe. Belangrijke signalen zijn:

• Identiteit: gebruikers, groepen, rollen (bijv. bevoorrechte rollen zoals Global Administrator).
• Doelresource: cloud-app (Exchange Online, SharePoint/OneDrive, Teams, maar ook derden via Enterprise App).
• Cliënttype: browser, moderne clients, mobiele apps, evenals „Legacy Authentication“ (ouderwetse protocollen zonder moderne tokens, bijv. oudere IMAP/POP/SMTP-authvarianten).
• Apparaatstatus: „Compliant“ of „hybrid joined“ (beheerd apparaat, typisch via Intune of domeinverbonden met apparaatsstatus).
• Netwerk/locatie: Named Locations (gedefinieerde IP-ranges), landen/regio’s, risico-indicatoren.
• Sessievoorwaarden: Session Lifetime, App-Enforced RESTrictions, Continuous Access Evaluation (lopende herbeoordeling bij risico-evenementen).

Gezien de operationele kant hangt de kwaliteit van uw CA-configuratie sterk af van de betrouwbaarheid van deze signalen. Een Named Location is slechts zo goed als uw IP-adreshygiëne. „Compliant“ is slechts zo goed als uw apparaatbeheer en de definitie van compliance. En de risicobeoordeling is alleen nuttig als u ook met de daaruit voortvloeiende Events werkt.

Microsoft 365 correct beveiligen met Conditional Access: een in de praktijk toepasbare set policies

In plaats van één „grote“ regel werkt in de dagelijkse praktijk een set van enkele duidelijk afgebakende policies beter. Dat vermindert bijwerkingen en maakt foutzoeken bij een incident eenvoudiger. Een beproefd basismodel bestaat uit:

1) Baseline voor alle gebruikers: MFA afdwingen, Legacy blokkeren

Voor normale gebruikersaccounts is de baseline: MFA verplicht en Legacy Authentication wordt geblokkeerd. Legacy is hier niet „ouderwets“, maar technisch problematisch: deze protocollen ondersteunen vaak geen moderne MFA-challenge en vormen daarom een klassiek instappunt voor Passwortspraying.

Belangrijk: blokkeer Legacy niet „ergens in de toekomst“, maar plan een overgangsfase met meting. Controleer via Sign-in Logs welke clients nog Legacy gebruiken. In organisaties hangen daar vaak multifunctionals, scan-to-mail of oudere mailclients in speciale omgevingen aan vast.

2) Admin-policy: duidelijk strenger dan de baseline

Geprivilegieerde rollen moeten een eigen policy krijgen: toegang alleen vanaf gedefinieerde Admin-Endgeräten (bijv. „compliant“ en eventueel een separate Admin-Workstation-Strategie), MFA met hoge zekerheid (phishing-resistent, bijv. FIDO2/Passkey of certificaat-gebaseerd), en bij voorkeur beperkingen voor risicovolle landen/locaties. Zelfs als niet elk bedrijf direct een volledige Privileged-Access-Architektur (PAM, oftewel privileged access management) implementeert, is dit onderscheid direct zinvol: een gecompromitteerd Adminkonto heeft een ander schadebereik dan een gecompromitteerd Nutzerkonto.

3) Policy voor externe samenwerking en gasten

Gasttoegang (B2B Collaboration) creëert vaak onverwachte datapaden: gasten downloaden bestanden uit SharePoint, werken in Teams of hebben toegang tot projectportalen. Stel hier bewust vast of gasten alleen met MFA mogen inloggen, of bepaalde Apps uitgesloten zijn en hoe lang Sessions geldig blijven. Voor projectwerk is vaak een kortere Session-Lebensdauer zinvol om het risico van „vergeten Logins“ te verkleinen.

4) Policy voor gevoelige datapaden: apparaat of sessie beveiligen

In de dagelijkse praktijk zijn er verschillende beschermingsbehoeften: een Vertriebsmitarbeiter mag misschien vanaf elk Gerät e-mails lezen, maar niet zonder beheerd Gerät grote hoeveelheden data uit SharePoint downloaden. Zulke verschillen legt u niet vast met een algemene „erlaubt/verbietet“-regel, maar met CA-Kombinationen: „Zugriff erlaubt, wenn Gerät compliant“ of „Zugriff nur per Browser mit eingeschränkter Sitzung“. Dat is minder rigide dan compleet blokkeren – en toch effectief.

MFA-uitzonderingen: waar ze realistisch zijn — en hoe u ze controleert

MFA-uitzonderingen zijn geen teken van zwakte, zolang ze doelbewust zijn vormgegeven en operationeel worden gecontroleerd. Zonder gecontroleerde uitzonderingen ontstaan schaduwoplossingen: Nutzer omzeilen processen, Admins schakelen regels impulsief uit, en op den duur is de Policy-Sammlung niet meer te volgen.

Belangrijk is de onderscheiding: een MFA-uitzondering is zelden „MFA aus“, maar vaak „MFA anders“ of „Zugriff nur unter anderen Bedingungen“. Typische uitzonderingencategorieën:

Uitzonderingsgeval 1: Niet-interactieve toegangen en Schnittstellen

Veel procesnahe softwareoplossingen integreren M365-diensten: e-mailverzending, toegang tot agenda, SharePoint-bestandsopslag, Teams-meldingen of Graph-API-toegang. Dergelijke integraties mogen niet via gebruikersaccounts met uitgeschakelde MFA verlopen. Beter is een technische toegang via app-registraties (applicatie in Entra ID) met duidelijke machtigingen en een levenscyclus voor secrets en certificaten. Dat is geen „MFA-uitzondering“, maar een andere authenticatiemethode die beter te auditen is.

Operationele consequenties: secrets moeten geroteerd worden, certificaten verlopen en machtigingen moeten opnieuw gecertificeerd worden. Als u integraties plant, definieer eigenaarschap (wie certificaten/secrets vernieuwt) en monitoring (bijv. waarschuwingen vóór verlopen). Anders wordt uit „veilige“ app-auth een ongeplande uitval.

Uitzonderingsgeval 2: apparaten zonder moderne aanmelding (bijv. scanners, printers, ruimtesystemen)

Hier ontstaan de klassieke discussies over SMTP-Relay, Scan-to-Mail of zaalpostvakken. De verkeerde oplossing is vrijwel altijd „een gebruikersaccount zonder MFA“. Beter zijn technische paden die niet afhangen van interactieve aanmelding: gecentraliseerde mail-relay met IP-RESTrictie, certificaat- of connector-benaderingen, of gescheiden systeempostvakken met beperkte machtigingen. Cruciaal is: het apparaat zelf kan MFA niet bedienen, dus het ontwerp moet het transport- en netwerkpad beveiligen.

Uitzonderingsgeval 3: noodbedrijf en beperkte bereikbaarheid

Buitendienst, productie of ploegendienst kennen situaties zonder mobiele ontvangst of zonder private mobiele apparaten. Het loont om vroeg alternatieve MFA-methoden te overwegen: hardware-tokens, FIDO2-beveiligingssleutels, of Windows Hello for Business (apparaatgebonden aanmelding). „Tijdelijk MFA uit“ is operationeel verleidelijk, maar slecht schaalbaar en vrijwel niet te auditen.

Uitzonderingsgeval 4: geautomatiseerde jobs met gebruikerscontext

Sommige legacy-systemen starten jobs „als gebruiker“, bijvoorbeeld voor SharePoint-uploads of rapportages. Dat is tegenwoordig riskant, omdat het rollen en toegangsrechten vermengt. Als vervanging niet direct mogelijk is, werk met tussenoplossingen: beperkte serviceaccounts, duidelijke Named Locations, strikte wachtwoord-/secret-beleid en consequente logging. En: plan de migratie naar app-identiteiten als een apart werkpakket, niet als „later eens“.

Hoe u uitzonderingen documenteert, goedkeurt en weer verwijdert

Uitzonderingen zijn in de operatie alleen acceptabel als ze een levenscyclus hebben. Praktisch heeft zich een lichtgewicht werkwijze bewezen die zonder bureaucratie werkt maar toch auditbestendig is:

1. Motivatie in één zin: Welke bedrijfs- of operationele functie hangt eraan (bijv. „Scan-to-Mail op locatie X“)?
2. Technische indeling: Welke app/protocollen, welke accounts, welke datapaden?
3. Compenserende controles: Wat beperkt het risico (IP-RESTrictie, minimaal noodzakelijke rechten, monitoring)?
4. Vervaldatum: Elke uitzondering krijgt een reviewdatum. Zonder review wordt deze verwijderd of opnieuw goedgekeurd.
5. Owner: Wie is verantwoordelijk als het vastloopt of als de uitzondering afloopt?

Zo worden uitzonderingen niet „goed“, maar wel bestuurbaar. En dat is in de praktijk precies het verschil tussen een robuuste M365-beveiligingsbasis en een wildgroei aan beleid.

Break-Glass-Accounts: Notfallzugang ohne Sicherheitsloch

Break-Glass-accounts zijn noodaccounts voor toegang tot de tenant wanneer reguliere admin-toegang niet werkt – bijvoorbeeld door een foutieve configuratie in Conditional Access, uitval van een MFA-provider of een identity-incident. Het doel is duidelijk, maar de uitvoering kent typische valkuilen: een Break-Glass-account dat nooit getest wordt helpt in het geval van een incident niet. Een Break-Glass-account dat te gemakkelijk bereikbaar is, is een aantrekkelijk doelwit.

Wat Break-Glass niet is

• Geen dagelijks beheeraccount: Het mag niet tijdens de normale bedrijfsvoering worden gebruikt.
• Geen verzamelplaats voor uitzonderingen: Het vervangt geen zorgvuldig Conditional Access‑ontwerp.
• Geen „we hebben er een, dat is genoeg”: Zonder proces, test en alarmering is het slechts een theoretisch plan.

Basisprincipes voor Break-Glass in de operatie

Een praktisch werkende inrichting richt zich op drie doelen: bereikbaar in noodgevallen, moeilijk aan te vallen tijdens de normale operatie, en goed traceerbaar.

• Minstens twee accounts: Redundantie tegen uitsluiting, verkeerde bediening of gecompromitteerde inloggegevens.
• Sterk beveiligd: Lange, willekeurige wachtwoorden; geen e-mail‑doorsturingen; geen gebruik voor apps/integraties.
• Doelgericht van CA uitgezonderd – maar nauwgezet: Gewoonlijk is er een uitzondering op bepaalde CA‑policies, zodat u in noodgevallen niet door uw eigen regels wordt buitengesloten. Tegelijkertijd moeten andere beveiligingsmechanismen actief zijn: meldingen bij gebruik, RESTrictieve roltoekenning, afzonderlijke bewaring van de toegangsgegevens.
• Logging en alarmering: Elke aanmelding moet een onmiddellijke melding veroorzaken (SIEM/SOC of op z’n minst e-mail/Teams‑alarm naar een incident-postvak). Het gebruik van Break-Glass is per definitie een beveiligingsgebeurtenis.

Een belangrijk punt: beslis bewust of Break-Glass met of zonder MFA wordt beheerd. Veel organisaties laten het zonder MFA om bij uitval van MFA handelingsbekwaam te blijven. Dan moeten de compenserende controles echter extra goed zijn (bewaring, toegang tot het wachtwoord, alarmering, regelmatig wisselen). Alternatief kan men Break-Glass voorzien van hardwaregebaseerde MFA (bijv. FIDO2) die onafhankelijk is van mobiele netwerken. Belangrijk is niet de „juiste” ideologie, maar een noodpad dat in uw context daadwerkelijk werkt.

Rollout-realiteit: zo voorkomt u lockouts en supportpieken

Veel CA-/MFA-rollouts mislukken niet om technische redenen, maar organisatorisch: te snel, te breed, zonder telemetrie en zonder een helder supportproces. Een stabiele rollout werkt met golven en meetpunten.

Stap 1: zichtbaarheid creëren (voordat u blokkeert)

Gebruik Sign-in-Logs en analyses om te achterhalen: welke apps worden gebruikt? Welke clients zijn „legacy”? Welke locaties/IP‑ranges zijn reëel? Welke gebruikers hebben uitzonderlijk veel aanmeldproblemen? Zonder deze gegevens is elke policy een blinde vlucht.

Stap 2: pilotgroepen met echte uitzonderingsgevallen

Pilots zouden niet alleen „IT en een paar vrijwilligers” moeten zijn. Neem bewust randgevallen mee: buitendienst, productielocaties, projectmedewerkers met gasttoegang, en minimaal één afdeling met typische tools van derden. Het doel is geen harmonie, maar het vroegtijdig vinden van de echte struikelblokken.

Stap 3: helpdesk-playbooks vastleggen

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.
• Clientmanagement (bijv. Intune): compliance-definitie, apparaatsstatus, uitrol van Authenticator/Passkeys, apparaatlevenscyclus.
• Netwerk: IP-ranges voor Named Locations, proxy-/TLS-inspectie-uitzonderingen, locatiewisseling.
• Service Owner van bedrijfsapplicaties: integratiepaden (Graph/SMTP/SharePoint), overgang van legacy-authenticatie, secret-rotatie.
• Helpdesk: standaardprocessen voor MFA-reset, apparaatwissel, onboarding/offboarding.

De belangrijkste managementbeslissing is vaak niet ‚MFA ja/nee‘, maar: hebben we tijd en middelen voor het aanvullende werk (legacy afbouwen, integraties moderniseren, apparaatbeheer stabiliseren)? Zonder dit werk blijft de veiligheidswinst achter bij de verwachtingen – of wordt de exploitatie onnodig zwaar.

Conclusie: veiligheid wint wanneer noodsituatie en uitzonderingen onderdeel van het systeem zijn

Microsoft 365 goed beveiligen betekent Conditional Access als centrale besturingslaag gebruiken – niet als een eenmalige configuratie. MFA is daarbij verplicht, maar de daadwerkelijke operationele kwaliteit ontstaat door nette uitzonderingen (met vervaldatum, Owner en compenserende controles) en door Break-Glass-Accounts die getest, bewaakt en organisatorisch ingebed zijn. Wie deze drie elementen samenbrengt, vermindert accountrisico’s, krijgt auditbaarheid zonder overhead en voorkomt dat beveiligingsregels bij een incident tegen zichzelf werken.

Project of moderniseringsopdracht met Net-Base bespreken.