- Los certificados de arranque seguro emitidos originalmente en 2011 caducarán entre 2025 y 2026.
- La falta de actualización impide recibir nuevas protecciones contra bootkits y vulnerabilidades críticas de firmware.
- La renovación se realiza mayoritariamente vía Windows Update o actualizaciones de BIOS/UEFI del fabricante.
Seguramente habrás oído hablar del Arranque Seguro, pero pocos sabemos realmente cómo funciona bajo el capó. Básicamente, es un escudo de seguridad integrado en el firmware UEFI que se encarga de que solo se ejecute software verificado y de confianza mientras el dispositivo se enciende. Pero para evitar problemas es necesario comprobar la fecha de los certificados Secure Boot regularmente.
El sistema utiliza un montón de certificados digitales que actúan como una especie de «carné de identidad» para los controladores y cargadores de arranque. El problema es que estos certificados no son eternos y tienen una fecha de caducidad. Para quienes usamos Windows o Linux, estamos ante una bomba de tiempo silenciosa, ya que las claves emitidas hace más de una década están llegando al final de su vida útil. Si no nos ponemos las pilas para actualizarlas, podríamos vernos con equipos vulnerables o, en el peor de los casos, con problemas para arrancar el sistema operativo.
Entendiendo el funcionamiento del Secure Boot
Antes de comprobar la fecha de los certificados Secure Boot, hay que entender cómo funciona este mecanismo. Para que el proceso de inicio sea seguro, el firmware UEFI gestiona una jerarquía de claves. En la cima tenemos la PK (Platform Key), que suele ser del fabricante. Luego viene la KEK (Key Exchange Key), que permite gestionar las bases de datos de firmas. Estas bases de datos se dividen en dos: la DB, donde están las firmas permitidas para ejecutar, y la DBX, que es básicamente una «lista negra» de certificados revocados por seguridad.
Cuando encendemos la máquina, el firmware revisa que el cargador de arranque esté firmado por una autoridad de confianza. Si todo cuadra, el control pasa al sistema operativo. Este mecanismo es vital para frenar los malwares de tipo bootkit, que intentan infectar la máquina antes incluso de que el antivirus de Windows empiece a funcionar.
El problema de la caducidad en 2025 y 2026
Microsoft emitió una serie de certificados en 2011 que ahora mismo están en la cuenta atrás. Para los usuarios de Windows, la fecha crítica es junio de 2026, mientras que quienes usan Linux podrían notar problemas ya en septiembre de 2025. No es que el PC vaya a dejar de encenderse de la noche a la mañana, pero el riesgo es que el equipo quede en un estado de seguridad degradado. Por esa razón, comprobar la fecha de los certificados Secure Boot es esencial.
Si los certificados caducan y no se han actualizado a las versiones 2023, el dispositivo no podrá recibir nuevas protecciones contra vulnerabilidades recién descubiertas. Esto afecta directamente a herramientas como saber si tu PC tiene BitLocker activado o a la capacidad de actualizar el gestor de arranque, dejando la puerta abierta a amenazas emergentes que podrían comprometer la integridad de los datos.
Cómo comprobar la fecha de los certificados Secure Boot en Windows
La forma más sencilla de comprobar la fecha de los certificados Secure Boot y saber si estamos al día es entrar en la aplicación de Seguridad de Windows. Si vas al apartado de Seguridad del dispositivo y miras el estado de Secure Boot, un icono verde nos indica que todo está en orden. Si ves un color amarillo o rojo, significa que hay algo que revisar urgentemente.
Para los más detallistas o administradores de sistemas, se puede usar PowerShell ejecutado como administrador. Al introducir el comando ::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023', el sistema nos responderá True si ya tenemos la nueva clave instalada. Si el resultado es False, tenemos que actuar.
Soluciones manuales y forzadas en Windows
Aunque la mayoría de los equipos se actualizan solos vía Windows Update, a veces el proceso se queda colgado. Si tu versión de Windows es la 26100.6725 o superior y sigues con problemas, puedes forzar la actualización del registro. Ejecutando en PowerShell el comando reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f, le decimos al sistema que hay actualizaciones disponibles.
Después de tocar el registro, es necesario lanzar la tarea programada de actualización mediante Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update". Es probable que necesites reiniciar el ordenador un par de veces para que los cambios se escriban correctamente en la NVRAM del firmware y el icono de seguridad finalmente se ponga verde. Solo así podremos comprobar la fecha de los certificados Secure Boot.
El escenario para usuarios de Linux y Debian
En el mundo Linux, comprobar la fecha de los certificados Secure Boot se vuelve más complejo. Aquí dependemos del cargador shim, que es el puente firmado por Microsoft para permitir el arranque. Si el shim es antiguo (versiones anteriores a la 15.7), es muy probable que caduque en septiembre de 2025, provocando que el sistema no arranque o lance advertencias constantes.
Para comprobar la fecha de los certificados Secure Boot en Debian, podemos usar sudo mokutil --sb-state para ver si el arranque seguro está activo y sudo mokutil --list-enrolled para buscar la cadena «Microsoft Corporation UEFI CA 2023». Si no aparece, la solución pasa por actualizar el paquete shim-signed a la versión 15.8-1 o superior mediante los repositorios oficiales.
Además de actualizar el software, es fundamental usar herramientas como fwupdmgr para ver si el fabricante de la placa base ha lanzado una actualización de BIOS/UEFI que incluya las nuevas claves. Si el fabricante ha abandonado el soporte del equipo y no hay BIOS nueva, la última opción (aunque no sea la más segura) es desactivar el Secure Boot desde la configuración de la máquina.
Gestión en entornos empresariales y virtuales
Para quienes gestionan flotas de equipos mediante Intune, es vital asegurar que los datos de diagnóstico estén configurados como «Requeridos». Esto facilita que Microsoft despliegue los certificados automáticamente. No obstante, en servidores físicos, se recomienda realizar un inventario previo y ejecutar la actualización en oleadas, empezando por los equipos menos críticos para evitar cualquier imprevisto con el arranque.
El caso de las máquinas virtuales (VMs) es el más peliagudo. A veces, aunque Windows esté actualizado, el firmware virtual del hipervisor no permite escribir en la NVRAM. Si en el Visor de Eventos aparece el Event ID 2, significa que el sistema intentó escribir la clave pero el hipervisor se lo impidió. Aquí la solución no está dentro de la VM, sino en parchear el hipervisor y revisar la compatibilidad del hardware virtual.
Tener el sistema actualizado y el firmware al día es la única garantía para que el PC no se convierta en un pisapapeles o en un coladero de seguridad cuando lleguen las fechas límite de 2025 y 2026. Basta con verificar la versión del shim en Linux o ejecutar el comando de validación en PowerShell para dormir tranquilos sabiendo que la cadena de confianza de nuestro arranque sigue intacta.
Redactor especializado en temas de tecnología e internet con más de diez años de experiencia en diferentes medios digitales. He trabajado como editor y creador de contenidos para empresas de comercio electrónico, comunicación, marketing online y publicidad. También he escrito en webs de economía, finanzas y otros sectores. Mi trabajo es también mi pasión. Ahora, a través de mis artículos en Tecnobits, intento explorar todas las novedades y nuevas oportunidades que el mundo de la tecnología nos ofrece día a día para mejorar nuestras vidas.