security.txt en España: solo 19 de 197 grandes empresas lo publican, y ninguna de las 28 de banca y seguros

El 5 de octubre de 2026, en Hard2bit pedimos el archivo security.txt a los dominios de 219 grandes empresas españolas de ocho sectores. De los 197 que dieron una respuesta concluyente, 19 lo publican, el 9,6 %, y 12 lo tienen con un contacto y una fecha de caducidad vigente. Entre los 28 dominios de banca y seguros no apareció ninguno, y tampoco en industria ni en educación superior privada.

Un security.txt es un archivo de texto que una organización publica en su web para indicar a quién hay que avisar cuando alguien encuentra un fallo de seguridad en sus sistemas. Lo describe el RFC 9116, publicado en abril de 2022, y sus dos campos obligatorios son un contacto y una fecha de caducidad.

La muestra es la de nuestra radiografía de DMARC en grandes empresas españolas, del 7 de septiembre. El 73 % de aquellos dominios tenía una política DMARC de cuarentena o rechazo contra la suplantación de correo, mientras que 178 de los 197 con respuesta concluyente no publican el archivo que indica a un investigador de buena fe dónde escribir. El escaneo mide solo el archivo, y una empresa sin security.txt puede tener otro canal de aviso.

¿Cuántas grandes empresas españolas publican security.txt?

En el escaneo de Hard2bit del 5 de octubre de 2026, 19 de los 197 dominios de grandes empresas españolas con respuesta concluyente (el 9,6 %) publicaban un security.txt. Doce de esos archivos tenían un campo de contacto y una fecha de caducidad vigente. Dos de los 12 escriben mal el contacto, de modo que 10 cumplen al pie de la letra los dos campos obligatorios del RFC 9116.

Para cada empresa pedimos /.well-known/security.txt y la ruta antigua /security.txt, con y sin www, en el dominio de la muestra, y /.well-known/security.txt en el dominio al que redirige su página principal. Solo dimos por bueno un archivo de texto con al menos una línea Contact:. Una página de error o una redirección a la portada cuenta como ausencia. Otros 22 dominios respondieron con un bloqueo del cortafuegos o no respondieron, y quedan fuera del cálculo. Los resultados se publican agregados por sector y sin nombrar a ninguna empresa, igual que en el estudio de DMARC.

Retail y tecnología reúnen 13 de los 19 archivos. Los tres sectores sin ninguno suman 73 dominios con respuesta concluyente, entre ellos los 28 de banca y seguros, el sector que más aplicaba la política de rechazo en el estudio de DMARC.

La calidad de los 19 archivos encontrados es desigual:

• 12 tienen la fecha Expires vigente, 2 la tienen caducada y 5 no la incluyen, aunque el RFC la exige.
• 4 de los 12 vigentes fijan la caducidad a más de un año vista. El RFC recomienda menos de un año.
• 10 incluyen el campo Policy, que apunta a la política de divulgación.
• 1 está firmado con OpenPGP, como recomienda el RFC para que el archivo no se pueda suplantar.
• 2 solo existen en la ruta antigua, fuera de /.well-known/.
• 9 remiten al equipo de seguridad de una matriz extranjera o al de un proveedor, y 6 declaran el español entre los idiomas preferidos.

Ocho de los 19 archivos son el de un grupo multinacional extranjero y uno más lo sirve un proveedor, lo que apunta a un despliegue corporativo más que a una decisión tomada en España. Los otros diez no remiten a una matriz extranjera ni a un proveedor.

¿Publican security.txt las administraciones públicas españolas?

En el escaneo de Hard2bit del 5 de octubre de 2026, uno de los 29 portales públicos españoles con respuesta concluyente publicaba security.txt, y lo hacía sin el campo Expires, de modo que ninguno tenía los dos campos obligatorios. La muestra son 32 portales: los de las 17 comunidades autónomas y 15 de la Administración General del Estado y de organismos estatales.

En los Países Bajos, security.txt está desde el 25 de mayo de 2023 en la lista de estándares que las administraciones deben aplicar o, si no lo hacen, justificar, según el Forum Standaardisatie. En el Reino Unido, la guía técnica del Government Digital Service indica a sus servicios que redirijan a un archivo central. En España no hemos encontrado ninguna recomendación de INCIBE ni del CCN que lo mencione.

¿Qué es security.txt y qué debe contener?

security.txt es un archivo de texto plano, servido por HTTPS en la ruta /.well-known/security.txt, que indica cómo comunicar una vulnerabilidad a la organización titular del dominio. El RFC 9116 es un documento informativo del IETF y no tiene rango de estándar.

