Sign-in risk versus gebruikersrisico in Microsoft Entra ID: wat is het verschil?

By Mirko Peters · 2026-10-26

Ontdek de belangrijkste verschillen tussen sign-in risk en gebruikersrisico in Microsoft Entra ID Protection en leer hoe je voorwaardelijke toegang correct configureert.

Automatically translated with AI from the original post. Read the English original

Sign-in risk en gebruikersrisico in Microsoft Entra ID Protection zijn afzonderlijke beveiligingsmetingen. Sign-in risk beoordeelt of één authenticatiepoging verdacht is, terwijl gebruikersrisico bepaalt of de kernreferenties van een account over meerdere sessies zijn gecompromitteerd.

Belangrijkste punten

• Sign-in risk beoordeelt de kans dat een specifieke authenticatiepoging niet afkomstig is van de legitieme accounteigenaar.
• Gebruikersrisico beoordeelt of de referenties van een account permanent zijn gecompromitteerd of zijn blootgesteld bij een datalek.
• Een enkel onbeheerd sign-in risk kan na verloop van tijd geleidelijk optellen en uitgroeien tot een gemarkeerde gebruiker met een hoog risico.
• Sign-in risk wordt doorgaans meteen opgelost via een MFA-uitdaging, terwijl gebruikersrisico vaak een veilige wachtwoordwijziging vereist.
• Microsoft Entra ID P2 is nodig om risicogebaseerde beleidsregels, uitgebreide rapportagegeschiedenis en geautomatiseerd herstel volledig te benutten.

Het kernverschil begrijpen

Wanneer beheerders Microsoft Entra ID Protection voor het eerst inrichten, is een van de meest voorkomende verwarringen het door elkaar halen van sign-in risk en gebruikersrisico. Beide metingen steunen op het enorme signaalnetwerk van Microsoft, waarbij dagelijks triljoenen signalen worden geanalyseerd van consumentenaccounts, zakelijke tenants en zelfs Xbox-diensten. Toch beantwoorden ze fundamenteel verschillende vragen.

Een beveiligingssysteem mag één ongebruikelijke aanmelding niet op dezelfde manier behandelen als een werkelijk gestolen account. Als een beheerder elke keer dat iemand inlogt vanaf een onbekende locatie of een onverwacht netwerk een algemene accountblokkade instelt, komt de productiviteit tot stilstand. Omgekeerd laat een tijdelijke MFA-uitdaging bij een echt gecompromitteerd account de hardnekkige dreiger vrij om later opnieuw in te loggen zodra de uitdaging verloopt. Begrijpen hoe deze twee metingen onafhankelijk functioneren en hoe ze op elkaar inwerken, is essentieel voor een evenwichtige cloudbeveiliging.

Wat is sign-in risk?

Sign-in risk richt zich uitsluitend op één moment: het exacte ogenblik waarop een gebruiker probeert toegang te krijgen tot een resource zoals Microsoft Teams, SharePoint of Outlook. Het gaat volledig om de specifieke context van die ene aanmeldpoging en niets anders. Het systeem vraagt zich af of de kenmerken van dit specifieke verzoek overeenkomen met het normale gedragspatroon van de gebruiker.

Microsoft Entra ID Protection beoordeelt verschillende variabelen tijdens realtime aanmeldcontroles. Daarbij gaat het om verbindingen vanaf anonieme IP-adressen, die vaak worden gebruikt om geografische locaties te verbergen, om onmogelijke reisscenario’s waarbij aanmeldingen vanuit geografisch ver uiteenliggende regio’s plaatsvinden binnen een onrealistisch korte tijd, of om signalen van een password spray-aanval, waarbij een aanvaller één veelgebruikt wachtwoord tegelijkertijd test op duizenden zakelijke accounts. Ongebruikelijke aanmeldkenmerken worden bovendien dynamisch gewaardeerd: hoe afwijkender het verzoek is ten opzichte van historische basislijnen, hoe hoger de risicoscore oploopt.

Belangrijk: een aanmeldingsrisicoscore geldt strikt voor die ene poging. Als een gebruiker tijdens die specifieke aanmelding met succes een extra MFA-verificatie (step-up) doorloopt, wordt het risico dat bij die aanmelding hoort meteen geneutraliseerd. De gebruiker gaat dan gewoon verder met zijn werkdag, zonder dat de status van het account blijvend wordt benadeeld.

Wat is gebruikersrisico?

Gebruikersrisico gaat juist niet over één aanmelding. Het gaat over de gezondheid en integriteit van het account zelf. Bij gebruikersrisico is de vraag of de inloggegevens van het account in verkeerde handen zijn gevallen, wat betekent dat een aanvaller de permanente sleutels tot het koninkrijk in handen heeft en wanneer hij maar wil terug kan keren om gegevens te compromitteren.

De belangrijkste oorzaak van gebruikersrisico is het opduiken van inloggegevens in bekende datalekken. Wanneer gebruikersnamen en wachtwoorden op het dark web worden gelekt of via info-stealing malware worden buitgemaakt, markeert de threat intelligence van Microsoft die gegevens direct. Andere indicatoren zijn geverifieerde infrastructuur van dreigingsactoren die direct contact heeft met het gebruikersprofiel, of afwijkende activiteitenpatronen die wijzen op langdurige ongeoorloofde toegang.

Wanneer een account wordt gemarkeerd vanwege gebruikersrisico, blijft de dreiging bestaan, ook nadat de gebruiker is uitgelogd. Omdat een aanvaller het wachtwoord buiten de normale sessiegrenzen kan hebben verkregen, is het uitdagen van de gebruiker met MFA zelden voldoende om een hoge gebruikersrisicoscore volledig op te lossen. De onderliggende kwetsbaarheid moet worden aangepakt.

