Quick Start: Multi-Factor Authenticatie (MFA) - Dag 1

💼 Management Samenvatting

Multi-Factor Authenticatie (MFA) is de allerbelangrijkste security control voor M365 en moet DAG 1 worden geïmplementeerd. Deze quick start guide helpt organisaties om binnen 4-8 uur MFA uit te rollen voor alle gebruikers.

Aanbeveling
IMPLEMENT
Risico zonder
Critical
Risk Score
10/10
Implementatie
16u (tech: 4u)
Van toepassing op:
M365
Azure AD
Alle Gebruikers

MFA is de single meeste effective security control volgens Microsoft en alle security frameworks met 99.9% preventie van account compromises. Zonder MFA zijn organisaties extreem kwetsbaar: phishing steelt wachtwoorden in seconden, password spray attacks proberen common passwords, credential stuffing gebruikt gelekte credentials, en one compromised account is mogelijk volledige tenant takeover. MFA voorkomt dit door tweede factor te vereisen (smartphone, security key) die aanvaller niet heeft. Voor nieuwe M365 tenants is MFA de absolute EERSTE prioriteit - zelfs vóór andere controls. Cost-benefit ratio is extreem gunstig: minimale implementatie effort, gratis included in M365, immediate risk reduction van 99.9%.

PowerShell Modules Vereist
Primary API: Microsoft Graph API
Connection: Connect-MgGraph
Required Modules: Microsoft.Graph.Identity.SignIns, Microsoft.Graph.Users

Implementatie

Deze quick start guide implementeert baseline MFA voor alle gebruikers binnen één werkdag via Conditional Accesssbeleid: beleid scope is alle gebruikers met exclusion van 2 break-glass accounts, Require MFA voor alle cloud apps, MFA methods: Microsoft Authenticator (preferred), SMS/Phone (backup), FIDO2 keys (geavanceerd), Registration enforcement: Force users to register MFA bij next sign-in, Target: 100% MFA coverage binnen 7 dagen. De guide omvat: prerequisites check, step-by-step implementation, user communication templates, helpdesk preparation, en monitoring dashboard setup.

Vereisten (Pre-Implementation Checklist)

Een succesvolle MFA-implementatie begint met een degelijke voorbereiding waarin je zeker weet dat de technische basis staat als een huis. Controleer daarom eerst of de tenant beschikt over Azure AD Premium P1 of een bundel waarin voorwaardelijke toegang is inbegrepen, en loop systematisch alle licentierapportages door zodat iedere gebruiker die MFA moet ontvangen ook daadwerkelijk een toewijzing heeft. Bevestig tegelijkertijd dat de beheerders die de uitrol leiden zijn voorzien van de juiste rollen en dat hun accounts het wachtwoordbeleid voor break-glass scenario's naleven. Combineer deze inventarisatie met een risicoanalyse per gebruikersgroep zodat duidelijk wordt waar de afhankelijkheden liggen met on-premises systemen, legacy clients of gedeelde accounts die mogelijk niet direct kunnen worden omgezet.

Parallel aan de licentiecontrole richt je de noodprocedures in. Twee cloud-only break-glass-accounts met unieke UPN's, lange willekeurige wachtwoorden en geen MFA vormen de ruggengraat voor toegang wanneer Conditional Access per ongeluk iedereen blokkeert. Documenteer waar de wachtwoorden fysiek zijn opgeslagen, beschrijf wie toegang heeft tot de kluis en leg vast hoe vaak de accounts worden getest. Voeg deze accounts toe aan een aparte groep die structureel wordt uitgesloten van beleidsregels zodat het beheerteam in crisissituaties kan blijven handelen zonder beveiligingsmaatregelen uit te schakelen.

Er is bovendien een helder plan nodig voor de authenticatiemethoden die je toestaat. Voorzie eindgebruikers van duidelijke instructies over het installeren van Microsoft Authenticator, het koppelen van zakelijke accounts en het activeren van telefoon- of hardwaremethoden voor medewerkers die niet met smartphones werken. Stem met het device-team af hoe de app beschikbaar wordt gesteld via Company Portal of andere distributiemechanismen en toets of de privacy officers akkoord zijn met het gebruik van pushnotificaties. Beslis vooraf hoe uitzonderingen voor kritieke operators of externe partijen worden afgehandeld en documenteer tijdelijke vrijstellingen inclusief een vervaldatum.

