- Los certificados originales de Secure Boot emitidos en 2011 caducan en junio de 2026 y deben sustituirse por la Windows UEFI CA 2023.
- Windows 11 y Windows 10 con ESU reciben la renovación principalmente vía Windows Update, aunque algunos equipos requieren actualización de BIOS.
- En entornos corporativos es clave inventariar dispositivos, revisar claves de registro y eventos 1801/1808 y configurar MicrosoftUpdateManagedOptIn.
- Coordinar la actualización de firmware con los OEM y mantener Secure Boot habilitado refuerza la protección frente a malware y ataques al arranque.
Si utilizas Windows 10 o Windows 11 y tienes el Arranque seguro (Secure Boot) activado, te afecta directamente el cambio de certificados que Microsoft y los fabricantes de PC van a realizar de aquí a junio de 2026. No es un tema teórico: hablamos de la pieza que valida qué se puede ejecutar en tu máquina desde que pulsas el botón de encendido, y cuyos certificados originales están cerca de caducar.
Durante años hemos dado por hecho que el sistema se protegía desde el mismo arranque, pero ahora toca revisar que todo está preparado para la renovación de certificados Secure Boot. Microsoft, los OEM (como Acer) y los administradores de sistemas ya se han puesto manos a la obra, y conviene entender qué está pasando, qué consecuencias tiene no hacer nada y qué pasos prácticos puedes seguir tanto si eres usuario doméstico como si gestionas una flota de dispositivos en una empresa.
Por qué caducan los certificados de Secure Boot y qué implica
El mecanismo de Secure Boot basado en UEFI se apoya en certificados digitales almacenados en el firmware para decidir qué código es fiable al arrancar: cargadores de arranque, controladores de firmware, componentes críticos previos al sistema operativo, etc. Este modelo se diseñó alrededor de una jerarquía de claves que establece una cadena de confianza desde el firmware hasta Windows.
En esa jerarquía encontramos, por ejemplo, la Platform Key (PK) que suele ser del OEM (como Acer), las Key Exchange Keys (KEK) de Microsoft y del fabricante, y dos bases de datos esenciales: la DB (firmas permitidas) y la DBX (firmas revocadas). La DB incluye certificados y firmas que se consideran de confianza, mientras que la DBX se actualiza con elementos que deben bloquearse por ser inseguros o haber quedado comprometidos.
Los primeros certificados de Secure Boot emitidos conjuntamente por Acer y Microsoft datan de 2011, y se diseñaron con una vida útil aproximada de 15 años. Eso significa que a partir de junio de 2026 esos certificados iniciales alcanzan su fecha de caducidad. Si el firmware de tu equipo sigue dependiendo de ellos sin actualizarse a los nuevos certificados de 2023, la protección de arranque quedará obsoleta.
Con certificados caducados, el ordenador puede seguir encendiendo y ejecutando Windows con normalidad, pero la parte crítica es que Microsoft no podrá aplicar correctamente nuevas mitigaciones sobre el entorno de arranque. Esto incluye protecciones contra malware que se carga antes del sistema, intentos de saltarse BitLocker y otros ataques contra la cadena de confianza inicial.
En equipos más antiguos, o en sistemas que ya no reciben soporte (como instalaciones de Windows 10 sin ESU), el riesgo es acabar con un entorno de arranque que funciona, pero cuya superficie de ataque aumenta porque no recibe las mismas actualizaciones de seguridad ni puede aprovechar revocaciones modernas en la DBX.
Contexto: fin de soporte de Windows 10, auge de Windows 11 y dependencia de Secure Boot
El anuncio del fin de la vida útil de Windows 10 provocó que millones de usuarios dieran el salto a Windows 11 para no quedarse sin parches de seguridad. Hoy la cuota de mercado se ha inclinado claramente hacia Windows 11, con alrededor de un 63 % frente a un 35 % de Windows 10, en gran parte gracias a esa presión del fin de soporte.
Aunque todavía quedan instalaciones de Windows 10 con canales especiales como LTSC o programas de Extended Security Updates (ESU), la realidad es que la mayoría tendrá que convivir con Windows 11 o, en todo caso, con distribuciones Linux si quieren seguir bien protegidos. Pero eso no significa que Windows 11 sea inexpugnable: ahora entra en juego de forma muy directa la validez de los certificados Secure Boot.
Para Windows 11, el Arranque seguro no es un capricho, sino un requisito para la instalación en la mayoría de escenarios soportados. Microsoft insiste en mantenerlo activo no solo por seguridad general, sino porque muchas mitigaciones se apoyan justo en esa cadena de confianza. Incluso en el mundo gaming es cada vez más habitual que títulos modernos (como la saga Battlefield y otros AAA) exijan que Secure Boot esté habilitado para poder ejecutarse.
La última tanda de actualizaciones de seguridad para Windows 11 incluye precisamente la rotación de certificados Secure Boot que expiran en junio de 2026. Buena parte de los usuarios recibirán esos certificados automáticamente a través de Windows Update, sin tener que ir cazando ficheros o paquetes manuales.
En el caso de equipos de sobremesa o portátiles comprados a partir de 2024-2025, los fabricantes OEM ya han ido incorporando directamente los certificados UEFI CA 2023 en sus firmwares, de modo que estos ordenadores salen de fábrica preparados, y lo único que tienes que hacer es mantener Windows al día y no desactivar Secure Boot sin motivo.
Qué pasa si no renuevas los certificados Secure Boot
Una duda muy habitual es si el PC dejará de arrancar cuando llegue la fecha de caducidad. La respuesta, para la mayoría de usuarios, es que el equipo seguirá encendiendo y funcionando con normalidad. Podrás abrir tus aplicaciones, navegar por Internet y usar el sistema operativo tal y como lo haces ahora.
El problema real es más sutil: un equipo con certificados Secure Boot caducados puede dejar de recibir o de aplicar correctamente determinadas actualizaciones que requieren esa nueva cadena de confianza. Algunas mejoras críticas de seguridad a nivel de arranque podrían no instalarse, y se generarían huecos que los atacantes podrían aprovechar.
Además, esas renovaciones de certificados están pensadas para hacer frente a vulnerabilidades modernas en el entorno previo al sistema operativo. Si la base de certificados no se actualiza, el PC puede convertirse en un objetivo más fácil para malware de bootkit, rootkits persistentes o herramientas diseñadas para burlar mecanismos como BitLocker en fases muy tempranas del arranque.
Hay otro escenario a tener en cuenta: algunas aplicaciones, especialmente en entornos corporativos o de alto nivel de seguridad, pueden exigir que Secure Boot esté operativo y actualizado. Si las comprobaciones internas detectan certificados caducados, podrían negarse a ejecutarse o limitar funcionalidades, lo que impactaría en la productividad.
Por todo ello, la recomendación de Microsoft es clara: mantener siempre Secure Boot habilitado y actualizado, instalar las últimas actualizaciones de Windows 11 o, en el caso de Windows 10 con ESU, aplicar todos los parches de seguridad, y asegurarse de contar con la versión más reciente del firmware/BIOS disponible para cada equipo.
Cómo comprobar el estado de los certificados Secure Boot en Windows
Para saber si tu máquina ya ha adoptado los nuevos certificados de arranque seguro, puedes hacer una comprobación rápida desde PowerShell. Microsoft propone una orden que inspecciona el contenido de la base de datos de firmas (db) de Secure Boot y busca específicamente la presencia de la Windows UEFI CA 2023.
Con PowerShell abierto con permisos de administrador, se puede ejecutar algo equivalente a:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
Si el comando devuelve True, significa que el equipo ya está usando el nuevo certificado UEFI de 2023 y se encuentra protegido frente a la caducidad de los certificados originales de 2011. En ese caso, no tendrías que preocuparte más allá de seguir aplicando las actualizaciones normales de Windows y del firmware cuando aparezcan.
Por el contrario, si la expresión devuelve False, la máquina sigue dependiendo de certificados que caducan en junio de 2026. En ese escenario conviene revisar primero si Secure Boot está realmente activado en la BIOS/UEFI, y a continuación forzar o facilitar la llegada de las actualizaciones necesarias mediante Windows Update o mediante la configuración adecuada en entornos gestionados.
Para confirmar que el Arranque seguro está activo, puedes usar la herramienta de información del sistema con el comando msinfo32. En la ventana que se abre, revisa el campo correspondiente a “Estado de Arranque seguro”: si aparece “Activado”, la función está funcionando; si indica “Desactivado” o “No compatible”, tendrás que entrar en la UEFI de la placa base o del portátil para activarla, siempre que el hardware lo permita.
En caso de que tras comprobar msinfo32 y el comando de PowerShell sigas sin ver el certificado 2023, la siguiente parada lógica es Windows Update, revisando si hay actualizaciones pendientes, especialmente las clasificadas como de seguridad o de firmware. En muchas máquinas, basta con instalar esos paquetes y reiniciar para que la renovación de certificados quede aplicada de forma transparente.
Actualización manual de certificados Secure Boot en equipos individuales
Hay casos en los que, a pesar de tener Secure Boot habilitado y Windows Update funcionando, la actualización de la base de certificados no se aplica automáticamente. Para estos supuestos, Microsoft describe una forma de forzar la señalización de actualización mediante el Registro de Windows.
El procedimiento estándar pasa por crear o modificar el valor AvailableUpdates en la rama del registro dedicada a Secure Boot. En PowerShell con privilegios de administrador, se puede emplear un comando como:
reg add HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Es importante tener en cuenta que, al pegar este comando en PowerShell, hay que sustituir las barras “/” de la ruta del registro por las barras invertidas estándar de Windows para que la orden funcione correctamente. Una vez creado o ajustado ese valor, Windows debería detectar que tiene actualizaciones de certificados disponibles y proceder a aplicarlas tras el siguiente ciclo de Windows Update y reinicio.
Antes de tocar el Registro, es recomendable asegurarse de que el sistema cumple los requisitos básicos: Secure Boot activado en BIOS, versión de Windows soportada (Windows 11 o Windows 10 con ESU, principalmente), y servicio de Windows Update operativo. Cualquier cambio erróneo en el registro puede causar problemas, así que conviene tener copia de seguridad o un punto de restauración.
Una vez finalizado el proceso y tras uno o varios reinicios, se puede volver a lanzar el comando de PowerShell que busca “Windows UEFI CA 2023” en la base de datos de Secure Boot. Si en esta ocasión la respuesta es True, la máquina ya trabaja con los certificados renovados y las futuras mitigaciones de arranque podrán aplicarse sin trabas.
Supervisión avanzada: eventos, registro y WMI para administradores
En entornos empresariales, Microsoft recomienda ir mucho más allá de la comprobación manual con un par de comandos. Para entender en qué punto está cada equipo respecto a la actualización de certificados Secure Boot, resulta clave revisar los eventos de sistema y recolectar información detallada mediante PowerShell, registro y consultas WMI/CIM.
Un primer paso es inspeccionar los eventos de arranque seguro más recientes, en especial los identificadores 1801 y 1808. Estos eventos están documentados como parte de los registros asociados a la base de datos de arranque seguro (db) y a las actualizaciones de la base de datos de revocaciones (DBX). Analizar los eventos más recientes ayuda a saber si hay actualizaciones pendientes, errores de aplicación o estados de éxito.
Además, se sugiere hacer un inventario detallado de dispositivos en toda la organización. Con scripts de PowerShell se pueden reunir parámetros como el nombre de máquina (HostName, por ejemplo $env:COMPUTERNAME) y la fecha y hora de colección (Get-Date), para tener una foto clara del parque de equipos en un momento concreto.
Desde el Registro, hay varias claves especialmente relevantes. Por un lado, la clave principal de arranque seguro en HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot, donde se pueden evaluar valores como SecureBootEnabled, HighConfidenceOptOut o AvailableUpdates. Estos datos indican si Secure Boot está activo, si el dispositivo ha optado por ciertas políticas de confianza y si hay actualizaciones de certificados disponibles.
Por otro lado, está la rama de mantenimiento en HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing, que recoge parámetros como UEFICA2023Status, WindowsUEFICA2023Capable y UEFICA2023Error. Estos valores permiten saber si el dispositivo es capaz de adoptar los nuevos certificados UEFI CA 2023, si los ha aplicado y si se ha registrado algún fallo durante el proceso.
También resulta útil la sección de atributos de dispositivo: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\DeviceAttributes, donde se almacenan datos como OEMManufacturerName, OEMModelSystemFamily, OEMModelNumber, FirmwareVersion, FirmwareReleaseDate, OSArchitecture o CanAttemptUpdateAfter. Esta información ayuda a cruzar la compatibilidad de firmware con el estado de las actualizaciones de Secure Boot.
En cuanto a los registros de eventos, conviene recopilar indicadores como el LatestEventId asociado a arranque seguro, el BucketID y el nivel de confianza extraídos de los eventos 1801/1808, así como los contadores Event1801Count y Event1808Count. Con esa telemetría, los equipos de TI pueden detectar patrones, errores recurrentes o dispositivos que nunca completan correctamente las actualizaciones de certificados.
Finalmente, mediante consultas WMI/CIM se obtienen detalles adicionales sobre el sistema: versión de Windows (Get-CimInstance Win32_OperatingSystem para OSVersion y LastBootTime), fabricante y producto de la placa base (Get-CimInstance Win32_BaseBoard), fabricante y modelo de equipo ((Get-CIMInstance Win32_ComputerSystem).Manufacturer y .Model), y datos de BIOS (Get-CIMInstance Win32_BIOS para la descripción y la fecha de lanzamiento). Todo ello permite correlacionar versiones de firmware, hardware y estado de Secure Boot en un mismo inventario.
Entornos gestionados con Intune y dispositivos IT-managed
Para las organizaciones que usan Intune u otras soluciones MDM para administrar sus dispositivos Windows, la pregunta clave es si basta con dejar que Windows Update haga su trabajo o si hay que tomar medidas adicionales de cara a 2026. Microsoft ha indicado que, en entornos gestionados, siempre que los datos de diagnóstico estén habilitados al menos en el nivel “Requerido”, las actualizaciones necesarias se entregarán de forma automática.
En la práctica, esto significa que si tus políticas de Intune ya permiten esa telemetría y tienes bien configuradas las opciones de actualizaciones, puedes estar razonablemente tranquilo. Aun así, muchos administradores se plantean si deben crear manualmente ciertas claves de registro, como MicrosoftUpdateManagedOptIn, o si estas se configuran de manera transparente cuando el dispositivo cumple los requisitos.
Microsoft ha publicado documentación específica indicando que la clave MicrosoftUpdateManagedOptIn, situada en HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot, debe establecerse a 1 en dispositivos con actualizaciones gestionadas por TI para que la renovación automática de certificados se lleve a cabo correctamente. En algunos casos, esta clave puede ser configurada automáticamente, pero en otros puede interesar forzarla mediante políticas.
La recomendación, por tanto, es revisar las directivas de Intune relacionadas con diagnósticos y actualizaciones, verificar el estado real de las máquinas mediante scripts de inventario, y, si es necesario, desplegar una política de configuración que asegure que MicrosoftUpdateManagedOptIn está en el valor adecuado y que las ramas de Servicing reflejan compatibilidad con UEFI CA 2023.
Es igualmente importante no confiar ciegamente en que “no habrá que hacer nada en 2026”. Aunque Microsoft automatiza gran parte del proceso, cada organización tiene particularidades: dispositivos con firmware antiguo, equipos que no se conectan regularmente, políticas de red restrictivas o máquinas con actualizaciones diferidas. Un plan proactivo de validación evita sorpresas a última hora.
Rol de los fabricantes (OEM) y actualizaciones de BIOS/firmware
Los fabricantes de ordenadores y placas base, como Acer, tienen un papel fundamental en todo este proceso. Ellos controlan la Platform Key (PK) y parte de las KEK que residen en el firmware, así como las versiones de BIOS/UEFI que determinan cómo se cargan y gestionan las bases de datos DB y DBX de Secure Boot.
Según ha comunicado Acer, la compañía planea publicar actualizaciones de BIOS específicas para portátiles y sobremesas afectados en el primer trimestre de 2026. Estas versiones incluyen la PK, la KEK y la DB actualizadas con los certificados 2023, de modo que tras aplicar la BIOS el equipo quedará alineado con la nueva cadena de confianza de Secure Boot.
Otros OEM seguirán estrategias similares, por lo que conviene que los administradores de TI y los usuarios avanzados estén atentos a las notas de soporte de sus fabricantes. En muchos casos, el proceso implicará descargar una nueva BIOS desde la web del OEM o recibirla vía herramientas propias (como utilidades de actualización automática) y aplicar la actualización siguiendo las instrucciones estándar.
Para equipos que ya salieron al mercado en 2024 o 2025, lo habitual es que la BIOS venga de fábrica con las claves de 2023, o que reciban esa actualización poco después de la compra. Si adquiriste el PC en esas fechas, es probable que ya tengas los certificados renovados; aun así, una verificación con PowerShell nunca está de más para confirmarlo.
En el caso de infraestructuras distribuidas, centros de datos o parques de portátiles grandes, puede que sea necesario coordinar con los OEM un plan de despliegue escalonado de firmware, evitando aplicar BIOS críticas a todos los dispositivos a la vez sin pruebas previas. Esto se integra dentro de la gestión del ciclo de vida criptográfico y del firmware que muchas empresas ya aplican.
Buenas prácticas de ciberseguridad alrededor de Secure Boot
La renovación de certificados Secure Boot no es un evento aislado, sino parte de la gestión del ciclo de vida criptográfico de la organización. Planificar rotaciones de claves y certificados, auditar qué se está usando realmente en el entorno y mantener controles de integridad en firmware y TPM reduce la probabilidad de que alguien manipule el sistema en las etapas iniciales del arranque.
En esta línea, conviene combinar los controles de arranque con otras capas de protección: cifrado de disco mediante BitLocker, sistemas de detección y respuesta (EDR/XDR), monitorización de cambios en firmware y configuración, y revisiones periódicas de las políticas de seguridad de Windows y del hardware. Todo esto ayuda a que un fallo puntual en una capa no implique el compromiso total del equipo.
Empresas especializadas en ciberseguridad y pruebas de intrusión pueden aportar valor realizando evaluaciones de la cadena de arranque, simulando ataques contra el firmware, UEFI y el propio Secure Boot, y verificando que las defensas se comportan según lo esperado. Estos trabajos suelen incluir también recomendaciones de automatización y orquestación de actualizaciones.
En organizaciones con infraestructuras muy distribuidas, apoyarse en servicios cloud como Azure o AWS para montar canales de distribución y gestión centralizada de actualizaciones puede simplificar el control de parches, certificados y firmware. Además, el uso de cuadros de mando en Power BI y análisis de telemetría ayuda a priorizar qué dispositivos requieren atención urgente.
El uso de herramientas de inteligencia artificial y detección de anomalías centradas en eventos de arranque y comportamiento del firmware empieza a ser cada vez más habitual. Estos sistemas permiten detectar patrones extraños en registros de Secure Boot, reinicios anómalos o modificaciones en la configuración de UEFI que podrían indicar un intento de ataque o una mala configuración.
En el plano operativo, algunas recomendaciones básicas pasan por: revisar periódicamente Windows Update y los estados de seguridad en el Centro de seguridad de Windows, solicitar firmwares oficiales a los fabricantes para las máquinas que no se actualizan automáticamente, probar las actualizaciones en laboratorios antes del despliegue masivo y mantener inventarios actualizados y sistemas de gestión de parches bien configurados.
La combinación de estas prácticas con la correcta renovación de certificados Secure Boot ayuda a mantener una postura de seguridad sólida, reduciendo las ventanas de exposición y facilitando auditorías futuras, ya sean internas o externas.
En definitiva, la caducidad de los certificados de Secure Boot en junio de 2026 obliga a revisar cómo están configurados y actualizados nuestros equipos, tanto en el ámbito doméstico como en grandes organizaciones: asegurarse de que Secure Boot está activo, confirmar la presencia de la Windows UEFI CA 2023 desde PowerShell, validar claves y eventos de registro, coordinarse con los OEM para aplicar firmwares recientes y aprovechar las capacidades de Intune, WSUS, SCCM o soluciones MDM para automatizar despliegues marca la diferencia entre un entorno que sigue protegido frente a amenazas modernas en el arranque y otro que, aunque aparente normalidad, acumula riesgos silenciosos difíciles de detectar a simple vista.
Tabla de Contenidos
- Por qué caducan los certificados de Secure Boot y qué implica
- Contexto: fin de soporte de Windows 10, auge de Windows 11 y dependencia de Secure Boot
- Qué pasa si no renuevas los certificados Secure Boot
- Cómo comprobar el estado de los certificados Secure Boot en Windows
- Actualización manual de certificados Secure Boot en equipos individuales
- Supervisión avanzada: eventos, registro y WMI para administradores
- Entornos gestionados con Intune y dispositivos IT-managed
- Rol de los fabricantes (OEM) y actualizaciones de BIOS/firmware
- Buenas prácticas de ciberseguridad alrededor de Secure Boot