L1 BIO 06.02 ISO A.6.7 CIS 1.32

Azure: MFA Verplicht Stellen Voor Device Registration En Azure AD Join

📅 2025-10-29
•
⏱️ 5 minuten lezen
•
🟢 Should-Have

💼 Management Samenvatting

Het afdwingen van meervoudige authenticatie bij iedere device-registratie in Azure AD sluit een populaire aanvalsketen af waarin gestolen wachtwoorden worden misbruikt om een ogenschijnlijk vertrouwd apparaat binnen de tenant te brengen.

Aanbeveling
Veranker meervoudige authenticatie als harde voorwaarde voor iedere device-registratie of Azure AD Join en beheer de instelling centraal, inclusief periodieke verificatie via script en auditrapportages.
Risico zonder
High
Risk Score
7/10
Implementatie
3u (tech: 1u)
Van toepassing op:
✓ Azure
✓ Azure AD
✓ Device Registration

Wanneer registration policies uitsluitend op een gebruikerswachtwoord steunen, kan een kwaadwillende een eigen apparaat toevoegen, Windows Hello for Business-credentials uitrollen en vervolgens maandenlang bewegingen uitvoeren zonder dat de SOC een afwijking ziet. Door MFA als harde toegangspoort te positioneren, wordt iedere poging om een device te koppelen gekoppeld aan een sterke verificatie-evenement, waardoor phishing, password-spray en token replay geen opstapje meer vormen naar een vertrouwde device-identiteit, en Nederlandse overheidsorganisaties aantoonbaar voldoen aan BIO-paragraaf 06.02 over beheerste mobile device-aanmelding.

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

Implementatie

De maatregel vereist dat in de Azure AD device settings de optie "Require multifactor authentication to register or join devices" permanent op "Yes" staat en dat dit beleid wordt ondersteund door geregistreerde MFA-methoden, geactualiseerde enrollmentprocedures en geautomatiseerde controles. Dit raakt Azure AD Join voor beheerde werkplekken, Azure AD Registration voor BYOD en hybride join-scenario's, en zorgt ervoor dat een apparaat pas een primaire sleutel ontvangt nadat de eigenaar met een tweede factor is gevalideerd.

Vereisten

