What security.txt Actually Is
security.txt is a plain text file, defined in RFC 9116, that tells anyone who finds a security vulnerability on your site exactly how to report it. It lives at a predictable location — /.well-known/security.txt — so security researchers and automated scanners don't have to dig through your contact page or guess at an email address.
A minimal example looks like this:
Contact: mailto:security@example.com
Expires: 2027-01-01T00:00:00.000Z
Preferred-Languages: en
That's the entire format: a small set of plain-text fields, each on its own line. No JSON, no XML, nothing complicated.
Why This Matters Beyond "Nice to Have"
Without a security.txt file, a researcher who finds a vulnerability on your WordPress site has limited options: dig through your contact form, guess an email address, or — if they can't find anything reasonable — post the vulnerability publicly without giving you a chance to fix it first. None of those outcomes are good for you.
There's also a regulatory angle. The EU Cyber Resilience Act, which applies to products with digital elements sold in the EU, requires manufacturers to have a documented vulnerability handling and disclosure process. security.txt isn't the entire compliance requirement, but it's the standard, expected way to make that process publicly discoverable. If your WordPress site serves EU users or sells digital products, having one is a small, low-effort step toward that broader expectation.
What Fields Actually Belong in the File
The RFC defines several fields, not all of which are required. Here's what each one does:
Contact (required, at least one): How to reach you. Can be an email (mailto:), a URL to a report form, or both. You can list multiple Contact lines if you have more than one reporting channel.
Expires (required): An ISO 8601 timestamp. This forces you to revisit and reconfirm the file periodically — a security.txt that's years out of date with stale contact info is arguably worse than not having one. Set it to something realistic, like one year out, and update it when it expires.
Encryption (optional): A link to a PGP key if you want researchers to encrypt reports containing sensitive details before sending them.
Acknowledgments (optional): A link to a page crediting researchers who've reported issues responsibly — a small incentive that some researchers specifically look for before deciding to report rather than disclose publicly.
Preferred-Languages (optional): Which languages you can read reports in.
Canonical (optional): The authoritative URL of the file itself, useful if your site is reachable via multiple domains.
Policy (optional): A link to your full vulnerability disclosure policy — the detailed document describing scope, expected response times, and what researchers can expect from you.
Adding security.txt to WordPress
Because WordPress's "Settings → Permalinks" structure handles most URLs through PHP, getting a static file to live at /.well-known/security.txt needs one of two approaches:
Option A — Upload the file directly via FTP/file manager. Create a file named security.txt with the content above, and upload it to the .well-known directory at your site's web root (create the directory if it doesn't exist). This works on virtually any host and doesn't depend on WordPress at all, which is actually an advantage — it'll keep working even if you switch themes or plugins.
Option B — Use a plugin that manages it for you. Manually maintaining a static file means remembering to update the Expires field yearly and keeping the contact details in sync if they change. Erdo CRA Compliance generates and serves a security.txt file as part of its broader EU compliance scan, alongside the other documentation (vulnerability disclosure policy, SBOM) that the Cyber Resilience Act expects — so it's maintained in one place rather than as a forgotten static file from three years ago.
Common Mistakes
A few things worth checking once you've added the file:
- Forgetting to update Expires. An expired security.txt signals neglect more than an absent one does. Set a calendar reminder, or use a tool that manages this for you.
- Using a contact address nobody monitors. If security@yourdomain.com routes to an inbox nobody checks, you've solved the discoverability problem and created a new dead end.
- Putting it only at the domain root. /.well-known/security.txt is the current standard location. A root-level /security.txt is allowed as a fallback for older crawlers, but don't rely on it alone.
- Treating it as the whole compliance story. security.txt makes your disclosure channel discoverable; it doesn't replace having an actual triage process for when a report comes in.
Wrapping Up
security.txt is a five-minute fix with an outsized benefit: it turns "I found a bug on your site, now what?" from a dead end into a documented process. Whether you add it manually as a static file or let a compliance tool maintain it alongside your other EU documentation, it's one of the lowest-effort, highest-leverage security practices a WordPress site can adopt.