Google hará obligatorio el uso de autenticación multifactor (MFA) para la generación de nuevos tokens OAuth 2.0 en la Google Ads API a partir del 21 de abril de 2026. La medida fue reportada por Search Engine Land el 17/4/2026 y se aplicará por defecto a nuevas autenticaciones; los tokens OAuth existentes seguirán funcionando sin interrupción (Search Engine Land, 17/4/2026). En la práctica, esto obliga a que quien genere credenciales mediante flujos estándar valide su identidad con un segundo factor como teléfono o app autenticadora.

¿Cómo impacta esto en el mercado argentino?

La noticia mejora la seguridad pero sube la complejidad operativa para agencias y anunciantes locales que dependen de flujos de autenticación manuales y de equipos distribuidos. La medida entra en vigor cuatro días después del anuncio (del 17 al 21/4/2026), así que hay poco margen para cambios en procesos internos (Search Engine Land, 17/4/2026). A nivel de riesgo, la evidencia pública sugiere que MFA reduce drásticamente el compromiso de cuentas: Microsoft reportó en 2019 que la adopción de MFA bloquea el 99.9% de intentos de acceso malicioso (Microsoft Security, 2019). Para los equipos argentinos esto es un trade-off claro: menos riesgo de fugas de datos pero más fricción en generación de credenciales y rotación de tokens. Recomendamos auditar quién genera tokens hoy, centralizar permisos y planificar la migración de flujos humanos a cuentas de servicio donde sea posible, para no frenar la operación comercial.

Qué hay que cambiar en el stack técnico y operativo

La actualización obliga a revisar tres puntos concretos: 1) workflows de autenticación de usuario, 2) automatización y CI/CD que generan tokens, y 3) gobernanza de credenciales. Google aclara que los service accounts no se ven afectados y son la opción recomendada para casos automatizados y offline (Search Engine Land, 17/4/2026). Eso implica readecuar scripts y pipelines para operar con cuentas de servicio o bien integrar MFA en los procesos de emisión de refresh tokens cuando el flujo sea inevitablemente humano. Desde el punto de vista de datos, es momento de exigir propiedad y trazabilidad: quién creó cada token, con qué alcance y cuándo expirará. La lista de herramientas implicadas —Ads Editor, Scripts, BigQuery Data Transfer y Data Studio— obliga a coordinar cambios con equipos de analytics y seguridad para evitar interrupciones en transferencias y reportes (Search Engine Land, 17/4/2026).

¿Es esto un problema o una oportunidad para la estrategia?

Es las dos cosas. La imposición de MFA sube la barrera operativa —más pasos para generar credenciales, formación del personal, ajuste de pipelines— pero reduce exposición a accesos no autorizados. Desde la lente estratégica, vemos esto como un recordatorio de prioridades: validar identidad continuamente, asegurar una atribución limpia y retener la propiedad de los datos antes de escalar automatismos o contenidos generados por IA. En términos prácticos, conviene tratar la medida como un catalizador para limpiar el stack: auditar tokens, migrar a service accounts donde corresponda y documentar procesos. Comparado con el estado anterior, donde MFA era opción, ahora la seguridad se vuelve estándar para nuevos tokens; eso obliga a rediseñar workflows, no a improvisar parches. Para equipos que priorizan ventas y branding, la conclusión es clara: invertir unas horas en arquitectura de identidad evita perder días (o guita) por un incidente o una interrupción de acceso en plena campaña.