Google Ads API exigirá passkeys a partir de agosto de 2026

Google empezará a exigir passkeys en el flujo de inicio de sesión de la Google Ads API que emite nuevas credenciales, y el cambio comenzará a implementarse el 5 de agosto de 2026. El flujo de autenticación que genera nuevos refresh tokens de OAuth 2.0 tendrá que completar una verificación con passkey, y el inicio de sesión solo con contraseña y los métodos de doble factor más antiguos, como los códigos SMS y las contraseñas de un solo uso basadas en tiempo, ya no se aceptarán para ese paso. Para las marcas y agencias que gestionan Google Ads a gran escala mediante automatización, se trata de un plazo de seguridad ineludible, no de una mejora opcional.

Qué ha pasado

El 27 de julio de 2026, el Google Ads Developer Blog anunció que «la Google Ads API empezará a exigir passkeys a los usuarios de la Google Ads API». Está previsto que la implementación comience el 5 de agosto y llegue a todos los usuarios en las semanas siguientes.

El requisito se aplica al flujo de autenticación de usuario que genera nuevos refresh tokens de OAuth 2.0. Los refresh tokens existentes no se ven afectados: siguen funcionando, y las integraciones no tendrán que reautorizarse cuando los intercambien por access tokens. Lo que cambia es el acto de autorizar un token nuevo. A los usuarios nuevos se les pedirá iniciar sesión con una passkey y, si no tienen ninguna, se les invitará a crear una. Google también señala un retraso de confianza de hasta siete días antes de que una passkey recién creada se considere de confianza y pueda usarse, por lo que recomienda configurarla con antelación en lugar de esperar al momento en que haya que emitir un token.

El alcance va más allá del código escrito directamente contra la API. Google mencionó Google Ads Editor, Google Ads scripts, BigQuery Data Transfer Service y los conectores de Data Studio entre las herramientas que también empezarán a exigir autenticación basada en passkeys.

Por qué importa

Las contraseñas y los códigos de un solo uso por SMS o por aplicación son exactamente los factores que los ataques de phishing y de apropiación de cuentas están diseñados para capturar. Las passkeys son resistentes al phishing: están vinculadas al sitio legítimo y no se pueden suplantar ni reutilizar como sí ocurre con una contraseña o un código de un solo uso, por lo que este cambio cierra una vía de entrada muy explotada hacia cuentas publicitarias que gestionan presupuestos y datos de clientes. La contrapartida es operativa: cualquier equipo que haya automatizado la generación de tokens asumiendo que una contraseña más un código de un solo uso son suficientes se encuentra ahora con un paso que un script no puede completar en silencio.

Qué significa esto para las marcas con múltiples ubicaciones

Para un equipo central de marketing o martech que gestiona Google Ads en cientos o miles de ubicaciones, el riesgo aquí es una interrupción silenciosa de la automatización, más que un inicio de sesión bloqueado. Las cargas masivas mediante Google Ads Editor, los scripts programados y las transferencias de datos de BigQuery dependen todas del flujo de tokens que está cambiando, y un token que no se pueda regenerar en agosto detiene el proceso que alimenta.

El trabajo por hacer antes de la fecha límite es de gobernanza, no de clics. Haz un inventario de todas las integraciones y conectores que ejecutan el flujo de autenticación de usuario contra la Google Ads API, ya que ese es el flujo que cambia; el acceso mediante cuentas de servicio utiliza sus propias credenciales y no forma parte de este requisito. Confirma qué identidades de usuario emiten nuevos refresh tokens y asegúrate de que cada una de esas identidades tenga ya registrada una passkey de confianza, teniendo en cuenta el retraso de confianza de siete días. Decide quién custodia las passkeys de las cuentas compartidas o gestionadas por equipos, y documéntalo, para que el dispositivo de un solo empleado que se marche no sea el motivo por el que todo un conjunto de campañas nacionales no pueda volver a autenticarse. Reforzar el acceso a las plataformas que sustentan tu presencia y tus datos publicitarios es la misma disciplina que hay detrás de la postura de PinMeTo en materia de ISO 27001 y residencia de datos en la UE: controla quién y qué puede acceder a las cuentas, y demuéstralo.

«La Google Ads API empezará a exigir passkeys a los usuarios de la Google Ads API.»

Google Ads Developer Blog

En resumen

Las automatizaciones existentes siguen funcionando con sus refresh tokens actuales, y las renovaciones habituales de access tokens no se ven afectadas, así que nada se rompe el propio 5 de agosto. La exposición se produce la primera vez que cada integración tiene que generar un nuevo refresh token de OAuth después de la implementación, que es cuando una passkey ausente se convierte en un flujo de trabajo bloqueado. Las marcas que gestionan Google Ads y los datos de sus ubicaciones a través del API Suite de PinMeTo y coordinan su actividad publicitaria local de pago mediante las campañas publicitarias locales deberían registrar sus passkeys y asignar responsables ahora mismo, antes de que la implementación comience el 5 de agosto y llegue a sus cuentas en las semanas posteriores, y deberían tener en cuenta el retraso de confianza de siete días de las passkeys al hacerlo.