Communicatie bepaalt het tempo van adoptie. Schrijf een aankondigingsmail waarin bestuurders uitleggen waarom MFA verplicht wordt, lever een stappenplan in begrijpelijke taal en zorg dat leidende gebruikers al vóór de grote uitrol hun registratie afronden zodat zij als ambassadeur kunnen optreden. Plan begeleide registratiesessies, reserveer vergaderruimtes met stabiele wifi en stel FAQ's beschikbaar aan de helpdesk. Licht het supportteam ruim op tijd in over verwachte pieken, voorzie ze van testaccounts om scenario's te doorlopen en organiseer een escalatiepad voor gebruikers die ondanks begeleiding vastlopen.

Tot slot borg je de planning en governance. Leg vast dat de voorbereiding maximaal één werkdag duurt, dat de technische configuratie binnen vier uur staat en dat de adoptieperiode van een week actief wordt gevolgd met dashboards. Definieer meetpunten zoals het percentage geregistreerde gebruikers, het aantal geblokkeerde aanmeldingen en de tijd die nodig is om uitzonderingen af te handelen. Maak duidelijk dat uitstel directe impact heeft op de risicopositie van de organisatie en dat de stuurgroep alleen afwijkt van de planning wanneer er een alternatief control binnen dezelfde termijn beschikbaar is. Deze afspraken vormen het kompas waarmee het projectteam versneld maar gecontroleerd naar de dag-1 implementatie toewerkt.

Implementatie (Step-by-Step - 4-8 uur)

De implementatiefase vertaalt de voorbereide besluiten naar concrete acties waarbij je steeds in kleine stappen werkt om regressie te voorkomen. Start met een gezamenlijke kickoff tussen identity-, netwerk- en supportteams zodat iedereen weet welk doel binnen dezelfde dag gehaald moet worden en welke afhankelijkheden bestaan. Leg nogmaals uit dat MFA het fundament is voor alle andere securitymaatregelen en dat eventuele issues onmiddellijk moeten worden geëscaleerd. Door de scope helder te houden — alle gebruikers, alle cloud-apps, twee uitzonderingsaccounts — voorkom je dat het project verzandt in discussies over toekomstige uitbreidingen.

Begin met het hard maken van de break-glass-accounts. Controleer of de wachtwoorden recent zijn geroteerd, login-historie geen verdachte activiteiten toont en of de accounts niet per ongeluk in dynamische groepen terecht zijn gekomen die alsnog beleidsregels toepassen. Registreer bij voorkeur een fysieke sleutel als extra verificatiemiddel dat offline beschikbaar blijft, en voer direct na creatie een testaanmelding uit vanaf een vertrouwde werkplek. Documenteer de bevindingen in het change record zodat auditors later kunnen nagaan dat deze stap daadwerkelijk is uitgevoerd en beoordeel of aanvullende monitoring op de accounts nodig is binnen Sentinel of een ander SIEM.

Vervolgens richt je de registratiewave in. Communicatie, logistiek en ondersteuning worden samengebracht in een draaiboek dat beschrijft welke mailtemplates wanneer worden verzonden, welke managers hun teams persoonlijk aanspreken en hoe medewerkers begeleiding kunnen aanvragen. Plan tijdsloten waarin servicedeskmedewerkers beschikbaar zijn via Teams of op locatie om gebruikers stap voor stap door de registratie te loodsen. Het doel van deze wave is om de eerste helft van de organisatie te laten registreren voordat er ook maar één enforce actief wordt, zodat je draagvlak opbouwt en kinderziektes vroegtijdig opvangt.

Gebruik PowerShell-script 01-multi-factor-authenticatie.ps1 (functie Invoke-Monitoring) – Controleer huidige MFA status en identificeer gebruikers zonder MFA.

Het PowerShell-script dat aan deze quick start is gekoppeld fungeert als telemetriebron. Gebruik het om per afdeling inzichtelijk te maken hoeveel gebruikers al een tweede factor hebben geactiveerd, welke methoden populair zijn en welke accounts nog volledig onbeveiligd zijn. Door het script meerdere keren per dag te draaien en de resultaten te visualiseren in bijvoorbeeld Power BI kun je managers gericht aanspreken, successen vieren en uitzonderingen onderbouwen. Dezelfde data voedt het registratiedraaiboek zodat je weet wanneer je van informeren naar verplichten kunt gaan.

