Op 6 juli 2026 breidt Entra ID Conditional Access uit naar Windows Hello for Business-inschrijving en macOS Platform SSO-registratie. Beleidsvereisten zoals vertrouwde locaties en authenticatiesterkte gelden dan ook tijdens apparaatregistratie — niet alleen bij het dagelijks inloggen. Welke beleidsregels moet u controleren en wat kunt u deze week nog doen?
In de week van 6 juli 2026 rolt Microsoft een beveiligingswijziging uit in Entra ID die directe gevolgen heeft voor organisaties die Windows Hello for Business of macOS Platform SSO gebruiken. Conditional Access-beleidsregels die de actie Beveiligingsgegevens registreren targeten, worden vanaf dat moment ook geëvalueerd tijdens de inschrijving van Windows Hello for Business-referenties en de registratie van macOS Platform SSO. Wie zijn CA-beleidsregels niet controleert, riskeert dat gebruikers hun apparaatregistratie niet meer kunnen voltooien.
De wijziging is een doelbewuste stap van Microsoft richting consistenter identiteitsbeleid. Tot op heden gold er een vereenvoudigde beoordeling tijdens registratieflows: MFA werd afgedwongen, maar de Grant-controls van het toepasselijke Conditional Access-beleid werden niet geëvalueerd. Met de update sluit Microsoft dat gat.
Windows Hello for Business is een phishingbestendige authenticatiemethode die is ingebouwd in Windows 10 en Windows 11. Bij de eerste keer inloggen op een apparaat dat beheerd wordt via Intune of via een Entra ID-join doorloopt een gebruiker een provisioningflow: er wordt een apparaatgebonden cryptografische sleutel aangemaakt in de TPM-chip en gekoppeld aan een biometrisch profiel of pincode. Die sleutel werkt alleen op dat specifieke apparaat, en de private key verlaat het apparaat nooit.
Tijdens die provisioningflow controleerde Entra ID tot nu toe of de gebruiker correct authenticeerde — MFA was verplicht — maar werden de Grant-controls van eventuele Conditional Access-beleidsregels die de actie Beveiligingsgegevens registreren targeten, niet geëvalueerd. Vereisten als een Compliant Device, een vertrouwde netwerklocatie of een specifieke authenticatiemethode waren op het inschrijfmoment dus niet van toepassing, ook al golden ze bij regulier inloggen.
Vanaf de week van 6 juli worden de Grant-controls van Conditional Access-beleid dat de actie Beveiligingsgegevens registreren target, ook geëvalueerd bij Windows Hello for Business-provisioning en macOS Platform SSO-registratie. In de praktijk betekent dit: als uw beleid vereist dat registratie alleen plaatsvindt op een vertrouwde locatie, dan kan een medewerker die thuis zijn nieuwe laptop inschrijft, de Windows Hello for Business-provisioning niet voltooien — tenzij zijn thuisnetwerk is aangemerkt als vertrouwde Named Location.
Ditzelfde geldt voor authenticatiesterkte. Als uw beleid een specifieke authenticatiemethode als Grant-control vereist, dan moet de gebruiker op dat moment over die methode beschikken. Voor organisaties die phishingbestendige MFA als eis stellen, betekent dit dat de gebruiker al over een phishingbestendige methode moet beschikken vóórdat hij Windows Hello for Business kan inschrijven — wat een circulaire afhankelijkheid creëert als WHfB zelf de phishingbestendige methode is die u wilt uitrollen.
Niet elke organisatie heeft actie nodig. De wijziging raakt alleen organisaties met Conditional Access-beleidsregels die expliciet de actie Beveiligingsgegevens registreren targeten met Grant-controls. Als er geen dergelijk beleid bestaat — wat het geval is in veel basisconfiguraties — verandert er niets en hoeft u niets te doen.
De organisaties die wél zo'n beleid hebben, moeten twee scenario's controleren. Ten eerste, beleid met locatiebeperkingen: als registratie wordt beperkt tot vertrouwde locaties of Compliant Devices, dan kan dit nieuwe medewerkers blokkeren die hun eerste apparaat inschrijven vanuit een locatie die nog niet als vertrouwd is geconfigureerd. Ten tweede, beleid met authenticatievereisten die een circulaire afhankelijkheid creëren: als u Windows Hello for Business wilt gebruiken als phishingbestendige methode maar u vereist al een phishingbestendige methode voor de registratiestap zelf, dan kan de gebruiker de initiële inschrijving nooit voltooien.
Naast Windows Hello for Business geldt dezelfde wijziging voor macOS Platform SSO-registratie. macOS Platform SSO koppelt een macOS-apparaat aan een Entra ID-identiteit via een apparaatgebonden referentie die is opgeslagen in de Secure Enclave van de Mac. De inschrijving verloopt via de macOS Setup Assistant of via een beheerde onboarding-flow in Intune of een andere MDM-oplossing.
Voor organisaties met een gemengd apparatenpark — Windows en macOS naast elkaar — geldt dat beide platformen nu dezelfde CA-evaluatie doorlopen bij registratie. Dit vereenvoudigt het beleid op de lange termijn, maar vraagt nu aandacht om te controleren of de bestaande beleidsregels de inschrijving op beide platformen niet onbedoeld blokkeren.
Stap 1: identificeer de relevante beleidsregels. Open het Entra-portaal via entra.microsoft.com, navigeer naar Beveiliging > Conditional Access, en filter op beleidsregels die de actie Beveiligingsgegevens registreren targeten. Als er geen beleid is dat deze actie target, hoeft u niets te doen.
Stap 2: beoordeel de Grant-controls per gevonden beleid. Stel uzelf de vraag: kan een nieuwe medewerker die zijn eerste apparaat inschrijft, op dat moment aan alle Grant-controls voldoen? Denk daarbij aan iemand die thuis werkt, op een onbekend netwerk zit of nog geen phishingbestendige methode heeft ingesteld. Als het antwoord nee is, overweeg dan of de Grant-controls moeten worden aangepast of dat er een uitzondering nodig is voor de initiële inschrijving.
Stap 3: test via report-only-modus. Zet het beleid tijdelijk in report-only, voer een testregistratie uit via een testgebruiker en controleer de aanmeldingslogboeken in het Entra-portaal. U ziet precies welke Grant-controls zouden worden afgedwongen en of er een blokkering zou optreden. Dit kost minder dan dertig minuten en neemt de onzekerheid volledig weg voordat de wijziging van kracht wordt.
De uitrol vindt plaats in de week van 6 tot 13 juli 2026. Dat geeft IT-teams nog een korte window om actie te ondernemen. Drie prioriteiten voor de komende dagen: audit uw CA-beleidsregels op de actie Beveiligingsgegevens registreren, beoordeel of onboarding-scenario's voor nieuwe medewerkers nog steeds werken onder de Grant-controls van uw beleid, en overweeg een Named Location voor nieuw apparaatregistratie als uw beleid locatiebeperkingen bevat.
Als uw onboarding-flow vereist dat medewerkers thuis Windows Hello for Business inschrijven en uw beleid beperkt registratie tot vertrouwde locaties, dan zijn er twee oplossingen: thuisnetwerken toevoegen als Named Location, of een afzonderlijk registratiebeleid zonder locatiebeperking configureren dat alleen van toepassing is op de eerste inschrijving. Microsoft raadt aan om dit scenario in report-only te testen vóór 6 juli, zodat u met zekerheid weet wat er verandert in uw specifieke configuratie.
De wijziging op 6 juli sluit een reëel beveiligingsgat: de inschrijving van phishingbestendige authenticatiemethoden was tot op heden niet onderworpen aan dezelfde CA-eisen als het dagelijks inloggen. Dat is nu anders. Voor IT-teams is de vereiste actie beperkt maar tijdgevoelig. Wilt u uw Conditional Access-configuratie laten doorlichten of hulp bij het inrichten van phishingbestendige authenticatie voor uw apparatenpark? Neem contact op met Zarioh voor een vrijblijvend gesprek.
Was dit artikel nuttig?
Ontvang nieuwe artikelen direct in je inbox.
Geen spam. Afmelden kan altijd.
