Deja de comparar herramientas de account takeover como si fueran intercambiables. No lo son. Un proveedor de MFA demuestra quién inicia sesión, una suite de fraude puntúa lo que hace la cuenta después del login, y una herramienta de navegador te dice si la sesión que corre en la página es siquiera humana. Son tres trabajos distintos en tres momentos distintos. Una tabla de funcionalidades que las amontona oculta la pregunta que necesitas responder: ¿qué capa te falta?
Esta guía compara prevención de ATO por capa defensiva (identidad/MFA, suite de fraude y navegador+bot), no por logo de vendor. Para cada capa verás qué observa, cuándo actúa, qué hueco deja abierto y dónde cside añade evidencia de navegador que las otras dos no pueden capturar. Sin precios inventados ni checklists falsas.
La razón para pensar en capas es simple: los atacantes se mueven por un camino. Credenciales robadas se validan con bots, sesiones válidas se secuestran después de que la MFA pase, y el fraude solo aparece en la transacción. Cada capa cubre una parte del camino y se queda ciega en el resto.
Compara la prevención de ATO por capa defensiva
| Capa defensiva | Qué demuestra | Cuándo actúa | Punto ciego que deja |
|---|---|---|---|
| Identidad / MFA | Quién se autentica | En login, antes de la sesión | Robo de sesión y AiTM después de que pasa el factor |
| Suite de fraude | Si las acciones de la cuenta parecen riesgosas | Después del login, en la transacción | Sesiones automatizadas o secuestradas que parecen "normales" hasta el cobro |
| Navegador + bot | Si la sesión en sí es humana y confiable | En la página, durante la sesión | Política de identidad del servidor e historial transaccional entre comercios |
Lee la tabla por su última columna. La debilidad de cada capa es la razón de existir de otra capa. Compra para cerrar el punto ciego que realmente tienes, no para acumular la lista de funcionalidades más larga.
Capa 1, Identidad y MFA: demuestra quién, no cómo
La capa de identidad (Okta, Microsoft Entra ID y similares) decide si una credencial más un segundo factor deberían abrir la puerta. Las políticas adaptativas pueden pedir un desafío adicional cuando el contexto del login parece raro, como un dispositivo nuevo, una geografía nueva o una velocidad extraña. Es la base, y factores resistentes al phishing como passkeys (WebAuthn bajo NIST SP 800-63B AAL2/AAL3) cierran el credential stuffing como camino.
El punto ciego es todo lo que pasa después de que el factor pasa. Un proxy adversary-in-the-middle permite que la víctima se autentique normalmente, MFA incluida, roba el token de sesión resultante y entra. La capa de identidad ya devolvió "success". No tiene nada más que decir. Si tu único control ATO es MFA, una sesión robada parece exactamente el usuario legítimo.
Capa 2, Suites de fraude: puntúan la cuenta, tarde en el camino
Las suites de fraude (Sift, Forter y pares) puntúan eventos a lo largo del recorrido (alta, login, transacción) usando modelos de machine learning entrenados con datos entre comercios. Son fuertes al final de la monetización: picos de velocidad, cambios de dirección de envío, cambios de método de pago y flujos de chargeback. Para una empresa con equipo de fraud ops y volumen real de chargebacks, esta capa se paga sola.
Dos límites honestos. Primero, las señales más fuertes llegan tarde, cerca de la transacción, después de que el takeover ya ocurrió. Segundo, la inteligencia de dispositivo incorporada en una suite es una función dentro de una puntuación de caja negra, no un stream de señales crudas de navegador que tú controlas. Cuando una sesión automatizada se comporta como un humano paciente hasta el pago, la suite suele puntuarla como limpia hasta el fraude. Un account takeover impulsado por bots es justo el caso en que esa puntuación llega demasiado tarde.
De datos de cside: las instalaciones de playwright-stealth (tooling de automatización diseñado para ocultar que un navegador lo controla un script) crecieron aproximadamente 10x durante 2025 según el informe de cside sobre el futuro de la seguridad web. Ese es el kit al que las suites de fraude tienen menos visibilidad, porque imita un navegador normal en la capa transaccional.
Capa 3, Navegador y bot: ¿esta sesión es siquiera humana?
La capa de navegador se ejecuta en la página y responde la pregunta que las otras dos no pueden: ¿esta sesión es un humano real en un navegador real, o un framework de automatización con credenciales humanas? Es la capa que más se compra de menos, y se sienta justo en el hueco entre "MFA aprobada" y "transacción liquidada".
Señales concretas que captura esta capa y que nunca llegan a una puntuación del servidor:
navigator.webdrivery banderas de automatización: la propiedad que los navegadores exponen cuando una sesión está controlada por WebDriver/CDP, además de rastros residuales que los plugins stealth intentan parchear y no cubren.- Fugas CDP y Runtime: actividad de Chrome DevTools Protocol y artefactos
Runtimeque delatan un navegador headless o controlado remotamente aunque el user agent parezca normal. - Deriva de fingerprint: la misma "cuenta" presentando fingerprints de dispositivo inconsistentes o rotados entre logins, una señal típica de granjas de bots y tooling compartido de replay de sesiones.
- Comportamiento de proxy residencial y VPN: señales de comportamiento que muestran que una IP residencial aparentemente limpia se usa para lavar tráfico automatizado, más allá de una simple blocklist de IPs.
- Scripts maliciosos en la página: overlays de robo de credenciales o lógica de redirección AiTM inyectada mediante scripts de terceros o propios, capturada en runtime antes de que el usuario sea phisheado.
Esa última señal conecta con el punto ciego de la capa 1. Los atacantes inyectan overlays CSS y scripts no autorizados en páginas legítimas para empujar a los usuarios hacia un login falso que proxifica su código MFA en tiempo real. La capa de identidad ve una autenticación limpia; la capa de navegador ve el script inyectado y la sesión controlada.
Cómo comprar entre las tres capas
No compres la checklist más larga. Compra la capa que tu ruta de ataque deja abierta.
- Mapea tu camino. Escribe login → validación → acceso → persistencia de sesión → monetización, y marca qué capa observa cada paso.
- Encuentra el punto único de fallo. Si MFA es tu único control ATO, tu hueco es robo de sesión. Es un problema de capa de navegador, no de MFA más fuerte.
- Evita señales duplicadas sin acción compartida. Dos herramientas marcando "dispositivo nuevo" son desperdicio si ninguna puede hacer enforcement.
- Ejecuta una prueba real. Reproduce incidentes históricos contra la capa candidata y verifica si habría marcado la sesión, no solo la transacción.
- Conecta el traspaso. Una señal de navegador debería activar step-up MFA en la capa 1 o alimentar una puntuación de riesgo en la capa 2, vía API o webhook, para que cada capa actúe con la evidencia de las demás.
Dónde encaja cside
cside es la capa de navegador y bots, y está diseñada para alimentar a las otras dos, no para sustituirlas. Se ejecuta client-side para capturar señales de dispositivo e IP real, detección de agentes IA y bots, detección de comportamiento VPN/proxy y visibilidad en runtime de los scripts que se ejecutan en tus páginas de login y checkout. Esas señales se envían por API y webhook, para que un desajuste de dispositivo o un framework de automatización detectado active step-up MFA en tu proveedor de identidad o eleve la puntuación dentro de tu suite de fraude.
cside no proxifica tu tráfico y no ejecuta tu política de identidad ni tu flujo de chargebacks. Cierra el hueco específico que dejan las otras dos capas, la sesión viva, dentro de la página, entre autenticación y pago, y entrega la evidencia a las herramientas que hacen enforcement.
Lecturas adicionales en cside
- Comparar soluciones para prevención de account takeover
- Cómo prevenir el fraude por account takeover: guía en 4 pasos para empresas
- cside AI Agent Detection
- cside Signup Shield, para el problema previo de la creación de cuentas nuevas falsas y el abuso de pruebas en el registro