Een robuuste invoering van MFA bij device-registratie begint met een nauwkeurige inventarisatie van het apparaatlandschap binnen de organisatie. Functioneel beheer moet onderscheid maken tussen volledig beheerde werkplekken, speciale beheerstations, mobiele toestellen voor veldwerkers en BYOD-varianten, omdat elk profiel andere join-paden en authenticatiemethoden kent. De inventarisaties uit de Nederlandse Baseline voor Veilige Cloud vormen de basis: zonder inzicht in bestaande Windows Autopilot-profielen, Intune-inschrijvingsmethoden en lokale AD-joinprocessen is het onmogelijk om te voorspellen welke gebruikers de maatregel het eerst raakt of welke uitzonderingen tijdelijk nodig zijn. Daarnaast is licentie- en identiteitsvoorbereiding essentieel. Azure AD Premium P1-functies zijn vereist om conditionele toegang en registratiecampagnes af te dwingen, en iedere gebruiker die een apparaat mag koppelen moet minimaal twee MFA-methoden geregistreerd hebben zodat een kapotte telefoon geen blokkade vormt. Dit betekent dat self-service registratieportalen, authenticator-app distributie en FIDO2-beheer op orde moeten zijn, inclusief het opnemen van externe leveranciersaccounts en gastidentiteiten die incidenteel beheerwerk verrichten binnen de tenant. Governance- en procesafspraken moeten vóór activering worden vastgelegd. Change- en releasekalenders horen een onderhoudsvenster te reserveren voor de omschakeling, inclusief voorafgaande goedkeuring van de CISO en de functioneel beheerder die verantwoordelijk is voor de device settings in Azure AD. Documenteer welke rollen het beleid mogen wijzigen, hoe audit-logging wordt bewaakt en welke fallback geldt wanneer een ketenpartner onverwacht wordt geblokkeerd, bijvoorbeeld door tijdelijk een geregistreerde administrator in te zetten om de join namens de partner uit te voeren. Ook de ondersteunende organisatiestructuur moet klaar zijn. De servicedesk dient scripts voor eerste- en tweedelijnsdiagnostiek paraat te hebben, inclusief herkenbare foutcodes, een stappenplan om gebruikers via de Microsoft Authenticator opnieuw te koppelen en instructies voor medewerkers die alleen een sms-methode gebruiken. Helpdeskmedewerkers moeten een simulatie hebben doorlopen waarin ze een apparaat registreren en een MFA-mislukking behandelen, zodat ze tijdens de daadwerkelijke uitrol niet hoeven te improviseren en wachtrijen voorkomen worden. Tot slot vraagt deze control om actuele documentatie en testvoorzieningen. Er moet een representatieve testtenant of minstens een afgeschermde pilotgroep bestaan waarin nieuwe Windows-builds, mobiele enrollmentprofielen en hybride join-scripts worden getest met MFA ingeschakeld. De documentatie in het device enrollment-handboek moet stap voor stap beschrijven hoe gebruikers worden geïnformeerd, welke eisen gelden voor netwerkverbindingen (bijvoorbeeld toegang tot pushnotificatiediensten) en hoe bewijsstukken voor audits worden opgeslagen. Zonder deze basisvoorwaarden kan de implementatie wel technisch slagen maar organisatorisch alsnog spaak lopen. Verder moeten beveiligings- en privacyteams vooraf bepalen welke gegevenscategorieën op de apparaten worden verwerkt en welke wettelijke eisen daardoor gelden. Wanneer gevoelige strafrechtelijke of gezondheidsgegevens op tablets worden ingevoerd, is het noodzakelijk dat het DPIA-register beschrijft hoe een MFA-gedwongen device-registratie bijdraagt aan het beperken van datalekken. Betrek ook leveranciers die apparatuur namens de organisatie voorbereiden: zij moeten aantonen dat hun staging-omgevingen MFA ondersteunen en dat apparaten pas worden geleverd nadat de organisatie de uiteindelijke join uitvoert. Door deze ketenafspraken contractueel vast te leggen ontstaat er geen grijs gebied waarin een slecht beveiligd stagingapparaat alsnog als vertrouwd endpoint wordt toegevoegd. Voer bovendien een risicoanalyse per directie of dienst uit om te bepalen welke bedrijfsprocessen bij een foutieve device-registratie zouden stilvallen. Gebruik de uitkomsten om extra voorzorgsmaatregelen (bijvoorbeeld dedicated enrollmentlijnen voor noodhulpdiensten) te rechtvaardigen en om bestuurders te laten zien dat de vereiste randvoorwaarden budgettair én organisatorisch zijn geborgd.

Implementatie

Gebruik PowerShell-script mfa-required-device-join.ps1 (functie Invoke-Implementation) – Implementeren.

