MFA verplicht in Microsoft 365 zonder gedoe uitrollen

Bijna elk incident dat we bij nieuwe klanten terugvinden begint hetzelfde: een gebruiker vult zijn wachtwoord in op een nagemaakte inlogpagina, en een dag later gaan er facturen met een gewijzigd rekeningnummer de deur uit. Multifactor authenticatie stopt dat scenario in de meeste gevallen. Toch draait een deel van de MKB-organisaties er nog zonder, of met MFA die alleen "aan staat" voor de mensen die zich vrijwillig hebben aangemeld.

De techniek is niet het probleem. De uitrol is het probleem: gedeelde mailboxen, oude Outlook-clients, de multifunctional die scans mailt, een directeur die op vakantie is. Hieronder de volgorde die bij ons werkt, en de dingen die je beter vóór de uitrol regelt dan erna.

Wat je oplost, en wat niet

MFA beschermt de inlog. Het beschermt niet tegen een gebruiker die zelf een frauduleuze betaling doet, en het stopt een aanvaller niet als die een geldige sessiecookie steelt via een adversary-in-the-middle phishingkit. Dat is geen reden om het niet te doen, wel een reden om er twee dingen bij te zetten: token protection of een compliant-device-eis waar het kan, en een korte instructie voor je financiële mensen over betaalverzoeken.

Inventariseer eerst wat er kapotgaat

De uitrol strandt bijna altijd op accounts die geen mens zijn. Loop deze lijst langs voordat je iets aanzet:

• Servicelaccounts en apparaten: scanners, kopieerapparaten, boekhoudpakketten die via SMTP mailen, backup- en monitoringtools. Zet die om naar een dedicated verzendmethode met een eigen policy-uitzondering op basis van vertrouwd IP-adres, of beter: naar moderne authenticatie met certificaat.
• Gedeelde mailboxen: die horen geen eigen inlog te hebben. Blokkeer sign-in erop en geef mensen delegatie.
• Oude clients: basic authenticatie is bij Exchange Online allang uitgeschakeld, maar er staan nog steeds machines met Office 2013 of een IMAP-client. Die vallen om.
• Externe partijen: de boekhouder of de salarisverwerker met een account in jouw tenant. Informeer ze vooraf, anders bel je alsnog op vrijdagmiddag.

Draai voor die inventarisatie de sign-in logs van de laatste dertig dagen en filter op legacy authenticatie en op clients waar je de naam niet van herkent. Wat je daar ziet, is precies je risicolijst.

Regel je break-glass accounts

Voordat je een policy aanzet die iedereen raakt: maak twee noodaccounts met globale beheerdersrechten, met een lang uniek wachtwoord, uitgesloten van de conditional access policies, en zet er alerting op zodat je een mail krijgt zodra er mee wordt ingelogd. Bewaar de gegevens buiten de tenant, dus niet in de SharePoint van datzelfde bedrijf. Zonder deze stap sluit je jezelf een keer buiten en dan is de enige uitweg een supportcase van meerdere dagen.

Kies je methode voordat gebruikers het zelf doen

Als je niets instelt, kiezen gebruikers massaal sms. Dat is de zwakste optie en de duurste in beheer. Zet in de authenticatiemethoden de Microsoft Authenticator met number matching aan, sms uit of alleen als tijdelijke uitzondering, en overweeg passkeys voor de mensen die vaak op verschillende apparaten werken. Voor medewerkers zonder zakelijke telefoon en zonder bereidheid hun privételefoon te gebruiken: koop een handvol hardware tokens. Die discussie kost anders meer tijd dan de hele uitrol.

Rol uit per groep, niet in één keer

Maak een beveiligingsgroep, begin met IT en een paar meewerkende collega's, en breid uit in blokken van tien tot vijftien mensen. Gebruik conditional access in report-only modus voordat je een policy scherpzet: je ziet dan in de logs precies wie er geraakt zou zijn zonder dat iemand buitengesloten raakt. Een week report-only levert meestal nog twee of drie verrassingen op.

Zet daarna de registratie open met een korte deadline. Twee weken werkt beter dan een maand: bij een maand doet iedereen het in de laatste twee dagen. Stuur een instructie van één A4 met screenshots van de app-installatie en de QR-scan, en plan een inloopmoment van een uur waar mensen langs kunnen komen. Dat uur bespaart tien losse telefoontjes.

Wat er in de praktijk misgaat

De klassiekers, met de oplossing erbij:

• Iemand krijgt een nieuwe telefoon en de app is weg. Regel vooraf hoe je de reset doet, en wie mag bepalen dat de beller echt die persoon is. Telefonisch een MFA-methode resetten zonder identiteitscheck is precies de route die aanvallers gebruiken.
• De meldingen komen niet binnen. Meestal batterijoptimalisatie op Android of uitgezette notificaties. Laat de gebruiker inloggen via de code in de app in plaats van de push.
• Iemand werkt op locatie zonder bereik. De code in de Authenticator werkt offline. Sms niet.
• De hele tent klaagt over "elke keer inloggen". Dat komt bijna altijd door een te korte sessieduur of door beleid dat per applicatie opnieuw vraagt. Laat de standaard sessieduur staan en stuur bij met sign-in frequency alleen op risicovolle acties.

Rond het netjes af

Als iedereen erop zit: schakel de registratieperiode uit, blokkeer legacy authenticatie hard, en zet een policy die MFA eist voor alle beheerdersrollen zonder uitzondering. Controleer daarna maandelijks of er nieuwe accounts zijn aangemaakt die buiten de groep vallen. Dat laatste is precies waar het na een jaar alsnog fout gaat: één nieuwe medewerker die per ongeluk buiten de policy is gezet.

Wil je dit laten uitvoeren of eerst laten uitzoeken wat het bij jouw tenant losmaakt, kijk dan bij Microsoft 365 beheer of security en compliance.