Give vulnerability reports a working front door

A reporting route, not a new alert

This is evergreen guidance, not news of a new incident. Security weaknesses are sometimes found by customers, researchers or suppliers who have no obvious way to reach the organisation responsible. The NCSC says a vulnerability disclosure process should give them a dedicated contact route, a clear policy and a security.txt file that makes those details easy to find.

RFC 9116 defines security.txt as a machine-readable text file for publishing vulnerability-disclosure contacts and practices. It does not replace the policy or the team behind it. Its job is discovery: helping a finder locate the right route before a useful report disappears into a general inbox, reaches an unrelated supplier or is disclosed elsewhere through frustration.

Make the file accurate and scoped

For a web service, RFC 9116 requires the file at the domain's /.well-known/security.txt path over HTTPS, served as UTF-8 plain text. Contact and Expires are the two required fields. Contact identifies one or more reporting methods in preference order; Expires states when the information becomes stale. Policy can link to the disclosure policy, while Encryption can point to a key for protected email where that is genuinely supported.

The scope is narrower than many teams assume. A file applies to the domain or IP address from which it is retrieved, not automatically to parent domains or subdomains. The NCSC recommends publishing it across relevant domains and subdomains, which means each separately operated host needs an intentional decision. Record those locations in the asset inventory so a forgotten campaign site or supplier-managed subdomain does not retain obsolete contact details.

Do not publish fields merely because the format allows them. Every address, form, policy page and encryption key creates an operational promise. RFC 9116 warns that stale information can send reports to the wrong party and may be worse than no file. Keep the expiry less than a year ahead, as both sources recommend, and make renewal a named maintenance task rather than an annual surprise.

What businesses should do

Start behind the web page. Name the person or function that owns incoming reports, provide cover for absence and decide how urgent findings reach the affected service owner. Use a monitored secure form or dedicated address. The NCSC recommends protecting vulnerability information and notes that a secure web form can be a straightforward option. Apply normal phishing caution because attachments and links in unsolicited reports may still be hostile.

Publish a short disclosure policy covering the contact method, secure communication options, information that helps assessment, what the reporter should expect, and the boundaries of permitted activity. A security.txt file does not itself grant permission to test; RFC 9116 says permission should be expressed in the policy. Keep the wording realistic. Do not promise reward, acknowledgement or a fixed remediation time unless the organisation can consistently deliver it.

Test the route from outside the organisation. Confirm the standard URL returns the intended plain-text file over HTTPS, each contact reaches the monitored queue, the policy opens without authentication and the expiry is tracked. Send a harmless test report and follow it through acknowledgement, ownership and closure. Repeat after domain, hosting, email or supplier changes.

• Give the reporting queue a named owner and deputy.
• Publish Contact and Expires fields for each relevant domain.
• Link to a clear policy that defines scope and expectations.
• Treat reports and their attachments as untrusted input.
• Test delivery and renew the file before it expires.

The Beekeeper view

Security.txt is deliberately small, but the control is not the file alone. The real control is a reliable path from an external observation to an accountable service owner, with enough safety and communication around it to reach a sensible decision.

A polished policy attached to an abandoned inbox is theatre. A short, standards-based file backed by a rehearsed human process is far more useful: it reduces avoidable delay without pretending every report is valid or every vulnerability can be fixed immediately.