security.txt in Spain: only 19 of 197 large companies publish one, and none of the 28 in banking and insurance

On 5 October 2026 we at Hard2bit requested the security.txt file from the domains of 219 large Spanish companies in eight sectors. Of the 197 that gave a conclusive response, 19 publish one (9.6%), and 12 of those files have a contact and an expiry date that has not passed. None turned up among the 28 banking and insurance domains, nor in manufacturing or private higher education.

A security.txt is a text file an organisation publishes on its website to say who should be told when someone finds a security flaw in its systems. It is described in RFC 9116, published in April 2022, and its two mandatory fields are a contact and an expiry date.

The sample is the one from our DMARC snapshot of large Spanish companies of 7 September. Of those domains, 73% had a DMARC policy of quarantine or reject against email spoofing, whereas 178 of the 197 that gave a conclusive response do not publish the file that tells a good-faith researcher where to write. The scan measures the file only, and a company without security.txt may have another reporting channel.

How many large Spanish companies publish security.txt?

In Hard2bit's scan of 5 October 2026, 19 of the 197 large Spanish company domains that gave a conclusive response (9.6%) published a security.txt. Twelve of those files had a contact field and an expiry date still in force. Two of the 12 write the contact incorrectly, so 10 satisfy the two mandatory fields of RFC 9116 to the letter.

For each company we requested /.well-known/security.txt and the legacy /security.txt path, with and without www, on the sample domain, and /.well-known/security.txt on the domain its home page redirects to. We only accepted a text file with at least one Contact: line. An error page or a redirect to the home page counts as absent. Another 22 domains answered with a firewall block or did not answer, and are left out of the calculation. Results are published in aggregate by sector and no company is named, as in the DMARC study.

Retail and technology account for 13 of the 19 files. The three sectors with none add up to 73 domains with a conclusive response, including all 28 in banking and insurance, the sector that applied DMARC reject most widely in September.

The quality of the 19 files varies:

• 12 have a current Expires date, 2 have one that has lapsed and 5 omit it, although the RFC requires it.
• 4 of the 12 current ones set the expiry more than a year ahead. The RFC recommends less than a year.
• 10 include the Policy field, which points to the disclosure policy.
• 1 is signed with OpenPGP, as the RFC recommends so that the file cannot be forged.
• 2 exist only at the legacy path, outside /.well-known/.
• 9 point to the security team of a foreign parent company or of a supplier, and 6 list Spanish among their preferred languages.

Eight of the 19 files are the file of a foreign multinational group and one more is served by a supplier, which suggests a corporate rollout more than a decision taken in Spain. The other ten point neither to a foreign parent nor to a supplier.

Do Spanish public administrations publish security.txt?

In Hard2bit's scan of 5 October 2026, one of the 29 Spanish public portals that gave a conclusive response published security.txt, and it had no Expires field, so none had both mandatory fields. The sample is 32 portals: those of the 17 autonomous communities and 15 belonging to central government and state bodies.

In the Netherlands, security.txt has been on the "comply or explain" list of standards for public bodies since 25 May 2023, according to the Dutch Standardisation Forum. In the UK, the Government Digital Service's technical guidance tells its services to redirect to a central file. We found no recommendation from INCIBE or the CCN, Spain's two national cybersecurity bodies, that mentions it.

What is security.txt and what should it contain?

security.txt is a plain-text file, served over HTTPS at /.well-known/security.txt, that explains how to report a vulnerability to the organisation that owns the domain. RFC 9116 is an informational IETF document and does not have the status of a standard.

It has two mandatory fields:

• Contact, with an email address prefixed with mailto: or a URL to a form. It can be repeated, in order of preference.
• Expires, with the date after which the content should not be trusted. It can appear only once.

