Expiración Secure Boot 2026: riesgos y soporte
En 2026 no pasa nada “visible” para la mayoría de usuarios. El equipo enciende, Windows carga, todo parece igual. Pero por debajo, algo importante cambia: la base sobre la que el sistema decide en qué confiar al arrancar.
No es una actualización típica ni un parche más. Lo que caduca son certificados que forman parte de la cadena de confianza del arranque. Dicho de forma más directa: el firmware deja de apoyarse en referencias que hasta ahora eran válidas.
Eso no rompe el equipo, pero sí cambia el nivel de verificación. Y ese tipo de cambio es fácil de pasar por alto porque no genera errores evidentes.
Secure Boot actúa antes de que el sistema operativo tenga oportunidad de intervenir. Comprueba firmas digitales usando claves almacenadas en la propia plataforma (PK, KEK, db, dbx). Mientras esas claves están actualizadas, el filtro funciona. Cuando dejan de estarlo, el sistema sigue arrancando… pero con menos garantías.
El problema no es inmediato, sino progresivo. El equipo no se vuelve inseguro de un día para otro, pero pierde capacidad para detectar modificaciones en componentes de arranque. Y eso abre un espacio que normalmente no está vigilado por herramientas tradicionales.
Qué cambia realmente con la expiración de certificados
Los certificados emitidos en 2011 —como Microsoft Corporation KEK CA 2011 o UEFI CA 2011— tienen fecha de caducidad. En este ciclo, ese límite llega entre junio y octubre de 2026.
No significa que el sistema deje de funcionar. Lo que ocurre es más sutil: si no se actualizan esas autoridades, la validación deja de basarse en una cadena vigente.
Microsoft ya contempló este escenario con una nueva autoridad (2023 Microsoft Windows PCA) que se distribuye mediante Windows Update en equipos compatibles. En condiciones normales, el proceso es automático.
Donde empiezan las diferencias es en los equipos que no están dentro de ese “flujo normal”: sistemas fuera de soporte, configuraciones alteradas o firmware que no acepta fácilmente nuevas claves.
Ahí no hay aviso claro. El equipo sigue funcionando, pero la validación ya no es equivalente a la que tenía antes.
No todos los equipos están en la misma situación
A primera vista puede parecer un problema general, pero en realidad depende bastante del contexto.
Hay casos donde conviene mirar esto con más atención:
- Equipos que siguen en uso diario pero ya no reciben actualizaciones de Microsoft.
- Sistemas donde Secure Boot está desactivado por decisiones anteriores (compatibilidad, instalaciones personalizadas).
- Entornos donde el arranque seguro es parte del control de seguridad (empresas, datos críticos).
Y otros donde la urgencia baja bastante:
- Equipos antiguos que ya no cumplen funciones sensibles.
- Sistemas aislados o con uso muy limitado.
No es que en estos casos no exista riesgo, pero cambia la prioridad. No todo requiere intervención inmediata.
Comprobar el estado: rápido y suficiente para decidir
Antes de pensar en cambios, lo más útil es saber dónde estás parado.
Con msinfo32, en el resumen del sistema, puedes ver el estado de Secure Boot. No hace falta más para una primera evaluación.
Si aparece activado y el sistema recibe actualizaciones, lo más probable es que la transición ocurra sin intervención.
Si aparece desactivado o el sistema ya no se actualiza, entonces sí conviene detenerse a pensar qué hacer.
Ese simple dato suele ser suficiente para separar lo que es mantenimiento normal de lo que requiere atención.
La decisión no es técnica, es operativa
Aquí es donde cambia el enfoque. No se trata solo de saber cómo funciona Secure Boot, sino de decidir si vale la pena intervenir.
Hay situaciones claras donde actuar tiene sentido:
- Equipos que siguen en uso activo y manejan información relevante.
- Configuraciones donde Secure Boot está desactivado pero podría activarse sin romper compatibilidad.
- Sistemas que ya no reciben actualizaciones automáticas.
En cambio, forzar cambios en equipos antiguos o poco críticos puede ser innecesario. A veces es más razonable mantenerlos aislados o planificar su sustitución.
Además, tocar firmware no es algo trivial. Cambiar Secure Boot puede afectar el arranque si hay controladores o configuraciones incompatibles. No es complejo, pero tampoco es algo para hacer sin revisar antes.
Más que una fecha concreta, esto es un punto de revisión. Si todo está en orden, no hay urgencia. Si no lo está, conviene saberlo antes de que deje de ser evidente.
Para detalles técnicos y fechas específicas, puedes consultar la documentación oficial sobre la expiración del certificado de arranque seguro y actualizaciones de CA.
