Los certificados de Secure Boot caducan en junio de 2026: qué deben implementar los equipos de TI antes de la fecha límite para su flota de Windows
A partir de junio de 2026, los certificados Microsoft Secure Boot emitidos en 2011 perderán su validez. Los dispositivos Windows que no hayan instalado el certificado de 2023 no podrán aplicar futuras actualizaciones de Secure Boot y dejarán de confiar en software de terceros recién firmado. Los equipos de TI disponen aún de aproximadamente dos meses para realizar inventarios, pruebas e implementaciones. Quien espere hasta junio para actuar, llegará tarde.
Lo más importante en resumen
- Microsoft ha anunciado la sustitución de los certificados de Secure Boot utilizados desde 2011 para junio de 2026. La validez de los certificados Microsoft Corporation KEK CA 2011, Microsoft Windows Production PCA 2011 y Microsoft Corporation UEFI CA 2011 finalizará de forma escalonada entre junio y octubre de 2026.
- Los dispositivos que no dispongan de los certificados actualizados de 2023 no podrán instalar nuevas actualizaciones de Secure Boot tras su caducidad ni confiarán en software de terceros firmado después de la fecha límite.
- Los equipos con Windows comercializados desde principios de 2024 ya incluyen los certificados de 2023 de fábrica. Todos los dispositivos anteriores deben actualizarse activamente.
- La verificación del estado se realiza mediante una entrada en el registro: UEFICA2023Status debe tener el valor «updated». Microsoft proporciona comandos de PowerShell para realizar inventarios (aka.ms/GetSecureBoot).
- El hardware más antiguo sin soporte de firmware por parte del fabricante (OEM) podría no recibir nunca esta actualización. En estos casos, solo queda evaluar el riesgo o proceder al reemplazo del equipo.
Lo que caduca concretamente en junio de 2026
Secure Boot es un mecanismo UEFI (Interfaz de firmware extensible unificada) que, al arrancar un ordenador, verifica si el firmware cargado, el gestor de arranque y el sistema operativo proceden de una fuente de confianza. Esta cadena de confianza se basa en firmas criptográficas emitidas por entidades conocidas como Certificate Authorities (CAs). En 2011, Microsoft estableció tres CAs centrales: la Microsoft Corporation KEK CA 2011 para la base de datos de claves de intercambio (Key Exchange Key Database), la Microsoft Windows Production PCA 2011 para componentes de Windows firmados y la Microsoft Corporation UEFI CA 2011 para software de terceros.
Estos tres certificados perderán su validez a partir de junio de 2026. Sin embargo, su sustitución no supone un fallo repentino, sino un proceso escalonado que se prolongará hasta octubre de 2026. Microsoft ya implementó los certificados sucesores en 2023 y los está distribuyendo progresivamente mediante actualizaciones de Windows a los dispositivos existentes. Los equipos comercializados desde principios de 2024 incluyen ya las CAs de 2023 directamente de fábrica, lo que representa una ventaja estratégica para empresas con parques de equipos recientes, pero un riesgo para todas las demás.
Este cambio responde a motivos técnicos y regulatorios. Los certificados de 2011 proceden de una época en la que SHA-1 aún era ampliamente utilizado y la arquitectura Secure Boot afectaba a muchos menos fabricantes que hoy en día. Con la transición a las CAs de 2023, Microsoft adapta los algoritmos criptográficos a los estándares actuales y reduce simultáneamente la duración de validez de los certificados a un período más manejable para entornos productivos.
Definición
UEFI CA 2011 frente a UEFI CA 2023 hace referencia a dos generaciones de certificados Secure Boot. Las CAs de 2011 han garantizado durante más de una década la cadena de confianza para el firmware de Windows y de terceros. Las CAs de 2023 las sustituyen a partir de junio de 2026 con algoritmos de firma actualizados y una estructura de validez más clara. Ambas CAs pueden coexistir activas, pero solo los dispositivos que tengan instalado el conjunto de 2023 podrán confiar en nuevas actualizaciones tras la expiración de las de 2011.
Qué dispositivos están afectados
La regla es sencilla: todo lo fabricado antes de 2024 necesita una actualización activa. En la práctica, esto afecta a la mayoría de los dispositivos en una empresa típica, ya que la vida útil promedio de un portátil oscila entre cuatro y seis años, y los equipos de sobremesa suelen seguir en uso aún más tiempo. Los servidores también se ven implicados, aunque los hosts de virtualización y las máquinas virtuales (VM) se tratan de forma diferente.
Los dispositivos físicos con Windows reciben los certificados de 2023 a través de los canales habituales de Windows Update. Sin embargo, su distribución no es automática en el sentido de que «cada equipo lo reciba garantizadamente». Microsoft gestiona la entrega de forma escalonada. Algunas categorías de dispositivos aún esperan la aprobación de los fabricantes originales (OEM). Dell, HP, Lenovo y Fujitsu tienen cronogramas distintos para sus actualizaciones de firmware, que integran los cambios en las autoridades de certificación (CA) directamente en el hardware. Los equipos de TI deben verificar el estado específico de cada modelo y no asumir que Windows Update resolverá el problema por sí solo.
Las máquinas virtuales constituyen un caso especial. Hyper-V, VMware y KVM admiten Secure Boot, pero las actualizaciones de certificados se gestionan a través de la firmware virtualizada, no del sistema operativo invitado. Para entornos vSphere, VMware ha publicado guías específicas para realizar la transición; Microsoft distribuye las actualizaciones para Hyper-V mediante parches del host. En entornos KVM basados en Linux, el proceso es más complejo y suele requerir intervención manual en cada host de máquinas virtuales.
Particularmente delicados son los dispositivos antiguos que, desde la perspectiva del fabricante, han alcanzado su fin de soporte (End-of-Service). Es posible que para este hardware ya no exista firmware compatible que incorpore las nuevas CA de 2023. Tanto Microsoft como los fabricantes probablemente no darán soporte a todos los equipos antiguos. La redacción de XDA Developers señaló en un análisis a finales de marzo de 2026 que una parte significativa de los PC con Windows anteriores a 2020 probablemente nunca recibirá esta corrección. Para los equipos de TI, esto implica que dichos dispositivos deben inventariarse, priorizarse y, o bien reemplazarse cuanto antes, o bien operarse en segmentos de red aislados con privilegios reducidos.
La verificación del inventario: PowerShell y el Registro
La buena noticia para los equipos de TI: el estado de un dispositivo se puede comprobar con un esfuerzo mínimo. Microsoft ofrece dos métodos. El primero es una entrada en el Registro, ubicada en la ruta HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\UEFICA2023Status. El valor de esta entrada debería terminar mostrando «updated». Otros valores como «NotStarted» o «InProgress» indican que la implementación aún no ha finalizado.
El segundo método es una consulta mediante PowerShell que Microsoft ha publicado en su blog de la comunidad técnica. Esta consulta enumera las entradas actuales de la base de datos de Secure Boot y permite una comparación automatizada con el estado deseado. Para realizar un inventario a escala de toda la flota, se recomienda combinar este enfoque con herramientas como Microsoft Intune, Configuration Manager u otras soluciones equivalentes de gestión de endpoints capaces de consultar este valor del Registro en todos los dispositivos. Verificar manualmente cientos de equipos no es práctico.
Es fundamental distinguir entre «certificado instalado» y «certificado activo». Un dispositivo puede tener el certificado de 2023 almacenado en su base de datos UEFI sin que se utilice realmente. Solo cuando el estado muestra «updated» y la firmware emplea las autoridades de certificación (CA) de 2023 para validar los cargadores de arranque, el equipo está debidamente preparado. La transición completa requiere varios reinicios y, en algunos casos, ajustes manuales en la configuración UEFI. Por ello, los equipos de TI deberían probar el proceso previamente en un pequeño grupo de dispositivos piloto por modelo antes de lanzar la actualización en toda la flota.
El proceso de actualización en cuatro pasos
Microsoft recomienda un enfoque estructurado que los equipos de TI pueden implementar en las próximas seis a ocho semanas. El proceso se divide en cuatro pasos que se construyen lógicamente uno sobre otro y no se pueden ejecutar en paralelo:
Inventario y agrupación
Recopilar el estado de todos los dispositivos Windows mediante una comprobación del registro o una consulta de PowerShell. Agruparlos por modelo del fabricante, antigüedad y versión de firmware. El resultado es una lista con dispositivos clasificados en las categorías «ya actualizados», «actualización disponible» y «sin soporte del OEM».
Implementación piloto en grupo de prueba
Selección de la redacción
RecomendadoCyber Resilience Act desde el 11 de septiembre de 2026: La obligación de notificación de 24 horas, para la que los equipos de seguridad IT deben establecer procesos ahoraRecomendadoPrivileged Access Management: Por qué las cuentas de administrador son la mayor puerta de entrada para los atacantesRecomendadoCisco FMC Zero-Day: El ransomware Interlock explota una vulnerabilidad CVSS 10.0 desde enero
Más de la red MBF Media
MyBusinessFutureStadtwerke Bernau: Lecciones de contadores inteligentescloudmagazinValkey 9 tras 18 meses: Cómo la bifurcación de Redis está…Digital ChiefsConsolidación de Proveedores 2026: Por qué 68% de las organizaciones de TI quieren consolidar – y por qué la hoja de ruta dura 18 meses más de lo planeado
Lectura adicional
Cuando los atacantes son más rápidos que los parches
Entre la divulgación y la explotación de una vulnerabilidad suelen mediar hoy solo días.
Mini Shai-Hulud: el gusano npm devora la cadena de suministro
Mini Shai-Hulud se propaga a sí mismo a través de npm y PyPI: cómo el gusano de la cadena de suministro Tokens roba y …
Protección DNS: la capa que muchos pasan por alto
Casi cada ataque comienza con una consulta DNS. Cómo el **Protective DNS** bloquea tempranamente malware y phishing, y por qué **DNS sobre HTTPS** cierra…