The optional fields in the RFC are Policy (a link to the disclosure policy), Preferred-Languages, Canonical (the file's official URL), Encryption (a link to a public key), Acknowledgments and Hiring. The IANA registry has since added two more: CSAF, for machine-readable security advisories, and Bug-Bounty, registered in March 2026, to state whether a financial reward is on offer.

An example of a correct security.txt, in five lines:

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

Under the RFC, the file applies only to the domain or subdomain that serves it, and its presence does not authorise security testing. That permission, if given, has to be in the linked policy.

How does Spain compare with other countries?

At 9.6% in Hard2bit's scan of 5 October 2026, large Spanish companies sit well below Germany's DAX (87.5% in 2025) and above the internet as a whole (1.25% in January 2025). The German figure comes from an academic study of the 40 DAX companies, which found security.txt on the sites of 35 of them, up from 10 two years earlier.

The companies that answered its survey, 20% of the index, cite legal obligations such as NIS2 and the Cyber Resilience Act among the drivers. The German sample is the 40 largest listed companies and ours includes mid-sized firms, so the figures are not equivalent.

The internet-wide figure is from URIports, which found in January 2025 that 1.25% of the top million domains published the file and that fewer than half of those met the RFC.

Is security.txt a legal requirement?

No EU law requires security.txt. NIS2 does require vulnerability handling and disclosure, and the Cyber Resilience Act will require manufacturers to have a contact address and a disclosure policy, which is what the file advertises.

• NIS2, Article 21(2)(e), lists "vulnerability handling and disclosure" among its risk-management measures. Implementing Regulation (EU) 2024/2690 requires the digital providers in its scope to have a disclosure procedure in line with the national policy. Spain has still not transposed the directive, as we explain in NIS2 without a national transposition law.
• ENISA's map of national policies says Spain has not yet formally designated the coordinating CSIRT for disclosure that Article 12 of NIS2 provides for. The list of coordinators ENISA maintains for the CRA points to INCIBE-CERT for vulnerability coordination.
• From 11 December 2027, the Cyber Resilience Act (CRA) will require manufacturers of products with digital elements to have a coordinated vulnerability disclosure policy and a contact address for reports. The duty to notify exploited flaws, covered in our article on the CRA's 24-hour deadline, has applied since 11 September 2026.
• The German BSI's technical guideline TR-03183-3, from August 2025, is the most demanding official text we found. It says the manufacturer must publish a security.txt in line with RFC 9116, sign it and review it every quarter. It is a technical guideline and has no force of law.

Recital 58 of NIS2 also points to ISO/IEC 29147, on vulnerability disclosure, and ISO/IEC 30111, on handling reports internally. An auditor reviewing the vulnerability management of an entity under NIS2 may ask how it receives reports from third parties, and a security.txt that links to the policy is easy evidence to produce.

What legal risk do you run in Spain if you report a flaw?

Spain has no legal safe harbour for someone who finds a vulnerability and reports it in good faith. Under Article 197 bis of the Criminal Code, anyone who accesses an information system by breaching its security measures and "without being duly authorised" faces six months to two years in prison.

Article 201 requires, with exceptions, a complaint from the injured party before these offences can be prosecuted. The Prosecutor General's Circular 3/2017 mentions ethical hacking explicitly and makes criminal action depend on the affected party filing a complaint. Recital 60 of NIS2 encourages member states to adopt guidelines on not prosecuting researchers, and ENISA describes the Spanish framework as not yet formalised.

Until such guidelines exist, the main protection for the person reporting is the policy the company has published. A policy that defines which tests are allowed and commits not to file a complaint against anyone who follows it bears on both the authorisation and the complaint. It binds only the organisation that signs it and only within its scope, and it does not bind the public prosecutor where Article 201 dispenses with the complaint, for example when the facts affect many people or the general interest.

What happens when a company does not say how to report a vulnerability?

When a company has no published, monitored security contact, a report can take longer to arrive or reach the press first. TechCrunch has documented several recent cases in the United States. In December 2025 a researcher said that Home Depot did not answer his emails about a credential that had been exposed for about a year, and that the flaw was fixed once the outlet contacted the company. In April 2026 a security and privacy advocate found no way to alert the fashion retailer Express to an exposure of customer data.

For the company, the flaw stays open for longer and the first it hears may be from a third party. Without a security mailbox, the researcher is left with the customer service form or social media.

How do you publish a security.txt properly?

Publishing a correct security.txt takes less than an afternoon once someone has been made responsible for reading the reports. These are the five parts, and the first two take most of the work:

• A role mailbox such as security@, monitored by more than one person and exempt from the filters that discard attachments and links.
• A published vulnerability disclosure policy: which systems it covers, which tests are not accepted (denial of service, social engineering, data extraction), how quickly reports are acknowledged, and a commitment not to take legal action against anyone who complies. Three working days is the deadline for a first reply in the European Commission's policy and for confirming receipt in INCIBE's.
• The file at /.well-known/security.txt on every domain that matters, served as text/plain, with Expires less than a year ahead and a calendar reminder to renew it.
• An exception in the web application firewall for that path. In our scan, 22 domains blocked the request or did not answer, and we could not tell whether the file existed.
• An OpenPGP signature and the Canonical field, if the team already manages OpenPGP keys.

The mistakes URIports found most often also appear in our sample: a missing Expires and dates that have lapsed or sit too far ahead. Ours adds addresses without mailto:. The securitytxt.org generator prevents the formatting errors.

At Hard2bit we publish ours at /.well-known/security.txt, with the policy on our security page. Our public attack surface scanner checks this file and runs thirteen other tests, all free, and the guide to checking a domain's security explains how to read the result. Anyone who receives reports regularly will also need a process to triage and fix them, which is the job of vulnerability management.

Method: the scan ran on 5 October 2026, in a single pass from one origin, using HTTPS requests to public paths, with no authentication and no security testing. The company sample is the 219 domains from the September 2026 DMARC study, one per company; the public sector sample is 32 portals chosen by Hard2bit. A response counts as conclusive when the server returns the file, a 404 error or a page from the site; firewall blocks, server errors and unanswered requests are excluded.

Limits: a company may publish the file on another domain outside the sample, or have a reporting channel that does not rely on security.txt. Results are aggregated and no organisation is identified. The legal section is for information only and does not constitute legal advice.