Setting Up security.txt and Vulnerability Disclosure 2026

What security.txt Is and Which Problem RFC 9116 Solves

security.txt is a machine- and human-readable text file located at a standardized path: https://your-domain.com/.well-known/security.txt. It answers one decisive question: how does an external finder report a security gap without guessing? Before RFC 9116, researchers had to track down the right contact through contact forms, LinkedIn, or generic info@ addresses — friction that causes reports to land in spam or never be sent at all.

The standard was adopted as RFC 9116 by the IETF in 2022 (IETF 2022). It defines a simple key-value format: each line consists of a field name, a colon, and a value. The file must be served over HTTPS and located at the canonical path /.well-known/security.txt — an additional fallback in the web root (/security.txt) is permitted, but /.well-known/ is the intended location. This puts the information exactly where automated scanners and researchers look first.

The benefit is asymmetric: publishing takes minutes, while the payoff in an emergency is hours or days of saved response time. A researcher who finds a reporting channel is more likely to disclose in a coordinated way — instead of going public out of frustration. In 2024, a prominent case made headlines when a researcher broke with coordinated disclosure after failing to reach anyone (DARKNAVY 2024). A clear channel reduces exactly this friction.

The Fields of security.txt: Required, Optional, and Useful

RFC 9116 distinguishes between a few mandatory fields and a set of optional ones. Only two are strictly required: Contact (one or more) and Expires (exactly once). All other fields increase the value but are not mandatory (IETF 2022). The overview below shows the key fields and their purpose.

Contact: mailto:security@your-domain.com
Contact: https://your-domain.com/security-contact
Expires: 2026-12-31T23:59:00.000Z
Encryption: https://your-domain.com/pgp-key.txt
Policy: https://your-domain.com/security-policy
Acknowledgments: https://your-domain.com/hall-of-fame
Preferred-Languages: en, de
Canonical: https://your-domain.com/.well-known/security.txt

RFC 9116 additionally recommends signing the file with a PGP key (-----BEGIN PGP SIGNATURE-----) so that its authenticity is verifiable. Germany's BSI names exactly this combination — security.txt with contact address, PGP key, and reporting URL — as recommended practice in its CVD guideline (BSI). The signature is not a mandatory field, but it makes sense for high-protection needs because it makes a tampered file detectable.

Coordinated Vulnerability Disclosure: The Process Behind the File

security.txt is only the front door. Behind it sits the actual process: coordinated vulnerability disclosure (CVD). CVD describes how a reported vulnerability is fixed in coordination between finder and operator before details become public. The BSI has published its own CVD guideline and operates a central reporting office (BSI). At the EU level, the Cyber Resilience Act explicitly requires manufacturers of digital products to maintain a coordinated vulnerability disclosure policy (CRA, EU).

A resilient CVD process involves more than an email address. It governs how reports are acknowledged, within what timeframe an initial response is given, how status is communicated, and under which conditions a so-called safe harbor applies — that is, the assurance that good-faith research will not be prosecuted. The OWASP Vulnerability Disclosure Cheat Sheet describes these building blocks as a minimum standard for operators (OWASP).

How Widespread Adoption Really Is — and Where It Falls Short

The adoption figures are sobering but trending up. Among the top 1M domains, the share with security.txt rose from 0.7% (6,816 domains) in April 2024 to 1.25% (12,510 domains) in 2025 (URIports 2025) — nearly a doubling, but still a single-digit per-mille range across the entire domain universe. Even among large IT companies the gap is wide: in one sample, 39 of 50 IT firms tested (78%) failed to serve an RFC 9116-compliant security.txt (Hartwork Blog 2025).

More important than existence is quality. Of the domains that publish a security.txt at all, only 44% meet the RFC requirements (URIports 2025). The most common error sources: an expired or missing Expires field, missing HTTPS delivery, an incorrect path outside /.well-known/, or a file with the wrong content type. A formally present but faulty file conveys a false sense of security.

Cyber Resilience Act and NIS2: Why CVD Is Becoming Mandatory

