Noodaccounts in Microsoft 365: voorkom dat beheer onbereikbaar wordt

Een storing, een fout in Conditional Access of het vertrek van de laatste bereikbare beheerder kan ervoor zorgen dat niemand meer bij het Microsoft 365-beheer kan. Juist op zo'n moment moet een organisatie een gecontroleerde noodroute hebben. Microsoft noemt dit een emergency access account. In de praktijk wordt ook de term break-glassaccount gebruikt.

Een noodaccount is geen extra dagelijks beheerdersaccount en ook geen wachtwoord dat voor het gemak door het team wordt gedeeld. Het is een zorgvuldig afgeschermde herstelroute voor uitzonderlijke situaties. De inrichting moet daarom twee ogenschijnlijk tegengestelde doelen combineren: het account moet sterk beveiligd zijn én bruikbaar blijven wanneer normale identiteits-, apparaat- of netwerkafhankelijkheden uitvallen.

Deze gids helpt directie, office management en IT-verantwoordelijken om noodtoegang als bedrijfscontinuïteitsmaatregel te organiseren. De technische beheeromgeving staat in het Microsoft Entra-beheercentrum, maar begin niet met losse instellingen. Spreek eerst eigenaarschap, opslag, alarmering en het gebruiksproces af. Wil je weten of beheerrechten en herstelroutes in jouw omgeving aantoonbaar zijn geborgd? Laat je Microsoft 365-omgeving beoordelen met de SCAV-IT IT-scan.

Wanneer heb je noodtoegang nodig?

Normale beheerders horen met een persoonlijk account te werken, met sterke meervoudige verificatie en zo weinig mogelijk permanente rechten. Noodaccounts vormen de terugvaloptie als die normale route niet beschikbaar is. Microsoft noemt onder meer deze scenario's:

• beheerders kunnen hun normale verificatiemethode niet gebruiken;
• een storing raakt de identiteitsprovider of federatieve aanmeldroute;
• een fout in Conditional Access sluit alle normale beheerders buiten;
• alle bevoegde beheerdersrollen zijn alleen activeerbaar, maar niemand kan de activering goedkeuren;
• de laatst bereikbare Global Administrator vertrekt of is onverwacht niet beschikbaar.

Het doel is dus niet om iedere beheerhinder te omzeilen. Noodtoegang is bedoeld voor situaties waarin normaal herstel niet snel genoeg mogelijk is en de organisatie anders de regie over de tenant verliest.

Leg vooraf vast wat bij jouw organisatie als noodsituatie telt. Een beheerder die zijn telefoon thuis heeft laten liggen is geen reden om een noodaccount te gebruiken. Een tenantbrede blokkade waardoor kritieke gebruikers, beveiligingsinstellingen of bedrijfsdiensten niet meer kunnen worden beheerd, kan dat wel zijn.

Waarom Microsoft minimaal twee accounts adviseert

Microsoft adviseert twee of meer noodaccounts. Eén account kan zelf onbruikbaar raken door een verlopen of beschadigde beveiligingssleutel, een foutieve wijziging, een vergeten registratie of een blokkade. Twee onafhankelijk ingerichte accounts verkleinen de kans op één gemeenschappelijk uitvalpunt.

Maak de accounts cloud-only op het standaard onmicrosoft.com-domein. Laat ze niet synchroniseren vanuit een lokale Active Directory en koppel ze niet aan een federatieve identiteitsprovider. Als juist de lokale omgeving, synchronisatie of federatie uitvalt, moet de noodroute daar niet van afhankelijk zijn.

Geef ieder noodaccount een permanente actieve Global Administrator-rol. Voor normale beheerders is tijdelijke activering via Privileged Identity Management vaak een sterke maatregel. Bij een noodaccount kan zo'n activering juist een nieuwe afhankelijkheid vormen, bijvoorbeeld wanneer een goedkeurder niet bereikbaar is. Lees voor het verschil tussen normale en tijdelijke beheerrechten ook Microsoft Entra PIM: tijdelijk beheer met controleerbare toegang.

Permanente Global Administrator-rechten maken het account zeer gevoelig. Beperk daarom het aantal noodaccounts, gebruik ze nooit voor dagelijks werk en geef ze geen postvak of productiviteitslicentie als dat niet nodig is. De kracht van het account is alleen verdedigbaar als het gebruik zeldzaam, bewaakt en aantoonbaar is.

