# DBSC in Chrome: waarom gestolen sessiecookies straks waardeloos zijn

![Hand die een gouden hangslot vasthoudt als symbool voor beveiliging](/images/blog-2026/dbsc-chrome-sessiecookies-apparaatgebonden.webp)

Device Bound Session Credentials (DBSC) is algemeen beschikbaar in Chrome op Windows en staat standaard aan. DBSC bindt een sessiecookie aan het apparaat waarmee je bent ingelogd, waardoor een gestolen cookie op een ander apparaat veel minder waard wordt. Beheerders kunnen de functie niet uitschakelen; de uitrol startte op 25 mei 2026 en kan tot 60 dagen duren. 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.

De bescherming draait op hardwareniveau. Op Windows gebruikt DBSC daarvoor een Trusted Platform Module (TPM), een beveiligingschip die standaard op de meeste Windows 11-apparaten zit. De cryptografische sleutels die de sessie aan het apparaat binden, worden in die chip bewaard. Daarnaast is Chrome versie 146 of hoger nodig. Voldoet een apparaat niet aan deze eisen, dan blijft een sessie in sommige gevallen ongebonden en geldt de extra bescherming daar dus niet.

Belangrijk om te weten: DBSC geldt alleen voor nieuwe sessies. Wie al was ingelogd op het moment dat DBSC actief werd, moet zich afmelden en opnieuw aanmelden om de sessie te binden. Bepaalde browserextensies of handmatige wijzigingen aan cookies kunnen de werking bovendien verstoren.

Je hoeft je als gebruiker verder 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 en geldt voor alle Google Workspace-klanten, Workspace Individual-abonnees en gebruikers met een persoonlijk Google-account. 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.

DBSC beschermt je sessies zonder dat je er iets voor hoeft te doen, net zoals een browser je waarschuwt voor een onveilige site zonder dat je daarom hebt gevraagd.

## 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](/blog/google-workspace-alert-center-beheerder) 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. Je kunt de combinatie ook actief inzetten: via context-aware access kun je DBSC verplicht stellen voor toegang tot specifieke Workspace-apps. Wie dan op een niet-ondersteund platform werkt, wordt voor die app geblokkeerd. Die verplichting geldt alleen voor desktop-webapps, niet voor mobiele apps of API's.

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, wat aansluit bij de zero trust-gedachte in de rest van Workspace.

## DBSC in het kort

| Onderdeel | Detail |
| --- | --- |
| Beschikbaar | Chrome op Windows, versie 146 of hoger |
| Hardware | Trusted Platform Module (TPM) op Windows |
| Uitrol | Vanaf 25 mei 2026, geleidelijk tot 60 dagen |
| Stand | Standaard aan, niet uit te schakelen |
| Geldt voor | Nieuwe sessies, niet voor bestaande sessies |
| Logging | Audit-logging in de security investigation tool |

## 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. Wie al ingelogd was, moet zich eenmalig afmelden en opnieuw aanmelden om de sessie te binden. 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. Overweeg daarbij of je DBSC voor gevoelige apps wilt verplichten. Meer daarover lees je in ons artikel over [zero trust met context-aware access](/blog/google-workspace-zero-trust-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 maakt een gestolen sessiecookie in hoge mate onbruikbaar. 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](/blog/google-workspace-account-beveiligen-na-hack). DBSC is dus een laag, geen totaaloplossing.

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

## Veelgestelde vragen

**Moet ik iets doen om DBSC te gebruiken?**

Nee. DBSC staat standaard aan in Chrome op Windows en wordt automatisch uitgerold. Je hoeft als beheerder niets in te stellen.

**Kunnen wij DBSC uitschakelen?**

Nee, beheerders kunnen de functie niet uitschakelen. Dat is bewust, omdat de bescherming alleen werkt als hij consequent aanstaat. Via context-aware access kun je DBSC voor specifieke apps juist verplicht stellen.

**Hoe lang duurt de uitrol?**

De uitrol startte op 25 mei 2026 en kan tot 60 dagen duren. Reken er dus op dat niet elke gebruiker op hetzelfde moment de functie heeft.

**Waar zie ik wat DBSC doet?**

Gebeurtenissen rond DBSC zijn terug te vinden in de audit-logging in de security investigation tool. Daar kun je onderzoeken of sessies worden gebonden of geweigerd.

**Betekent dit dat gestolen cookies nu volledig nutteloos zijn?**

Een gestolen sessiecookie wordt door de apparaatbinding in hoge mate onbruikbaar, maar DBSC is een laag en geen totaaloplossing. Blijf inzetten op sterke authenticatie, context-aware access en monitoring.

## Conclusie

DBSC maakt van een sessiecookie een apparaatgebonden bewijs, waardoor een gestolen cookie een aanvaller veel minder oplevert. Sinds 25 mei 2026 rolt Google de functie uit in Chrome op Windows, standaard aan en niet uit te schakelen, met logging in de security investigation tool. Het is een krachtige laag tegen accountovername, die je het beste combineert met sterke authenticatie, context-aware access en actieve monitoring.

Wil je je Chrome- en Workspace-omgeving hierop inrichten of je sessiebeveiliging tegen het licht houden? Neem [contact](/contact) op of bekijk onze diensten voor [cybersecurity](/diensten/cybersecurity) en [IT-beheer](/diensten/it-beheer).

## Bronnen

- [Google Workspace Updates: DBSC nu algemeen beschikbaar in Chrome op Windows](https://workspaceupdates.googleblog.com/2026/05/prevent-account-takeovers-with-DBSC-now-generally-available-in-the-Chrome-browser-for-Windows.html)
- [Google Workspace Admin Help: cookiediefstal voorkomen met sessiebinding](https://support.google.com/a/answer/15956470)