El conjunto de preguntas de Cyber Essentials cambió el 27 de abril de 2026. La versión Danzell introdujo algo que el esquema no tenía antes: preguntas en las que una respuesta incorrecta hace fracasar la evaluación de forma inmediata, en lugar de reducir una puntuación. Varias de ellas caen de lleno sobre Microsoft 365, y dos de ellas atrapan cosas que la mayoría de los tenants lleva arrastrando en silencio durante años.
Nosotros mismos tenemos Cyber Essentials, así que esto está escrito desde haber pasado por ello y no desde leer la especificación.
Esto es una lista de comprobación para ejecutar antes de enviar, no un sustituto del conjunto de preguntas oficial de IASME.
El cambio que pilla a la gente
Dos cosas importan más que el resto.
Las preguntas de autenticación multifactor ahora pueden hacerle fracasar de forma inmediata. Antes una posición de MFA imperfecta era algo que se explicaba. Ahora, para las cuentas dentro del alcance, es aprobado o suspenso.
Hay una definición formal de los servicios cloud dentro del alcance. Esto cierra el hueco que permitía a las organizaciones argumentar que Microsoft 365 quedaba fuera del límite de la evaluación. Si sus usuarios inician sesión en él y contiene datos de la organización, está dentro del alcance. Ese argumento se ha acabado.
Juntas significan que la evaluación ahora alcanza sitios que antes se dejaban en paz.
Eso cambia la naturaleza del trabajo. Una pregunta de fallo automático no es algo a lo que se le escribe una respuesta cuidadosa; o puede responderla honestamente de forma afirmativa o no puede. El ejercicio se convierte en descubrimiento en lugar de en redacción: una lista de cada identidad que puede autenticarse, qué la autentica y qué se rompería si la cambiara. Producir esa lista es la mayor parte del esfuerzo. La remediación suele ser rápida.
El orden que hace repetible un aprobado de Cyber Essentials: descubrir primero, decidir después, cambiar en tercer lugar y conservar las evidencias.
Las dos que de verdad pillan a la gente
Cuentas de servicio
Todo tenant las tiene. La cuenta que ejecuta una exportación programada. Aquella con la que se autentica una aplicación de negocio. La creada para una migración en 2021 que nadie apagó.
Normalmente no tienen MFA, porque MFA rompería lo que sea que automatizan. Eso era tolerable cuando la pregunta se puntuaba. Ahora no lo es.
Encuéntrelas antes de discutir sobre ellas. Dos vistas le dan la lista de candidatas rápidamente:
- Centro de administración de Microsoft Entra, Protección, Métodos de autenticación, Detalles de registro de usuario. Muestra cada cuenta y si es apta para MFA y está registrada. Filtre por las cuentas sin nada registrado y estará mirando su exposición.
- Entra ID, Supervisión, Registros de inicio de sesión, filtrados a inicios de sesión de usuario no interactivos. La automatización aparece aquí, no en el registro interactivo. Una cuenta con miles de inicios de sesión no interactivos y sin método registrado es una cuenta de servicio, se llame como se llame.
La misma lista sale de Microsoft Graph PowerShell como CSV:
Connect-MgGraph -Scopes 'AuditLog.Read.All','Directory.Read.All'
Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
Where-Object { -not $_.IsMfaRegistered } |
Select-Object UserPrincipalName, IsAdmin, IsMfaCapable |
Export-Csv .\no-mfa.csv -NoTypeInformation
Qué hacer, en orden de preferencia:
- Sustituya la cuenta por completo. Una identidad de carga de trabajo o una identidad administrada es la respuesta correcta para cualquier cosa que se ejecute desatendida. Sin inicio de sesión interactivo, sin pregunta de MFA, sin secreto compartido en un archivo de configuración.
- Si tiene que seguir siendo una cuenta, quítele los derechos de inicio de sesión interactivo, acótela con conditional access y sea capaz de mostrar qué puede y qué no puede hacer.
- Documente por qué existe. Un evaluador aceptará una excepción controlada mucho más fácilmente que una cuenta que nadie sabe explicar.
Un ejemplo trabajado: una exportación financiera se ejecuta cada noche bajo una cuenta con licencia con una contraseña en una tarea programada. La respuesta correcta la mueve a un registro de aplicación con credenciales de certificado y solo los permisos de Graph que la exportación necesita, eliminando la cuenta y la contraseña a la vez. Si la aplicación todavía no puede hacer eso, mantenga la cuenta, bloquee el inicio de sesión interactivo, restrínjala mediante conditional access a ese único servicio y registre el control compensatorio.
El modo de fallo aquí es descubrirlas la semana en que envía. Siempre son más numerosas de lo esperado.
Buzones compartidos
Esta es la que sorprende a la gente. Se supone que un buzón compartido no debe tener ningún inicio de sesión habilitado. El acceso está pensado para delegarse a usuarios con nombre que tienen su propia MFA.
En la práctica muchos tenants tienen buzones compartidos con una cuenta subyacente habilitada y una contraseña que alguien conoce, creada hace años para que un teléfono o un escáner pudiera enviar correo. Eso es una cuenta con contraseña y sin MFA, que contiene datos de la organización, y el nuevo conjunto de preguntas tiene una opinión al respecto.
Compruebe cada buzón compartido en busca de un inicio de sesión habilitado:
Connect-ExchangeOnline
Connect-MgGraph -Scopes 'User.Read.All'
Get-Mailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited |
ForEach-Object { Get-MgUser -UserId $_.ExternalDirectoryObjectId -Property UserPrincipalName,AccountEnabled } |
Where-Object { $_.AccountEnabled } |
Select-Object UserPrincipalName
Todo lo que devuelva necesita el inicio de sesión bloqueado, en el centro de administración de Entra bajo Usuarios o con Update-MgUser -UserId <upn> -AccountEnabled:$false. Delegue el acceso con Add-MailboxPermission para acceso total y Add-RecipientPermission para enviar como, de modo que cada acción contra ese buzón pertenezca a una identidad que lleva su propia MFA.
Si algo necesita realmente enviar correo desatendido, eso es un problema de permisos de aplicación, no un problema de contraseña de buzón. Muévalo a un registro de aplicación con permisos de correo acotados, o a un conector de recepción restringido a una dirección estática conocida. Donde la autenticación SMTP básica siga habilitada, Set-CASMailbox -Identity <mailbox> -SmtpClientAuthenticationDisabled $true la cierra por buzón y el ajuste equivalente en Set-TransportConfig la cierra para toda la organización. Compruebe primero qué admite cada dispositivo: un dispositivo multifunción que deja de escanear a correo en silencio es una cola de soporte que nadie le agradecerá.
El resto de la lista
Cada cuenta de usuario con licencia tiene MFA. No «tenemos una política». Verifique la aplicación efectiva, incluidas las cuentas creadas desde que se escribió la política, los invitados y cualquiera excluido de conditional access. Lea las exclusiones de cada política en concreto, porque ahí es donde vive la deriva: un grupo de proyecto añadido durante quince días en 2024, una cuenta de proveedor, un rol de directorio que salta la regla en silencio.
Las cuentas de invitado están contabilizadas. Los invitados se autentican en su tenant de origen, así que su MFA puede quedar satisfecha en otro sitio, y los ajustes de acceso entre tenants deciden si su tenant confía en esa afirmación. No tiene que tomar una decisión concreta, pero debe saber cuál tomó.
Las cuentas de emergencia son una excepción documentada. Se le permiten cuentas de acceso de emergencia. Se espera que las controle y las supervise: dos cuentas solo en la nube, excluidas de las políticas que podrían dejar fuera a todo el mundo, credenciales divididas y guardadas físicamente, y una alerta que se dispare en el momento en que cualquiera de las dos inicie sesión. La guía actual favorece un método resistente al phishing en lugar de solo una contraseña, así que revise eso si el par tiene ya algunos años.
Las cuentas administrativas están separadas de las cuentas de uso diario. Un administrador que consulta el correo desde la misma identidad es un hallazgo esperando a ocurrir. Donde la licencia lo permita, la elevación justo a tiempo mediante Privileged Identity Management le da la separación y un registro ya hecho de quién tuvo qué rol y cuándo.
La autenticación heredada está apagada. Si la autenticación básica todavía puede alcanzar algo, la respuesta sobre MFA no es cierta en la práctica. Filtre los registros de inicio de sesión por una aplicación cliente de «Otros clientes» y vea qué aparece. La mayoría de los protocolos heredados en Exchange Online están retirados desde hace mucho; la autenticación SMTP es la que sobrevive, porque algo operativo depende de ella.
Sus evidencias de parcheado de dispositivos son exportables. Al esquema le importa el estado de los dispositivos, y la respuesta tiene que venir de algo que pueda mostrar en lugar de afirmar. Intune puede producirlo, y demostrarlo desde Intune es un ejercicio aparte que merece la pena hacer antes de necesitarlo. Lo que quiere es una exportación fechada del cumplimiento de compilación y actualizaciones por dispositivo, no una captura de pantalla de un panel que la semana que viene tendrá otro aspecto.
Su declaración de alcance coincide con la realidad. Con los servicios cloud definidos formalmente, un límite inexacto es ahora un suspenso directo en lugar de una discusión. Recorra la lista de servicios en los que su gente inicia sesión con una identidad de trabajo, incluidos los que un departamento adoptó sin decírselo a nadie.
Haga esto en el orden correcto
Ejecute el descubrimiento antes de tocar nada. La tentación es empezar a bloquear inicios de sesión según los va encontrando, que es como una ejecución programada de facturación se detiene en silencio un viernes por la tarde.
El orden que funciona:
- Enumere cada cuenta: usuarios, cuentas de servicio, buzones compartidos, invitados.
- Para cada una, establezca para qué sirve y si algo depende de ella.
- Decida el estado objetivo de cada una.
- Cámbielas de forma controlada, vigilando qué se rompe.
- Capture las evidencias sobre la marcha, porque las necesitará otra vez el año que viene.
Dese unas seis semanas. Perseguir para qué se usa una cuenta misteriosa es lo que más tarda, y las políticas de conditional access en modo solo informe le permiten medir un endurecimiento antes de que caiga sobre nadie.
Conserve las evidencias como una exportación fechada por control en lugar de una carpeta de capturas de pantalla: el informe de detalles de registro, las políticas de conditional access con las exclusiones visibles, el estado de inicio de sesión de los buzones compartidos, el procedimiento de emergencia, la exportación de cumplimiento de dispositivos y una nota por excepción.
Cyber Essentials se renueva cada año, así que todo lo que construya como algo puntual lo volverá a construir en doce meses. Construirlo como algo repetible es la diferencia entre quince días y una tarde la próxima vez.
Dónde conecta esto
El problema de las evidencias y el problema de la seguridad son el mismo problema visto desde dos lados. Nuestra ruta de seguridad y conformidad de Microsoft 365 cubre la postura, y conformidad ISO y preparación para auditorías cubre el rastro de evidencias. Escribimos antes sobre mapear los ajustes de Microsoft 365 a Cyber Essentials e ISO 27001, y ese mapeo sigue siendo válido; lo que cambió es la consecuencia de equivocarse.
La higiene de cuentas se solapa casi por completo con el trabajo de altas, cambios y bajas, así que ejecutar bien la lista de comprobación de offboarding de Microsoft 365 le hace una parte de esto.
Dónde encaja EtherInsights
Reunir estas evidencias a mano, cada año, a través de un tenant es exactamente el tipo de trabajo que se aplaza hasta que es urgente. EtherInsights existe en parte por esa razón. Informa sobre identidad y cobertura de MFA, estado de dispositivos e Intune, y configuración del tenant desde un solo sitio, de modo que la pasada de descubrimiento se convierte en un informe que puede volver a ejecutar el año que viene y comparar con este.
Para los proveedores de servicios gestionados la multiplicación es la clave: la misma lista a través de veinte tenants son veinte ejercicios de descubrimiento, y las cuentas que fallan en uno tienden a parecer idénticas en el siguiente. Ejecutarla como un informe repetible es lo que hace soportable la renovación anual, y seguridad y conformidad de Microsoft 365 es donde la postura y las evidencias se juntan.
Explore la seguridad y conformidad de Microsoft 365 para ver cómo la postura, las evidencias y la reevaluación anual se juntan en un solo sitio.