Voorkom deze 7 fouten in Microsoft Entra ID (en wat je wel moet doen)
Leestijd 5 minuten Gepubliceerd: 05 december 2025
Blog
Azure
Security & Compliance
7 fouten in Microsoft Entra ID om te vermijden
Gelekte inloggegevens zijn nog steeds de nummer 1 ingang voor aanvallers op dit moment. Dat laat zien hoe belangrijk een goede Entra ID-configuratie is.
We hebben zeven veelvoorkomende Entra ID-fouten verzameld, met tips en aanpakken zodat je ze in je eigen tenant kunt vermijden.
Fout #1: Sign-in risk en risiconiveaus in Conditional Access verkeerd begrijpen/configureren
De eerste fout is dat veel mensen verkeerd inschatten hoe Conditional Access moet werken.
Ga in het protection-gedeelte naar Conditional Access → Policies en filter op risk om policies te zien die aan risicogebeurtenissen gekoppeld zijn. Onder Sign-in risk zie je vinkjes voor High, Medium en Low (zie afbeelding).
Op het eerste gezicht denk je misschien dat deze opties “groter dan of gelijk aan” betekenen. Bijvoorbeeld: als je Low selecteert, ga je er misschien van uit dat Medium en High ook meekomen.
Dat klopt niet. Deze vinkjes betekenen “gelijk aan”, niet “groter dan of gelijk aan”. Als je Low selecteert, geldt de policy alleen voor low-risk sign-ins.
Een gerelateerde fout ontstaat als je user risk en sign-in risk in één policy combineert. In dat geval moeten beide condities waar zijn voordat de policy ingrijpt. Maak daarom aparte policies voor user risk en sign-in risk. Zo kunnen beide triggers onafhankelijk werken en werkt je bescherming zoals bedoeld.
Fout #2: Problemen met passwordless authenticatie
Veel admins maken een Conditional Access-policy voor high-risk users en zetten onder Grant de optie Wachtwoord wijzigen aan. Dat klinkt logisch, maar het dwingt een wachtwoordwijziging af en voegt een extra laag die passwordless gebruikers in de weg zit.
Wat er gebeurt: als je een passwordless user als gecompromitteerd markeert, krijgt die de status “high risk”. Bij de volgende aanmelding wordt een wachtwoordwijziging afgedwongen — maar die gebruiker heeft geen traditioneel wachtwoord. Resultaat: een doodlopende weg.
Oplossingen:
- Blokkeer authenticatie: In plaats van een wachtwoordwijziging te eisen, kun je authenticatie blokkeren voor high-risk gebruikers. Dat geeft een duidelijker signaal en voorkomt verwarring.
- Sluit passwordless users uit: Sluit passwordless accounts uit van policies die een wachtwoordwijziging vereisen. Zo behandel je wachtwoord- en passwordless gebruikers verschillend en voorkom je blokkades.
Fout #3: De “one-size-fits-all” gedachte
Gebruik niet dezelfde policies voor alle gebruikers. Maak custom policies. Administrators en VIPs hebben andere risico's dan gewone gebruikers en vragen vaak strengere regels.
Voorbeeld:
- Maak één policy voor admins en VIPs — bijvoorbeeld strenger optreden en blokkeren bij medium of zelfs low user risk.
- Maak aparte policies voor algemene gebruikers — bijvoorbeeld blokkeren pas bij high risk.
Rol Identity Protection gefaseerd uit: begin met pilotgebruikers, bouw vertrouwen op, voorkom een stortvloed aan false positives en verhoog de dekking later.
Security E-book
Leer hoe je je Azure omgeving kunt beveiligen met verschillende technologieën, tools en best practices die we dagelijks toepassen bij onze softwaregedreven klanten.
Download nu!Fout #4: Gastgebruikers uitsluiten van bescherming
Sluit gasten niet automatisch uit van Entra ID Protection. Gastgebruikers loggen vaak in vanaf apparaten die je niet beheert, wat de beveiligingsrisico’s verhoogt.
Veel mensen denken: “Ik heb geen controle over gastidentiteiten, dus ik kan hun risico niet beoordelen. Ik wil ze ook niet buitensluiten, dus laten we user-based risk policies voor gasten overslaan.”
Dat klinkt logisch, maar in werkelijkheid heb je veel minder zicht en controle over hun accounts, apparaten en sessies. Sterker nog, je zou strenger moeten zijn met Entra ID Protection policies voor gasten. Overweeg strengere Identity Protection policies voor gastgebruikers om risico’s van hun toegang te beperken.
Fout #5: Audit log retentie over het hoofd zien
De volgende fout heeft te maken met audit log retentie. Hoe lang Entra ID logs bewaard blijven hangt af van je licentie. Risicogebruikers verdwijnen echter nooit:
- Free: 7 dagen risk-sign-ins
- P1-licentie: 30 dagen
- P2-licentie: 90 dagen
Problemen met databehoud: Een upgrade van je licentie haalt geen oudere logs terug. Komt er een incident en koop je P1 of P2 om meer geschiedenis te krijgen, dan helpt dat niet met oude data. Dit kan lastig zijn als je Entra ID Protection al onderzocht hebt voor je de licentie kocht. Items op de Risky users-pagina worden niet beïnvloed door retentie, maar de data die je nodig hebt voor een goed onderzoek misschien wel.
Bijvoorbeeld: het veld “Risk asked updated” kan buiten je log retentie vallen, waardoor het onmogelijk is om een volledig onderzoek te doen naar andere Entra ID-logs zoals Risky sign-ins of Risk detecties.
Hoe dit te voorkomen:
- Proactief monitoren: Review en onderzoek risico’s regelmatig om problemen vroeg te signaleren.
- Data exporteren: Exporteer logs naar oplossingen zoals Log Analytics of Microsoft Sentinel om informatie te bewaren buiten de standaardretentieperiode.
Wil je leren hoe je je Azure cloud kunt beveiligen?
Bekijk dan ons GRATIS Azure Security webinar van 90 minuten voor praktische tips, best practices en praktische demo's over het beveiligen van je Azure omgeving.
Bekijk het nu!Fout #6: Geen break-glass noodaccounts implementeren
Veel organisaties vertrouwen volledig op Conditional Access zonder nood-“break-glass” accounts aan te maken die van alle policies zijn uitgezonderd.
Als Conditional Access verkeerd werkt, MFA-providers uitvallen of admins zichzelf buitensluiten, wordt herstel onmogelijk.
Waarom dit gevaarlijk is:
- Een verkeerde Conditional Access-configuratie kan alle admins buitensluiten
- Storingen bij MFA of identity providers kunnen toegang blokkeren
- Geen manier om tenant-instellingen te herstellen zonder Microsoft Support
Aanpak:
- Maak twee break-glass accounts, cloud-only, met sterke, willekeurige wachtwoorden
- Sluit ze uit van alle CA-policies, Identity Protection en MFA-eisen
- Monitor hun aanmeldingslogs met alerts (ze mogen nooit gebruikt worden)
Zo blijft herstel mogelijk bij identity-gerelateerde storingen.
Fout #7: Privileged Identity Management (PIM) niet gebruiken
Een van de grootste fouten in Entra ID-beveiliging is het permanent toewijzen van adminrechten aan accounts. Zonder PIM hebben admins continu toegang, wat het aanvalsvlak vergroot.
Waarom dit gevaarlijk is:
- Gestolen admin-credentials geven volledige, continue controle
- Moeilijker te volgen wie welke admin-actie uitvoerde
- Geen mogelijkheid tot tijdgebonden of goedkeuringsgebaseerde verhogingen
Aanpak met PIM:
- Verplicht Just-In-Time (JIT) verhoging voor alle privileged roles
- Dwing MFA af bij activatie
- Gebruik goedkeuringsworkflows voor gevoelige rollen
- Voer periodieke toegangsreviews uit
- Monitor PIM-activatie logs op verdachte activiteiten
PIM is een van de sterkste beschermingen tegen privilege-escalatie en tegen het in gevaar brengen van inloggegevens.
Conclusie
We hebben hier zeven veelvoorkomende fouten besproken die gaten in je Entra ID-configuratie kunnen veroorzaken en praktische manieren gedeeld om ze aan te pakken.
Op die manier kan je organisatie de Entra ID-bescherming versterken, de security posture verbeteren en het risico op ongeautoriseerde toegang of datalekken verlagen.
En onthoud: behandel Entra ID niet als een eenmalige taak. Continu toezicht en bijsturing zijn nodig om je gebruikers veilig te houden en je omgeving beschermd.
Neem contact met ons op!
Hulp nodig bij het implementeren van een aantal van de maatregelen in dit artikel of bij het verbeteren van de beveiliging in Azure?
Intercept helpt jouw organisatie een sterkere, betrouwbaardere basis te creëren in de Azure-cloud.