Cyberaanvallen worden steeds geraffineerder. In de vorige stap zagen we dat een aanvaller helemaal geen wachtwoord of MFA‑code hoeft te stelen om toegang te krijgen. Zodra een sessietoken wordt onderschept, fungeert dat token als een digitale sleutel. En zolang het geldig blijft, kan een aanvaller het vanaf andere apparaten of locaties opnieuw gebruiken.
Dat maakt tokens aantrekkelijk voor misbruik en laat zien dat identity‑beveiliging meer nodig heeft dan alleen sterke authenticatie.
Heb je vragen over tokenmisbruik of wil je sparren over jouw beveiligingsmodel? Wij denken graag met je mee.
Wat een token eigenlijk is
Wanneer een gebruiker zich succesvol aanmeldt, verstrekt Microsoft Entra één of meerdere tokens aan de client. Deze tokens zorgen ervoor dat een gebruiker ingelogd kan blijven, zonder telkens opnieuw MFA te hoeven uitvoeren. Voor gebruikers voelt dat prettig en efficiënt. Voor aanvallers is dit precies het mechanisme dat misbruik mogelijk maakt.
Een access token geeft directe toegang tot resources, terwijl een refresh token gebruikt wordt om nieuwe tokens op te halen. Omdat deze tokens bruikbaar blijven zolang ze geldig zijn, vormen ze een interessante aanvalsvector.
Het kernprobleem bij tokenmisbruik
Standaard zijn tokens niet gekoppeld aan een specifiek apparaat. Ze zijn herbruikbaar en lastig te onderscheiden van legitiem gedrag. Bij AiTM‑aanvallen wordt zo’n token tijdens de login direct onderschept en elders gebruikt, terwijl MFA keurig is doorlopen door de gebruiker zelf. Het probleem zit dus niet in de authenticatie, maar in wat daarna gebeurt.
Hoe Token Protection werkt
Token Protection introduceert een extra beveiligingslaag in Conditional Access. Het bindt tokens cryptografisch aan het apparaat waarop ze zijn uitgegeven. Daardoor werkt een refresh token uitsluitend op dat apparaat. Wordt het token op een ander apparaat gebruikt, dan wordt het automatisch geweigerd.
Het is geen extra authenticatiestap. Het gaat om het beperken van wat een token mag doen, zodat een onderschept token waardeloos wordt. Dit sluit naadloos aan bij eerder besproken thema’s zoals assume breach en impactbeperking, omdat het de schade minimaliseert wanneer een aanval toch slaagt.
Wat dit verandert in de praktijk
Door Token Protection verschuift het vertrouwen van “de gebruiker heeft MFA gedaan” naar “de gebruiker en het apparaat zijn gevalideerd”. Dit maakt AiTM‑aanvallen en token‑diefstal een stuk minder effectief. Zeker in scenario’s waarbij aanvallers direct proberen mee te liften op geldige sessies.
“Token Protection laat goed zien dat moderne identity‑beveiliging niet stopt bij inloggen. Het gaat om de volledige sessie. En die moet je net zo serieus beschermen als het wachtwoord.”
— Remco van Lent, directeur LinkSecure
Randvoorwaarden om rekening mee te houden
Token Protection werkt niet in alle scenario’s. Apparaten moeten geregistreerd zijn in Entra ID en gebruikers moeten inloggen via ondersteunde clients. In sommige browsersituaties werkt het nog beperkt, waardoor dit vooral interessant is voor beheerde werkplekken, vaste apparaten en gebruikers met kritieke rollen.
Voor organisaties die al werken met moderne werkplekken of Zero Trust‑principes, sluit Token Protection goed aan op bestaande strategieën.
Token Protection instellen in Conditional Access
Het configureren is technisch niet ingewikkeld, maar vereist wel een zorgvuldige aanpak.
- Maak in het Entra admin center een nieuwe Conditional Access policy aan.
- Start met een kleine pilotgroep, bij voorkeur beheerders of high‑impact accounts.
- Kies de cloud apps waarop je deze maatregel wilt toepassen — begin breed of richt je op kernservices zoals Exchange, SharePoint en Teams.
- Activeer in de sectie Session de instelling Require token protection for sign‑in sessions.
- Zet de policy eerst op Report‑only, zodat je in de logs ziet welke clients geraakt worden en waar uitzonderingen nodig zijn.
Pas wanneer duidelijk is dat de impact acceptabel is, zet je de policy actief aan.
Wat Token Protection niet oplost
Het blijft belangrijk om realistisch te zijn: Token Protection voorkomt geen phishing, vervangt geen MFA en neemt geen bewustzijn weg bij gebruikers. Het is één laag in een bredere strategie, waarin preventie, detectie en impactbeperking elkaar aanvullen. Wil je het risico van AiTM‑aanvallen structureel verkleinen, dan is een modern authenticatiemodel nodig met sterkere methoden zoals passkeys of phishing‑resistente inlogmethoden.
Klaar voor de volgende stap in identity‑beveiliging?
Token Protection is een logische vervolgstap in identity‑beveiliging. Het erkent dat aanvallers niet langer alleen proberen in te breken, maar inspelen op sessies die al geldig zijn. Door tokens te binden aan apparaten wordt een groot deel van dat risico afgekapt. Wil je sparren over de inzet van Token Protection of hulp bij het configureren ervan? Neem gerust contact op, wij helpen je graag verder.
De laatste stap in deze reeks gaat over het structureel voorkomen van dit soort aanvallen, door authenticatie zelf fundamenteel anders in te richten. Lees hier de blog Structureel uit de phishing-cyclus: phishing-resistente MFA afdwingen in Microsoft Entra ID.