Tiene dos campos obligatorios:

• Contact, con una dirección de correo precedida de mailto: o una URL a un formulario. Puede repetirse, por orden de preferencia.
• Expires, con la fecha a partir de la cual el contenido deja de ser fiable. Solo puede aparecer una vez.

Los campos opcionales del RFC son Policy (enlace a la política de divulgación), Preferred-Languages, Canonical (la URL oficial del archivo), Encryption (enlace a una clave pública), Acknowledgments y Hiring. El registro de IANA ha añadido después otros dos: CSAF, para avisos de seguridad en formato automatizable, y Bug-Bounty, registrado en marzo de 2026, para indicar si hay recompensa económica.

Ejemplo de security.txt correcto, en cinco líneas:

• Contact: mailto:seguridad@ejemplo.es
• Expires: 2027-09-30T22:00:00Z
• Policy: https://www.ejemplo.es/seguridad/
• Preferred-Languages: es, en
• Canonical: https://www.ejemplo.es/.well-known/security.txt

Según el RFC, el archivo solo vale para el dominio o subdominio que lo sirve y su presencia no autoriza a hacer pruebas de seguridad. Ese permiso, si se da, tiene que figurar en la política enlazada.

¿Cómo se compara España con otros países?

Con un 9,6 % en el escaneo de Hard2bit del 5 de octubre de 2026, las grandes empresas españolas quedan muy por debajo del DAX alemán, con un 87,5 % en 2025. Están por encima, en cambio, del conjunto de internet, con un 1,25 % en enero de 2025. El dato alemán procede de un estudio académico sobre las 40 empresas del DAX, que encontró security.txt en 35 de ellas, frente a 10 dos años antes.

Las empresas que respondieron a su encuesta, el 20 % del índice, citan obligaciones legales como NIS2 y el Reglamento de Ciberresiliencia entre los motivos. La muestra alemana son las 40 mayores cotizadas y la nuestra incluye empresas medianas, así que las cifras no son equivalentes.

El dato de internet es de la empresa URIports, que calculó en enero de 2025 que el 1,25 % del millón de dominios más visitados publicaba el archivo y que menos de la mitad de ellos cumplía el RFC.

¿Obliga alguna norma a publicar security.txt?

Ninguna norma europea obliga a publicar security.txt. NIS2 sí exige gestionar y divulgar las vulnerabilidades, y el Reglamento de Ciberresiliencia exigirá a los fabricantes una dirección de contacto y una política de divulgación, que es lo que el archivo anuncia.

• NIS2, artículo 21.2.e, incluye entre las medidas de gestión de riesgos «la gestión y divulgación de las vulnerabilidades». El Reglamento de Ejecución (UE) 2024/2690 exige a los proveedores digitales de su ámbito un procedimiento de divulgación conforme a la política nacional. España sigue sin transponer la directiva, como explicamos en qué hacer con NIS2 sin ley de transposición.
• El mapa de políticas nacionales de ENISA indica que España todavía no ha designado formalmente el CSIRT coordinador de la divulgación que prevé el artículo 12 de NIS2. La lista de coordinadores que ENISA mantiene para el CRA remite a INCIBE-CERT para la coordinación de vulnerabilidades.
• El Reglamento de Ciberresiliencia (CRA) obligará a los fabricantes de productos con elementos digitales, a partir del 11 de diciembre de 2027, a tener una política de divulgación coordinada y una dirección de contacto para recibir avisos. La obligación de notificar fallos explotados, que tratamos en el artículo sobre el plazo de 24 horas del CRA, se aplica desde el 11 de septiembre de 2026.
• La guía técnica TR-03183-3 de la BSI alemana, de agosto de 2025, es el texto oficial más exigente que hemos encontrado. Indica que el fabricante debe publicar un security.txt conforme al RFC 9116, firmarlo y revisarlo cada trimestre. Es una guía técnica y no una norma legal.

El considerando 58 de NIS2 remite además a las normas ISO/IEC 29147, sobre divulgación de vulnerabilidades, e ISO/IEC 30111, sobre su tratamiento interno. Un auditor que revise la gestión de vulnerabilidades de una entidad sujeta a NIS2 puede preguntar cómo recibe los avisos de terceros, y un security.txt con la política enlazada es una evidencia fácil de aportar.

¿Qué riesgo legal corre en España quien avisa de un fallo?

En España no existe una exención legal para quien descubre una vulnerabilidad y avisa de buena fe. El artículo 197 bis del Código Penal castiga con prisión de seis meses a dos años a quien acceda a un sistema de información «vulnerando las medidas de seguridad establecidas para impedirlo, y sin estar debidamente autorizado».

