Autenticación basada en dispositivos: cómo funciona, métodos y ventajas de seguridad

La autenticación basada en dispositivos verifica el hardware que solicita el acceso, como un portátil, un teléfono, una llave de hardware o un sensor IoT, antes de aceptar la conexión. La autenticación de usuarios demuestra quién lo pide; la autenticación de dispositivos demuestra qué lo pide. La mayoría de las arquitecturas necesitan ambas, porque una contraseña robada solo falla en un equipo desconocido si el equipo se comprueba.

El término se aplica a varios mecanismos distintos, con costes de seguridad y de ciclo de vida muy diferentes. Esta guía los separa, explica cómo funciona cada uno, muestra dónde encaja y dónde falla, y termina con un plan para desplegarlo. La publica Hideez, un proveedor de identidad para la plantilla que describe su propio enfoque solo en la última sección.

¿Qué es la autenticación basada en dispositivos?

Entonces, ¿qué es la autenticación basada en dispositivos? Concede el acceso comprobando el dispositivo, no solo a la persona. El dispositivo demuestra su identidad con un marcador criptográfico, como un certificado o una clave privada. La autenticación de usuarios, en cambio, comprueba una contraseña, un código o un dato biométrico.

Tomemos un portátil corporativo y la VPN. Con un inicio de sesión basado solo en contraseña, cualquier equipo que conozca las credenciales puede conectarse, incluido el de un atacante. Con la autenticación de dispositivos, la pasarela acepta el portátil solo si presenta un certificado X.509 registrado cuya clave privada permanece en el TPM. Una contraseña robada, por sí sola, ya no abre la sesión. En la práctica, el término abarca cuatro enfoques, y cada uno demuestra algo distinto:

Regla de decisión: elija el método cuyo punto más débil pueda tolerar su modelo de amenazas y, a continuación, añada una segunda capa.

¿Cómo funciona la autenticación basada en dispositivos?

La autenticación de dispositivos demuestra que una solicitud procede de un equipo o token concreto, no solo de un usuario que conoce una contraseña. El servidor emite un desafío y el dispositivo responde con algo que solo él debería tener. Todos los métodos siguen esta secuencia:

1. Registro: el dispositivo se registra y se vincula a un usuario mediante una cookie, un certificado o una clave pública.
2. Desafío: el servidor pide una prueba al dispositivo.
3. Respuesta: el dispositivo devuelve una cookie, un valor firmado o un informe de postura.
4. Decisión: la política de acceso concede, restringe o deniega la sesión.
5. Revocación: la vinculación se elimina cuando el dispositivo se pierde o se retira.

La solidez depende del identificador utilizado en el paso 3. De más débil a más sólido:

• Dirección MAC: un identificador, no un secreto, y fácil de suplantar.
• Secreto compartido o cookie: se copia y se reutiliza en otro equipo.
• Certificado con clave exportable: sólido solo si la clave privada no sale de donde está.
• Clave en un TPM o elemento seguro: no exportable, por lo que la clave permanece en el chip.
• Credencial FIDO2: vinculada al origen, por lo que un sitio de phishing no puede reutilizarla.

Cada peldaño tiene su ataque correspondiente: suplantación, reutilización, extracción de claves y, en lo más alto, robo físico.

Autenticación basada en dispositivos frente a autenticación de dispositivos

Muchas fuentes utilizan ambas expresiones como sinónimos, y ningún organismo de normalización define una diferencia entre ellas. Esta guía emplea una distinción práctica que ayuda a la hora de elegir un método.

La autenticación de dispositivos identifica el propio endpoint. Responde a la pregunta «¿es este un equipo conocido?» y se aplica a portátiles, servidores y sensores IoT sin nadie ante el teclado. Las pruebas habituales son un certificado X.509, una clave almacenada en un TPM o un secreto compartido.

La autenticación basada en dispositivos es más amplia. Abarca todos los esquemas en los que un dispositivo forma parte de la prueba de acceso, incluida una llave de hardware o un teléfono que representa a una persona. En ese caso, el dispositivo actúa como factor de posesión.

La distinción condiciona el diseño. Un certificado de equipo no dice nada sobre quién está sentado ante el portátil, por lo que un factor de usuario debe seguir funcionando en paralelo, normalmente como paso de MFA. Una llave de hardware demuestra la posesión por parte de una persona, pero no dice nada sobre el estado del ordenador al que está conectada. Trate ambas como capas.

