Puntos clave
- Los certificados de Secure Boot de Microsoft emitidos en 2011 caducan en 2026, por lo que los dispositivos Windows deben adoptar los certificados UEFI actualizados de 2023.
- Los dispositivos que no reciban las actualizaciones de la CA 2023 perderán las futuras protecciones de Secure Boot, incluidas las actualizaciones de revocación, los parches del gestor de arranque y las mitigaciones de vulnerabilidades.
- El script SecureBoot Management de NinjaOne audita los almacenes de certificados del firmware, sigue las fases de despliegue de Microsoft y clasifica los dispositivos en estados con acciones concretas.
- Cómo gestionar la rotación de Secure Boot: crea campos personalizados en NinjaOne, importa el script de automatización, audita los dispositivos, activa la suscripción a Windows Update y programa análisis periódicos.
- Los dispositivos marcados como Action Required suelen tener un firmware no escribible por el SO, lo que exige actualizaciones de BIOS del fabricante o un restablecimiento manual de las claves de Secure Boot.
- Los grupos de dispositivos de NinjaOne ayudan a priorizar los flujos de remediación para los endpoints Windows no conformes, en curso o bloqueados por el firmware, a cualquier escala.
¿Qué es la caducidad de los certificados de Secure Boot de Microsoft?
Secure Boot es una función de seguridad de UEFI que valida las firmas digitales del software previo al arranque antes de permitir su ejecución. Para ello, comprueba los módulos de firmware —incluidos los cargadores de arranque y los controladores UEFI— frente a un conjunto de certificados de confianza almacenados directamente en el firmware del dispositivo. Así se evita que los bootkits y otro malware previo al SO se instalen antes incluso de que arranque Windows.
Los certificados que han sostenido esta cadena de confianza desde Windows 8 están a punto de caducar. Microsoft ya ha publicado los certificados actualizados de 2023 para sustituirlos, y las organizaciones deben actuar antes de que caduquen los originales de 2011.
Certificados que caducan en 2026
- Microsoft Corporation KEK CA 2011 → Caduca en junio de 2026
- Microsoft UEFI CA 2011 → Caduca en junio de 2026
- Microsoft Windows Production PCA 2011 → Caduca en octubre de 2026
Los dispositivos que no reciban estas actualizaciones no dejarán de arrancar de inmediato, pero sí perderán la capacidad de recibir nuevas protecciones de seguridad de Secure Boot: actualizaciones de las listas de revocación, parches del gestor de arranque y mitigaciones para vulnerabilidades de arranque recién descubiertas. Esto genera una exposición que crece con el tiempo.
La solución de NinjaOne: el script SecureBoot Management
Vamos a usar un script de SunshineSam publicado en la comunidad de NinjaOne.
Puedes encontrar el script aquí: https://github.com/SunshineSam/Scripts/tree/main/NinjaRMM/Windows/SecureBoot%20Management
El script SecureBoot Management de NinjaOne
- Audita las bases de datos de certificados reales del firmware del dispositivo (db, KEK, dbDefault, dbx)
- Sigue el avance de la rotación en el despliegue multifase de Microsoft (fases 1 a 4)
- Detecta si el firmware es escribible por el SO, de modo que sepas si Windows Update puede aplicar la actualización automáticamente
- Asigna a cada dispositivo uno de los siete estados de despliegue, con indicaciones claras sobre el siguiente paso
- Opcionalmente aplica las mitigaciones de refuerzo SVN (con estrictos controles de seguridad para evitar inutilizar el equipo)
- Genera tarjetas de estado WYSIWYG y HTML con formato para tener visibilidad de todo el parque de dispositivos en NinjaOne
Paso 1: crear los campos personalizados
Empecemos configurando los campos personalizados que mostrarán el resultado del script en las vistas de dispositivos de NinjaOne. Ve a Administración → Dispositivos → Campos personalizados y crea dos campos:
- SecureBootCertStatusCard: un campo WYSIWYG para la tarjeta de estado HTML completa. Configúralo como Lectura/Escritura desde automatizaciones y solo lectura para los técnicos. En Avanzado, marca la casilla para que se expanda siempre.
- SecureBootCertStatus: un campo de texto (límite de 200 caracteres) para el resumen de una línea en texto plano. Es ideal para filtrar de un vistazo en las tablas de dispositivos y en los desencadenantes de alertas.
Una vez creados los campos, ve al menú Roles, sitúa el cursor sobre Windows Systems, haz clic en los puntos suspensivos, selecciona Editar y luego haz clic en Gestionar pestañas en la parte superior derecha. Añade una nueva pestaña llamada Secure Boot, cierra la ventana, cambia a la nueva pestaña y añade ambos campos personalizados.
Paso 2: importar el script desde la biblioteca de plantillas
Ve a Administración → Biblioteca → Automatización y haz clic en el botón «Añadir automatización». Copia y pega el script.
Una vez importado, crea las variables del script:
| Nombre visible | Nombre de la variable | Tipo | Valores |
| SecureBoot Action | securebootAction | Desplegable | Audit SecureBoot management status Enable opt-in for SecureBoot management Remove opt-in for SecureBoot management Valor predeterminado: Audit SecureBoot management status |
| Enforce SVN Compliance | enforceSvnCompliance | Desplegable | Passive Enforce SVN Valor predeterminado: Passive |
| Save Status Local | saveStatusLocal | Casilla de verificación | Passive Enforce SVN Valor predeterminado: sin marcar |
| Save Log to Device | saveLogToDevice | Casilla de verificación | Passive Enforce SVN Valor predeterminado: sin marcar |
| Include Default Hive | includeDefaultHive | Casilla de verificación | Passive Enforce SVN Valor predeterminado: sin marcar |
Paso 3: ejecutar una auditoría en un dispositivo real
Ejecuta el script con securebootAction en Audit y enforceSvnCompliance en Passive. Se trata de una ejecución totalmente de solo lectura: no se modifica nada en el dispositivo.
Cuando el script termine, abre el registro del dispositivo y ve a la pestaña Secure Boot. Verás la tarjeta de estado rellenada con un desglose detallado:
- Inventario de certificados: cuáles de los cuatro nuevos certificados de 2023 están presentes, pendientes o ausentes en el firmware del dispositivo
- Estado de despliegue: uno de los siete estados principales: Compliant, Pending, Action Optional, Action Required,* Disabled, Not Applicable o Unknown
- Registro de mantenimiento: el valor UEFICA2023Status y los posibles códigos de error
- Cronología del registro de eventos: un historial codificado por colores de los eventos de Secure Boot (ID de evento 1799, 1800, 1801, 1808 y otros)
- Estado de la suscripción: si Windows Update está configurado para gestionar la rotación automáticamente
- Cumplimiento de SVN: cuáles de las cuatro fases de refuerzo de Microsoft se han aplicado
*Si un dispositivo muestra Action Required, normalmente significa que el firmware no es escribible por el SO y requiere o bien una actualización de firmware BIOS/UEFI del fabricante, o bien un restablecimiento manual de las claves de Secure Boot. La tarjeta de estado mostrará enlaces a las guías específicas de cada fabricante para dispositivos Dell, HP, Lenovo, ASUS y Microsoft Surface.
Los siete estados de despliegue, explicados
Cada dispositivo en el que se ejecuta el script queda asignado exactamente a un estado principal. Esto es lo que significa cada uno y qué acción hace falta, si procede:
| Estado | Desencadenante | Significado |
| ✅ compliant | Se ha producido el evento 1808 o UEFICA2023Status = Updated en el registro de mantenimiento | El SO confirma que la rotación de certificados se ha completado. Las diferencias restantes de certificados o SVN se muestran mediante superposiciones. |
| ⚠️ Pending | Secure Boot activado, rotación en curso (eventos 1801, 1800, 1799, eventos de despliegue o progreso silencioso) | La actualización gestionada por WU está avanzando, falta reiniciar o las fases se han consumido parcialmente. Se ramifica según has2023InDb, has2023InDbDefault y el estado de la suscripción. |
| ⚠️ Action Optional | Faltan certificados en db, pero el firmware es escribible por el SO (RUNTIME_ACCESS + TIME_BASED_AUTH_WRITE) y la KEK 2023 está presente o se puede entregar | Windows Update acabará enviando los certificados directamente a la BIOS: no hace falta ninguna intervención humana. Una actualización de BIOS o un restablecimiento de claves puede acelerarlo. |
| ❌ Action Required | Faltan certificados tanto en db como en dbDefault y el firmware no es escribible por el SO, o se ha producido el evento 1803 (el fabricante no proporcionó una KEK firmada con la PK) o el evento 1795 (el firmware rechazó activamente la escritura de la KEK) | Windows no puede resolverlo por sí solo. Hace falta una actualización de firmware/BIOS del fabricante o un restablecimiento manual de las claves de Secure Boot. La tarjeta muestra enlaces a las guías específicas de cada fabricante. |
| ⚠️ Disabled | Hay hardware UEFI, pero Secure Boot está desactivado en el firmware | La rotación de certificados no se aplica hasta que se vuelva a activar Secure Boot. |
| ❔ Not Applicable | Entorno con BIOS heredada o sin UEFI | La rotación de la CA de 2023 no afecta a este dispositivo. |
| ❔ Uknown | Valor de reserva: no coincidió ninguna rama (debería ser poco frecuente) | La máquina de estados no llegó a resolverse. Revisa manualmente la salida del script y el registro de eventos. |
Paso 4: activar la suscripción y programar auditorías periódicas
Ahora que conocemos el estado de nuestros dispositivos, podemos empezar a actuar. Para la mayoría de los dispositivos de entornos gestionados, la vía más rápida es activar la suscripción a Windows Update para que el proceso de actualización de Microsoft envíe los nuevos certificados automáticamente.
Vuelve a ejecutar el script con $securebootAction en Enable opt-in for SecureBoot management. Esto configura las claves de registro de suscripción del equipo, establece el nivel de telemetría necesario y activa la tarea programada. Si el dispositivo ya está suscrito o ya es conforme, el script indica que no era necesario ningún cambio.
Para mantener los campos personalizados al día, programa el script como una automatización semanal. Ve a tu política de estaciones de trabajo y añade una automatización programada que ejecute el script en modo Audit con una periodicidad semanal. Así, a medida que los dispositivos completen su rotación —o encuentren problemas— lo verás reflejado en NinjaOne sin ningún esfuerzo manual.
Paso 5: crear grupos de dispositivos para una remediación específica
Con los campos personalizados actualizándose con regularidad, puedes crear grupos de dispositivos que muestren los equipos que necesitan atención. Ve a Dispositivos y crea un nuevo grupo de dispositivos con las siguientes condiciones:
- Estaciones de trabajo Windows en las que SecureBootCertStatus contiene Action Required: estos dispositivos necesitan una actualización de firmware o un restablecimiento manual de claves y no se resolverán por sí solos mediante Windows Update
- Estaciones de trabajo Windows en las que SecureBootCertStatus contiene Action Optional: estos avanzan automáticamente, pero puedes acelerarlos o confirmar que la suscripción está activada
- Estaciones de trabajo Windows en las que SecureBootCertStatus no contiene Compliant: un criterio amplio que recoge todo lo que aún no ha terminado
Guárdalos como «Secure Boot – Action Required» y «Secure Boot – In Progress». Ahora puedes vincular tareas automatizadas, condiciones de alerta o flujos de trabajo de los técnicos directamente a estos grupos, lo que hace manejable la remediación de todo el parque incluso a gran escala.
Riesgos de aplicar la obligatoriedad de SVN en Secure Boot
El script también permite aplicar las mitigaciones de refuerzo de Microsoft basadas en el Secure Version Number (SVN), que se corresponden con las cuatro fases del plan de despliegue de Microsoft. El SVN es la pieza de protección frente a reversiones: una vez aplicado, el firmware se negará a cargar cualquier versión anterior a la registrada, lo que impide que un atacante vuelva a un gestor de arranque vulnerable.
Las fases 3 y 4 son irreversibles. Una vez revocadas las CA de 2011 (fase 3) o escrito el SVN en el firmware (fase 4), no hay marcha atrás sin un restablecimiento físico de fábrica de la BIOS. El script aplica controles estrictos de requisitos previos para evitar que se apliquen fuera de orden. Si los dispositivos usan BitLocker, asegúrate de tener una copia de seguridad de las claves de recuperación de BitLocker antes de ejecutarlo en modo Enforce.
El enfoque recomendado hasta que Microsoft empiece a aplicarlo de forma obligatoria en junio de 2026 es dejar $enforceSvnCompliance en Passive. En modo Passive, el script audita e informa de tu estado de SVN sin realizar ningún cambio, y además ejecuta una comprobación de seguridad para limpiar cualquier bit preparado de forma prematura antes de que un reinicio pueda procesarlo.
El calendario de despliegue de Microsoft
Este es el despliegue en cuatro fases que Microsoft ha planificado para el proceso de actualización de los certificados de Secure Boot:
| Fase | Fecha | Qué ocurre | ¿Es disruptiva? |
| 1 | Mayo de 2024 | Actualización de UEFI: añade Windows UEFI CA 2023 a la base de datos de firmas (db) | No disruptiva |
| 2 | Febrero de 2025 | Actualización del gestor de arranque: instala un gestor de arranque firmado con la clave de la CA de 2023 | No disruptiva |
| 3 | Junio de 2026 | Revocación: actualiza dbx para revocar el antiguo certificado PCA 2011 y bloquear los componentes de arranque antiguos | Disruptiva |
| 4 | 2027 (estimado) | Actualización de SVN: escribe el Secure Version Number en el firmware para impedir la reversión a un gestor de arranque vulnerable | Disruptiva |
Para terminar
La fecha límite de junio de 2026 está a la vuelta de la esquina, pero ya tienes todo lo necesario para ir por delante. Recapitulemos lo que hemos visto:
- Crea dos campos personalizados: un campo WYSIWYG para la tarjeta y un campo de texto para el resumen
- Añade una pestaña Secure Boot a tu rol Windows Systems y asocia ambos campos
- Importa el script SecureBoot Management desde https://github.com/SunshineSam/Scripts/tree/main/NinjaRMM/Windows/SecureBoot%20Management
- Ejecuta una auditoría inicial en todo el parque en modo Passive/Audit para establecer la situación de partida
- Activa la suscripción a Windows Update en los dispositivos listos para la rotación automática
- Programa una automatización de auditoría semanal para mantener actualizados los registros de los dispositivos
- Crea grupos de dispositivos para los equipos en Action Required y Action Optional y dirige así la remediación
- En los dispositivos con estado Action Required, aplica primero las actualizaciones de firmware del fabricante y vuelve a auditar
Agradecimientos
¡Muchas gracias y todo el mérito para Sam K., el creador del script usado en este artículo! Puedes contactar con Sam en LinkedIn aquí: www.linkedin.com/in/samauroh
Recursos
- Visión general de los certificados de Secure Boot de Microsoft: KB5062710
- Blog de Microsoft para profesionales de TI – Secure Boot Playbook: techcommunity.microsoft.com
- Todos los recursos sobre Secure Boot: https://aka.ms/GetSecureBoot
- Documentación de la biblioteca de plantillas de NinjaOne y script SecureBoot Management: GitHub – SecureBoot-Management-CA2023.ps1
