Sophos Mobile: planificar con seguridad las reglas de contraseñas y las directivas de seguridad de Windows

Al configurar directivas de Windows en Sophos Mobile, la decisión más importante no es elegir el ajuste más estricto, sino realizar una prueba piloto con posibilidad de recuperación: confirmar la edición y el estado de administración, comprobar la recuperación de BitLocker antes de un posible reinicio, inventariar las cuentas locales y solo entonces asignar un único cambio a un dispositivo de prueba. Una directiva de Windows no es la directiva de Device Encryption de Sophos Fusion ni sustituye un procedimiento de recuperación de BitLocker. Para la gestión de claves y la recuperación, consulta Gestionar BitLocker con Sophos Fusion.

Antes de la primera asignación

Plataforma y ámbito: El dispositivo de destino debe estar realmente administrado como equipo Windows mediante Sophos Mobile; Sophos Endpoint Protection por sí solo no implica una inscripción MDM. La lista de requisitos de Sophos Mobile menciona Windows 10/11 Enterprise, Education y Pro, pero no Home; esto no garantiza que todas las configuraciones de directivas surtan efecto en todas las ediciones o compilaciones enumeradas. Según Sophos, Restrictions no se aplica a Pro, y Device Guard no se aplica ni a Pro ni a Windows en modo S. Comprueba en el dispositivo concreto la edición, la versión de Windows, los requisitos de hardware y las directivas GPO/MDM efectivas; una página de ayuda antigua no constituye una confirmación de compatibilidad actual.
Ciclo de vida: El soporte de Microsoft para las ediciones habituales de Windows 10 terminó el 14 de octubre de 2025; las ediciones LTSC/LTSB y los dispositivos con Extended Security Updates (ESU) válidas y activadas deben evaluarse por separado según su edición y versión. ESU no prolonga el ciclo de vida del producto de Microsoft ni el soporte ordinario, sino que proporciona actualizaciones de seguridad durante un período limitado a los dispositivos que cumplen los requisitos y están correctamente registrados. Aun así, la lista de requisitos de Sophos Mobile (versión 2026.38 del 21 de septiembre de 2026) incluye Windows 10 Enterprise/Education/Pro desde 20H2, así como Windows 11 Enterprise/Education/Pro. Se trata de una lista de plataformas de Sophos, no de una garantía de soporte de Microsoft para compilaciones antiguas de Windows 10 ni de una prueba de que todas las directivas de Windows funcionen. También Windows 11 depende de la versión y la edición: por ejemplo, 23H2 Pro ya está fuera del período de actualizaciones de Microsoft, mientras que 23H2 Enterprise/Education tiene plazos propios. Antes de la prueba piloto, consulta el ciclo de vida de la versión concreta en la información de estado de versiones de Microsoft y prueba el ajuste deseado precisamente en ese dispositivo.
Acceso y vía de recuperación: Prepara un acceso local de recuperación autorizado, asistencia disponible junto al dispositivo y una ventana de cambios. Si se usa BitLocker, mantén accesible mediante el procedimiento aprobado la clave de recuperación correspondiente al dispositivo afectado y al protector actual, y comprueba su disponibilidad antes del cambio; no consideres una entrada meramente existente o antigua como una recuperación probada. Identifica primero quién gestiona realmente la clave de recuperación de BitLocker actual de este dispositivo y dónde está guardada (por ejemplo, Fusion Device Encryption u otro sistema autorizado de gestión de claves). La administración MDM mediante Sophos Mobile por sí sola no demuestra que exista una clave almacenada en Fusion. No reveles una clave de Fusion de producción mediante Show Key solo para comprobar la preparación. Documenta los requisitos de contraseñas y las GPO existentes. Para Device Guard, comprueba además el estado actual de VBS/Credential Guard, así como Secure Boot y la compatibilidad con DMA.
Grupo piloto reducido: No asignes primero la directiva a un grupo amplio de dispositivos. Documenta el estado inicial, los usuarios afectados y el cambio visible esperado. Según Sophos, no existe una vía general de reversión mediante Uninstall policy para las directivas de Windows; los ajustes se corrigen actualizando la directiva o asignando otra. Un equipo desconectado o que no sincroniza no recibe de inmediato esta corrección de forma fiable.

Reglas de contraseñas: evitar reinicios y bloqueos de cuentas

La configuración Password policies controla Maximum number of failed attempts, Time in minutes until the device is locked, Password history y Maximum password age in days.

Time in minutes until the device is locked establece tras cuántos minutos de inactividad se bloquea el dispositivo. El usuario puede desbloquearlo por sí mismo. Este bloqueo por inactividad no es el umbral de intentos fallidos que puede provocar un reinicio con una solicitud de recuperación de BitLocker. Maximum password age in days establece cada cuántos días los usuarios deben cambiar su contraseña.