Autenticación basada en dispositivos frente a autenticación sin contraseña

La comparación entre la autenticación basada en dispositivos y el passwordless se reduce a qué se elimina y qué se demuestra. La autenticación sin contraseña elimina la contraseña del inicio de sesión. La autenticación basada en dispositivos añade un dispositivo a lo que se demuestra. Ambas se solapan, pero no son lo mismo.

• Ambas: una passkey FIDO2 almacenada en una llave de hardware o en un teléfono. La contraseña desaparece y un dispositivo guarda la credencial.
• Sin contraseña y sin vinculación al dispositivo: un código o enlace enviado por correo electrónico o SMS. La contraseña desaparece, pero nada vincula el inicio de sesión a un dispositivo registrado, y el código puede retransmitirse a través de un proxy de phishing.
• Basada en dispositivos pero con contraseña: un certificado de equipo para el acceso a la wifi o a la VPN mientras el usuario sigue escribiendo una contraseña en las aplicaciones, o una cookie de dispositivo de confianza que omite la MFA pero mantiene la contraseña.

Si el problema es la reutilización de contraseñas y el phishing, apunte a un inicio de sesión sin contraseña con credenciales vinculadas al origen. Si el problema es que equipos no gestionados acceden a la red, un certificado de dispositivo o una comprobación de postura lo resuelven mejor. La mayoría de las organizaciones combinan ambos.

Métodos comunes de autenticación basada en dispositivos

Los cuatro métodos siguientes son las credenciales más utilizadas para demostrar la posesión en el caso de personas y puestos de trabajo. Las cookies de dispositivo de confianza y las comprobaciones de postura, descritas más arriba, siguen siendo útiles como señales adicionales, y sus límites se tratan en la sección de riesgos. Cada método difiere en lo que exige al usuario, al dispositivo y al administrador.

Llaves de seguridad de hardware y autenticación FIDO2

Las llaves de seguridad de hardware son pequeños autenticadores, conectados por USB, NFC o Bluetooth, que almacenan claves privadas y firman desafíos. En la autenticación FIDO2, la llave crea un par de claves independiente para cada sitio. La clave privada nunca sale de la llave, el servidor solo almacena la clave pública y la firma está vinculada al origen del sitio, de modo que un sitio de phishing en otro dominio no puede obtener una respuesta utilizable. La FIDO Alliance lo describe como criptografía de clave pública en un intercambio de desafío-respuesta, sin ningún secreto compartido que un atacante pueda capturar.

El usuario desbloquea la llave con un PIN o un toque, por lo que un atacante necesita tanto la llave física como su PIN. Son credenciales vinculadas al dispositivo en sentido estricto: nunca salen del hardware.

Los costes son operativos. Las llaves deben distribuirse, y una llave perdida necesita una vía de recuperación que no sea una puerta trasera débil: registre una segunda llave por usuario, o verifique la identidad antes de emitir una sustituta, y revoque de inmediato la llave perdida. Las certificaciones se conceden por modelo, así que compruebe el modelo exacto; Hideez Key 5, por ejemplo, cuenta con la certificación FIDO2. Las llaves de hardware son adecuadas para puestos de trabajo compartidos, entornos sin teléfono y cuentas privilegiadas.

Autenticación con dispositivos móviles y passkeys

Un teléfono puede demostrar la posesión de tres formas: una aprobación push, un código de un solo uso o una passkey. Un OTP es cualquier contraseña de un solo uso; TOTP es la versión basada en el tiempo, generada a partir de un secreto compartido y del reloj. Ambos pueden introducirse en una página de phishing y retransmitirse al sitio real en tiempo real. Una passkey no puede retransmitirse, porque está vinculada al origen.

Las passkeys son credenciales FIDO, y la FIDO Alliance distingue dos tipos. Las passkeys sincronizadas se copian entre los dispositivos de un usuario a través del servicio en la nube del proveedor, lo que añade una dependencia de la cuenta de sincronización y de su proceso de recuperación. Las passkeys vinculadas al dispositivo nunca salen de un único dispositivo, y las almacenadas en llaves de seguridad de hardware ofrecen el máximo nivel de garantía. En el flujo entre dispositivos, un teléfono inicia sesión en un portátil mediante un código QR, y el Bluetooth confirma la proximidad física.

