Passkeys y multi-cuentas: aislamiento de claves en 2026

A partir del 1 de septiembre de 2026, Microsoft comenzará a incluir passkeys como método de inicio de sesión predeterminado en Entra ID, y a partir del 1 de febrero de 2027, desactivará la entrega de códigos SMS y de voz. Google hizo de las claves de acceso la opción principal de inicio de sesión para cuentas personales en octubre de 2023. Para una persona con una sola cuenta, esto es conveniente. Para aquellos que manejan decenas de cuentas en un entorno de anti-detección, el passkey se convierte fácilmente en un hilo invisible que conecta perfiles aislados entre sí. A continuación, analizamos cómo ocurre esto y cómo construir un esquema en el que las claves no "fugan" entre cuentas.

Por qué la cuestión surge ahora

Los passkeys existen desde 2022, pero en 2026 pasaron de "se puede activar" a "se le pedirá". Tres razones concretas:

Microsoft Entra ID. A partir de septiembre de 2026, a los usuarios que confirmaron el inicio de sesión por SMS o llamada se les activarán automáticamente los passkeys: en la próxima verificación de MFA, aparecerá la opción de registrar una clave. Hasta el 31 de enero de 2027 se puede posponer, pero a partir del 1 de febrero de 2027 no se podrá omitir. Microsoft justifica esto con su cifra: las campañas de phishing con IA reciben el 54% de los clics frente al 12% de las normales.
Google. Desde octubre de 2023, en cuentas personales, la opción "Omitir la entrada de contraseña cuando sea posible" está activada por defecto. Si se ha creado una clave, Google ofrece iniciar sesión con ella.
Transferencia de claves entre gestores. La FIDO Alliance publicó el estándar Credential Exchange (formatos CXF y CXP). En iOS 26 y macOS 26, se pueden transferir passkeys entre Apple Passwords, 1Password, Bitwarden, Dashlane y otras aplicaciones de manera cifrada, sin necesidad de exportar un archivo. La clave dejó de estar atada de forma permanente a un solo almacén. Para el multi-cuentas, esto es tanto una oportunidad como un riesgo.

Cómo funciona un passkey y por qué rompe la aislamiento de perfiles

Un passkey es un par de claves criptográficas. La clave pública la almacena el sitio, la clave privada la guarda el "autenticador". La clave está vinculada al dominio (en la especificación se llama rpId), por lo que un sitio de phishing no podrá obtenerla. La pregunta principal para el multi-cuentas es dónde se encuentra físicamente la clave privada. El anti-detección aisla cookies, localStorage, IndexedDB y huellas digitales. El almacenamiento de claves a menudo se encuentra fuera del perfil del navegador:

Windows Hello almacena las claves a nivel de cuenta de Windows. Cualquier navegador y cualquier perfil bajo esta cuenta accede al mismo almacenamiento.
La vinculación de claves de iCloud en macOS pertenece al Apple ID. Chrome y Safari en una misma Mac ven un conjunto de claves.
El gestor de contraseñas de Google está vinculado a la cuenta de Google con la que se ha iniciado sesión en el navegador o el teléfono. Una cuenta de Google de servicio en veinte perfiles es una única bóveda compartida.
Las extensiones-gestores (Bitwarden, 1Password y otros) almacenan las claves en el almacenamiento de su cuenta. Un único almacenamiento para todos los perfiles funciona como un único punto, a través del cual se puede ver todo.

De aquí proviene un fallo típico. Usted hace clic en "Iniciar sesión con la clave de acceso" en el perfil de la cuenta número 7, y el sistema muestra las claves de las cuentas número 3 y 12 en el mismo sitio. El sitio no ve esta lista: solo recibe la clave seleccionada. Pero un clic incorrecto — y la cuenta número 3 inicia sesión desde el perfil, IP y huella de la cuenta número 7. Tal conexión ya no se puede deshacer.

Qué sabe realmente el sitio al iniciar sesión con un passkey

El passkey no elimina el riesgo de scoring, simplemente reemplaza la contraseña. Al iniciar sesión, la plataforma sigue viendo la IP, la huella del navegador y el historial de sesiones. Además, recibe varias señales propias de WebAuthn:

Identificador de clave (credential ID). Es único para el par "cuenta — autenticador".
AAGUID — identificador del modelo del autenticador. Con él, sitios como Google firman la clave en la configuración de la cuenta: "creado en iCloud Keychain", "en el gestor de contraseñas de Google", etc. No es un número único de su dispositivo, pero es otra característica que debe coincidir con la leyenda del perfil.
Flags BE y BS (backup eligibility y backup state) indican si esta clave está sincronizada o vinculada al dispositivo.

Conclusión: un perfil "móvil" que inicia sesión con una clave de Windows Hello se ve tan ilógico como un iPhone con la zona horaria de Brasil y una IP de Alemania. La clave debe coincidir con la misma leyenda que el proxy y la huella.

Esquema paso a paso: una cuenta — un perfil — un almacenamiento — una IP

