Para un portátil personal dedicado a gaming y programación, la respuesta corta es que Secure Boot aporta poco valor real y, en muchos casos, complica más de lo que protege, así que desactivarlo suele ser una decisión perfectamente razonable. Aun así, merece la pena entender qué hace exactamente antes de tomar la decisión.
#Qué protege realmente Secure Boot
Secure Boot es una función del firmware UEFI que verifica que el gestor de arranque, el kernel y los módulos que se cargan al encender el equipo tengan una firma digital de confianza. Si algo en esa cadena ha sido modificado sin autorización, el sistema simplemente se niega a arrancar. Su objetivo principal es bloquear los llamados bootkits: malware que se instala antes de que cargue el sistema operativo y que resulta prácticamente invisible para cualquier antivirus una vez dentro.
Lo importante es entender los límites de esa protección: Secure Boot no evita que tu sistema se infecte por otras vías (un archivo malicioso, una vulnerabilidad de red, un USB con malware normal), solo bloquea una vía de ataque muy concreta y bastante específica.
#Por qué en Linux genera más dolores de cabeza que en Windows
Windows viene firmado de fábrica por Microsoft, así que Secure Boot no supone ninguna fricción para el usuario normal. En Linux la cosa cambia: distribuciones grandes como Ubuntu, Fedora o openSUSE incluyen un componente llamado shim que permite arrancar con Secure Boot activo, pero cuando entran en juego controladores propietarios como los de NVIDIA, ese shim no basta, porque el módulo del kernel de NVIDIA no viene firmado por defecto.
Ahí es donde aparece MOK (Machine Owner Key): tienes que generar tu propia clave, firmar el módulo con ella y añadirla manualmente a la base de claves de confianza del firmware. No es un proceso especialmente difícil una vez lo haces la primera vez, pero sí es un paso extra que rompe la comodidad de «instalar y listo», y que se repite cada vez que se actualiza el kernel o el driver si no se automatiza bien.
#¿Y si tengo Windows en dual boot?
Aquí sí conviene tener cuidado. Si además de Linux mantienes Windows en el mismo equipo con cifrado BitLocker, desactivar Secure Boot puede hacer que Windows pida la clave de recuperación al arrancar, ya que BitLocker usa el estado de Secure Boot como parte de sus comprobaciones de integridad. En ese escenario, lo más práctico suele ser dejarlo activado y lidiar con la configuración de MOK si usas NVIDIA, en vez de desactivarlo y arriesgarte a ese problema.
#Entonces, ¿lo activo o lo desactivo?
| Situación | Recomendación |
|---|---|
| Portátil personal solo con Linux, uso de gaming y programación | Desactivarlo es razonable, aporta poca protección adicional real |
| Equipo con Windows en dual boot y BitLocker activo | Mejor mantenerlo activado para evitar conflictos con el cifrado |
| Equipo compartido o con acceso físico de terceros | Mantenerlo activado añade una capa extra de protección real |
| Uso de GPU NVIDIA con controlador propietario | Si lo mantienes activo, tendrás que configurar MOK manualmente |
Muchos usuarios que ya han pasado por esta decisión coinciden en un patrón parecido: lo desactivan durante la instalación para evitar fricciones iniciales, y solo se molestan en volver a activarlo y configurar MOK si de verdad tienen un motivo de seguridad concreto (por ejemplo, portátiles que se dejan solos en según qué entornos). Para un uso estrictamente personal, sin acceso físico de otras personas al equipo, el beneficio real de mantenerlo activo es bastante limitado frente a la comodidad que se pierde.
#Un matiz importante que no debes ignorar
Existe un tema técnico que sí conviene tener presente independientemente de lo anterior: las claves de confianza que Microsoft firma para que los distintos shims de Linux funcionen tienen fecha de caducidad, y algunas de las emitidas en 2011 ya han empezado a expirar. Si decides mantener Secure Boot activado, es recomendable comprobar que el firmware y las herramientas como fwupd estén actualizados, para evitar que un día el sistema deje de arrancar por culpa de una clave caducada y no por ningún problema tuyo.