¿Puede alguien acceder a una aplicación de autenticación? Solo con acceso físico al teléfono y a su método de desbloqueo, así que imponga el bloqueo de pantalla y la biometría. Los métodos basados en el teléfono también presuponen un teléfono personal, algo que muchas salas blancas y almacenes prohíben.

Autenticación por proximidad

La autenticación por proximidad utiliza como señal la cercanía física de un token al puesto de trabajo. NFC funciona a unos pocos centímetros: el usuario acerca una llave o una tarjeta a un lector, un gesto deliberado difícil de activar por accidente. Bluetooth Low Energy funciona a unos pocos metros: el puesto de trabajo estima la distancia a partir de la intensidad de la señal, lo que permite desbloquear al acercarse y bloquear al alejarse.

Esa estimación es el punto débil. La intensidad de la señal varía con las paredes, los cuerpos y el ruido radioeléctrico, por lo que un umbral que funciona en una sala puede fallar en otra. Un ataque de retransmisión, en el que un atacante reenvía la señal entre un token lejano y el puesto de trabajo, también puede engañar a un desbloqueo basado solo en la proximidad. La solución habitual es combinar la proximidad con una segunda señal en el inicio de sesión, como un PIN o un toque, y utilizar la proximidad sobre todo para bloquear, donde una activación errónea no supone riesgo.

Pruebe el umbral de distancia en cada tipo de sala y establezca un breve margen de espera para que una ausencia momentánea no interrumpa el trabajo.

Autenticación de dispositivos basada en certificados

En la autenticación de dispositivos basada en certificados, una autoridad de certificación emite un certificado X.509 que vincula una clave pública a la identidad de un dispositivo. El dispositivo demuestra que posee la clave privada correspondiente firmando un desafío, normalmente dentro de un handshake TLS. Una pasarela VPN, una red wifi que utiliza 802.1X o una aplicación interna solo aceptan endpoints que tengan un certificado emitido por su autoridad.

¿Pueden utilizarse los certificados para autenticar? Sí, y sustituyen a la contraseña del dispositivo. Sin embargo, un certificado no es sólido de forma automática. Si la clave privada es exportable, puede copiarse a otro equipo. Almacénela en un TPM o elemento seguro para que no pueda salir del chip, y exíjalo en el registro.

La carga está en el ciclo de vida: emisión, renovación, caducidad y revocación. Los certificados caducados o huérfanos provocan interrupciones del servicio, y un certificado que nunca se revocó sigue funcionando después de perder el dispositivo. Inventaríe las fechas de caducidad antes del despliegue y configure alertas con suficiente antelación. Una dirección MAC, en cambio, es un identificador que se envía en claro y puede copiarse, así que utilícela, como mucho, para el inventario.

Principales ventajas de la autenticación basada en dispositivos

Las ventajas dependen del método elegido y de lo bien que se gestione el ciclo de vida. Tres destacan para las organizaciones que van más allá de las contraseñas por sí solas.

Mayor protección frente al phishing y el robo de credenciales

Las credenciales vinculadas al origen eliminan la principal debilidad de las contraseñas: no existe ningún secreto compartido que pueda robarse mediante phishing, reutilizarse o filtrarse. Una página de inicio de sesión falsa en otro dominio no recibe nada que el sitio real aceptaría, y una brecha en la base de datos del servidor solo expone claves públicas. El relleno de credenciales, que se basa en credenciales reutilizadas, no tiene nada con lo que trabajar. NIST SP 800-63B-4, definitiva desde julio de 2025, define requisitos técnicos para los niveles de garantía de los autenticadores; confirme con su equipo de cumplimiento normativo a qué nivel se refiere una normativa o un contrato.

La protección tiene límites. Cubre la credencial, no el endpoint. Un malware en un ordenador comprometido puede utilizar una sesión ya autenticada, y una cookie de dispositivo de confianza puede robarse y reutilizarse. Combine los métodos basados en dispositivos con la protección de endpoints y no aplique la confianza basada en cookies a las cuentas privilegiadas. La resistencia al phishing también depende del registro: una credencial registrada mediante un proceso de recuperación débil hereda esa debilidad.

Acceso más rápido y cómodo para los usuarios

Un toque en una llave o en un sensor es más rápido que escribir una contraseña larga y después un código. Menos contraseñas también significa menos restablecimientos por contraseñas olvidadas para la mesa de ayuda, al menos en las aplicaciones que cubre el nuevo método. Una cookie de dispositivo de confianza reduce las solicitudes repetidas de MFA en aplicaciones de bajo riesgo, que es su principal ventaja de usabilidad.