Gebruik phishingbestendige verificatie zonder gedeelde afhankelijkheid

Een noodaccount moet voldoen aan de verplichte MFA-eisen voor Microsoft-beheerportalen. Een uitsluiting in je eigen Conditional Access-beleid schakelt Microsofts verplichte MFA voor die portalen niet uit. Microsoft adviseert daarom een phishingbestendige methode, bij voorkeur een passkey op een FIDO2-beveiligingssleutel. Certificaatgebaseerde verificatie kan ook geschikt zijn als de organisatie al een goed beheerde PKI heeft.

Kies een verificatiemethode die niet dezelfde storing kan hebben als de normale beheerdersroute. Als reguliere beheerders bijvoorbeeld Microsoft Authenticator op hun werktelefoon gebruiken, laat de noodroute dan niet van dezelfde telefoons, hetzelfde mobiele netwerk of hetzelfde apparaatbeheer afhangen. Een fysieke FIDO2-sleutel in een beveiligde opslagplaats kan die afhankelijkheid doorbreken.

Let op deze uitgangspunten:

• registreer geen privételefoon of persoonlijk e-mailadres van één medewerker;
• bewaar wachtwoord en beveiligingssleutel niet onbeheerd op dezelfde plek;
• gebruik voor de twee noodaccounts waar mogelijk afzonderlijke sleutels en veilige locaties;
• houd alleen bevoegde personen op de hoogte van de opslag- en uitgifteprocedure;
• zorg dat de middelen ook buiten kantooruren bereikbaar zijn volgens het continuïteitsplan;
• leg uit wie de toegang mag vrijgeven en wie achteraf controleert.

Een kluis is alleen nuttig als de juiste mensen er tijdens een echte storing bij kunnen. Een sleutel die uitsluitend in een kantoor ligt terwijl het gebouw niet toegankelijk is, is geen robuuste noodroute. Andersom is een sleutel in een bureaulade of gewone gedeelde wachtwoordmap onvoldoende beschermd. Kies per organisatie een combinatie van fysieke beveiliging, bereikbaarheid en functiescheiding.

Behandel Conditional Access als risico én vangnet

Conditional Access beschermt normale accounts door voorwaarden te stellen aan locatie, apparaat, risico en verificatie. Een foutieve beleidswijziging kan echter ook alle beheerders blokkeren. Microsoft adviseert daarom noodaccounts uit te sluiten van beleid dat aanmelden blokkeert of aanvullende beperkingen afdwingt.

Gebruik bij voorkeur een speciale beveiligingsgroep voor de noodaccounts en sluit die groep bewust uit van relevante blokkerende beleidsregels. Documenteer iedere uitsluiting. Controleer ook of nieuwe beleidsregels dezelfde noodgroep meenemen, want één vergeten beleid kan de hele herstelroute alsnog blokkeren.

Een uitsluiting betekent niet dat het account zonder sterke verificatie werkt. De phishingbestendige methode blijft de primaire beveiliging. Bovendien geldt de verplichte Microsoft-MFA voor de betreffende beheerportalen ook voor noodaccounts. Het verschil is dat je eigen beleidsregels geen extra afhankelijkheid mogen introduceren die tijdens de noodsituatie onbereikbaar kan zijn.

Voer wijzigingen in Conditional Access eerst in rapportmodus of via een beheerste pilot in. Test uitsluitingen expliciet en controleer het gecombineerde effect van alle beleidsregels. De gids Conditional Access invoeren zonder jezelf buiten te sluiten beschrijft hoe een pilot, noodaccounts en nacontrole samenhangen.

Alarmeer op ieder gebruik

Een noodaccount hoort vrijwel nooit aan te melden. Daardoor is iedere aanmelding betekenisvol. Richt een waarschuwing in op zowel geslaagde als mislukte aanmeldpogingen en laat die waarschuwing naar meerdere bevoegde personen gaan. Microsoft beschrijft hiervoor Azure Monitor, Microsoft Sentinel of andere bewaking die de Entra-aanmeldlogboeken gebruikt.

Een melding moet minimaal duidelijk maken:

