La solicitud llega como una casilla. Una firma de doce personas quiere doble factor para todos, y la opción está ahí en la consola de administración. Lo que falla nunca es la casilla. Es el vendedor que se verifica con un mensaje de texto que ya no se va a aceptar, el escáner de la oficina que lleva años enviando documentos firmados con una contraseña, y la única cuenta de superadministrador en manos del dueño, que viaja justo el día en que la obligación entra en vigor.
Forzar la verificación es una fecha límite, no una función. Desde el momento en que aplica, una cuenta sin segundo paso no puede iniciar sesión, y el camino de regreso pasa por un administrador. Por eso casi todo el trabajo ocurre antes de tocar la opción. Este es el orden que usamos en proyectos de clientes, y los tres lugares donde se atoran los equipos pequeños.
Qué hace realmente la obligación
Hay dos interruptores distintos en el mismo lugar: en la consola de administración, entra a Seguridad, luego Autenticación y luego Verificación en dos pasos. Solo los superadministradores pueden cambiarlos.
El primero permite que la gente active la verificación en dos pasos por voluntad propia. El segundo, la obligación, la vuelve condición para iniciar sesión. Tiene dos formas. Activada empieza de inmediato. Activar la obligación a partir de una fecha recibe una fecha de inicio, y Google es claro en que esa opción es aproximada: la obligación empieza dentro de las 24 a 48 horas siguientes a la fecha que elegiste. Si necesitas un momento exacto, porque quieres a alguien en su escritorio para contestar el teléfono cuando pase, usa Activada. Durante una ventana con fecha, la gente ve recordatorios al iniciar sesión y Google también puede escribirles.
Cualquiera de los dos interruptores se puede limitar a una unidad organizativa en vez de todo el dominio, y eso es lo que permite una implementación por etapas. Algo más antes de planear: la página de ayuda de Google sobre la obligación de 2SV para administradores dice que Google está exigiendo verificación en dos pasos en las cuentas de administrador, con un despliegue gradual, y que durante su periodo de notificación la política de Google tiene precedencia sobre la que tú configuraste. Consultado el 6 de noviembre de 2026. Las cuentas de administrador ya corren contra un reloj que no es tuyo.
Antes de la opción: averigua quién ya está inscrito
El reporte está en Informes, luego Informes de usuarios y luego Seguridad, y requiere el privilegio de administrador de informes. Agrega la columna de inscripción en la verificación en dos pasos y, si también quieres ver a quién ya cubre una política, la columna de obligación.
Léelo como una foto atrasada. La misma página de ayuda dice que esos datos pueden tardar hasta 48 horas y te manda a la página de seguridad de cada usuario para ver el estado en tiempo real; la página de Google sobre retención y tiempos de retraso da una cifra más amplia para el mismo reporte, de 1 a 5 días. Usa el reporte para ver la forma del problema, y revisa a las personas una por una en su página de usuario en los días previos, porque ese es el dato que decide quién puede entrar esa mañana.
Si piensas prohibir los códigos por mensaje de texto y por llamada, primero encuentra a quienes los usan. Google señala el evento login_verification del registro de auditoría de inicio de sesión justamente para eso.
La implementación que hacemos, en orden
Seis pasos. La tercera columna es la que te dice que ya puedes avanzar.
| Paso | Qué cambiamos | Qué revisamos antes de avanzar |
|---|---|---|
| 1. Avisar | Activar la opción voluntaria en todo el dominio y anunciar la fecha por escrito | Todavía nadie puede quedar fuera. El aviso dice la fecha, los métodos permitidos y a quién llamar |
| 2. Administradores primero | Inscribir cada cuenta de administrador con un método resistente a phishing, más una llave o passkey de repuesto | Cada cuenta de administrador aparece inscrita en su propia página de usuario, no solo en el reporte |
| 3. Una segunda entrada | Agregar un segundo superadministrador y confirmar los datos de recuperación en ambas cuentas | La segunda persona entra hoy a la consola de administración, no en teoría |
| 4. Ensayo | Forzarla en una sola unidad organizativa: un equipo pequeño y cerca de quien puede ayudar | Esa unidad está inscrita por completo y el registro de auditoría no muestra fallas nuevas de verificación |
| 5. El resto | Forzarla en las demás unidades, con un periodo corto de inscripción para usuarios nuevos | Cada rezagado está inscrito o puesto en un grupo donde la verificación no se exige |
| 6. Apretar | Restringir los métodos permitidos cuando ya nadie dependa de textos ni llamadas | El registro de auditoría ya no muestra verificaciones por mensaje de texto ni por llamada |
Qué segundos pasos conviene permitir
Google da tres opciones para los métodos que la gente puede usar: Cualquiera; cualquiera excepto códigos por mensaje de texto o llamada; y solo llave de seguridad.
La del medio es la mejora típica y también el accidente típico. Google advierte sin rodeos que quienes se verifican con textos y llamadas quedarán fuera de sus cuentas, y por eso el paso 6 va después de que el registro de auditoría está limpio.
Solo llave de seguridad es la configuración estricta, y es más amplia de lo que sugiere su nombre: la guía de implementación de Google dice que la opción ahora admite passkeys además de llaves de seguridad, y que ambas ofrecen el mismo nivel de protección contra phishing. Trae dos consecuencias: tienes que definir un periodo de gracia para los bloqueos, y los usuarios no pueden generar sus propios códigos de respaldo, así que un administrador tiene que entregárselos.
Los códigos de seguridad existen para equipos donde no se puede usar una llave directamente. La recomendación de Google es que usar llaves de seguridad o passkeys de forma directa da la máxima protección contra phishing, así que los habilitamos solo cuando un equipo específico lo obliga, y dejamos anotado cuál es.
Las passkeys son primero un segundo paso y después un reemplazo de contraseña
Son dos cambios distintos y se confunden todo el tiempo. Una passkey usada como método de verificación no necesita ninguna configuración extra. Permitir que alguien entre sin escribir contraseña es otra cosa: Seguridad, luego Autenticación y luego Sin contraseña, y requiere el privilegio de administrador de configuración de seguridad. Viene desactivado, y desactivado significa que la gente igual puede crear y usar passkeys como segundo paso.
Dos detalles deciden cómo sale ese piloto. La opción del administrador es solo la mitad: cada usuario también tiene que activar el salto de contraseña y agregar una passkey en su propia cuenta, y su contraseña actual no se elimina. Y los usuarios no necesitan estar inscritos en la verificación en dos pasos para saltarse la contraseña con una passkey, que es justamente por lo que primero terminamos el trabajo de la obligación en vez de tratar las passkeys como un atajo para evitarla.
Si después desactivas la opción sin contraseña, ya nadie puede saltarse la contraseña, pero su passkey sigue sirviendo como segundo paso. Dos límites: el Proveedor de credenciales de Google para Windows no admite inicio de sesión sin contraseña, y los invitados de Workspace siempre entran con contraseña.
Qué se rompe la semana que la activas
La impresora. Siempre la impresora, y con ella el escáner, la máquina de contabilidad y cualquier script viejo que manda correo con usuario y contraseña. Desde el 1 de mayo de 2025, las cuentas de Workspace ya no admiten apps menos seguras, apps de terceros ni dispositivos que piden iniciar sesión con usuario y contraseña de Google, así que esos clientes necesitan OAuth. Cuando un dispositivo se autentica de forma directa y la verificación está activa, Google documenta el síntoma como un error de autenticación y la solución como una contraseña de aplicación: un código de 16 dígitos que solo se puede crear en una cuenta con verificación en dos pasos activada. Para impresoras y escáneres viejos que no manejan OAuth, la opción que Google recomienda es la retransmisión SMTP.
Arma ese inventario antes del día de la obligación. Las contraseñas de aplicación que ya tiene un usuario aparecen en su página en la consola de administración, y tanto tú como la persona pueden revocarlas, lo que convierte esa lista en un buen mapa de lo que está por romperse.
Pasar un dispositivo del inicio de sesión directo a la retransmisión SMTP también cambia el camino por el que sale tu correo, así que tu registro SPF tiene que cubrir el nuevo. Revisa que el dominio siga autenticando antes de la próxima corrida de facturas, no después de que un cliente te diga que nunca le llegó el recibo.
Las rutas de recuperación que deben estar listas antes de la fecha
Códigos de verificación de respaldo. Abre al usuario en la consola de administración, entra a Seguridad, luego Verificación en dos pasos, luego Obtener códigos de verificación de respaldo, y dicta un código a la persona. Los usuarios no pueden generarlos por su cuenta. Un juego nuevo invalida cualquier código anterior, y la ventana para usarlos empieza cuando los generas, así que se crean el día que se necesitan y no se guardan por adelantado. Solo un superadministrador puede generar códigos para otro administrador.
Más tiempo, pero con nombre. La forma documentada por Google para dar más plazo a un rezagado es agregarlo a un grupo donde la verificación no se exige. Es mejor que posponer toda la implementación y, como es un grupo, puedes ver quién está dentro y vaciarlo después.
Y luego la que nadie planea: el único superadministrador es la persona que quedó fuera. La recuperación pasa por la ruta de recuperación de acceso de administrador de Google, que te pide demostrar que el dominio es tuyo con un registro CNAME y contacta primero a los administradores existentes. Funciona y es lenta. Prevenirla casi no cuesta: más de un superadministrador, una llave de seguridad de repuesto guardada en un lugar seguro, y tener claro que solo otro superadministrador puede emitir códigos para una cuenta de administrador.
Qué vigilamos el mes siguiente
Cuatro cosas, en este orden. Que la inscripción llegue a todos, leída en las páginas de usuario y no en el reporte. Las contrataciones nuevas, que son la fuga habitual: el periodo de inscripción para usuarios nuevos es opcional y se puede fijar entre 1 día y 6 meses, y durante ese tiempo una cuenta nueva entra solo con contraseña, así que uno generoso deshace la política en silencio para cada persona que contratas. Que la lista de contraseñas de aplicación se encoja conforme los dispositivos pasan a OAuth o a retransmisión. Y un recordatorio en el calendario para confirmar que la cuenta del segundo superadministrador todavía entra, porque el día que la necesitas es un mal día para averiguarlo.
Vale decirlo con claridad: un segundo paso encarece una contraseña robada, no vuelve la cuenta imposible de engañar. Ya documentamos un robo real que pasó por encima del 2FA, y los métodos resistentes a phishing son la parte de esta implementación que de verdad responde a eso.
Cómo ayuda Guanacos Tech
Lo hacemos como un proyecto corto: inventario de quién se verifica cómo, cuentas de administrador endurecidas primero, una unidad forzada como ensayo, luego el resto con la recuperación lista, y los dispositivos resueltos antes de que se rompan. Si prefieres que la implementación pase sin una mañana de gente sin acceso, ese es el trabajo que hacemos como consultores de Google Workspace. Una llamada de 30 minutos alcanza para decirte cuáles de tus cuentas quedarían fuera si lo activaras mañana.
Fuentes
- Deploy 2-Step Verification, Google Workspace Admin Help
- Avoid account lockouts when 2-Step Verification is enforced by your organization
- About 2SV enforcement for admins
- Manage a user's security settings (backup verification codes, app passwords)
- Allow users to skip passwords at sign-in
- User reports: Security (2-Step Verification enrollment column)
- Send email from a printer, scanner, or app
- Recovering administrator access to your account