Hoe risiconiveaus worden berekend

Zowel aanmeldingsrisico als gebruikersrisico komen neer op drie duidelijke betrouwbaarheidsniveaus: laag, gemiddeld en hoog. Deze niveaus zijn machine learning-schattingen van de kans op een dreiging en geen absolute ja-of-nee-waarheden.

Hoog risico betekent dat de geautomatiseerde systemen van Microsoft sterk, geverifieerd bewijs van compromittering hebben, zoals expliciet gelekte inloggegevens die overeenkomen met dark web-databases of geverifieerde kwaadaardige IP-signaturen. Gemiddeld risico duidt op matige signalen van verdachte activiteit met een lagere absolute zekerheid. Laag risico wijst op afwijkend gedrag dat afwijkt van de standaardpatronen, maar waarvoor geen definitieve kwaadaardige indicatoren zijn.

Een belangrijk beheerdetail is hoe deze records na verloop van tijd verouderen. Items met laag risico verlopen automatisch na ongeveer zes maanden, zodat de dashboards overzichtelijk blijven. Items met gemiddeld en hoog risico verlopen echter niet vanzelf. Ze blijven staan in het beheercentrum totdat een geautomatiseerd beleid of een beheerder ze expliciet onderzoekt, herstelt of afsluit.

Het overloopeffect: hoe ze samenhangen

Hoewel aanmeldingsrisico en gebruikersrisico verschillende dingen beoordelen, zijn ze in rapportage en handhaving nauw met elkaar verbonden. Een enkel aanmeldingsrisico dat volledig onopgelost of onbevestigd blijft, kan zich na verloop van tijd opstapelen en uiteindelijk bijdragen aan de totale gebruikersrisicoscore.

Dit betekent dat een persoon als risicovolle gebruiker in het Entra ID-dashboard kan verschijnen, ook als de meest recente aanmeldpogingen volledig normaal leken. Het systeem herkent een cumulatieve geschiedenis van verdacht gedrag die de kans op langdurige compromittering verhoogt. Beheerders moeten beide rapporten tegelijk bekijken in plaats van ze als afzonderlijke silo's te behandelen.

Herstel automatiseren via voorwaardelijke toegang

Om te voorkomen dat beveiligingsteams verdrinken in handmatige meldingen, overbrugt Microsoft Entra Conditional Access de kloof tussen risicoscores en geautomatiseerde handhaving. Organisaties kunnen specifieke beleidsregels configureren die worden geactiveerd zodra de drempels voor laag, gemiddeld of hoog risico worden overschreden.

Bij aanmeldingsrisico kunnen beleidsregels acties afdwingen, zoals het vereisen van MFA, het forceren van een nieuwe aanmeldsessie of het volledig blokkeren van de toegang. Wanneer een gebruiker een MFA-uitdaging met succes doorloopt, wordt het risico direct hersteld.

Bij gebruikersrisico vereisen beleidsregels doorgaans een veilige wachtwoordwijziging of geautomatiseerd risicoherstel. Het slimme aan herstel van risico's is het aanpassingsvermogen: als de gebruiker inlogt met een traditioneel wachtwoord, eist het systeem een veilige wachtwoordwijziging en maakt het meteen alle bestaande sessies ongeldig. Als de gebruiker inlogt met wachtwoordloze methoden, worden actieve sessies beëindigd en wordt een nieuwe authenticatiestroom gestart. Deze geautomatiseerde reactie vermindert het aantal helpdeskticketS aanzienlijk en stopt aanvallers meteen.

Conclusie

Het onderscheid tussen aanmeldingsrisico en gebruikersrisico goed begrijpen stelt cloudarchitecten in staat om nauwkeurige, genuanceerde beveiligingsbeleidsregels op te stellen die bedrijfsgegevens beschermen zonder gebruikers in hun dagelijks werk onnodig te hinderen. Doordat je automatisering de standaardherstelacties laat uitvoeren, kunnen IT-teams hun energie richten op het onderzoeken van echte dreigingen. Wil je dieper ingaan op hoe deze beschermingslagen werken in moderne cloudomgevingen? Luister de volledige aflevering van de podcast voor een compleet overzicht van best practices voor configuratie, licentievereisten en praktijkvoorbeelden van beheer.

Veelgestelde vragen

Wat gebeurt er wanneer een aanmeldingsrisico wordt geactiveerd?

Wanneer een aanmeldingsrisico wordt gedetecteerd, kan Microsoft Entra Conditional Access de poging automatisch blokkeren, de toegang toestaan of de gebruiker vragen zijn identiteit te bewijzen met multi-factor authentication (MFA).

Hoe lang blijven gebeurtenissen met een laag risico zichtbaar in de rapporten van Entra ID Protection?

Detecties met een laag risico verdwijnen automatisch uit de rapporten na ongeveer zes maanden. Vermeldingen met een gemiddeld en hoog risico blijven staan totdat een beheerder ze wegneemt of de gebruiker het risico zelf oplost.

Kunnen gastaccounts gebruikmaken van automatische herstel van gebruikersrisico's?

Nee, de volledige geautomatiseerde risicoherstelprocedure werkt niet voor gast- en externe gebruikers, omdat Microsoft Entra ID de sessies van deze externe accounts niet op dezelfde manier intrekt als bij interne leden.

Wat is het verschil tussen 'Bevestigen als veilig' en 'Negeren' in de rapporten voor beheerders?

Met 'Bevestigen als veilig' geef je aan dat de melding een vals alarm was, veroorzaakt door normaal gedrag. 'Negeren' betekent dat de melding technisch gezien een terechte vondst was, maar in deze specifieke context onschadelijk bleek, bijvoorbeeld een geplande beveiligingstest.