Identity as an Anchor: waarom “we hebben MFA” geen security-statement is

Introductie

In veel organisaties leeft nog altijd de overtuiging dat “we hebben MFA, dus we zitten goed”.
Maar wie regelmatig in Microsoft 365-omgevingen duikt, weet dat dit meestal geen security-statement is, maar eerder een aanname zonder bewijs.

In de praktijk zien we omgevingen waar MFA op papier verplicht is, maar waar:

• uitzonderingen bestaan omdat medewerkers verwachten dat de werkgever hun privésmartphone niet “mag gebruiken”
• BYOD‐toestellen onvoldoende gecontroleerd of zelfs volledig buiten compliance vallen
• Windows Hello for Business wel “beschikbaar” is, maar niet afgedwongen
• admins uitzonderingen hebben die eigenlijk niet verdedigbaar zijn

De realiteit is: identiteit is pas een ankerpunt wanneer controles afdwingbaar, bewijsbaar en meetbaar zijn.
Zonder die drie principes blijft MFA een checkbox, geen beveiliging.

Technische verdieping

MFA coverage ≠ MFA enforcement

Figuur 1: EntraID – Authentication Methods – Montioring - Activity

In Microsoft Entra ID kan bijna elke omgeving tonen dat x% van de gebruikers een MFA-methode geregistreerd heeft. Maar dat is geen bewijs van beveiliging.

Enforcement gebeurt pas wanneer Conditional Access daadwerkelijk verhindert dat een gebruiker zonder sterke authenticatie binnenraakt:

• Authentication Strengths
  → afdwingbare phishing-resistente paden
• Policyevaluatie (CA)
  → welke combinaties van user/device/location/app effectief toegestaan worden
• Risky signins & user risk
  → waar Entra ID actief signaalgebaseerd risico berekent
• Device compliance
  → essentieel om cookie-theft en token replay tegen te gaan

Dat laatste is cruciaal: zonder device compliance wordt identity-beveiliging altijd half werk.
Het wordt technisch bijzonder moeilijk voor een aanvaller om een refresh token te misbruiken wanneer dat token aan een compliant device en TPM-hardware gebonden is. Dit is exact waarom WHfB, Cloud Kerberos Trust en modern token binding een hoeksteen vormen van een phishing-resistent pad.

Figuur 2: EntraID - Conditional Access - Authentication Strengths

Admins en privilege-flows

Voor adminaccounts gelden andere regels dan voor gewone gebruikers. Eén fout of één misleidende klik kan een volledige tenant compromitteren. Daarom:

• geen BYOD
• geen zwakke MFA-methodes
• geen uitzonderingen
• geen mailbox of Teamsaccount op het adminprofiel
• beperkt internetgebruik (alleen noodzakelijke whitelisted Microsoft-endpoints)

Een admin-account is geen “werkaccount”. Communicatie, opzoekwerk, email en browsing gebeuren altijd vanuit een gewoon gebruikersaccount. Het admin-account blijft steriel en wordt enkel gebruikt voor beheer.

Minimale vereisten:

• phishing-resistente portable credential (zoals FIDO2 of passkey)
• lokale credential zoals Windows Hello for Business
• strenge Conditional Access, afgestemd op privileg-eniveau
• PIM-governance, zodat adminrechten enkel tijdelijk bestaan

Wat wij in de praktijk vaststellen

Steeds opnieuw zien we dezelfde patronen:

• MFA is “verplicht”, maar alleen voor de 80% die akkoord ging met een authenticatorapp
• de overige 20% heeft uitzonderingen die niet gecompenseerd worden
• BYOD toestellen zitten in een grijze zone zonder compliance
• WHfB staat wel aan, maar niemand controleert of gebruikers het effectief gebruiken
• geen enkele groep heeft een phishingresistant enforcement policy
• Conditional Access policies zijn “report-only” in plaats van blokkerend

Dit soort risico’s worden meestal pas zichtbaar wanneer je de omgeving systematisch laat analyseren via een security audit.

Figuur 3: EntraID - Users - Sign-In Logs - Filter

Waarom dit een reëel risico is

Wanneer identity geen afdwingbaar ankerpunt is:

• MFA kan worden omzeild via legacy signin paths
• token/cookie-theft blijft mogelijk op nietcompliant devices
• gebruikers met uitzonderingen vormen directe aanvalsroutes
• admins worden een to zwakke schakel
• risk signals in Entra ID worden genegeerd omdat ze niet gekoppeld zijn aan CAafhandeling
• gedeelde toestellen creëren tokenexposure
• CApolicies dekken scenario’s niet af op OSniveau (iOS vs Android vs Windows)

Het probleem is dus niet of MFA bestaat, maar of identiteit consequent als juridische, technische en operationele bron van bewijs gebruikt wordt.

Wat een volwassen aanpak is

Een volwassen identitystrategie is geen lijst met instellingen, maar een consistent model. De kracht ligt in samenhang.

1. Identity is het ankerpunt

• device compliance is verplicht
• tokens worden hardwaregebonden
• geen toegang zonder moderne, traceerbare authenticatie
• non-compliant devices hebben maximaal beperkte toegang

Figuur 5: EntraID - Devices - All Devices - Filter

2. Gebruikers worden ingedeeld in persona’s

Zoals Microsoft het aanbeveelt:

• admins & highly regulated users
• non-admins

Elke persona krijgt:

• een voorkeur-portable credential
• een lokale credential (WHfB, Secure Enclave, passkeys…)
• toepasselijke CA-policies

3. Afdwingbaarheid boven configuratie

Niet: “We hebben passkeys ingeschakeld.”
Wel: “Alle gebruikers in groep X mogen enkel binnen via phishing-resistente authenticatie.”

4. Geen BYOD tenzij zwaar beperkt

BYOD zonder compliance betekent dat identity nooit een betrouwbaar ankerpunt kan zijn.

5. Exceptions zijn bewust, beperkt en gecompenseerd

Niet omgekeerd: geen uitzonderingen die het model ondergraven.

Reflectie & conclusie

• De praktijk toont dat “MFA voor iedereen” vaak mislukt op basis van perceptie, vakbondsdruk of BYOD-verwachtingen. Daarom is 80% afdwingen beter dan 0% afdwingen.
• Device compliance is een essentieel onderdeel van identity-beveiliging omdat cookie-theft nauwelijks werkt op een TPM-gebonden token.
• Voor admins is phishing-resistent de enige aanvaardbare optie zonder uitzonderingen.
• MFA-coverage zegt niets: enkel afdwingbaarheid, identity-signalen en meetbare policies vormen een hard ankerpunt.

De toekomst van identity-security draait dus niet om “MFA hebben”, maar om bewijskracht, traceerbaarheid en afdwingbare standaarden.

Veel van deze risico’s worden pas zichtbaar wanneer je identity‑configuratie systematisch wordt doorgelicht, precies waar een grondige security audit het verschil maakt.