DBSC in Chrome: waarom gestolen sessiecookies straks waardeloos zijn

Device Bound Session Credentials (DBSC) is algemeen beschikbaar in Chrome op Windows, met een uitrol vanaf 25 mei 2026 die tot 60 dagen kan duren. DBSC bindt sessiecookies aan het apparaat waarmee je bent ingelogd, waardoor een gestolen sessiecookie veel minder bruikbaar wordt. De functie staat standaard aan en beheerders kunnen haar niet uitschakelen. In dit artikel lees je wat DBSC oplost, hoe het samenhangt met context-aware access en waarom dit uitmaakt voor je beveiliging.

Wat DBSC is

DBSC staat voor Device Bound Session Credentials. Het is een mechanisme in Chrome dat ervoor zorgt dat een sessie alleen geldig is op het apparaat waarmee die sessie is gestart. De sessiecookie, het bewijs dat je bent ingelogd, raakt daardoor gebonden aan dat specifieke apparaat.

Je hoeft je hier als gebruiker niets van aan te trekken. Je logt in zoals altijd en merkt in de praktijk weinig verschil. De verandering zit achter de schermen, in de manier waarop Chrome en de website samen controleren of een sessie echt bij jou hoort.

Waarom gestolen sessiecookies zo gevaarlijk zijn

Om het belang van DBSC te begrijpen, moet je weten hoe een sessiecookie werkt. Als je inlogt, geeft de website je een cookie die zegt: deze persoon is ingelogd. Zolang je die cookie meestuurt, hoef je niet opnieuw in te loggen. Dat is handig, maar ook kwetsbaar.

Een aanvaller die zo'n cookie weet te bemachtigen, kan zich voordoen als jou zonder je wachtwoord te kennen. Dat kan via malware op een apparaat, via een phishingpagina die de cookie onderschept, of via een kwetsbaarheid in een browser of extensie. Zodra de cookie in handen is van de aanvaller, kan die de sessie overnemen. Voor de website ziet het verkeer eruit als gewoon ingelogd gebruik, want de cookie klopt.

Wachtwoorden wijzigen helpt in zo'n situatie vaak niet direct, omdat de aanvaller de bestaande sessie gebruikt en niet je wachtwoord. Dit is precies het type aanval dat accountovernames mogelijk maakt, en het is een van de redenen dat sessiecookies zo'n gewild doelwit zijn.

Hoe DBSC sessiecookies aan het apparaat bindt

DBSC pakt dat probleem bij de wortel aan. In plaats van een sessiecookie die overal werkt zolang hij geldig is, wordt de sessie gekoppeld aan het apparaat. Een gestolen cookie is dan niet meer genoeg: de aanvaller heeft ook het apparaat nodig waarop de sessie hoort.

Dat betekent niet dat een gestolen cookie volstrekt nutteloos is in elke denkbare situatie, maar de drempel wordt fors hoger. De aanvaller moet niet alleen de cookie zien te bemachtigen, maar ook de binding met het apparaat doorbreken. Dat is precies de verdedigingslaag die je wilt: het kost de aanvaller meer moeite dan het oplevert, en de aanval wordt minder aantrekkelijk.

Voor organisaties die met Google Workspace werken, betekent dit dat het risico van accountovername via gestolen sessies kleiner wordt. Dat is relevant voor iedere organisatie, maar zeker voor teams die veel op afstand werken en waar apparaten en netwerken minder voorspelbaar zijn.

Standaard aan en niet uit te schakelen

DBSC staat standaard aan in Chrome op Windows. Beheerders kunnen de functie niet uitschakelen. Dat is een bewuste keuze van Google: de bescherming werkt alleen als hij consequent aanstaat, en een instelling die per organisatie verschilt, zou het voordeel ondermijnen.

Dat betekent voor jou als beheerder dat je geen keuze hoeft te maken, maar er wel rekening mee moet houden. Je kunt de functie niet in een testomgeving uitzetten om iets uit te sluiten. Ga er dus van uit dat het aanstaat bij je Windows-gebruikers en dat sessies zich anders gedragen dan voorheen.

Dit is een van die maatregelen die beveiliging standaard veilig maakt. Net zoals een browser je waarschuwt voor een onveilige site zonder dat je daarom hebt gevraagd, beschermt DBSC je sessies zonder dat je er iets voor hoeft te doen.

Audit-logging in de security investigation tool