Zodra duidelijk is dat het grootste deel van de organisatie voorbereid is, creëer je het Conditional Access-beleid in rapportagemodus. Kies een duidelijke naamgeving, voeg alle gebruikers toe op één na de break-glassgroep en selecteer alle cloudtoepassingen zodat er geen blinde vlekken ontstaan. Zet de grant controls op "Require multi-factor authentication" en activeer de policy uitsluitend in Report-only. Laat deze configuratie minimaal enkele dagen draaien en analyseer de sign-in logs om te zien welke applicaties, accounts of protocollen mogelijk problemen geven. Documenteer bevindingen, vooral wanneer serviceaccounts of on-premises toepassingen basisverificatie eisen, zodat je gericht aanvullende maatregelen kunt treffen.

Wanneer het rapport aantoont dat er geen functionele blokkades meer zijn, activeer je de registratiecampagne. Forceer dat iedere gebruiker bij de eerstvolgende aanmelding zijn methode configureert en stel een redelijke termijn in waarbinnen bevestiging opnieuw wordt gevraagd zodat gegevens actueel blijven. Monitor realtime hoeveel aanmeldingen worden geblokkeerd omdat gebruikers het scherm wegklikken en zorg dat het helpdeskteam een gestandaardiseerd antwoord klaar heeft met een link naar de handleiding. Door het registratiebeleid kort vóór het weekend te activeren kun je de impact spreiden en heb je op maandag concrete cijfers voor de stuurgroep.

De laatste stap is het omzetten van het Conditional Access-beleid van rapportage naar handhaving. Communiceer een dag van tevoren dat aanmeldingen zonder geregistreerde methode worden geweigerd, benadruk dat break-glass uitsluitend voor noodgevallen is en kondig aan dat auditlogs actief worden beoordeeld. Zet daarna de policy live en volg gedurende de eerste uren ieder foutbericht op om schijnbaar technische incidenten te onderscheiden van gebruikers die simpelweg nog niet hebben geregistreerd. Houd gedurende drie dagen verhoogde bezetting op de servicedesk aan, plan een terugblik met het projectteam en leg vast welke verbeteringen je bij de volgende securitycontrol direct kunt toepassen.

monitoring (Post-Implementation)

Gebruik PowerShell-script 01-multi-factor-authenticatie.ps1 (functie Invoke-Monitoring) – Continue monitoring van MFA coverage en compliance.

Monitoring start direct na de omschakeling naar enforced MFA en concentreert zich in de eerste week volledig op het beperken van verstoringen. Plan dagelijkse stand-ups tussen identitybeheer en servicedesk waarin de cijfers van de afgelopen 24 uur worden besproken: hoeveel gebruikers hebben succesvol geregistreerd, hoeveel aanmeldingen zijn geblokkeerd en welke applicaties leveren de meeste vragen op. Houd een draaiboek klaar voor scenario's waarin kritieke functies geraakt worden en wijs een eigenaar aan die direct kan besluiten om tijdelijk ondersteuning te bieden zonder het beleid uit te schakelen.

Gebruik het gekoppelde PowerShell-script om geautomatiseerd rapportages te genereren over de voortgang. Door het script te plannen op een Azure Automation-account of een beheerserver kun je elk uur een actuele lijst ontvangen van accounts zonder MFA-methoden, uitgesplitst naar afdelingen en locaties. Deze data helpt niet alleen bij het prioriteren van follow-up, maar vormt ook de basis voor dashboards die bestuurders laten zien dat de doelstelling van honderd procent dekking binnen een week haalbaar is. Integreer de uitvoer met Microsoft Lists of een CMDB zodat acties traceerbaar blijven.

Naast registratiepercentages moeten ook de aanmeldingslogboeken intensief worden geanalyseerd. Azure AD Sign-in Logs, Conditional Access insights en Identity Protection bieden inzicht in trends zoals een plotselinge stijging van mislukte aanmeldingen uit specifieke landen of protocollen. Door queries in Log Analytics voor te bereiden kun je in één keer zien of serviceaccounts, verouderde clients of federatieve partners moeite hebben met de nieuwe policies. Maak voor de stuurgroep een korte dagelijkse rapportage waarin de belangrijkste bevindingen en maatregelen worden samengevat.