Password history es el número de contraseñas anteriores que Sophos Mobile conserva para impedir su reutilización; una contraseña nueva no puede coincidir con ninguna de ellas. Sophos permite el valor 0 para no imponer la restricción correspondiente en los intentos fallidos, el tiempo de bloqueo y la antigüedad máxima de la contraseña. Esto no es una recomendación para desactivar todas las protecciones: elige valores adecuados al modelo de cuentas y a la capacidad de recuperación, y pruébalos por separado. La complejidad de la contraseña (por ejemplo, su longitud o las clases de caracteres) no se puede configurar mediante esta directiva de Mobile; la determina Windows y depende, entre otras cosas, del tipo de cuenta. No tomes cifras concretas de complejidad documentadas históricamente como valores predeterminados universales de Windows en la actualidad.

Si una directiva de complejidad de Windows correspondiente está activada y es efectiva para la cuenta afectada, al crear o cambiar la contraseña también pueden aplicarse comprobaciones respecto al nombre de la cuenta y a componentes del nombre completo o del nombre para mostrar. Si estas comprobaciones de nombres se aplican y cómo lo hacen depende de la directiva efectiva y del tipo de cuenta; acláralo para las cuentas afectadas antes de la prueba piloto. Esto no implica una regla universal para cualquier secuencia de caracteres de un nombre ni demuestra cuáles son los requisitos actuales de las cuentas de Microsoft.

Antes de activar «Maximum number of failed attempts»: Sophos indica que, al alcanzar el umbral en equipos Windows, se produce un reinicio con solicitud de recuperación de BitLocker. Microsoft precisa que, para la regla MDM correspondiente de Windows, en un equipo de escritorio no se borran los datos, sino que se activa la recuperación de BitLocker; si BitLocker no está habilitado, la regla no se puede aplicar. Por tanto, no interpretes un umbral de intentos fallidos ni como borrado de datos ni como protección efectiva en un dispositivo sin cifrar. Comprueba el estado de BitLocker y el acceso real a la clave de recuperación del dispositivo antes de asignar la directiva; no provoques deliberadamente intentos fallidos en dispositivos de producción. Si, además del usuario inscrito en Sophos Mobile, existen otros usuarios locales y al menos uno de ellos no tiene permiso para cambiar su contraseña, según Sophos no se puede asignar esta directiva de contraseñas. Revisa y corrige los permisos de las cuentas en un paso independiente y aprobado; no amplíes permisos ni elimines cuentas a ciegas para forzar la aplicación de la directiva.

Para la prueba piloto, inventaría primero las cuentas y directivas existentes, establece una duración de inactividad y una antigüedad de contraseña adecuadas al flujo de trabajo y confirma que la recuperación está preparada antes de fijar un umbral de intentos fallidos. Tras la asignación, comprueba sin modificar nada qué directiva está asociada al dispositivo y si la duración de inactividad elegida y la antigüedad máxima de la contraseña surten efecto. La prueba del umbral de intentos fallidos debe realizarse exclusivamente en un entorno de pruebas aislado y autorizado, con la clave de recuperación accesible. Si aparece una solicitud inesperada de recuperación de BitLocker, no repitas los intentos ni pruebes otras claves: coteja los identificadores del dispositivo y de la clave y sigue el procedimiento de recuperación autorizado del sistema que realmente administra las claves; solo si Sophos Device Encryption custodia la clave actual se aplica el procedimiento de recuperación de Fusion.

Restrictions: aclarar de antemano las consecuencias de cada casilla

Restrictions no es una medida general de refuerzo para Pro: Sophos excluye expresamente Windows Pro. Esta configuración incluye, entre otros ajustes, Forbid resetting the computer (impide restablecer el equipo tanto desde Configuración como desde Windows RE), Disable VPN settings, Disable Account settings, Forbid Bluetooth, Telemetry level y Forbid manual MDM unenrollment. Bloquear el restablecimiento o la cancelación de la inscripción MDM puede impedir un procedimiento previsto de soporte o retirada del dispositivo. Elige solo un ajuste justificado por cada cambio piloto y comprueba su funcionamiento en el dispositivo antes y después de la asignación.

Forbid manual configuration, en la sección Wi-Fi, supone un riesgo especial: al aplicar este ajuste se eliminan los perfiles configurados previamente por el usuario, así como los perfiles de Wi-Fi Sense. Desmarcar la casilla no vuelve a crear automáticamente los perfiles eliminados. Antes de realizar esta intervención, asegura otro acceso de administración y de red ya probado, así como un procedimiento documentado para restaurar los perfiles WLAN necesarios. Los perfiles WLAN, los certificados y SCEP pertenecen a un procedimiento independiente de redes y certificados de Windows; sin esta garantía, no actives aquí un bloqueo de WLAN.

