In short
Builds an RFC 9116 security.txt file
You need a contact address and an expiry date; policy URL optional
You get a file to copy or download for /.well-known/security.txt
Runs in your browser; nothing is uploaded
Who uses it
Product security and PSIRT owners
The PSIRT lead publishes one clear intake address, so reports stop landing in sales or support inboxes.
Device makers and brands
The compliance lead shows a public vulnerability reporting channel, one of the CRA Annex I vulnerability-handling items.
Machine builders and automation OEMs
The engineering head gives customers and researchers a documented contact for every machine line.
How it works
security.txt is defined by RFC 9116 and documented for implementers at securitytxt.org. The file this tool generates goes at /.well-known/security.txt on your own domain — the same convention CISA uses for its own disclosure contacts, part of the agency's Coordinated Vulnerability Disclosure process. For how that intake-to-fix workflow is structured once a report arrives, see our CVD process guide.
Contact: mailto:[email protected] Preferred-Languages: en
RFC 9116 requires both Contact and Expires — fill in both before copying or downloading.
A deterministic, offline read of your fields — not a live AI model, and nothing you type here is sent anywhere.
The one fix that matters most: add an Expires date. RFC 9116 makes Expires mandatory too, and a consumer should treat a file without one as invalid.
- No Policy URL set. It is optional under RFC 9116, but adding your vulnerability disclosure policy tells a researcher your scope and safe-harbor terms before they report anything.
- No Canonical URL set. RFC 9116 §2.5.3 recommends one if this file might be mirrored or fetched from more than one location, so a consumer can confirm which copy is authoritative.
Host the downloaded file at /.well-known/security.txt on your own domain.
Enter your contactType the email address or URL researchers should use. An email address gets the mailto: prefix automatically. Set the expiry and optional fieldsPick the Expires date, then add your policy URL, canonical URL and preferred languages. The offline review names the one field that matters most. Copy or downloadCopy the text or download security.txt, then publish it at /.well-known/security.txt on your own domain.
Which security.txt fields does RFC 9116 actually require, and which are optional?
RFC 9116 requires every security.txt file to carry at least one Contact field and an Expires field. Contact can be an email address, a phone number or a web URL a researcher can use to reach you, and securitytxt.org's implementer documentation shows examples of each form.
Everything else — Policy, Encryption, Acknowledgments, Preferred-Languages, Canonical — is optional under the RFC but commonly published alongside the required fields. CISA's own published file fills in several of them as part of its Coordinated Vulnerability Disclosure process, one real example of pairing the required Contact/Expires pair with the optional fields a researcher actually benefits from. Publishing the file is the easy part; our PSIRT as a service staffs the intake and response process behind the Contact address it points to.
What you get
/.well-known/security.txt
Contact: mailto:[email protected]
Expires: 2027-11-01T00:00:00.000Z
Policy: https://example.com/security-policy/
Canonical: https://example.com/.well-known/security.txt
Preferred-Languages: en
Formats and standards
Standard names belong to their owners and are used only to identify the formats; nominative use, no endorsement implied.
Delivered by Netbase JSC
SoftWSP is a brand of Netbase JSC. Facts of Netbase JSC as of .
Founded
2012
Reach
Clients in around 80 countries
Delivery model
Remote, worldwide
Vulnerability reports
PSIRT via [email protected], published security.txt
The full job, done for you
The file tells researchers where to write. Our PSIRT service runs what happens next: triage, coordinated disclosure, a case record for every report and draft regulatory reports when a case meets the criteria.
Need this across a product range or in your pipeline? Talk to sales.
Frequently asked questions
What is security.txt?
A plain-text file, defined by RFC 9116, that a website publishes at /.well-known/security.txt so a security researcher who finds a vulnerability knows exactly who to contact, instead of guessing an address or searching for a contact page.
Where do I host the file this tool generates?
At /.well-known/security.txt on your own domain — for example https://example.com/.well-known/security.txt. RFC 9116 defines that exact path; hosting it anywhere else means tools and researchers that look it up by convention will not find it.
What happens when the Expires date passes?
RFC 9116 requires an Expires field so researchers can tell a stale, abandoned file from a current one. Once the date passes, treat the file as out of date and publish a refreshed one with a new Expires value; some scanners flag or ignore expired files.
Do I need to fill in the Policy field?
RFC 9116 does not require it, but it is worth including: a Policy URL pointing at your vulnerability disclosure policy tells a researcher what to expect (scope, safe-harbor terms, response times) before they report anything. The linked guide below has a policy template you can publish that URL from.
Does any government agency actually use security.txt?
Yes — CISA, the US Cybersecurity and Infrastructure Security Agency, publishes its own file at cisa.gov/.well-known/security.txt and documents a Coordinated Vulnerability Disclosure process for reports it receives.
Related
Sources
Questions about this page?