Windows Hello para empresas se ha convertido en la pieza clave de la estrategia sin contraseñas de Microsoft: combina PIN, biometría y claves criptográficas para que los usuarios inicien sesión sin escribir contraseñas, pero con un nivel de seguridad muy superior. Todo ello, apoyado en seguridad por hardware, TPM y modelos modernos de SSO tanto en la nube como en entornos híbridos y locales.
Lejos de ser solo “el PIN de Windows”, Windows Hello for Business (WHfB) es un sistema distribuido que integra Microsoft Entra ID (antes Azure AD), Active Directory, PKI, Kerberos, FIDO2 y políticas avanzadas de dispositivo y usuario. Si eres admin de Windows o de identidad, entender cómo encaja todo —registro, aprovisionamiento, sincronización de claves, certificados y autenticación— es fundamental para desplegarlo sin dolores de cabeza y con inicio de sesión único robusto y resistente al phishing.
Qué es exactamente Windows Hello para empresas y cómo cambia la autenticación
Windows Hello para empresas es la versión corporativa y gestionada de Windows Hello. Reemplaza la contraseña por una credencial de clave pública asociada al dispositivo, protegida por TPM y desbloqueada con un PIN o un gesto biométrico. Esta credencial permite autenticarse frente a Microsoft Entra ID, Active Directory o AD FS, y a servicios que confían en ellos.
En vez de basarse en secretos compartidos (contraseñas, OTP, códigos SMS), WHfB genera un par de claves pública/privada por usuario y dispositivo. La clave pública se registra en el proveedor de identidades (IdP) y la privada se queda segura en el dispositivo, sin poder exportarse. El usuario solo aporta “entropía” con su PIN o biometría para liberar esa clave privada cuando quiere autenticarse.
El resultado es una experiencia de autenticación resistente al phishing, al robo de credenciales y a ataques de fuerza bruta, manteniendo el SSO tanto en la nube (Microsoft 365, aplicaciones modernas) como en servicios locales (Kerberos, aplicaciones legacy, VPNs basadas en certificados, etc.).
Fases internas de Windows Hello para empresas: de cero a SSO
Para entender bien WHfB conviene dividir su funcionamiento en varias fases cronológicas: registro del dispositivo, aprovisionamiento, sincronización de claves (si aplica), inscripción de certificados (si se usan) y, por último, autenticación diaria.
1. Registro de dispositivos
En primer lugar, el equipo tiene que pasar por un proceso de registro de dispositivo. Este paso asocia el dispositivo con un IdP específico y le da una identidad propia:
- Implementaciones en la nube o híbridas: el IdP es Microsoft Entra ID y el dispositivo se registra en el servicio de registro de dispositivos.
- Implementaciones puramente locales: el IdP es AD FS y el registro se realiza contra el servicio de registro de dispositivos empresariales expuesto por AD FS.
Tras el registro, el dispositivo dispone de una identidad confiable que le permite autenticarse frente al IdP cuando un usuario inicia sesión. Existen distintos tipos de registro (unión a dominio, unión a Microsoft Entra, registro personal, etc.), conocidos como tipos de relación o “join types”, que determinan el comportamiento posterior de WHfB y del SSO.
2. Fase de aprovisionamiento
Durante el aprovisionamiento, el usuario deja de ser un “usuario de contraseña” y pasa a tener su contenedor de Windows Hello en el dispositivo. Este contenedor agrupa el material criptográfico asociado a sus cuentas (corporativa, educativa, personal) de manera aislada por proveedor de identidad.
El flujo típico de aprovisionamiento sigue estos pasos:
- En el asistente de experiencia de usuario (CXH), el usuario se autentica con el IdP mediante MFA (normalmente usuario/contraseña más un segundo factor).
- Tras superar la MFA, el sistema solicita al usuario que configure un PIN y, si hay hardware compatible, uno o varios gestos biométricos (cara, huella).
- Se crea el contenedor de Windows Hello en el dispositivo.
- El equipo genera un par de claves pública/privada de autenticación, preferiblemente ligado a TPM; si no hay TPM, se protege mediante cifrado software.
- La clave privada se almacena localmente, sellada por el TPM cuando existe, y marcada como no exportable.
- La clave pública se registra en el IdP asociada a la cuenta del usuario:
- En entornos en la nube, el servicio de registro de dispositivos la escribe en el objeto de usuario de Microsoft Entra ID.
- En escenarios locales, AD FS guarda la clave en Active Directory.
Desde ese momento, cuando el usuario desbloquea el dispositivo con PIN o biometría, en realidad está “desencadenando” el uso de esa clave privada de Hello para demostrar su identidad al IdP.
3. Detalles del contenedor de Windows Hello y tipos de claves
El contenedor de Windows Hello no guarda solo una clave: puede albergar distintos tipos de material criptográfico, cada uno con su función y con su propio “protector”. Cada protector cifra su copia de la clave de autenticación con una técnica diferente (por ejemplo, sellado en TPM usando el PIN como entropía o cifrado simétrico derivado del PIN si no hay TPM).
Dentro del contenedor podemos encontrar:
- Una clave de autenticación principal: siempre un par asimétrico (pública/privada) creado durante el registro. Es la que hay que desbloquear cada vez usando PIN o biometría. Si el usuario restablece el PIN, se genera una nueva clave y todo el material que protegía la anterior se vuelve a cifrar con la nueva.
- Una o varias claves de identificador de usuario (user ID keys): pueden ser simétricas o asimétricas según el IdP y el modelo de confianza. En implementaciones basadas en certificados, estas claves se usan para generar las solicitudes hacia la CA o para RDP, VPN, etc.
- Opcionalmente, una clave administrativa, pensada para escenarios de restablecimiento (por ejemplo, recuperación de PIN) y datos asociados al TPM del dispositivo.
Las claves de identificador de usuario se utilizan para demostrar posesión de la clave privada frente al servicio (firmar un nonce, por ejemplo). Active Directory, Microsoft Entra ID y las cuentas Microsoft personales requieren pares de claves asimétricos; el dispositivo genera el par, registra la parte pública y protege la privada, que jamás abandona el dispositivo.
Si tu organización dispone de PKI corporativa, puedes asociar las claves de identificador de usuario a certificados emitidos por vuestra CA, lo que permite que WHfB se integre con aplicaciones que dependen de certificados (VPN clásicas, RDP con smart card, etc.). Si no necesitas PKI, el propio IdP puede generar y gestionar este material de identificación para reducir complejidad.
4. Sincronización de claves en entornos híbridos
En despliegues híbridos, donde Microsoft Entra ID y Active Directory coexisten, hace falta una fase adicional: sincronizar la clave pública de Hello desde la nube al directorio local para que los controladores de dominio puedan validar a los usuarios.
La clave pública se almacena en el atributo msDS-KeyCredentialLink del objeto de usuario en Active Directory, y la sincronización la gestiona Microsoft Entra Connect Sync. Sin esta réplica, sería imposible que un dominio local verificara una autenticación basada en WHfB procedente de un dispositivo unido a Microsoft Entra.
5. Inscripción de certificados (cuando se usa Certificate Trust)
En los modelos donde WHfB se apoya en certificados para autenticación Kerberos o aplicaciones locales, aparece una fase adicional: la inscripción de certificados.
Una vez registrada la clave, el cliente genera una solicitud de certificado y la envía a la entidad de registro de certificados (CRA), que suele residir en el servidor AD FS y orquestar la petición frente a la PKI corporativa. La CA emite el certificado, que se almacena dentro del contenedor de Hello del usuario en el dispositivo y se utiliza para autenticarse en recursos locales que esperan ver un certificado de tarjeta inteligente o similar.
Autenticación diaria, SSO y papel de la seguridad por hardware
En el día a día, cuando el usuario enciende el equipo o lo desbloquea, la autenticación se basa siempre en la parte privada de la credencial de Windows Hello (clave o certificado), más el gesto del usuario (PIN o biometría). Ese gesto nunca se envía al IdP ni se almacena como tal en el sistema.
La autenticación es, de facto, de dos factores:
- Algo que el usuario tiene: la clave o certificado asociado al dispositivo.
- Algo que el usuario sabe o es: un PIN local o un dato biométrico.
Cuando el usuario introduce el PIN o usa la huella/cara, Windows libera la clave de autenticación de su contenedor y la utiliza para firmar criptográficamente datos enviados al IdP. El proveedor de identidades comprueba esta firma con la clave pública almacenada y, si todo cuadra, emite los tokens necesarios para acceder a recursos (Microsoft 365, aplicaciones SaaS, recursos on-prem, etc.).
Ni el PIN ni el template biométrico salen del dispositivo. El PIN ni siquiera se guarda como texto: sirve como entropía para operaciones criptográficas y para desbloquear el material protegido por TPM. El IdP solo ve pruebas criptográficas de que el usuario controla la clave privada registrada.
Token de actualización principal (PRT) y SSO moderno
El inicio de sesión único en el mundo Microsoft moderno se apoya en un token clave: el Primary Refresh Token (PRT). Es un JSON Web Token que incluye claims del usuario y del dispositivo, y habilita el SSO hacia aplicaciones protegidas por Microsoft Entra ID o AD FS.
El PRT se obtiene al iniciar sesión o desbloquear el dispositivo con una credencial de confianza (WHfB o credenciales tradicionales), de forma análoga a como antes se obtenía el TGT de Kerberos en un entorno solo on-prem. En dispositivos:
- Unidos a Microsoft Entra o híbridos unidos a Microsoft Entra: el PRT se emite en el propio inicio de sesión.
- Dispositivos personales registrados (BYOD): el PRT se genera al agregar una cuenta profesional o educativa al dispositivo.
Sin PRT, los usuarios tendrían que introducir credenciales continuamente y las directivas de acceso condicional basadas en el estado del dispositivo no podrían evaluarse. Con WHfB y un PRT válido, se consigue un SSO fluido y a la vez condicionado por estado del equipo, cumplimiento, riesgo, etc.
Configuración de políticas clave: SSO y seguridad por hardware
WHfB ofrece un conjunto amplio de configuraciones de directiva tanto vía CSP (para MDM como Intune) como vía GPO. Muchas de ellas están centradas en reforzar el SSO y asegurar que siempre se aprovecha el hardware de seguridad disponible en el dispositivo.
Uso obligatorio de dispositivos de seguridad de hardware (TPM)
Una de las políticas más relevantes ordena que el aprovisionamiento de Windows Hello para empresas solo se realice en dispositivos con TPM utilizable (1.2 o 2.0). Un TPM proporciona una protección adicional porque la clave privada queda ligada a ese componente físico; aunque un atacante copie el disco, no podrá usar la clave en otro equipo.
Mediante CSP, esta configuración se controla con:
./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/RequireSecurityDevice- Y, opcionalmente, exclusión de determinados TPM 1.2 con:
./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/ExcludeSecurityDevices/TPM12
Además, existe el equivalente en GPO bajo las plantillas administrativas de Windows Hello para empresas a nivel de equipo. Si se habilita, no habrá aprovisionamiento WHfB en equipos sin TPM válido, con lo que refuerzas drásticamente la seguridad del entorno.
Configurar SSO local: certificado vs confianza en la nube
Para el SSO frente a recursos locales (controladores de dominio, aplicaciones on-prem), WHfB puede usar tres modelos de confianza principales: basado en certificados, basado en clave (Key Trust) y, más recientemente, Cloud Kerberos Trust (confianza en la nube).
Existen dos políticas fundamentales:
- Uso de certificado para autenticación local:
./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCertificateForOnPremAuth
Si se habilita, WHfB inscribe un certificado de inicio de sesión dentro del contenedor y lo utiliza para autenticación local. - Uso de confianza en la nube para autenticación local:
./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCloudTrustForOnPremAuth
Si se activa, WHfB utiliza un vale Kerberos derivado de la autenticación en Microsoft Entra ID para autenticarse frente a recursos on-prem, sin necesidad de emitir certificados adicionales.
Deshabilitar o no configurar estas directivas hace que el sistema recurra a una clave o certificado, según las otras opciones activas. En GPO, estas opciones se encuentran en las secciones de equipo y usuario bajo Componentes de Windows > Windows Hello para empresas.
Control maestro: habilitar o no Windows Hello para empresas
Hay una directiva global para decidir si un dispositivo usa o no WHfB y si se lanza el asistente de aprovisionamiento tras el inicio de sesión:
./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UsePassportForWork./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/DisablePostLogonProvisioning
Con ellas puedes:
- Obligar a que todos los usuarios aprovisionen WHfB en el dispositivo.
- Impedir totalmente el uso de WHfB.
- Permitir que cada usuario decida si quiere configurar Hello.
- Evitar que tras el primer inicio de sesión se dispare automáticamente el asistente, útil cuando usáis una solución de terceros para aprovisionar WHfB.
Políticas de PIN, recuperación y controles de complejidad
El PIN de Windows Hello es uno de los pilares de la solución. Aunque mucha gente lo confunde con una contraseña “corta”, en realidad es un factor local ligado al dispositivo, protegido por el TPM y mucho menos reutilizable que una contraseña clásica.
Expiración, historial y longitud del PIN
Las directivas de PIN permiten ajustar su ciclo de vida y complejidad de forma similar —aunque más granular— a las contraseñas tradicionales:
- Expiración: puedes obligar a que el PIN caduque entre 1 y 730 días. Si el valor es 0, el PIN nunca expira (valor por defecto).
- Historial: se define cuántos PIN anteriores no pueden reutilizarse, entre 0 y 50. Un valor 0 significa que no se almacena historial.
- Longitud mínima y máxima: mínimo configurable a partir de 4 caracteres; máximo hasta 127, siempre respetando que el mínimo sea menor que el máximo y que por defecto, si no se configura, se exige como mínimo 6 caracteres.
Si no se establecen estas políticas, el comportamiento por defecto permite hasta 127 caracteres y exige un PIN de al menos 6, sin imposiciones adicionales más allá de las reglas de complejidad que definas.
Requisitos de composición del PIN
Puedes decidir qué tipo de caracteres se admiten y cuáles se exigen en el PIN de Windows Hello:
- Dígitos: si habilitas la política de requerir dígitos, el PIN debe incluir al menos un número. Si la deshabilitas, se prohíben los números. Sin configurar, se permiten pero no son obligatorios.
- Letras minúsculas: permite exigir al menos una, prohibirlas totalmente o dejarlas opcionales.
- Letras mayúsculas: mismo esquema que las minúsculas.
- Caracteres especiales: se puede requerir al menos uno, prohibirlos o permitirlos. Se considera un conjunto amplio de símbolos (
! " # $ % & ' ( ) + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~).
Estas reglas permiten ajustar el equilibro entre usabilidad y robustez. Eso sí, si se exagera la complejidad, aumenta el riesgo de olvidos de PIN y de tickets de soporte, algo que muchas organizaciones tratan de evitar precisamente cuando adoptan WHfB.
Recuperación de PIN
La recuperación de PIN permite a un usuario restablecer un PIN olvidado sin perder las credenciales o certificados asociados (incluyendo claves vinculadas a cuentas personales en ese equipo). Para ello, Windows Hello cifra un secreto de recuperación que queda almacenado localmente, de modo que solo el propio servicio de recuperación y el dispositivo puedan descifrarlo.
Esta funcionalidad exige que el usuario realice autenticación multifactor frente a Microsoft Entra ID para poder recuperar el PIN. Si habilitas la política correspondiente (por CSP o GPO), Windows generará y custodiará ese secreto de recuperación; si la deshabilitas o dejas sin configurar, el dispositivo no creará ni guardará el secreto y, en caso de olvido de PIN, el usuario tendrá que eliminarlo por completo y aprovisionar uno nuevo, volviendo a registrarse en los servicios a los que daba acceso el PIN anterior.
Biometría, protección anti-suplantación y ESS
La biometría en WHfB (cara, huella, iris) es un complemento al PIN, no un sustituto total. Siempre hay un PIN de respaldo para cuando el sensor falla o el contexto no permite usarlo.
Protección anti-suplantación mejorada
Existe una política específica para exigir protección contra suplantación mejorada (enhanced anti-spoofing) en el reconocimiento facial. Al habilitarla, Windows solo permitirá autenticación facial si el sensor y el stack cumplen estos requisitos avanzados de detección de ataques (por ejemplo, evitar login con fotos, vídeos o deepfakes sencillos).
Si se deshabilita o no se configura, Windows no exigirá esa protección reforzada y la autenticación facial será menos restrictiva. La ruta CSP asociada es ./Device/Vendor/MSFT/PassportForWork/Biometrics/FacialFeaturesUseEnhancedAntiSpoofing, y el equivalente se encuentra también en GPO bajo las opciones de biometría de Windows Hello para empresas.
ESS: Enhanced Sign-in Security con periféricos
La Enhanced Sign-in Security (ESS) es una capa adicional que combina VBS (Virtualization Based Security), TPM 2.0 y componentes específicos para aislar por hardware las plantillas biométricas y las operaciones de comparación.
Con ESS, los datos biométricos (cara, huella) y las comparaciones se realizan en regiones de memoria aisladas y protegidas, a las que el resto del sistema operativo no tiene acceso directo. También se protege el canal entre los sensores y el algoritmo, de modo que malware o atacantes no puedan inyectar o reproducir datos biométricos falsos para simular inicios de sesión o bloquear usuarios.
La política EnableESSwithSupportedPeripherals permite dos valores principales:
- 0: ESS habilitado incluso si hay sensores periféricos o integrados que no soportan ESS. Se permiten operaciones de autenticación con esos dispositivos, con ciertas limitaciones. No es la opción más recomendada.
- 1: ESS habilitado sin admitir sensores periféricos o integrados no ESS. Es decir, se bloquean para Windows Hello las operaciones biométricas de cualquier dispositivo que no soporte ESS. Es la configuración con mayor seguridad.
Si se deshabilita o deja sin configurar, en dispositivos ESS se bloquean los sensores que no sean compatibles con ESS, manteniendo un enfoque conservador para la seguridad.
Uso de biometría en general
La política UseBiometrics controla si Windows Hello para empresas permite usar gestos biométricos o si solo se admite el PIN. Si se habilita o deja sin configurar, la biometría está permitida; si se deshabilita, se prohíbe su uso y los usuarios tendrán que autenticarse siempre con PIN u otros factores.
En cualquier caso, los datos biométricos:
- Se almacenan solo en el dispositivo local (base de datos en
C:\Windows\System32\WinBioDatabase). - Cada sensor tiene su propio archivo y clave única generada aleatoriamente, cifrada con AES en modo CBC y hash SHA-256.
- No se envían a servidores externos ni se sincronizan entre equipos, evitando puntos únicos de recolección para atacantes.
Integración con tarjetas inteligentes y aplicaciones heredadas
Muchas organizaciones siguen dependiendo de tarjetas inteligentes y aplicaciones que esperan certificados “tipo smart card”. WHfB incorpora opciones para emular o integrarse con estos entornos sin perder los beneficios de la autenticación moderna.
Emulación de tarjeta inteligente y enumeración
Por defecto, Windows impide que usuarios en la misma máquina vean las credenciales de Windows Hello aprovisionadas para otros usuarios. Una política permite optar por lo contrario en escenarios donde:
- Un mismo usuario tiene cuentas con y sin privilegios en el mismo equipo.
- Quiere iniciar sesión con la cuenta “normal” pero elevar privilegios antes de cerrar sesión, usando sus propias credenciales Hello.
También existe la opción de deshabilitar la emulación de tarjeta inteligente. Si se activa, las credenciales WHfB deján de ser compatibles con aplicaciones que esperan una smart card. Si se deja deshabilitada o no configurada, Windows sigue proveyendo esa emulación automáticamente.
Usar certificados de Hello como certificados de tarjeta inteligente
Otra política importante es UseHelloCertificatesAsSmartCardCertificates. Si se habilita, las aplicaciones pueden tratar los certificados de Windows Hello para empresas como certificados de tarjeta inteligente. Eso sí, en ese contexto los factores biométricos no están disponibles cuando se pide autorización para usar la clave privada del certificado.
Si no se configura o se deshabilita, las aplicaciones no usan los certificados de Hello de este modo y la biometría permanece disponible para el usuario. No es compatible tener esta opción activa simultáneamente con la directiva que desactiva la emulación de tarjeta inteligente.
Requisitos de PKI, CRL y certificados de controlador de dominio
En despliegues donde WHfB debe dar SSO a recursos on-prem mediante certificados y Kerberos, la PKI y la infraestructura de certificados deben estar bien ajustadas, sobre todo si hay dispositivos solo unidos a Microsoft Entra que van a autenticarse contra Active Directory.
Punto de distribución de CRL accesible por dispositivos unidos a Entra
Uno de los puntos críticos es la lista de revocación de certificados (CRL). Cuando una CA revoca un certificado, añade información a esta lista, y Windows la consulta para validar si el certificado sigue siendo válido.
En muchos entornos on-prem el CDP (CRL Distribution Point) se publica como ruta LDAP en Active Directory. Esto funciona bien para máquinas unidas al dominio, pero no para dispositivos unidos solo a Microsoft Entra, que no pueden leer AD antes de autenticarse. Se genera así una dependencia circular: para validar el certificado del controlador de dominio necesitas leer AD, pero no puedes leer AD sin autenticarte primero.
La solución es publicar el CDP en un servidor web accesible vía HTTP (no HTTPS), que no requiera autenticación previa. El procedimiento típico implica:
- Instalar IIS u otro servidor web en un servidor interno.
- Crear un directorio virtual (por ejemplo,
cdp) que apunte a una carpeta compartida donde la CA pueda publicar las CRL. - Ajustar permisos NTFS y de recurso compartido para que la CA pueda escribir en esa carpeta.
- Crear un registro DNS (por ejemplo,
crl.midominio.com) apuntando a ese servidor. - Configurar la CA emisora para incluir un CDP HTTP en las extensiones de los certificados emitidos, y para publicar la CRL y la delta CRL en esa ubicación.
Después hay que forzar la publicación de una nueva CRL y verificar que desde un navegador se puede acceder a http://crl.tudominio.com/cdp y ver los archivos .crl generados.
Reemisión de certificados de controlador de dominio y validación estricta de KDC
Los certificados ya emitidos no se actualizan solos con el nuevo CDP; hay que renovarlos. En especial, los certificados de controlador de dominio que se usan para autenticación Kerberos. WHfB aplica la característica de «KDC strict validation» cuando un dispositivo unido a Microsoft Entra se autentica contra un dominio on-prem, por lo que el certificado del DC debe cumplir varios requisitos:
- El DC debe poseer la clave privada del certificado presentado.
- La CA raíz que emitió el certificado del DC debe estar en las raíces de confianza del dispositivo.
- Debe usar la plantilla de certificado de autenticación Kerberos, no plantillas antiguas.
- El certificado tiene que incluir el EKU de autenticación de KDC.
- En el Subject Alternative Name debe figurar un nombre DNS que coincida con el nombre del dominio.
- El algoritmo de firma debe ser como mínimo SHA256.
- La clave pública debe ser RSA de 2048 bits.
Tras ajustar la CA y renovar los certificados de DC, hay que comprobar en la pestaña de detalles de cada certificado que el CDP HTTP correcto está presente. Esto es vital para que los dispositivos unidos solo a Entra confíen en los controladores de dominio al autenticarse con WHfB.
Implementar el certificado raíz de la CA en dispositivos unidos a Entra
Por último, los dispositivos unidos a Microsoft Entra deben confiar en la CA raíz de la empresa. Esto se consigue exportando el certificado raíz desde la cadena de confianza del certificado del DC y distribuyéndolo a los equipos, por ejemplo mediante:
- Una política de certificado de confianza de equipo en Microsoft Intune, apuntando al almacén de raíces de confianza del equipo.
- O métodos equivalentes en otras soluciones MDM/gestionadas.
Si este paso se omite, aunque todos los demás elementos estén bien configurados, los dispositivos no confiarán en los DC y las autenticaciones con WHfB fallarán en la capa de TLS/certificado.
Windows Hello para empresas aporta un salto importante en seguridad y experiencia de inicio de sesión: reemplaza contraseñas por credenciales ligadas al dispositivo, protegidas por hardware y gestionadas centralmente, ofreciendo SSO moderno y resistente al phishing tanto en la nube como en entornos locales. Eso sí, para que funcione de verdad bien hay que tomarse en serio la preparación de la infraestructura de identidad y PKI, definir las políticas adecuadas de PIN, biometría y uso obligatorio de TPM, y acompañarlo de un despliegue por fases con comunicación clara a usuarios, de forma que el cambio se perciba como una mejora y no como otra complicación de TI.