The regulatory tailwind is substantial. The EU Cyber Resilience Act (CRA) requires manufacturers of products with digital elements to maintain a coordinated vulnerability disclosure policy with a clear reporting channel — full application of the requirements applies from 11 December 2027 (CRA, EU). The CVD policy is one of eight vulnerability-handling requirements that must be in place by then (CRA, Article 14).

The CRA explicitly recommends publishing security policies in machine-readable form — and security.txt is the established format for exactly that. In parallel, the EU launched ENISA's European Vulnerability Database (EUVD) in 2025 to consolidate information on vulnerabilities affecting the EU market (ENISA). According to ENISA, 21.3% of security incidents in Europe in early 2025 were traced to the exploitation of vulnerabilities (ENISA) — direct evidence of why a working reporting path matters.

Nationally, the framework is becoming more concrete too: the NIS2 Directive and its implementation raise the requirements for vulnerability handling across many companies. The BSI recommends security.txt with contact address, PGP key, and reporting URL as a first step — even for smaller organizations without a large budget (BSI). A reward-free CVD program or a simple security.txt is thus an inexpensive way to align with upcoming EU rules.

Setting Up security.txt: Step by Step

Setup usually takes less than 15 minutes. The following order has proven effective — from the file through the process to permanent monitoring.

1. Create a mailbox — set up a monitored address such as security@your-domain.com, ideally with an auto-reply as acknowledgment
2. Set the mandatory fields — at least Contact and Expires; the expiry date less than one year in the future (IETF 2022)
3. Place the file — at /.well-known/security.txt, served over HTTPS with content type text/plain
4. Add optional fields — Policy (link the policy), Encryption (PGP key), Preferred-Languages, Canonical
5. Sign it — sign the file with PGP, as recommended by the BSI (BSI), to make tampering detectable
6. Write a disclosure policy — define scope, permitted tests, response times, and safe harbor (OWASP)
7. Check per host — each public subdomain needs its own reachable file
8. Monitor — automatically check presence, RFC conformance, and expiry date so the file does not silently expire

Monitoring Presence and Expiry: Where the Security Scan Comes In

A security.txt is not set-and-forget. It disappears during relaunches, server migrations, or CMS updates, and its expiry date inevitably elapses. Without monitoring, this only surfaces when a researcher cannot find contact details — exactly at the wrong moment. The XICTRAQ security scan checks the file's presence at /.well-known/security.txt, validates the mandatory fields, and monitors the Expires date so you are warned before it expires.

security.txt is one component of a broader security-headers and compliance check. If the file disappears, the expiry date lapses, or the content changes unexpectedly, you receive a notification via email, Slack, Discord, or Telegram — before it becomes a friction point in an emergency. This keeps the reporting path discoverable over time.

The reporting channel plugs into an end-to-end control chain: security.txt tells researchers how to report — the remaining security headers and script controls close the gaps that attacks run through in the first place. The following articles explore how these layers interact.

Anyone also securing their interfaces will find further guidance in the article on GraphQL API monitoring and on DNS propagation monitoring with multiple resolvers. Together with a maintained reporting channel and solid GDPR compliance, this forms a verifiable, multi-layered protection base.

Keeping the Reporting Path Discoverable Over Time

security.txt is one of the few security features with a nearly unbeatable effort-to-benefit ratio: minutes of setup against potentially hours of saved response time in an emergency. With the Cyber Resilience Act, the underlying CVD process becomes mandatory for many manufacturers from December 2027 anyway (CRA, EU) — those who start now build routine before the deadline bites.

The real challenge is not creating the file but keeping it current. An expired Expires, a file lost during a relaunch, or a security.txt placed only on the main domain but not on subdomains makes the reporting path invisible — and no one notices until it is too late. This is exactly where automated monitoring comes in: it checks presence, conformance, and expiry continuously and reports any deviation before it becomes a problem.

Combined with monitoring your security headers, script integrity, and API endpoints, this creates seamless control over the security layer of your online presence — from the front door for researchers to the technical safeguards behind it.

Frequently Asked Questions About security.txt and Vulnerability Disclosure