El artículo 201 exige, con excepciones, denuncia de la persona agraviada para perseguir estos delitos. La Circular 3/2017 de la Fiscalía General del Estado menciona de forma expresa el *hacking* ético y supedita la actuación penal a la denuncia del afectado. NIS2, en su considerando 60, anima a los Estados miembros a adoptar directrices para no perseguir a los investigadores, y ENISA describe el marco español como todavía no formalizado.

Mientras no existan esas directrices, la principal protección de quien avisa es la política que la empresa haya publicado. Una política que delimite qué pruebas admite y se comprometa a no denunciar a quien la respete afecta tanto a la autorización como a la denuncia. Solo obliga a quien la firma y dentro de su alcance, y no vincula al Ministerio Fiscal cuando el artículo 201 no exige denuncia, por ejemplo si los hechos afectan a una pluralidad de personas o a los intereses generales.

¿Qué ocurre cuando no se sabe cómo reportar una vulnerabilidad a una empresa?

Cuando una empresa no tiene un contacto de seguridad publicado y atendido, el aviso puede tardar más en llegar o llegar antes a la prensa. TechCrunch ha documentado varios casos recientes en Estados Unidos. Un investigador contó en diciembre de 2025 que Home Depot no respondió a sus correos sobre una credencial que llevaba cerca de un año expuesta, y que el fallo se corrigió cuando el medio contactó con la empresa. En abril de 2026, un especialista en seguridad y privacidad no encontró forma de avisar a la cadena de moda Express de una exposición de datos de clientes.

Para la empresa, el fallo sigue abierto más tiempo y la primera noticia puede llegarle de un tercero. Sin un buzón de seguridad, al investigador le quedan el formulario de atención al cliente o las redes sociales.

¿Cómo publicar un security.txt bien hecho?

Publicar un security.txt correcto lleva menos de una tarde si antes se ha decidido quién va a leer los avisos. Los cinco elementos son estos, y los dos primeros concentran casi todo el trabajo:

• Un buzón de rol, como seguridad@, atendido por más de una persona y fuera de los filtros que descartan adjuntos y enlaces.
• Una política de divulgación de vulnerabilidades publicada: qué sistemas cubre, qué pruebas no se admiten (denegación de servicio, ingeniería social, extracción de datos), el plazo de acuse de recibo y el compromiso de no emprender acciones legales contra quien la cumpla. Tres días hábiles es el plazo de primera respuesta en la política de la Comisión Europea y el de confirmación de recepción en la de INCIBE.
• El archivo en /.well-known/security.txt de cada dominio relevante, servido como text/plain, con Expires a menos de un año y un recordatorio en el calendario para renovarlo.
• Una excepción en el cortafuegos de aplicaciones para esa ruta. En nuestro escaneo, 22 dominios bloquearon la petición o no respondieron, y no pudimos saber si el archivo existía.
• La firma OpenPGP y el campo Canonical, si el equipo ya gestiona claves.

Los errores que URIports encontró con más frecuencia aparecen también en nuestra muestra: falta de Expires y fechas caducadas o demasiado lejanas. En la nuestra se suman direcciones sin mailto:. El generador de securitytxt.org evita los errores de formato.

En Hard2bit publicamos el nuestro en /.well-known/security.txt, con la política en nuestra página de seguridad. El escáner de superficie de ataque pública comprueba este archivo y hace otras trece pruebas, todas gratuitas, y la guía para comprobar la seguridad de un dominio explica cómo leer el resultado. Quien reciba avisos con regularidad necesitará además un proceso para clasificarlos y corregirlos, que corresponde a la gestión de vulnerabilidades.

Metodología: escaneo realizado el 5 de octubre de 2026, en una sola pasada y desde un único origen, con peticiones HTTPS a rutas públicas, sin autenticación y sin pruebas de seguridad. La muestra de empresas son los 219 dominios del estudio de DMARC de septiembre de 2026, uno por empresa; la del sector público, 32 portales elegidos por Hard2bit. Una respuesta es concluyente cuando el servidor devuelve el archivo, un error 404 o una página del sitio; los bloqueos del cortafuegos, los errores de servidor y las peticiones sin respuesta se excluyen.

Límites: una empresa puede publicar el archivo en otro dominio no incluido, o tener un canal de aviso que no pase por security.txt. Los resultados son agregados y no se identifican organizaciones. El apartado legal es informativo y no constituye asesoramiento jurídico.