De monitoring moet ook organisatorische indicatoren meenemen. Houd het volume en de inhoud van helpdesktickets bij om te bepalen of extra instructievideo's, walk-in sessies of communicatiecampagnes nodig zijn. Wanneer dezelfde vraag drie keer terugkomt, voeg je een antwoord toe aan het kennisportaal en informeer je de change manager zodat deze de volgende dag in de intranetupdate kan worden meegenomen. Blijf bovendien testen of de break-glass-accounts ongestoord kunnen aanmelden; plan een maandelijkse test en log het resultaat formeel.

Na de eerste week verschuift de focus van incidentbestrijding naar continue verbetering. Automatiseer een wekelijkse controle die nieuwe gebruikers zonder geregistreerde methode detecteert en stuur deze lijst direct naar HR of het onboardingteam. Meet de verdeling tussen Microsoft Authenticator, SMS en hardwaremethoden en spreek af dat sms slechts een tijdelijke fallback blijft. Wanneer het aandeel sms-verificaties te hoog blijft, ontleed je de oorzaken (bijvoorbeeld medewerkers zonder bedrijfstelefoon) en bied je alternatieven zoals FIDO2-sleutels of vaste telefoontjes.

Koppel de monitoring ten slotte aan bredere securityprocessen. Deel trends met het SOC zodat brute-forcecampagnes sneller worden opgemerkt en laat Internal Audit meekijken naar de bewijslast: screenshots van policies, export van registratiecijfers en attesteringsbrieven van systeemverantwoordelijken. Leg alle bevindingen vast in het risicoregister en gebruik de data om het beleid periodiek te herijken. Op die manier blijft MFA niet alleen operationeel functioneren, maar is het aantoonbaar onderdeel van de bredere cybersecuritygovernance.

Troubleshooting (Common Issues)

Gebruik PowerShell-script 01-multi-factor-authenticatie.ps1 (functie Invoke-Remediation) – Herstellen.

Troubleshooting start met rust en structuur. Wanneer een gebruiker meldt dat aanmelden niet lukt, haal je eerst de basisinformatie op: welk apparaat wordt gebruikt, welke foutmelding verschijnt en of de gebruiker eerder succesvol een tweede factor heeft ingesteld. Pas daarna kies je de oplossing. Door dit patroon consequent te volgen voorkom je dat ad-hoc uitzonderingen ontstaan of dat helpdeskmedewerkers policies omzeilen om maar snel door te kunnen. Leg vast dat iedere case wordt geregistreerd met ticketnummer, zodat trends zichtbaar worden en terugkerende problemen gericht kunnen worden aangepakt.

Gebruik het meegeleverde script ook voor herstelwerk. De functie Invoke-Remediation haalt lijsten op van accounts waarbij registratie is begonnen maar niet is afgerond, of waar methoden zijn verwijderd terwijl de policy al enforced is. Door deze gegevens naast de helpdesktickets te leggen zie je direct of gebruikers echt een technisch probleem hebben of simpelweg begeleiding nodig hebben. Automatiseer waar mogelijk resetacties: het opnieuw uitgeven van een registratieverzoek of het verwijderen van verouderde telefoonnummerrecords kan veilig via de Azure AD portal zolang je het vier-ogenprincipe toepast.

Veelvoorkomende issues lossen zich op met duidelijke instructie. Wanneer sms-berichten niet aankomen controleer je of het nummer in E.164-formaat staat, of roaming aanstaat en of de provider nummers van korte codes blokkeert. Bied direct het alternatief van een spraakoproep aan en leg uit dat deze optie vaak ook werkt op vaste toestellen. Kan de Authenticator-app geen QR-code scannen, laat de gebruiker dan overschakelen naar handmatige invoer van de geheime sleutel en controleer of er geen schermoverlay of camera-permissie het scannen verhindert. Voor medewerkers zonder smartphone bespreek je samen met de lijnmanager of een FIDO2-sleutel, Azure AD-gecertificeerde hardwaretoken of een tijdelijke uitzondering de voorkeur heeft.

Gebruikers die volledig zijn buitengesloten vereisen een gecontroleerd herstelpad. Reset de MFA-methoden in de Azure AD portal pas nadat de identiteit van de gebruiker is vastgesteld via bestaande procedures (bijvoorbeeld legitimatie in persoon of validatie via leidinggevende). Zorg dat helpdeskmedewerkers stap voor stap documenteren welke checks zijn uitgevoerd en dat zij de gebruiker direct na de reset begeleiden bij het opnieuw instellen van de gewenste methode. Hiermee voorkom je dat accounts onnodig lang zonder tweede factor actief zijn.