• welk noodaccount is gebruikt;
• wanneer de poging plaatsvond;
• vanaf welk netwerk of welke locatie de poging kwam;
• of de aanmelding slaagde;
• wie het gebruik heeft geautoriseerd;
• of het om een geplande test of echte noodsituatie ging.

Laat de waarschuwing niet alleen aankomen in een systeem dat tijdens dezelfde storing onbereikbaar kan zijn. Denk na over een tweede communicatiekanaal, bijvoorbeeld een beveiligde telefonische escalatie of een extern beheerd meldpunt. Voorkom wel dat gevoelige accountgegevens in gewone e-mail, chat of sms worden gedeeld.

Controleer na ieder gebruik de aanmeld- en auditlogboeken. Het Microsoft 365-auditlogboek gebruiken voor incidentonderzoek en bewijs helpt om onderzoeksvragen, exports en opvolging beheersbaar te organiseren. Bewaar alleen noodzakelijke gegevens en volg de afgesproken bewaartermijn.

Test de volledige herstelroute ieder kwartaal

Microsoft adviseert noodaccounts minimaal iedere 90 dagen te valideren. Alleen controleren dat de gebruiker nog in de lijst staat is niet genoeg. Een goede oefening bewijst dat de hele keten werkt, zonder productie-instellingen onnodig te veranderen.

Neem in de kwartaaltest op:

1. controleer of beide accounts bestaan, niet geblokkeerd zijn en cloud-only blijven;
2. controleer of de Global Administrator-rol permanent actief is;
3. controleer of wachtwoord, beveiligingssleutel en opslagprocedure beschikbaar zijn;
4. meld gecontroleerd aan via een schone browsercontext;
5. voer een onschadelijke beheercontrole uit, bijvoorbeeld het openen van een beheeroverzicht;
6. bevestig dat de gebruikswaarschuwing de juiste ontvangers bereikt;
7. beoordeel aanmeld- en auditlogboeken op afwijkingen;
8. sluit de oefening af met datum, deelnemers, resultaat en verbeteracties.

Plan de oefening vooraf, zodat de melding niet voor een echt incident wordt aangezien. Laat twee bevoegde personen aanwezig zijn als je functiescheiding hebt afgesproken. Noteer nooit het wachtwoord of een herstelgeheim in het testverslag.

Wissel niet automatisch na iedere test alle middelen als daar geen beleid of incidentreden voor is. Onnodige wijzigingen kunnen juist fouten introduceren. Roteer een wachtwoord of vervang een sleutel volgens je vastgestelde beleid, bij een personeelswijziging, na ongeautoriseerde blootstelling of wanneer de integriteit niet meer zeker is. Test na iedere wijziging opnieuw.

Leg een kort noodproces vast

Tijdens een incident is een lang technisch document moeilijk bruikbaar. Maak daarom een beknopt noodproces dat zonder geheime gegevens beschrijft:

• welke situaties noodtoegang rechtvaardigen;
• wie het gebruik mag autoriseren;
• waar de middelen veilig worden uitgegeven;
• wie tijdens het gebruik meekijkt en registreert;
• welke eerste beheeracties zijn toegestaan;
• hoe communicatie en escalatie verlopen;
• welke logboeken en bewijzen worden veiliggesteld;
• wanneer de noodsessie wordt beëindigd;
• wie de nacontrole en eventuele vervanging uitvoert.

De eerste actie na aanmelden is meestal niet meteen een grote beleidswijziging. Bevestig eerst de oorzaak en omvang. Controleer of sprake is van een fout, storing of mogelijk misbruik. Maak alleen de minimale wijziging die nodig is om normale, persoonlijke beheertoegang veilig te herstellen. Gebruik daarna weer de reguliere beheeraccounts.

Als het noodaccount tijdens een beveiligingsincident is gebruikt, behandel de sessie als zeer gevoelig. Controleer wijzigingen, actieve sessies, nieuwe verificatiemethoden en roltoewijzingen. Vervang betrokken geheimen of sleutels als blootstelling niet kan worden uitgesloten.

Veelgemaakte fouten

Eén noodaccount is voldoende

Eén account blijft één uitvalpunt. Gebruik minimaal twee onafhankelijk ingerichte accounts en test beide.

Het account gebruikt hetzelfde werkdomein en dezelfde aanmeldketen