En los puestos de trabajo compartidos, el cambio rápido de usuario durante el relevo de turno mantiene las colas cortas. La comodidad tiene condiciones. El registro lleva tiempo, un usuario sin llave necesita una vía de recuperación que no tarde horas y un lector poco fiable anula rápidamente la ganancia. Mida el tiempo de inicio de sesión y las solicitudes a la mesa de ayuda durante un piloto en lugar de dar por hecha una mejora. Las passkeys y las llaves también funcionan en los flujos del navegador que los usuarios ya conocen, lo que acorta la formación y reduce las fricciones en la adopción. Tenga en cuenta la carga de soporte de la primera semana, porque los usuarios olvidan las llaves en casa y se equivocan al introducir el PIN.

Mayor control sobre el acceso corporativo

Los métodos basados en dispositivos vinculan cada acceso a un dispositivo registrado e identificado, de modo que los administradores pueden saber qué dispositivo inició sesión, cuándo y con qué política. El registro puede limitarse a una red de confianza o a un usuario verificado. Las políticas pueden exigir un PIN, restringir el acceso a aplicaciones concretas, establecer reglas distintas para los administradores y los usuarios normales, o bloquear los dispositivos que no superen una comprobación de postura.

La revocación es la otra mitad del control. Cuando se pierde un portátil, una llave o un teléfono, eliminar su vinculación pone fin a su acceso sin cambiar todas las contraseñas del usuario. Póngalo a prueba: revoque un dispositivo piloto y cronometre cuánto tarda la revocación en surtir efecto. Los registros de altas, inicios de sesión y revocaciones también proporcionan a los auditores evidencias de cómo se gestionan las credenciales, lo que favorece el cumplimiento normativo sin garantizarlo. Revise esos mismos registros periódicamente para detectar dispositivos que llevan meses sin iniciar sesión y deberían retirarse. Asigne un responsable a cada política, para que las excepciones se revisen en lugar de acumularse.

Casos de uso de la autenticación basada en dispositivos

Los mismos mecanismos se aplican de forma distinta según quién utilice el dispositivo, dónde y con qué restricciones. Tres casos de uso muestran el abanico.

Acceso sin contraseña a las aplicaciones empresariales

Una passkey o una llave de hardware pueden desbloquear el proveedor de identidad, que a su vez inicia la sesión del usuario en las aplicaciones empresariales integradas en el inicio de sesión único mediante SAML u OpenID Connect (OIDC). Un único inicio de sesión robusto sustituye a muchas contraseñas, y las propias aplicaciones no necesitan cambios. Empiece por las aplicaciones que contienen los datos más sensibles y amplíe después el alcance a medida que los usuarios se familiaricen con el método.

Prevea las excepciones. Las aplicaciones heredadas que no admiten ninguno de los dos protocolos necesitan una pasarela o un agente de inyección de credenciales, o bien conservan sus contraseñas. Decida qué proveedor de identidad aloja la política, como Microsoft Entra ID o Keycloak, y compruebe que acepta el autenticador elegido antes del despliegue. Mantenga una vía de recuperación documentada, porque un acceso sin contraseña sin recuperación convierte una llave perdida en un bloqueo de la cuenta. Pruebe el inicio de sesión en todos los navegadores y sistemas operativos que utiliza la plantilla. Para las cuentas de administrador, exija primero autenticadores resistentes al phishing y extiéndalos después al resto de la plantilla.

Puestos de trabajo compartidos y empleados de primera línea

Lo que se puede verificar depende de quién controla el dispositivo. En un endpoint gestionado, un agente informa de la postura del dispositivo. En un dispositivo BYOD o de un contratista no hay agente, por lo que la única señal fiable es la prueba criptográfica de que el usuario posee una credencial.

• Portátil gestionado: comprobación de postura más certificado o llave FIDO2.
• BYOD: autenticador FIDO2 o passkey; la postura es desconocida.
• Contratista: credencial de duración limitada, revocada al finalizar el contrato.
• Quiosco compartido: un autenticador de hardware por usuario, con bloqueo de sesión al alejarse.