DBSC is niet alleen een stille bescherming; er zit ook waarneembaarheid aan vast. De gebeurtenissen rond DBSC zijn terug te vinden in de audit-logging in de security investigation tool. Dat betekent dat je als beheerder kunt zien wat er gebeurt en kunt onderzoeken of er iets afwijkends plaatsvindt.

Dat is belangrijk, want een beveiligingsmaatregel waar je niets van ziet is lastig te beheren. Met de logging kun je nagaan of sessies worden geweigerd of gebonden, en kun je patronen herkennen die op een probleem wijzen. Denk aan een gebruiker die herhaaldelijk vastloopt, of een apparaat dat zich onverwacht gedraagt.

Voor het onderzoeken van incidenten is dit waardevol. Als je vermoedt dat een account is overgenomen, kun je met de logging nagaan of de aanval via een sessie verliep en of DBSC daar iets tegen heeft gedaan. Samen met het Alert Center heb je dan meerdere bronnen om een incident te reconstrueren.

Impact op context-aware access en monitoring

DBSC staat niet op zichzelf. Het raakt aan je bestaande beveiligingslagen, in het bijzonder context-aware access.

Context-aware access bepaalt of iemand toegang krijgt op basis van factoren zoals identiteit, locatie, apparaatstatus en IP-adres. DBSC voegt daar een apparaatgebonden sessie aan toe. Het is verstandig om te controleren of je beleid nog klopt nu sessies zich anders gedragen. Test vooral situaties waarin gebruikers wisselen van apparaat of netwerk.

Ook je monitoring verdient aandacht. Als sessies vaker worden geweigerd of opnieuw moeten worden opgezet, kan dat tot ruis leiden in je signalen. Zorg dat je weet hoe normaal gedrag eruitziet, zodat je afwijkingen kunt onderscheiden. Een gebruiker die vastloopt omdat zijn omgeving niet met DBSC omgaat, is iets anders dan een aanval.

Op langere termijn is de combinatie krachtig: een aanval moet zowel de sessie als het apparaat zien te verslaan. Dat sluit aan bij de zero trust-gedachte in de rest van Workspace, waar identiteit, apparaat en context samen bepalen of iets mag.

Wat je als beheerder concreet doet

Omdat je DBSC niet kunt aan- of uitzetten, verschuift je rol van instellen naar begeleiden. Een paar concrete acties helpen om de uitrol soepel te laten verlopen.

Ten eerste: informeer je gebruikers kort. De meeste mensen merken niets van DBSC, maar wie veel wisselt tussen apparaten kan een keer opnieuw moeten inloggen. Een korte uitleg voorkomt dat zoiets als een storing wordt ervaren.

Ten tweede: controleer je testscenario's. Applicaties en scripts die met sessies werken, kunnen zich anders gedragen nu sessies aan een apparaat zijn gebonden. Test de flows die voor jouw organisatie belangrijk zijn, juist op het moment dat een gebruiker van apparaat of netwerk wisselt.

Ten derde: gebruik de logging actief. De DBSC-gebeurtenissen in de security investigation tool zijn niet alleen voor incidenten. Ze helpen je ook om te zien of het normale gedrag in jouw omgeving klopt en waar gebruikers mogelijk vastlopen.

Ten vierde: herzie je context-aware access-beleid. Omdat DBSC en CAA elkaar versterken, is dit een goed moment om te controleren of je beleid nog past bij de manier waarop jullie werken. Meer daarover lees je in ons artikel over zero trust met context-aware access.

Wat DBSC wel en niet oplost

Het is net zo belangrijk om te weten wat DBSC niet doet, zodat je er geen verkeerde verwachtingen van krijgt.

DBSC lost een gestolen sessiecookie in hoge mate onbruikbaar maken op. Het apparaat wordt onderdeel van het sessiebewijs, dus een losse cookie is niet meer genoeg. Dat verkleint het risico van accountovername via sessiediefstal.

DBSC lost niet alles op. Een aanvaller die toegang heeft tot het apparaat zelf kan nog steeds schade aanrichten, want dan is de binding geen barrière. Een aanvaller die je wachtwoord heeft en op een nieuw apparaat inlogt, wordt ook niet automatisch gestopt; daar helpen andere maatregelen zoals tweestapsverificatie en je account beveiligen na een hack. DBSC is dus een laag, geen totaaloplossing.

De kracht zit in stapelen. Combineer DBSC met sterke authenticatie, context-aware access en goede monitoring, en je maakt het een aanvaller aanzienlijk moeilijker. Gebruik de security checklist 2026 om te controleren of je die lagen op orde hebt.