Telemetry level enumera en la lista de Sophos los niveles Full, Enhanced, Basic y Security. Su efecto real en Windows y su disponibilidad dependen de la edición actual y de las directivas de Microsoft; la lista de Sophos no demuestra que cada nivel funcione en todos los dispositivos piloto. Del mismo modo, los términos históricos de la interfaz, como Cortana o Wi-Fi Sense, no demuestran que surtan efecto en las versiones actuales de Windows.

Device Guard: elegir primero una vía reversible

La configuración Device Guard de Sophos puede activar la seguridad basada en virtualización (VBS) y Credential Guard. Turn on virtualization-based security (VBS) es el campo específico para activar VBS; la selección en Credential Guard configuration es independiente. Según Sophos, los ajustes se aplican en el primer arranque del equipo Windows después de la asignación de la directiva. Antes de asignar la directiva, comprueba el hardware y las directivas GPO/MDM existentes y programa un reinicio controlado.

En Platform security level, Sophos distingue dos opciones:

Secure Boot utiliza las funciones de protección admitidas por el dispositivo. Sin unidades de gestión de memoria de entrada/salida (IOMMU), VBS utiliza la función Secure Boot de UEFI; con IOMMU, VBS utiliza Secure Boot con protección frente al acceso directo a la memoria (DMA).
Secure Boot and DMA protection exige Secure Boot con protección DMA. Si el dispositivo no admite protección DMA, esta selección no activa VBS.

Comprobaciones previas de Credential Guard antes de la asignación: Solo si se va a activar Credential Guard en el dispositivo piloto, identifica las vías de inicio de sesión y acceso realmente utilizadas en ese tenant: WLAN o 802.1X por cable, VPN (especialmente PEAP/EAP-MSCHAPv2), SSO con NTLMv1, RDP/soporte remoto con credenciales de Windows guardadas o CredSSP, así como aplicaciones con delegación Kerberos sin restricciones. Microsoft documenta las consecuencias para la autenticación: con MS-CHAP y NTLMv1 puede dejar de funcionar el SSO y ser necesario volver a iniciar sesión manualmente; esto no significa que dichos protocolos queden bloqueados por completo en todos los casos. La autenticación WLAN/VPN basada en certificados no queda bloqueada por ello. El cliente de Escritorio remoto no puede transmitir credenciales de Windows guardadas al host de destino; CredSSP ya no puede usar credenciales guardadas o de SSO, aunque siguen siendo posibles las credenciales introducidas explícitamente. En cambio, la delegación Kerberos sin restricciones sí queda bloqueada. Comprueba las dependencias adicionales solo si se utilizan realmente en la prueba piloto: Consulta con los responsables de identidades y aplicaciones si se necesita Kerberos PKINIT con RSA en vez de Diffie-Hellman o Kerberos DES: Credential Guard bloquea PKINIT con RSA y DES; volver a introducir la contraseña no resuelve estos casos. Identifica también los Security Support Provider/Authentication Packages (SSP/AP) propios o de terceros y las aplicaciones que leen credenciales de Windows guardadas: estas integraciones pueden fallar, especialmente si necesitan hashes de contraseñas de LSA o interfaces no admitidas. Para las vías realmente afectadas, acuerda una alternativa compatible y una prueba funcional representativa antes de asignar la directiva; si alguna vía crítica sigue sin aclararse, no asignes Credential Guard. Evalúa con los responsables de identidades y redes únicamente las vías relevantes para el dispositivo elegido; antes de reiniciar, ten preparado un acceso de administración o de consola local probado de forma independiente y una vía de reversión aprobada sin bloqueo UEFI. Si la conexión de red habitual o la de soporte remoto es el único medio de acceso, todavía no asignes Credential Guard.

Para una prueba piloto que requiera reversión remota, la opción pertinente es Credential Guard configuration: Turn on without lock: Sophos indica que se puede revertir mediante Turn off o una directiva de grupo de Windows. Turn on with UEFI lock no debe planificarse como un interruptor remoto reversible. Sophos exige presencia física en el equipo para desactivarlo; Microsoft documenta un procedimiento específico de EFI/arranque con confirmación antes de iniciar el sistema. No actives este modo sin preparar expresamente una vía local de reversión. Turn off no elimina un bloqueo UEFI ya establecido. Incluso sin bloqueo UEFI, otras directivas de administración pueden prevalecer sobre el cambio o Windows puede haber activado Credential Guard de forma predeterminada.

