Stop met account takeover-tools te vergelijken alsof ze uitwisselbaar zijn. Dat zijn ze niet. Een MFA-provider bewijst wie inlogt, een fraud suite scoort wat het account na login doet, en een browserlaagtool vertelt je of de sessie die in de pagina draait wel menselijk is. Dat zijn drie verschillende taken op drie verschillende momenten. Een functieraster dat ze in één tabel stapelt, verbergt de vraag die je moet beantwoorden: welke laag mis je?
Deze gids vergelijkt ATO-preventie op verdedigingslaag (identity/MFA, fraud suite en browser+bot), niet op vendorlogo. Per laag zie je wat hij waarneemt, wanneer hij optreedt, welk gat hij openlaat en waar cside browserlaagbewijs toevoegt dat de andere twee niet kunnen vastleggen. Geen verzonnen prijzen, geen valse functiechecklists.
De reden dat gelaagdheid ertoe doet: aanvallers bewegen zich langs een pad. Gestolen credentials worden door bots gevalideerd, geldige sessies worden gekaapt nadat MFA slaagt, en de fraude duikt pas op bij de transactie. Elke laag dekt een deel van dat pad en is blind voor de rest.
Vergelijk ATO-preventie per verdedigingslaag
| Verdedigingslaag | Wat bewijst het | Wanneer het optreedt | Blinde vlek die het openlaat |
|---|---|---|---|
| Identity / MFA | Wie authenticeert | Bij login, vóór de sessie | Sessiediefstal en AiTM nadat de factor slaagt |
| Fraud suite | Of de acties van het account riskant lijken | Na login, bij de transactie | Geautomatiseerde of gekaapte sessies die "normaal" lijken tot de uitbetaling |
| Browser + bot | Of de sessie zelf menselijk en vertrouwd is | In de pagina, tijdens de sessie | Server-side identitybeleid en transactiegeschiedenis tussen merchants |
Lees de tabel op zijn laatste kolom. De zwakte van elke laag is de bestaansreden van een andere. Koop om de blinde vlek te sluiten die je daadwerkelijk hebt, niet om de langste functielijst te verzamelen.
Laag 1, Identity en MFA: bewijst wie, niet hoe
De identitylaag (Okta, Microsoft Entra ID en dergelijke) beslist of een credential plus een tweede factor de deur moet openen. Adaptieve policies kunnen een challenge opschroeven wanneer de logincontext raar oogt, zoals een nieuw apparaat, nieuwe geografie of vreemde snelheid. Dit is de fundering, en phishing-resistente factoren als passkeys (WebAuthn onder NIST SP 800-63B AAL2/AAL3) sluiten credential stuffing als pad af.
De blinde vlek is alles wat nadat de factor slaagt gebeurt. Een adversary-in-the-middle-proxy laat het slachtoffer normaal authenticeren, MFA inbegrepen, en steelt vervolgens het resulterende sessietoken en wandelt naar binnen. De identitylaag heeft allang "success" teruggegeven. Het heeft verder niets meer te zeggen. Als MFA je enige ATO-controle is, ziet een gestolen sessie er exact uit als de legitieme gebruiker.
Laag 2, Fraud suites: scoren het account, laat op het pad
Fraud suites (Sift, Forter en collega's) scoren events over de hele reis (aanmelding, login, transactie) met machine-learning-modellen getraind op data tussen merchants. Ze zijn sterk aan het monetisatie-einde: snelheidspieken, wisselingen van verzendadres, wijzigingen van betaalmethode, chargeback-workflows. Voor een onderneming met een fraud-ops-team en reële chargebackvolumes betaalt deze laag zichzelf terug.
Twee eerlijke beperkingen. Ten eerste komen de sterkste signalen laat aan, vlak bij de transactie, nadat de takeover al plaatsvond. Ten tweede is de device-intelligentie die in een suite is ingebakken een feature binnen een black-box-score, geen stroom ruwe browsersignalen die jij beheert. Wanneer een geautomatiseerde sessie zich gedraagt als een geduldige mens tot de uitbetaling, scoort de suite die vaak schoon tot aan de fraude. Een bot-gestuurde account takeover is precies het geval waarin die score te laat aankomt.
Uit cside-data: installaties van playwright-stealth (automatiseringstooling gebouwd om te verbergen dat een browser door een script wordt bestuurd) groeiden ongeveer 10x over 2025, volgens het cside-rapport over de toekomst van webbeveiliging. Dat is precies de tooling waar fraud suites het minst zicht op hebben, omdat die een normale browser imiteert op de transactielaag.
Laag 3, Browser en bot: is deze sessie überhaupt menselijk?
De browserlaag draait in de pagina en beantwoordt de vraag die de andere twee niet kunnen: is deze sessie een echte mens in een echte browser, of een automatiseringsframework dat de credentials van een mens draagt? Dit is de laag die de meeste teams te weinig kopen, en hij zit precies in het gat tussen "MFA geslaagd" en "de transactie is verwerkt".
Concrete signalen die deze laag vastlegt en die nooit een server-side score bereiken:
navigator.webdriveren automatiseringsflags: de property die browsers exponeren wanneer een sessie door WebDriver/CDP wordt bestuurd, plus de restsporen die stealth-plugins proberen te patchen en missen.- CDP- en runtime-lekken: Chrome DevTools Protocol-activiteit en
Runtime-artefacten die een headless of op afstand bestuurde browser verraden, zelfs wanneer de user-agent er normaal uitziet. - Fingerprint-drift: hetzelfde "account" dat inconsistente of roterende apparaatfingerprints toont over logins, een handelsmerk van botfarms en gedeeld sessie-replay-tooling.
- Residentieel-proxy- en VPN-gedrag: gedragssignalen dat een verder schoon lijkend residentieel IP wordt gebruikt om geautomatiseerd verkeer te wassen, voorbij een IP-blocklist alleen.
- Kwaadaardige in-page scripts: credentials-oogstende overlays of AiTM-redirectlogica geïnjecteerd via third- of first-party scripts, vastgelegd bij runtime voordat de gebruiker wordt gephisht.
Dat laatste signaal is de brug terug naar de blinde vlek van Laag 1. Aanvallers injecteren CSS-overlays en rogue scripts op legitieme pagina's om gebruikers naar een valse login te duwen die hun MFA-code realtime proxypassen. De identitylaag ziet een schone authenticatie; de browserlaag ziet het geïnjecteerde script en de bestuurde sessie.
Hoe koop je over de drie lagen heen
Koop niet de langste checklist. Koop de laag die je aanvalspad openlaat.
- Mep je pad uit. Schrijf login → validatie → toegang → sessiepersistentie → monetisatie, en markeer welke laag elke stap in de gaten houdt.
- Vind het single-point-of-failure. Als MFA je enige ATO-controle is, is je gat sessiediefstal. Dat is een browserlaagprobleem, geen probleem van sterkere MFA.
- Vermijd dubbele signalen zonder gedeelde actie. Twee tools die allebei "nieuw apparaat" vlaggen is verspilling, tenzij een van beide kan handhaven.
- Draai een echte proof. Speel historische incidenten af door de kandidaat-laag en controleer of die de sessie zou hebben gemarkeerd, niet alleen de transactie.
- Koppel de overdracht. Een browserlaagflag moet step-up-MFA triggeren bij Laag 1 of een risicoscore voeden bij Laag 2, via API of webhook, zodat elke laag optreedt op elkaars bewijs.
Waar cside past
cside is de browser- en botlaag, en is gebouwd om de andere twee te voeden in plaats van ze te vervangen. Het draait client-side om apparaat- en echte-IP-signalen vast te leggen, AI-agent- en botdetectie, VPN/proxy-gedragsdetectie en runtime-zicht in de scripts die op je login- en checkoutpagina's draaien. Die signalen gaan via API en webhook, zodat een apparaatmismatch of een gedetecteerd automatiseringsframework step-up-MFA kan afvuren bij je identityprovider of de score in je fraud suite kan verhogen.
cside proxyt je verkeer niet en draait niet je identitybeleid of je chargeback-workflow. Het sluit het specifieke gat dat de andere twee lagen openlaten, de live, in-page sessie tussen authenticatie en uitbetaling, en overhandigt het bewijs aan de tools die handhaving doen.
Verder lezen over cside
- Oplossingen voor account takeover-preventie vergelijken
- Account takeover-fraude voorkomen: een stappenplan in 4 stappen voor bedrijven
- cside AI Agent Detection
- cside Signup Shield, voor het bovenliggende probleem van het aanmaken van valse nieuwe accounts en trialmisbruik bij de aanmelding