De implementatie start met het vaststellen van de scope en het synchroniseren van alle betrokken teams. Werkplekkenbeheer, het Azure-identityteam, het SOC en communicatie plannen gezamenlijk het omschakelmoment om te voorkomen dat er tijdens een migratie of Windows-release extra variabelen ontstaan. Leg vast welke directorytenants, managementgroepen en device settings worden geraakt, en voer een configuration snapshot uit zodat bij een rollback precies kan worden aangetoond welke waarde eerder gold. Koppel hieraan een risk assessment waarin de impact op speciale doelgroepen, zoals laboratoriumsystemen of werkstations op beveiligde netwerken, expliciet wordt benoemd. Vervolgens wordt de technische wijziging bij voorkeur via het PowerShell-script code/azure/identity-access/mfa-required-device-join.ps1 uitgevoerd. Het script kan in dezelfde change worden gebruikt voor configuratie, monitoring en remediatie en ondersteunt het verstrekken van managementbewijzen doordat iedere run automatisch logging naar een centraal opslagaccount kan sturen. Voordat het script in productie draait, moet het team lokaal testen met -WhatIf en de vereiste Microsoft Graph-modules in de debug-omgeving laden. Ook hoort er een geheimbeheerbeleid te zijn voor de service-principal of het account dat de Graph-verbinding maakt. Na de configuratie volgt een gecontroleerde pilot. Kies een mix van devices (Windows 11, Surface, ruggedized tablets) en scenario's (Autopilot user-driven, self-service registratie, hybride join) en laat gebruikers de volledige enrollment doorlopen. Documenteer exacte tijdlijnen, aanmeldschermen en MFA-prompts zodat latere regressies sneller te herleiden zijn. Controleer in Azure AD audit logs dat de wijziging "Device settings updated" zichtbaar is en sla een export van het configuratiescherm als bewijslast op. Wanneer afwijkingen optreden, bijvoorbeeld doordat een legacy imagingproces nog op de oude waarde vertrouwde, moet de pilotgroep kunnen terugvallen op een vooraf beschreven workaround. Communicatie en verandermanagement vormen de volgende stap. Gebruikers ontvangen minimaal twee weken vooraf informatie via intranetartikelen, e-mailcampagnes en eventueel pushberichten vanuit het servicedeskportaal. De berichten leggen uit waarom MFA bij device-registratie noodzakelijk is, welke authenticatiemethoden zijn toegestaan en hoe men ondersteuning kan aanvragen. Voeg korte instructievideo's of stappenkaarten toe waarin zowel de Windows-ervaring als de registratie vanaf een mobiel toestel wordt getoond. Voor leidinggevenden en onboardingteams horen aparte sessies plaats te vinden waarin zij leren hoe zij nieuwe medewerkers begeleiden. Na de livegang blijft het projectteam de eerste veertien dagen in een verhoogde waakstand. Elke melding van een mislukte enrollment wordt gecategoriseerd op oorzaak (gebruikersfout, netwerk, registratiecapaciteit) en vergeleken met de verwachtingen uit het implementatieplan. Het team valideert dagelijks of de Graph-instellingen ongewijzigd zijn, en legt resultaten vast in het configuratieregister van de Nederlandse Baseline voor Veilige Cloud. Pas nadat de stabilisatieperiode zonder kritieke incidenten is afgerond, wordt de wijziging formeel overgedragen aan beheer en wordt het runbook voor reguliere onderhoudscycli bijgewerkt. Een succesvolle implementatie vereist bovendien een terugvalscenario waarin de instelling tijdelijk kan worden versoepeld zonder het beleid uit te schakelen. Documenteer hoe een emergency break-glass-account, beschermd met FIDO2 en Conditional Access, kan worden ingezet om een kritieke productie- of zorgomgeving te ontlasten terwijl het securityteam de oorzaak onderzoekt. Door deze afspraken vooraf te testen tijdens een game day blijft de bedrijfscontinuïteit geborgd, zelfs wanneer een onverwacht certificaat- of netwerkprobleem tijdens de uitrol optreedt. Sluit het project af met een formele evaluatie waarin lessons learned, resterende risico's en optimalisaties voor toekomstige device-initiatieven worden vastgelegd. Gebruik deze evaluatie om de backlog van beveiligingsverbeteringen te actualiseren en om bestuurders een duidelijke kosten-batenanalyse te bieden.

Compliance en Auditing