Compara el estado inicial y el estado deseado en el dispositivo de prueba mediante System Information (msinfo32.exe), en Virtualization-based Security Services Running: si el objetivo de la prueba era activarlo, Credential Guard debe figurar como en ejecución. Que la tarea de la directiva termine correctamente no demuestra por sí solo que se esté ejecutando. Después del reinicio, prueba con una cuenta autorizada en el dispositivo piloto representativo los inicios de sesión y conexiones previamente identificados que realmente se utilizan (en particular, 802.1X/WLAN, VPN, RDP/soporte remoto y las aplicaciones de SSO/delegación afectadas; cuando existan, también las integraciones PKINIT-RSA/DES y SSP/AP, y las aplicaciones que leen credenciales de Windows guardadas), así como la vía de recuperación independiente; no deduzcas que las conexiones de red y soporte funcionan solo porque Credential Guard esté en ejecución. Si hay discrepancias, comprueba primero la edición, Secure Boot/DMA, las demás directivas y el estado del reinicio; no experimentes activando o desactivando el bloqueo UEFI. Si se usa without lock, planifica la reversión mediante la directiva de Windows preparada o la GPO correspondiente, sincroniza el dispositivo y vuelve a comprobar el estado después de reiniciar. Si se usa with UEFI lock, detente y utiliza el procedimiento local de recuperación de Microsoft aprobado, con acceso físico.

No desplegar a ciegas las configuraciones de correo electrónico

La ayuda de Mobile incluye Email account para Exchange Online/Server e IMAP/POP como configuraciones de Windows. Para que funcionen los marcadores como %_EMAILADDRESS_% y %_USERNAME_%, el usuario asignado debe tener cumplimentados en Sophos Fusion los campos Exchange Login y Email Address. Si hay varias cuentas de Exchange con distintas directivas de buzón, según Sophos Windows solo puede aplicar una directiva; además, el usuario puede rechazar los cambios de configuración de Exchange. Los campos de contraseña en un borrador de directiva no sustituyen un procedimiento aprobado de identidad y gestión de secretos.

Conflicto importante de vigencia: Sophos describe expresamente la configuración de correo de Exchange para la aplicación Mail de Microsoft; Microsoft dejó de ofrecer soporte para Windows Mail/Calendar/People el 31 de diciembre de 2024 e indica que ya no se pueden enviar ni recibir correos o eventos mediante estas aplicaciones. La página de Sophos sobre IMAP/POP no indica ningún cliente de destino que cuente actualmente con soporte; tampoco se ha demostrado que esta configuración se transfiera al nuevo Outlook. Por ello, aquí no se ofrecen instrucciones para desplegar esa aplicación de correo en producción ni se presupone una migración automática al nuevo Outlook. Primero aclara el cliente de destino, la autenticación, la directiva de buzón y el soporte actual en el tenant concreto y haz pruebas por separado.

Despliegue, comprobación y reversión

Tras las comprobaciones previas, crea en Sophos Mobile, bajo Policies > Windows, una directiva nueva y exclusiva para la prueba piloto. Antes de editar una directiva existente, comprueba primero todos los dispositivos y grupos a los que está asignada: los cambios de una directiva de Windows ya asignada se sincronizan automáticamente en la próxima conexión de esos dispositivos y no constituyen una prueba limitada a un solo dispositivo. Mediante Add configuration, agrega únicamente la configuración comprobada, guarda la directiva y, con Assign, selecciona exclusivamente el dispositivo piloto elegido. En las directivas de Windows, la página Schedule task descrita en el cuadro de diálogo de Sophos está disponible para las directivas de Android, Knox e iOS, no para Windows; no prometas aquí una asignación programada de Windows. Por tanto, la prueba solo debe comenzar cuando la persona responsable de atender el dispositivo esté preparada.

Tras la asignación, compara la vista Policies del dispositivo afectado, el estado de las tareas y el comportamiento real del dispositivo. Las directivas de Windows se sincronizan automáticamente al conectar el dispositivo; su aparición en la interfaz no demuestra por sí sola que surtan efecto localmente. Ante un cambio inesperado, no actives otro ajuste de seguridad: mantén el dispositivo accesible, corrige de forma controlada solo la directiva reservada al piloto o asigna una directiva sustitutiva ya comprobada, espera a la sincronización y al reinicio necesario y vuelve a verificar localmente. Antes de modificar otra directiva compartida asignada, comprueba a qué dispositivos y grupos se aplica. Esto no restaura automáticamente los perfiles WLAN ya eliminados ni revierte un bloqueo UEFI o una solicitud de recuperación de BitLocker ya activada.

Delimitación: Los certificados raíz y de cliente, SCEP y los perfiles WLAN forman parte de un proceso independiente de redes y certificados de Windows. Los protectores de BitLocker y la gestión de claves de recuperación corresponden a Device Encryption. El modo quiosco y la inscripción de Windows tienen cada uno sus propios requisitos y vías de reversión; ninguna de estas tareas queda resuelta automáticamente mediante la directiva de seguridad examinada aquí.