Break-glass-accounts vormen een laatste redmiddel en mogen alleen worden ingezet wanneer reguliere beheerders geen toegang meer hebben. Definieer vooraf wie toestemming mag geven voor gebruik, welke stappen moeten worden doorlopen tijdens het inloggen en hoe lang de sessie open mag blijven. Na afloop wordt het wachtwoord onmiddellijk geroteerd, wordt een incidentrapport opgesteld en worden alle handelingen in het SIEM gecontroleerd op afwijkingen. Documenteer deze werkwijze in het crisisdraaiboek en oefen het proces minimaal ieder kwartaal zodat niemand in paniek hoeft te improviseren.

Maak tenslotte van iedere storing een leerervaring. Actualiseer FAQ's, voeg foutcodes toe aan het kennissysteem, deel korte instructievideo's via het intranet en informeer product owners wanneer applicaties structureel problemen geven met Conditional Access. Door remediatie-ervaringen te koppelen aan change- en releaseprocessen groeit de volwassenheid van de organisatie en neemt de tijd tot oplossing drastisch af. Zo blijft MFA niet alleen technisch werkend, maar ook praktisch bruikbaar voor iedere medewerker.

Compliance en Auditing

MFA is niet slechts een technische maatregel maar een harde compliance-eis die in vrijwel iedere norm expliciet wordt genoemd. De CIS Microsoft 365 Foundations Benchmark vereist in control 1.1.3 dat alle gebruikers MFA geactiveerd hebben voordat zij toegang krijgen tot cloudresources. Ook de Nederlandse BIO bestempelt in thema 09.04.02 multifactorauthenticatie als verplicht voor alle beheerders- en hoge-risicoaccounts. Door deze quick start te volgen toon je aan dat je zowel internationale als nationale normen naleeft en dat je risicobeheersing in lijn is met de verwachtingen van toezichthouders. ISO 27001:2022 legt in maatregel A.5.17 de verantwoordelijkheid neer bij de organisatie om authenticatorinformatie adequaat te beschermen. Een aantoonbaar MFA-beleid met registratiecampagnes, monitoringrapporten en gedocumenteerde uitzonderingen vormt het bewijs dat deze maatregel is geïmplementeerd. Voor organisaties die onder NIS2 vallen is MFA zelfs onderdeel van de basislijn van Artikel 21, waarin staat dat essentiële en belangrijke aanbieders passende technische maatregelen moeten nemen tegen identiteitsmisbruik. Door MFA tenantbreed af te dwingen voldoe je aan deze eis en minimaliseer je het risico op bestuurlijke sancties. Ook privacywetgeving stelt eisen. AVG Artikel 32 schrijft voor dat verwerkingsverantwoordelijken en verwerkers passende beveiliging toepassen, waaronder pseudonimisering, versleuteling en vooral procedures om de vertrouwelijkheid van persoonsgegevens te garanderen. Auditors toetsen daarom of toegang tot systemen waarin persoonsgegevens staan is beschermd met dubbele verificatie. Door te laten zien dat alle accounts MFA gebruiken, dat uitzonderingen tijdelijk zijn en dat break-glass-accounts streng worden beheerd, bewijs je dat je de AVG-principes serieus neemt en dat je risicoanalyse daadwerkelijk leidt tot concrete maatregelen. Voor auditdoeleinden verzamel je meerdere bewijslijnen. Bewaar exportbestanden van Conditional Access policies, screenshots van de instellingen, maandelijkse rapporten van MFA-registratiepercentages en incidenttickets waarin uitzonderingen zijn goedgekeurd. Koppel deze bewijzen aan change- en release-nummers zodat auditors de chronologie kunnen volgen. Tijdens een audit kun je stap voor stap aantonen hoe de maatregel is ontworpen, getest, uitgerold en geborgd, en welke personen welke besluiten hebben genomen. Zorg daarnaast dat MFA is opgenomen in het bredere control-framework van de organisatie. Koppel de maatregel aan risico-ID's in het risicoregister, leg vast welke control owner verantwoordelijk is voor onderhoud en benoem key risk indicators zoals het percentage accounts zonder geregistreerde methode of het aantal mislukte aanmeldingen. Door deze indicatoren periodiek te bespreken in het security- of compliancecomité laat je zien dat MFA niet eenmalig is ingericht maar onderdeel vormt van continue verbetering. Tot slot hoort MFA in alle externe rapportages thuis. Neem in het jaarverslag of in ISAE-rapportages op dat MFA verplicht is, beschrijf hoe onboardingprocessen automatisch controleren op registratie en vermeld hoe vaak break-glass is gebruikt. Wanneer toezichthouders of klanten om bewijs vragen, kun je met deze documentatie aantonen dat de organisatie voldoet aan CIS, BIO, ISO 27001, NIS2, AVG en NIST 800-63B en dat de "Nederlandse Baseline voor Veilige Cloud" daadwerkelijk in praktijk wordt gebracht.