Het verplicht stellen van MFA voor device-registratie is niet alleen een technische best practice maar ook een compliance-eis die direct bijdraagt aan de aantoonbaarheid van maatregelen in audits. Door het beleid te verankeren in de Nederlandse Baseline voor Veilige Cloud en de besluitvorming vast te leggen in het CISO-dossier kan de organisatie aantonen dat er een vastgesteld afwijkingsproces bestaat, inclusief de lijst met scenario's waarin een tijdelijke uitzondering nodig is. Elke uitzondering moet een einddatum hebben en gekoppeld worden aan compenserende controles, bijvoorbeeld het blokkeren van device-registratie voor een specifieke groep totdat hun identiteitsmiddelen zijn vernieuwd. CIS Azure Benchmark v3.0.0 control 1.32 stelt expliciet dat MFA verplicht moet zijn voor het registreren en joinen van apparaten. Deze control wordt door veel auditors gebruikt als uitgangspunt voor cloudassessments, waardoor een aantoonbare configuratie cruciaal is. Bewaar daarom exports van de Azure Portal device settings, Graph-configuratie en het uitvoerresultaat van het script mfa-required-device-join.ps1. Voeg eraan toe welke change- en release-notities zijn goedgekeurd, zodat duidelijk is dat de instelling niet toevallig maar bewust is geactiveerd. Binnen de Baseline Informatiebeveiliging Overheid (BIO) sluit de maatregel aan op paragraaf 06.02 over mobiel apparaatbeheer en op de BIO-uitwerking van toegangsbeveiliging. De vertaling naar ISO 27001:2022 raakt controls A.6.7 en A.8.1, waarin wordt geëist dat mobiele apparatuur en assets onderworpen worden aan passende beveiligingsmaatregelen en formele eigendomsregistratie. Door MFA te eisen tijdens device-registratie wordt de identiteit van de eigenaar gekoppeld aan het apparaatrecord, waardoor de organisatie kan aantonen dat het eigendom en de verantwoordelijkheid traceerbaar zijn. Voor Europese zorgplichten onder NIS2, en specifiek artikel 21, geldt dat essentiële en belangrijke entiteiten organisatorische en technische maatregelen moeten nemen om risico's voor netwerk- en informatiesystemen te beheren. Het bundelen van device onboarding met sterke authenticatie bewijst dat er een geïntegreerde identiteits- en toegangscontrole bestaat voor werkplekken, iets wat toezichthouders nadrukkelijk toetsen. Documenteer in het NIS2-register welke processen afhankelijk zijn van vertrouwde apparaten, hoe traceerbaarheid wordt gerealiseerd en welke metrics (zoals het percentage succesvolle MFA-prompt bij device-join) als Key Control Indicator worden gemonitord. Auditors verwachten concrete bewijsstukken in drie categorieën: beleidsdocumenten, configuratiebewijzen en operationele logging. Zorg dat het beleidsdocument beschrijft wanneer MFA vereist is, wie het mag aanpassen en hoe vaak de instelling wordt herbevestigd. Bewaar daarnaast screenshots, Graph-exports en output van het deployment-script in een onveranderbaar archief met een bewaartermijn van zeven jaar. Voor operationele logging zijn Azure AD audit logs en Intune enrollmentrapportages noodzakelijk; ze moeten aantonen dat elke registratie een MFA-claim bevat en dat afwijkingen worden onderzocht. Door deze documentatie gestructureerd te beheren kan de organisatie tijdens een audit binnen enkele minuten laten zien dat de control effectief, herhaalbaar en duurzaam is ingericht. Controleer tenslotte dat de bewaartermijnen van alle bewijsstukken aansluiten op wettelijke verplichtingen. Voor veel overheidsorganisaties geldt een archiefplicht van minimaal zeven jaar, maar voor kritieke infrastructuur of strafrechtelijke gegevens kan een langere termijn noodzakelijk zijn. Leg vast wie verantwoordelijk is voor het periodiek toetsen van de effectiviteit (bijvoorbeeld via een jaarlijkse interne audit) en hoe bevindingen worden opgevolgd binnen het ISMS. Daarmee ontstaat een gesloten PDCA-cyclus die auditteams overtuigt dat de maatregel niet alleen is ingevoerd, maar ook duurzaam geborgd wordt.

