Software sin soporte: las vulnerabilidades que ningún parche va a corregir
Casi todos los programas de vulnerabilidades parten de un supuesto: cuando aparece un fallo, el fabricante publica un parche y tu trabajo es instalarlo rápido. El software al final de su vida útil (EOL, por end of life) rompe ese supuesto. Cuando un producto se queda sin soporte, se siguen descubriendo vulnerabilidades, pero los parches dejan de llegar. Tu escáner puede seguir marcando el CVE. Solo que no hay nada que instalar.
Esta guía explica por qué la tecnología sin soporte necesita su propio proceso, qué enseña a cualquier organización la directiva de CISA de 2026 sobre equipos perimetrales sin soporte y cómo gestionar los sistemas que no puedes retirar mañana.
Qué significa realmente "fin de vida"
Los fabricantes usan varios términos (fin de venta, fin de soporte, fin de vida, fin de servicio) y las fechas cambian según el producto. Para seguridad, la fecha que importa es el último día en que el fabricante publica correcciones de seguridad. A partir de ahí:
- Se siguen encontrando y publicando vulnerabilidades.
- El fabricante ya no publica parches para ellas.
- Tu proceso de parches no tiene nada que instalar, así que el hallazgo queda abierto indefinidamente.
Windows 10 es el ejemplo más conocido. Microsoft terminó su soporte el 14 de octubre de 2025: sin correcciones de errores, sin correcciones de seguridad y sin soporte técnico. Las organizaciones pueden comprar actualizaciones de seguridad extendidas (ESU) por hasta tres años, que solo incluyen actualizaciones de seguridad críticas e importantes. ESU te da tiempo; no es una estrategia.
Por qué a los atacantes les gustan los equipos sin soporte
En febrero de 2026, CISA publicó la directiva operativa vinculante BOD 26-02, "Mitigating Risk From End-of-Support Edge Devices". Es obligatoria para las agencias civiles federales de Estados Unidos, pero CISA anima a todos los equipos de defensa a seguirla. Su razonamiento vale mucho más allá del gobierno:
- Los equipos perimetrales están donde el atacante quiere estar. Firewalls, routers, switches, gateways VPN, balanceadores de carga y puntos de acceso inalámbricos dan a internet y muchas veces están integrados con los sistemas de identidad.
- Son especialmente vulnerables a fallos nuevos. CISA dice que los equipos sin soporte son especialmente vulnerables a ataques contra vulnerabilidades recién descubiertas y sin parche, y que conoce campañas de explotación extendidas de actores avanzados contra ellos.
- Se convierten en una puerta de entrada. En una alerta conjunta, CISA, el FBI y el NCSC del Reino Unido advirtieron que los equipos perimetrales sin soporte pueden servir de entrada a entornos modernos que sí tienen soporte.
El catálogo de vulnerabilidades explotadas conocidas (KEV) de CISA muestra cómo se ve esto en la práctica. Para algunos fallos explotados en routers al final de su vida útil, la "acción requerida" no es parchear, porque no hay parche: es desconectar el producto o dejar de usarlo. Cuando Zyxel confirmó la explotación de fallos en routers DSL antiguos a principios de 2025, su consejo fue reemplazarlos por productos más nuevos. Si usas el KEV para priorizar, lee nuestra guía del catálogo KEV y recuerda que algunas entradas solo se cierran retirando el equipo.
Qué pide la BOD 26-02 y por qué es una buena plantilla
La directiva convierte un objetivo vago ("deshacernos de lo viejo") en una secuencia con plazos:
| Plazo | Acción |
|---|---|
| De inmediato | Actualizar a una versión con soporte los equipos con soporte que corren software sin soporte. |
| 3 meses | Inventariar todos los equipos que aparecen en la lista de CISA de equipos sin soporte. |
| 12 meses | Empezar a retirar los equipos que ya estaban sin soporte cuando salió la directiva e inventariar los que perderán el soporte en el próximo año. |
| 18 meses | Terminar de retirar todos los equipos perimetrales sin soporte identificados. |
| 24 meses | Tener un descubrimiento continuo y un proceso de ciclo de vida que retire los equipos antes de que pierdan el soporte o en ese momento. |
No necesitas ser una agencia federal para usar esa estructura: corrige lo que se puede corregir hoy, conoce lo que tienes, pon fecha de retiro y evita que el problema se repita.
Un programa de fin de vida en seis pasos
1. Inventaría versiones de software y firmware, no solo equipos
No puedes seguir fechas de soporte de cosas que no sabes que tienes. Tu inventario necesita producto, versión y ubicación de sistemas operativos, aplicaciones, equipos de red y firmware. Lo que un agente no alcanza, como appliances y equipos de red, necesita descubrimiento sin agente; lo explicamos en escaneo con agente o sin agente.
2. Asocia cada elemento a su fecha de fin de soporte
Registra la fecha de fin de soporte del fabricante para cada producto y versión. Trata las fechas de los próximos 12 meses como un aviso para planificar, no como una sorpresa. El requisito 12.3.4 de PCI DSS 4.0 ya lo pide: revisar al menos una vez cada 12 meses las tecnologías de hardware y software en uso, incluido si siguen recibiendo correcciones de seguridad a tiempo, con un plan aprobado por la alta dirección para remediar la tecnología obsoleta, incluida la que tiene un fin de vida anunciado.
3. Ordena primero por exposición
No todo sistema sin soporte tiene el mismo riesgo. Un gateway VPN sin soporte expuesto a internet no es lo mismo que un servidor aislado de laboratorio. Empieza por lo expuesto a internet y lo perimetral, y después por lo que guarda datos sensibles o se conecta a la identidad. Mira por qué la exposición a internet cambia la prioridad.
4. Actualiza donde puedas, reemplaza donde debas
Muchos hallazgos de "fin de vida" son en realidad versiones viejas de productos que sí tienen soporte. Eso es trabajo normal de parches y va en tu proceso de gestión de parches. El hardware realmente al final de su vida necesita un proyecto de reemplazo con presupuesto y fecha.
5. Contén lo que tiene que quedarse
Algunos sistemas no se pueden reemplazar rápido: controladores industriales, equipos médicos, una aplicación heredada que nadie puede reescribir este año. Para esos, reduce la exposición: quita el acceso desde internet, segmenta la red, limita quién llega a las interfaces de administración, vigila más de cerca y evalúa el soporte extendido de pago donde exista.
6. Haz explícita la excepción
Cada sistema sin soporte que se queda debería tener un responsable, una razón documentada, controles compensatorios y una fecha de vencimiento para la decisión. Eso es una aceptación formal del riesgo, no un ticket olvidado; nuestra guía sobre aceptación de riesgo en vulnerabilidades explica cómo mantener honestas esas decisiones.
Preguntas frecuentes
¿Un CVE en un producto sin soporte es menos urgente porque no tiene parche? No. Suele ser más urgente, porque las únicas remediaciones son los controles compensatorios o el reemplazo, y las dos tardan más que instalar un parche.
¿Pagar soporte extendido resuelve el problema? Cierra la brecha durante el tiempo que pagas y para las actualizaciones que el fabricante decida publicar. Usa ese tiempo para migrar.
¿Y los componentes de código abierto que ya nadie mantiene? Aplica la misma lógica. Una librería o un runtime sin mantenedor activo no recibirá correcciones para vulnerabilidades nuevas, así que síguelo como cualquier otra tecnología al final de su vida útil y planifica la actualización.
Cómo ayuda priorIQ.ai
ScannerIQ combina agentes nativos con escáneres sin agente distribuidos por zonas de red para inventariar endpoints, software e identidades, y enriquece los hallazgos con NVD, CISA KEV y EPSS. CloudIQ clasifica qué recursos cloud están realmente expuestos a internet. PriorIQ Core lo une en un solo inventario de software y equipos, ordena los hallazgos abiertos por riesgo real y registra las excepciones en Risk Accepted & Decisions, para que un sistema sin soporte que tiene que quedarse sea una decisión con responsable y no algo invisible. Solicita una demo.