Una comprobación de postura describe el estado de un dispositivo, y un autenticador FIDO2 demuestra la posesión, no el estado. En el inicio de sesión en puestos de trabajo compartidos, la limitación suele ser el teléfono: las salas blancas, las zonas estériles y los almacenes descartan las notificaciones push y el registro mediante QR, por lo que un método basado en un toque o en una tarjeta se convierte en la base práctica. Los guantes y las batas estériles también hacen poco práctico escribir contraseñas, y un relevo de turno exige un cambio rápido de usuario.

Inicio de sesión por proximidad y bloqueo automático del puesto de trabajo

En los entornos sanitarios, industriales y logísticos, la autenticación en el puesto de trabajo se produce muchas veces por turno, a menudo con guantes o con las manos ocupadas. Escribir una contraseña cada vez es lento, y los trabajadores que lo encuentran demasiado lento dejan las sesiones abiertas o comparten credenciales.

El inicio de sesión por proximidad resuelve ambos aspectos. Un toque o la aproximación inician la sesión, y el bloqueo automático la cierra cuando el trabajador se aleja, de modo que una pantalla desatendida no queda abierta para la siguiente persona. Combine un temporizador de inactividad corto con el bloqueo por proximidad para que cualquiera de los dos eventos cierre la sesión. Esto también facilita las auditorías: cada sesión tiene entonces un inicio claro, un final claro y un usuario identificado.

Pruebe tres situaciones antes del despliegue: el cambio rápido de usuario en un relevo de turno, un trabajador que deja el token sobre la mesa y un token con la batería agotada. Cada una necesita un resultado definido, como un bloqueo, una anulación por parte de un supervisor o un token de repuesto.

Riesgos y limitaciones de seguridad de la autenticación basada en dispositivos

La seguridad de la autenticación basada en dispositivos varía según el método, porque cada uno falla en un punto distinto y necesita sus propios controles. Enumere primero lo que necesita el atacante y, después, asigne a cada riesgo un control, un responsable y una prueba.

• Cookie de dispositivo de confianza: basta con robar la cookie una vez para que funcione desde cualquier equipo.
• Comprobación de postura: falsificar el estado notificado o comprometer el agente que lo notifica.
• Certificado: extraer una clave privada exportable o utilizar un certificado que nunca se revocó.
• OTP: retransmitir el código a través de un proxy de phishing.
• Autenticador FIDO2: hacerse con el dispositivo físico y burlar su PIN.

El plan de mitigación asocia cada riesgo a un control, un responsable y una prueba:

• Dispositivo perdido: revocar la vinculación (equipo de gestión de identidades y accesos). Revoque un dispositivo piloto y cronometre el efecto.
• Clave exportable: exigir el almacenamiento en TPM (equipo de endpoints). Intente una exportación.
• Certificado caducado: alertar antes de la caducidad (responsable de la PKI). Pruébelo en preproducción con un certificado de corta duración.
• Recuperación débil: verificar al usuario antes de emitir códigos (mesa de ayuda). Solicite la recuperación haciéndose pasar por otra persona.
• Cookie de sesión robada: acortar la duración de la sesión y vincular las sesiones al dispositivo cuando la plataforma lo permita (responsable de la aplicación). Reutilice una cookie capturada desde otro equipo en un entorno de pruebas.

Cada método añade, además, un ciclo de vida que gestionar, y una credencial sólida con un proceso de recuperación débil es solo tan sólida como dicha recuperación.

Cómo implementar la autenticación basada en dispositivos en una organización

La implementación consiste sobre todo en gestionar el ciclo de vida. Abórdela como una secuencia y asigne un responsable a cada paso:

1. Aprovisionar: elija el método para cada segmento de la flota y prepare las credenciales.
2. Vincular al usuario: registre cada dispositivo a nombre de una persona verificada.
3. Aplicar la política: defina qué aplicaciones exigen qué método.
4. Supervisar: registre altas, inicios de sesión y fallos de política.
5. Recuperar: defina cómo recupera el acceso un usuario tras una pérdida.
6. Revocar: elimine la vinculación con rapidez y compruebe cuánto tarda en surtir efecto.
7. Retirar: dé de baja las credenciales cuando los dispositivos salgan de servicio.

Asigne los controles a los marcos que utilizan sus auditores. Los métodos basados en dispositivos favorecen el cumplimiento normativo al generar evidencias auditables; por sí solos no hacen que una organización cumpla la normativa.