Monitoring

Gebruik PowerShell-script mfa-required-device-join.ps1 (functie Invoke-Monitoring) – Controleren.

Monitoring van deze control begint met het vastleggen van welke signalen aantonen dat MFA tijdens device-registratie daadwerkelijk plaatsvindt. Azure AD audit logs registreren events zoals "Device registration" en "Join type" met detailvelden waarin de MFA-status staat vermeld; deze gegevens moeten dagelijks naar een centraal SIEM of Microsoft Sentinel workspace worden gestuurd. Koppel de logging aan het assetregister zodat duidelijk is welk apparaat bij welke dienst hoort en of het enrollmentbeleid overeenkomt met de beleidsdocumentatie. Het PowerShell-script mfa-required-device-join.ps1 bevat de functie Invoke-Monitoring, die periodiek via een automation account of Azure Function kan draaien. De functie leest de Graph-instelling uit, vergelijkt deze met de gewenste waarde en schrijft resultaten weg naar een configuration management database. Combineer dit met een geplande runbook-taak die een notificatie naar Teams of e-mail stuurt wanneer de instelling onverwacht wordt gewijzigd, zodat beheer realtime inzicht behoudt in configuratiedrift. Naast configuratievalidatie moeten operationele indicatoren worden gevolgd. Maak in Sentinel een workbook dat per dag toont hoeveel device-registraties zijn gelukt, hoeveel daarvan een MFA-claim bevatten en welke gebruikers meerdere mislukte pogingen achter elkaar veroorzaken. Verrijk de gegevens met Conditional Access-signalen zodat zichtbaar wordt of uitzonderingsbeleid wordt misbruikt. Door de data te segmenteren naar businessunit of locatie kunnen beleidsmakers zien of bepaalde onderdelen structureel achterblijven. Definieer daarnaast detecties voor risicovolle patronen, zoals een plotselinge toename van registratiepogingen vanaf IP-adressen buiten Nederland of apparaten die tijdens kantooruren massaal worden toegevoegd maar nooit in Intune verschijnen. Koppel de detecties aan playbooks die automatisch een account blokkeren of een serviceticket aanmaken. Voor high-impact meldingen hoort het SOC een forensische analyse uit te voeren waarbij het device-object, de bijbehorende gebruiker en de MFA-bevestiging worden gecontroleerd. Tot slot moet monitoring gericht zijn op continue verbetering. Stel kwartaaldoelen vast, zoals een maximaal aandeel foutieve registratiepogingen of een vereiste dekking van 100 procent MFA bij join-events, en bespreek deze in het overleg tussen CISO, werkplekbeheer en servicemanagement. Documenteer lessons learned en verwerk ze in het runbook, bijvoorbeeld door nieuwe foutcodes toe te voegen of een geautomatiseerde selfservice-flow te bouwen voor het resetten van authenticatiemethoden. Zo blijft de control volwassen en aantoonbaar effectief. Naast technische signalen is gebruikerservaring een belangrijke indicator. Volg de wachttijden bij de servicedesk, het aantal gebruikers dat extra hulp vraagt bij het aanmelden en de gemiddelde duur van een complete enrollment. Door deze gegevens te spiegelen aan de technische logboeken ontstaat er een compleet beeld en kan worden vastgesteld of aanvullende training of communicatie nodig is. Neem de resultaten op in het maandelijkse kwaliteitsrapport zodat ook het bestuur ziet dat de maatregel niet onnodig frictie veroorzaakt. Plan ten minste twee keer per jaar een continuïteitstest waarbij bewust wordt gesimuleerd dat een configuratie wordt gewijzigd of dat de Graph-verbinding faalt. Tijdens zo'n test wordt geverifieerd of het monitoring-runbook de juiste escalatieroute activeert, of alerting daadwerkelijk binnen de afgesproken responstijd plaatsvindt en of fallback-mechanismen (zoals het blokkeren van joinrechten) tijdig in werking treden. De lessons learned uit deze oefeningen worden verwerkt in tooling, dashboards en opleidingen, waardoor de control beter bestand is tegen zowel menselijke fouten als kwaadwillende insiders.