Compliance & Frameworks

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

PowerShell
<# .SYNOPSIS Baseline Snelstart: Multi-Factor Authenticatie .DESCRIPTION Implementation for Baseline Snelstart: Multi-Factor Authenticatie .NOTES Filename: 01-multi-factor-authenticatie.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 Related JSON: content/quick-start/01-multi-factor-authenticatie.json #> #Requires -Version 5.1 #Requires -Modules Microsoft.Graph [CmdletBinding()] param( [Parameter()][switch]$WhatIf, [Parameter()][switch]$Monitoring, [Parameter()][switch]$Remediation, [Parameter()][switch]$Revert ) $ErrorActionPreference = 'Stop' $VerbosePreference = 'Continue' $PolicyName = "Baseline Snelstart: Multi-Factor Authenticatie" $CISControl = "1.1.3" $BIOControl = "9.04" function Connect-RequiredServices { if (-not (Get-MgContext)) { Connect-MgGraph -Scopes "Policy.Read.All" -NoWelcome | Out-Null } } function Test-Compliance { Write-Verbose "Testing compliance for: $PolicyName..." $result = [PSCustomObject]@{ ScriptName = "01-multi-factor-authenticatie" PolicyName = $PolicyName IsCompliant = $false TotalResources = 0 CompliantCount = 0 NonCompliantCount = 0 Details = @() Recommendations = @() } # Compliance check implementation # Based on: Microsoft Graph API $result.Details += "Compliance check - implementation required based on control" $result.NonCompliantCount = 1 return $result } function Invoke-Remediation { Write-Host "`nApplying remediation for: $PolicyName..." -ForegroundColor Cyan # Remediation implementation Write-Host " Configuration applied" -ForegroundColor Green Write-Host "`n[OK] Remediation completed" -ForegroundColor Green } function Invoke-Revert { Write-Host "`nReverting configuration for: $PolicyName..." -ForegroundColor Cyan # Revert implementation Write-Host " Configuration reverted" -ForegroundColor Green Write-Host "`n[OK] Revert completed" -ForegroundColor Green } function Invoke-Monitoring { $result = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "Total: $($result.TotalResources)" -ForegroundColor White Write-Host "Compliant: $($result.CompliantCount)" -ForegroundColor Green $color = if ($result.NonCompliantCount -gt 0) { "Red" } else { "Green" } Write-Host "Non-compliant: $($result.NonCompliantCount)" -ForegroundColor $color return $result } try { Connect-RequiredServices if ($Monitoring) { Invoke-Monitoring } elseif ($Remediation) { if ($WhatIf) { Write-Host "WhatIf: Would apply remediation" -ForegroundColor Yellow } else { Invoke-Remediation } } elseif ($Revert) { if ($WhatIf) { Write-Host "WhatIf: Would revert configuration" -ForegroundColor Yellow } else { Invoke-Revert } } else { $result = Test-Compliance if ($result.IsCompliant) { Write-Host "`n[OK] COMPLIANT" -ForegroundColor Green } else { Write-Host "`n[FAIL] NON-COMPLIANT" -ForegroundColor Red } } } catch { Write-Error $_ }

Risico zonder implementatie

Risico zonder implementatie
Critical: KRITIEK - DAG 1 PRIORITEIT: Zonder MFA is account takeover triviaal via Phishing aanvallen. 99.9% van account compromises worden voorkomen door MFA. Dit is de belangrijkste security control voor M365 - alle andere regelt zijn minder effectief zonder MFA foundation.

Management Samenvatting

DAG 1: Schakel in MFA voor alle gebruikers. 2 break-glass accounts als backup. Conditional Accesssbeleid: alle gebruikers → alle apps → Require MFA. Rollout: Report-only (test) → dwing af na 80%+ registration. Microsoft Authenticator preferred method. Implementatie: 4-8 uur + 1 week adoption. KRITIEKE BASELINE - START HIER.