Een gesynchroniseerd of federatief account kan uitvallen met de normale identiteitsroute. Gebruik cloud-only accounts op het onmicrosoft.com-domein.

De noodaccounts worden van alle beveiliging uitgesloten

Conditional Access-uitsluitingen mogen noodzakelijke blokkades wegnemen, maar het account heeft nog steeds sterke, phishingbestendige verificatie nodig. Microsofts verplichte MFA voor beheerportalen blijft van toepassing.

De beveiligingssleutel ligt veilig, maar niemand kan erbij

Beveiliging zonder bereikbaarheid levert geen werkende herstelroute op. Test de fysieke uitgifte en beschikbaarheid ook buiten kantooruren.

Een test bestaat alleen uit het bekijken van de gebruikerslijst

Daarmee bewijs je niet dat aanmelden, verificatie, autorisatie en alarmering werken. Voer minimaal iedere 90 dagen een gecontroleerde ketentest uit.

Niemand reageert op een aanmelding

Een alert zonder eigenaar is geen bewaking. Leg vast wie direct controleert of het gebruik gepland en geautoriseerd was.

Veelgestelde vragen

Is een noodaccount hetzelfde als een normaal Global Administrator-account?

Nee. Het heeft wel permanente Global Administrator-rechten, maar wordt uitsluitend gebruikt voor noodherstel en geplande tests. Normale beheerders werken met persoonlijke accounts en zo weinig mogelijk rechten.

Moet een noodaccount MFA gebruiken?

Ja. Microsofts verplichte MFA voor Azure en Microsoft-beheerportalen geldt ook voor emergency access accounts. Microsoft adviseert passkeys op FIDO2-beveiligingssleutels of certificaatgebaseerde verificatie.

Waarom sluit je het account dan uit van Conditional Access?

Om te voorkomen dat een eigen beleidsregel het account blokkeert tijdens de storing waarvoor het bedoeld is. De phishingbestendige verificatiemethode blijft bestaan en de Microsoft-verplichting voor MFA staat los van je eigen uitsluiting.

Mag één beveiligingssleutel door meerdere beheerders worden gebruikt?

Het noodaccount is niet aan één persoon gekoppeld. De middelen mogen alleen beschikbaar zijn voor vooraf bevoegde personen via een gecontroleerde uitgifteprocedure. Bewaar ze niet in een gewone gedeelde werkruimte en registreer ieder gebruik.

Hoe vaak moeten we testen?

Microsoft adviseert minimaal iedere 90 dagen. Test beide accounts, de verificatiemiddelen, de beheerrol, de alarmering en de registratie van het resultaat.

Hebben noodaccounts een Microsoft 365-licentie nodig?

Voor de identiteit en rol is doorgaans geen gewone productiviteitslicentie nodig. Licentievereisten kunnen wel afhangen van gebruikte beveiligings- en bewakingsfuncties. Controleer de actuele productvoorwaarden voor je gekozen inrichting.

Gebruikte Microsoft-bronnen

De productwerking en aanbevelingen zijn op 11 november 2026 gecontroleerd tegen deze officiële Microsoft-bronnen:

• Manage emergency access accounts in Microsoft Entra ID
• Mandatory multifactor authentication for Azure and admin portals
• Plan a Conditional Access deployment
• Secure access practices for administrators in Microsoft Entra ID

Microsoft kan verificatiemethoden, portalen en licentievoorwaarden wijzigen. Controleer daarom de actuele documentatie en tenantinstellingen voordat je de inrichting aanpast.

Maak noodtoegang onderdeel van continuïteit

Een goed noodaccount is onzichtbaar in het dagelijks werk, maar aantoonbaar beschikbaar wanneer normale beheertoegang uitvalt. De waarde zit niet alleen in twee accounts. De waarde ontstaat door onafhankelijke verificatie, veilige opslag, alarmering, duidelijke autorisatie en een oefening die minimaal ieder kwartaal bewijst dat de keten werkt.

Begin met de afhankelijkheden die je juist tijdens een storing niet wilt hebben: één persoon, één telefoon, één netwerk, één identiteitsprovider of één fysieke locatie. Haal die uit de herstelroute, bewaak ieder gebruik en herstel na een incident zo snel mogelijk de normale persoonlijke beheertoegang.