Remediatie

Gebruik PowerShell-script mfa-required-device-join.ps1 (functie Invoke-Remediation) – Herstellen.

Remediatie start zodra monitoring aangeeft dat het beleid is uitgeschakeld of dat er apparaten zonder MFA-claim zijn geregistreerd. Classificeer incidenten op ernst: een kortdurende configuratieafwijking vraagt een andere aanpak dan een daadwerkelijk ingeschreven rogue device. Breng onmiddellijk in kaart welke gebruikers, apparaten en beheerders betrokken waren bij het tijdsvenster waarin de control niet werkte, en blokkeer desnoods device join-rechten door een Conditional Access-beleid dat alleen beheerders toestaat om nieuwe apparaten toe te voegen totdat de oorzaak is opgelost. Gebruik daarna de functie Invoke-Remediation in het script mfa-required-device-join.ps1. Deze functie zet de configuratie terug naar de gewenste waarde, legt een auditrecord vast en kan optioneel een change-verzoek aanmaken via een webhook. Voer het script uit vanaf een beheerwerkstation dat onder lokale debugvoorwaarden draait, zodat PowerShell-modules en certificaten gecontroleerd zijn. Documenteer de exacte parameters, de gebruikte identiteit en de output van het script zodat forensische onderzoekers kunnen bevestigen dat de configuratie is hersteld. Wanneer er apparaten zijn toegevoegd zonder MFA-claim, moeten deze objecten worden gelabeld en onderzocht. Verwijder het device uit Azure AD, trek de primaire refresh token in en forceer een herregistratie waarbij de gebruiker expliciet wordt begeleid. Informeer de eigenaar waarom het apparaat is afgekeurd en bied hulp bij het opnieuw registreren van MFA-middelen. Als blijkt dat een aanvaller misbruik heeft gemaakt van gestolen credentials, volg dan het standaard incidentresponsplan: reset wachtwoorden, onderzoek laterale beweging en raadpleeg logbestanden uit Defender for Endpoint om te bepalen of het apparaat aanvullende malware heeft ontvangen. Elke remediatie-actie moet worden vastgelegd in het BIO-controlelogboek en in het NIS2-verplichte incidentregister. Beschrijf de oorzaak, de getroffen systemen, de getroffen gebruikers en de doorgevoerde compenserende maatregelen. Voeg bewijsmateriaal toe, zoals screenshots van de herstelde instelling, exportbestanden van verwijderd device-objecten en helpdesktickets die aantonen dat gebruikers opnieuw MFA hebben geconfigureerd. Deze documentatie ondersteunt audits en voorkomt dat dezelfde fout zich onopgemerkt herhaalt. Tot slot wordt een post-incidentreview uitgevoerd. Analyseer of het monitoringmechanisme te laat alarmeerde, of changeprocedures onvoldoende waarborgen boden, en of aanvullende technische maatregelen (bijvoorbeeld een Azure Policy die het joinen zonder MFA verhindert) nodig zijn. Pas waar nodig het runbook, de communicatiesjablonen en de training van beheerders aan. Door iedere remediatiecyclus te gebruiken als bron voor structurele verbeteringen blijft de Nederlandse Baseline voor Veilige Cloud een levend document dat organisaties helpt dreigingen voor te blijven. Wanneer het incident meldingsplichtig is onder de AVG of NIS2, moet het securityteam binnen 72 uur de toezichthouder informeren. Beschrijf in het remediatieplan hoe de benodigde feiten (tijdstip, aard van de storing, getroffen gegevens) worden verzameld en hoe juridische en communicatie-experts betrokken worden. Combineer dit met een follow-uprapportage richting bestuur en ketenpartners, zodat zij weten welke maatregelen zijn genomen en welke aanvullende acties zij eventueel moeten uitvoeren. Meet na iedere remediatie in welke mate gebruikers of processen hinder hebben ondervonden en leg deze impact vast als KPI. Wanneer meer dan een afgesproken drempelwaarde aan activiteiten is geraakt, activeer dan een verbetertraject waarin aanvullende automatisering of training wordt opgenomen. Zo blijft de organisatie leren van incidenten en wordt de responstijd aantoonbaar korter.

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
<# ================================================================================ AZURE POWERSHELL SCRIPT - Nederlandse Baseline voor Veilige Cloud ================================================================================ .SYNOPSIS MFA Required Device Join .DESCRIPTION CIS Azure Foundations Benchmark - Control 1.31 Controleert dat MFA is vereist voor device join. .NOTES Filename: mfa-required-device-join.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 1.31 #> #Requires -Version 5.1 #Requires -Modules Az.Accounts [CmdletBinding()] param([Parameter()][switch]$Monitoring) $ErrorActionPreference = 'Stop' $PolicyName = "MFA Required Device Join" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null } } try { Connect-RequiredServices if ($Monitoring) { Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "⚠️ Manual verification required" -ForegroundColor Yellow Write-Host "Controleer in Entra ID portal:" -ForegroundColor Gray Write-Host " - Azure AD > Devices > Device settings" -ForegroundColor Gray Write-Host " - Require MFA to join devices = Yes" -ForegroundColor Gray Write-Host " - Voorkomt ongeautoriseerde device registratie" -ForegroundColor Gray } else { Write-Host "`n⚠️ Manual verification: MFA for device join" -ForegroundColor Yellow } } catch { Write-Error $_; exit 1 } # ================================================================================ # Standaard Invoke-* Functions (Auto-generated) # ================================================================================ function Invoke-Implementation { <# .SYNOPSIS Implementeert de configuratie #> [CmdletBinding()] param() Invoke-Remediation } function Invoke-Monitoring { <# .SYNOPSIS Controleert de huidige configuratie status #> [CmdletBinding()] param() $Monitoring = $true try { Connect-RequiredServices if ($Monitoring) { Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "⚠️ Manual verification required" -ForegroundColor Yellow Write-Host "Controleer in Entra ID portal:" -ForegroundColor Gray Write-Host " - Azure AD > Devices > Device settings" -ForegroundColor Gray Write-Host " - Require MFA to join devices = Yes" -ForegroundColor Gray Write-Host " - Voorkomt ongeautoriseerde device registratie" -ForegroundColor Gray } else { Write-Host "`n⚠️ Manual verification: MFA for device join" -ForegroundColor Yellow } } catch { Write-Error $_; exit 1 } } function Invoke-Remediation { <# .SYNOPSIS Herstelt de configuratie naar de gewenste staat .DESCRIPTION Dit is een monitoring-only control, remediation delegeert naar monitoring #> [CmdletBinding()] param() Write-Host "[INFO] Dit is een monitoring-only control" -ForegroundColor Yellow Write-Host "[INFO] Running monitoring check..." -ForegroundColor Cyan Invoke-Monitoring }

Risico zonder implementatie

Risico zonder implementatie
High: Zonder deze control kan een aanvaller met een buitgemaakt wachtwoord een eigen apparaat koppelen, langdurige tokens verkrijgen en als vertrouwd endpoint deelnemen aan netwerkverbindingen, waardoor wachtwoordresets, compliance-eisen uit CIS 1.32 en BIO 06.02 en forensische controles worden ondergraven.

Management Samenvatting

Schakel in Azure AD → Devices → Device settings de optie "Require multifactor authentication to register or join devices" in, ondersteun dit met geregistreerde MFA-methoden en monitor via het script mfa-required-device-join.ps1 dat de instelling actief blijft; zo wordt device-based persistence effectief geblokkeerd.