Realice un inventario. Anote las plataformas donde sus cuentas ya tienen passkeys o han recibido la oferta de crearlas: Google, Microsoft, grandes marketplaces y redes sociales. En la configuración de seguridad de cada cuenta se puede ver cuántas claves están registradas y dónde fueron creadas. Todas las entradas inesperadas "Windows Hello" y "iCloud Keychain" son candidatas para eliminación.
Desactive el almacenamiento de claves del sistema para perfiles de trabajo. En el navegador donde funcionan los perfiles, desactive el guardado de contraseñas y claves de acceso en el gestor integrado. En la máquina de trabajo, no cree claves en Windows Hello o en la vinculación de iCloud. Si la ventana de creación de claves ofrece "este ordenador", elija otro método.
Elija un almacenamiento para cada cuenta. La regla es simple: el almacenamiento debe estar separado de la misma manera que los perfiles. Opciones:
- almacenamiento separado del gestor de contraseñas por cuenta o por grupo de cuentas de un mismo cliente;
- una clave hardware (FIDO2) para las cuentas más valiosas;
- para la automatización — un autenticador de software, que se detalla en el paso 6.
Un único almacenamiento para todos es la forma más común de vincular cuentas entre sí.
Registre la clave solo desde el perfil "nativo". El mismo perfil, la misma huella, el mismo proxy con sesión fijada, la misma geolocalización que durante el trabajo normal de la cuenta. Registrar una clave es una acción sensible, y las plataformas la observan detenidamente. Cambiar la IP a mitad del procedimiento a menudo lleva a una verificación adicional. Cómo mantener una dirección única para el perfil, lo hemos analizado en el artículo sesión sticky o rotación para el perfil de anti-detección.
Deje un acceso de respaldo. Un almacenamiento perdido significa una cuenta perdida. Para cada cuenta, se necesita un segundo método de acceso: un segundo passkey en otro almacenamiento, una contraseña con TOTP o códigos de recuperación que se guardan por separado de la clave. Microsoft en Entra exige directamente que los usuarios sean trasladados a métodos resistentes al phishing antes de febrero de 2027. No espere a que la ventana de registro deje de cerrarse.
En la automatización, use un autenticador virtual. En el Chrome DevTools Protocol hay un dominio WebAuthn. El método addVirtualAuthenticator crea un autenticador de software con el protocolo ctap2 y transporte internal (plataforma) o usb/hybrid. Los parámetros hasResidentKey y hasUserVerification incluyen el almacenamiento de la clave en el autenticador y la verificación del usuario. getCredentials después del registro devuelve la clave completa: credentialId, rpId, userHandle, signCount y la clave privada en formato PKCS#8. addCredential en el siguiente inicio la coloca de nuevo. Se obtiene una clave que vive solo en su almacenamiento secreto y se conecta a la sesión de una cuenta específica. Dos advertencias: el dominio está marcado como experimental y creado para probar WebAuthn, y la clave privada exportada es un secreto de nivel de contraseña, por lo que debe almacenarse en consecuencia.
Transfiera las claves a través de Credential Exchange, no manualmente. Si cambia de gestor o distribuye cuentas en diferentes almacenes, use la exportación integrada según el estándar FIDO: es compatible con Apple Passwords, 1Password, Bitwarden, Dashlane, DuckDuckGo, Devolutions. Tenga en cuenta que en macOS, algunas aplicaciones aún no han implementado este mecanismo.

Trampas

Sincronización por defecto. Una clave creada "en este dispositivo" puede ir inmediatamente a la nube de iCloud o Google y aparecer en todos los dispositivos de esa cuenta, incluido su teléfono personal.
Inicio de sesión cruzado por QR. El escenario "escanee el QR con el teléfono" (transporte híbrido) conecta a la sesión del perfil un teléfono real con sus claves. Para perfiles de trabajo, esto es una conexión adicional.
El mismo AAGUID en toda la granja es normal. Millones de personas utilizan el mismo gestor. No es peligroso un proveedor idéntico, sino una clave común o un almacenamiento compartido.
El passkey no soluciona el "inicio sucio". Si la cuenta inicia sesión con una IP que ya ha sido expuesta en cuentas vecinas, o desde un centro de datos que la plataforma no acepta, una fuerte criptografía no ayudará. El riesgo se evalúa en función de la combinación de señales.
El segundo factor también debe ser aislado. Si el acceso de respaldo es TOTP, los secretos también se distribuyen entre cuentas, y no se almacenan en una sola aplicación en su teléfono personal. Cómo vincular 2FA y proxy, lo hemos analizado en el material sobre la autenticación de dos factores en el trabajo a través de proxy.

Qué proxy se necesita y por qué

Para iniciar sesión con una clave, lo más importante es la constancia: la cuenta debe registrar la clave y luego iniciar sesión con ella desde la misma red, en la misma geolocalización. Por lo tanto:

Perfiles web en anti-detección — proxies residenciales con sesión fijada en el país de la cuenta. Estas son direcciones de proveedores locales, y coinciden con la leyenda de "usuario común en casa".
Plataformas móviles y cuentas con leyenda móvil — proxies móviles. Un perfil móvil que registra una clave desde una red doméstica en el otro extremo del país se sale de su historia.
Rotación en cada solicitud es adecuada para scraping, pero no para iniciar sesión en cuentas. Establezca un intervalo con margen para toda la sesión de trabajo.

Conclusión

Los passkeys hacen que el inicio de sesión sea resistente al phishing, pero trasladan el punto de conexión entre cuentas de cookies y contraseñas al almacenamiento de claves. Este punto a menudo se encuentra fuera del perfil de anti-detección: en Windows Hello, iCloud, cuenta de Google o almacenamiento compartido del gestor. El esquema de trabajo se ve así: cada cuenta tiene su perfil, su almacenamiento de claves, su IP permanente y un método de acceso de respaldo. Para la automatización, hay un autenticador virtual en CDP. Ocúpese de esto antes de febrero de 2027, cuando Microsoft dejará de permitir posponer el registro. Después, tendrá que resolverlo con prisa y directamente en cuentas activas.