• NIST SP 800-53: IA-3 (identificación y autenticación de dispositivos) corresponde a los certificados y a los autenticadores vinculados al hardware. IA-5 (gestión de autenticadores) corresponde a la emisión, la política de PIN y la revocación.
• NIST SP 800-207: los principios sobre la postura del dispositivo corresponden a las comprobaciones de postura realizadas antes de cada decisión de acceso.
• ISO/IEC 27001:2022: A.5.15 (control de acceso), A.5.16 (gestión de identidades) y A.8.5 (autenticación segura) corresponden al registro, la revocación y la aplicación de la MFA.
• NIS2 y PCI DSS 4.0: estos marcos abordan la MFA y el ciclo de vida de los autenticadores.

Pida a su delegado de protección de datos o a su responsable de cumplimiento normativo que verifique la redacción exacta de cada cláusula con respecto a su alcance antes de incluirla en un expediente de auditoría. Después, empiece por algo pequeño: pruebe un método con un equipo sobre una combinación real de dispositivos gestionados y no gestionados, pruebe la revocación de un dispositivo perdido y amplíe el alcance.

Cómo elegir una plataforma de autenticación basada en dispositivos

Una plataforma de autenticación basada en dispositivos debe evaluarse por el ciclo de vida que gestiona, no solo por la pantalla de inicio de sesión. Compare las opciones según estos criterios:

• Métodos compatibles: llaves de hardware, passkeys, certificados y proximidad, para que cada segmento de la flota disponga de un método adecuado.
• Registro y revocación: quién puede registrar un dispositivo, cómo se demuestra antes la identidad y con qué rapidez surte efecto una revocación.
• Recuperación: una vía documentada para un autenticador perdido que no debilite el modelo.
• Modelo de implantación: autoalojado, nube privada o nube multiinquilino, según las restricciones de datos y de residencia.
• Integración: protocolos estándar (SAML, OIDC, WS-Federation) y conectores publicados para su directorio y su proveedor de identidad.
• Uso sin conexión y compartido: comportamiento cuando la red no está disponible y cambio rápido de usuario en puestos compartidos.
• Evidencias: certificaciones de los modelos concretos de autenticador y registros de auditoría exportables.

Pida a cada proveedor que demuestre la revocación y la recuperación con un grupo piloto, no solo el registro.

Autenticación basada en dispositivos con Hideez

Hideez Workforce Identity utiliza smartphones, passkeys y llaves de seguridad de hardware para autenticar a los empleados en las aplicaciones empresariales y en los puestos de trabajo con Windows. Los administradores gestionan los usuarios, los autenticadores registrados y las políticas de acceso a través de Hideez Enterprise Server, disponible en la nube, en una nube privada o en sus propias instalaciones. Hideez es miembro certificado de la FIDO Alliance y cuenta con la certificación ISO 27001.

Los empleados pueden utilizar la aplicación móvil Hideez Authenticator o una llave de seguridad FIDO2 como Hideez Key 5. En la autenticación FIDO2, el autenticador demuestra la posesión de una credencial criptográfica sin transmitir una contraseña reutilizable. Mediante Passwordless SSO, ese inicio de sesión da acceso a las aplicaciones conectadas a través de SAML u OpenID Connect. La integración con Active Directory y Microsoft Entra ID permite a las organizaciones mantener su directorio de empleados actual.

En los ordenadores con Windows, Hideez permite el inicio de sesión sin contraseña y el acceso por proximidad. Un smartphone o una Hideez Key pueden activar el bloqueo automático de la sesión cuando el empleado se aleja. Esto resulta útil en los puestos de trabajo compartidos, donde los empleados se turnan con frecuencia y pueden olvidarse de bloquear la pantalla. Las llaves de hardware ofrecen una opción para los entornos en los que se restringe el uso de teléfonos personales.

Hideez Key 5 también puede incorporar una credencial de acceso físico para lectores de puertas y tornos compatibles, lo que permite a los empleados utilizar el mismo dispositivo para autenticarse en el puesto de trabajo y acceder al edificio.

Para ver cómo funcionaría Hideez con sus dispositivos y aplicaciones, solicite una demo. Después podrá realizar un piloto gratuito para probar el inicio de sesión, el bloqueo automático del puesto de trabajo y la gestión de autenticadores en su propio entorno. Si tiene preguntas sobre la compatibilidad o las opciones de implantación, póngase en contacto con el equipo comercial de Hideez.