/.well-known/security.txt is a standard location for a website's security contact information. It lets researchers find a public reporting address, encryption key, disclosure policy, and sometimes acknowledgements path, using a predictable file under the .well-known path at the site root.
What the file does and why it matters
/.well-known/security.txt gives websites a predictable place to publish security contact details so researchers can report issues without guessing whom to contact. That predictability reduces friction in responsible disclosure, which is especially important when a report is time-sensitive or when the right reporting channel is not obvious from the public site.
It is not a vulnerability reporting programme by itself. Rather, it is a discovery mechanism that points people to the organisation’s chosen reporting address, public encryption key, disclosure policy, and sometimes an acknowledgements page. The value comes from making the first step of disclosure easy and reliable.
What belongs in a security.txt file
The file usually contains a reporting contact, optional encryption material, and policy information that tells a researcher how the organisation wants vulnerabilities reported. Some organisations also include multiple contacts, language preferences, or a link to a formal disclosure programme. The content should be stable, readable, and maintained as part of the organisation’s public security posture.
Because the file is meant for external consumers, clarity matters more than internal convenience. A stale mailbox, dead link, or outdated policy can make the file look present while still failing the purpose it is supposed to serve. That is why many teams treat it as part of their vulnerability disclosure process rather than as a one-time website configuration.
How it fits into vulnerability disclosure and researcher workflows
security.txt works best as the front door to a broader disclosure process. Researchers use it to find the right entry point quickly, then follow the published policy for scope, response expectations, and safe-harbour terms. For organisations, that means the file should align with the actual intake path used by the security or PSIRT function, not describe an idealised process that nobody monitors.
A good implementation supports coordinated vulnerability disclosure, public reporting, and faster triage. In practice, that often means the security.txt content is kept consistent with the policy language on the site and with the team that will receive and handle the report. Bug bounty and vulnerability disclosure guidance is a useful companion for understanding how the file fits into a broader disclosure programme, while the vulnerability disclosure maturity model shows how organisations progress from a basic contact point to a more mature reporting process.
Operational and security considerations for publishing it
The main security value is not secrecy, it is trust. A correctly published file helps legitimate researchers reach the right channel, which can shorten the time between discovery and remediation. A poorly maintained file can create the opposite effect, delaying reports or pushing researchers toward less reliable contact methods.
Good practice is to keep the file reachable at the exact well-known path, keep the reporting address monitored, and review the disclosure policy whenever the organisation’s intake process changes. PSIRT operating guidance is relevant where the file feeds a formal vulnerability-handling function, and ISO/IEC 29147 and 30111 guidance helps anchor the file in a recognised disclosure and handling model. If the site publishes a public key, the organisation should also ensure the key is current and that staff know how messages encrypted to that key are processed.
Risk and Threat Considerations
When security.txt is missing, stale, or misleading, the risk is usually operational rather than exotic: valuable reports take longer to reach the right people, and some never do. Attackers can also benefit from the same confusion if the organisation’s public reporting path is hard to distinguish from decoy or abandoned contact points.
Failure mechanism: The file points researchers to an address, policy, or key that no longer matches the organisation’s real disclosure workflow, creating delay, misrouting, or loss of inbound reports.
Impact: Delayed triage can extend exposure windows for exploitable weaknesses, while broken contact details can reduce the chance that researchers choose the intended responsible channel.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8, NIST CSF 2.0 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | security.txt supports external vulnerability intake and triage |
| Recommendation — Publish and monitor a clear vulnerability reporting path so externally found issues reach triage quickly. | ||
| ISO/IEC 27001:2022 | A.5.24 — Information security incident management planning and preparation | security.txt is part of preparing external reporting and handling for security issues |
| Recommendation — Prepare a maintained external reporting route and align it with incident handling responsibilities. | ||
| CIS Controls v8 | CIS-17 — Incident Response Management | the file helps route external vulnerability reports into response operations |
| Recommendation — Define and test how public vulnerability reports enter incident response workflows. | ||
| NIST CSF 2.0 | RS.CO-1 — Personnel know their roles and order of operations when a response is needed | security.txt points reporters to the people and process that receive vulnerabilities |
| Recommendation — Assign clear ownership for the public reporting channel and the follow-up workflow. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | the public contact path depends on reliable handling of inbound report messages and errors |
| Recommendation — Ensure reporting workflows log, route and handle incoming security reports reliably. | ||
Practitioner Guidance
Why practitioners should care: security.txt is small, but it sits on the edge of vulnerability intake, communications, and trust. Treat it as an externally visible control surface, not as static website metadata.
Governance implication: The owner should be the team that can actually receive, triage, and respond to reports. If security, PSIRT, legal, or an external provider all touch the process, the published contact path should still resolve to one clearly accountable workflow.
Practitioner takeaway: Keep the file aligned with the real reporting process, review it whenever contacts or policy change, and test that the published path still reaches a monitored inbox or intake system.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org