security.txt for Agencies: Why Client Sites Should Publish a Contact File

security.txt is a standard file at /.well-known/security.txt that tells researchers how to report issues responsibly. For agencies, it is a public contact signal that can be added to client sites when the client has a process for receiving and triaging reports. It is not a guarantee, legal shield, or replacement for deeper technical review.

This tool checks public trust signals only. It is not a security audit, vulnerability scan, malware scan, or compliance check.

CertPilot's Client Website Trust Check detects whether security.txt is reachable as one public trust signal among HTTPS/TLS, headers, cookie flags, CAA, robots.txt, and sitemap.xml. For broader domain review, agencies can pair it with the free 10-domain audit.

For the broader public trust-signal framework, use the client website trust signals guide.

Quick answer: what security.txt is

security.txt is defined by RFC 9116. It gives people a predictable place to find reporting instructions. The common location is:

https://example.com/.well-known/security.txt

The file usually contains a contact method, an expiry date, and optional fields such as a policy URL, preferred languages, acknowledgments, or hiring link.

For agencies, the important question is not "can we create the file?" The important question is "who will monitor the contact path and respond?"

Why agencies should know about security.txt

Agencies build and maintain public websites for organizations that may receive reports from researchers, customers, partners, or automated tooling. Without a clear contact path, those reports can go to the wrong inbox, a generic sales form, or a social media account.

Adding security.txt is a small operational improvement when:

• The client has a monitored reporting inbox.
• The organization knows who triages incoming reports.
• The contact address is approved for public use.
• The website owner understands that the file must be kept current.

Do not publish a contact that nobody owns. A stale or ignored contact path can create more confusion than no file.

Where the file lives

The preferred path is:

/.well-known/security.txt

Some sites also support /security.txt, but the .well-known path is the standard location to prioritize.

The file should be served as plain text and reachable over HTTPS. If the site has multiple domains, agencies should decide whether each domain needs its own file or whether redirects should point to a central policy.

The minimum useful fields

| Field | Required? | Example | Agency note | |---|---|---|---| | Contact | Expected | mailto:reports@example.com | Use a monitored inbox or approved form | | Expires | Expected | 2026-12-31T23:59:00Z | Calendar renewal before it goes stale | | Policy | Optional | https://example.com/reporting-policy | Useful when the client has rules | | Preferred-Languages | Optional | en | Helpful for global clients | | Acknowledgments | Optional | Public thanks page | Only use if client maintains it | | Canonical | Optional | Full URL to the file | Useful when redirects or mirrors exist |

The file should be short and maintained. Avoid turning it into a long legal page or generic brand statement.

Contact and Expires

Contact and Expires are the two fields agencies should prioritize.

Contact should point to a channel that someone actually monitors. That might be a dedicated email address, intake form, or policy page. Avoid using a personal email address that will disappear when someone changes roles.

Expires tells readers when the file should no longer be treated as current. Agencies should put this date into the client's maintenance calendar. If the file expires and nobody updates it, the public signal becomes stale.

Optional fields agencies may consider

Optional fields can help mature clients, but they should only be used when true:

• Policy can link to reporting rules.
• Preferred-Languages can clarify accepted languages.
• Acknowledgments can link to public recognition.
• Canonical can state the official file URL.
• Hiring can point to relevant roles if the client wants that.

Do not add fields because they look complete. Add fields only when the client has the process behind them.

What not to put in security.txt

Avoid putting sensitive internal details in the file. It should not reveal internal systems, private contacts, credentials, escalation paths, or anything that should stay inside the organization.

Also avoid vague contact paths. A generic contact form may be acceptable only if it routes reports properly. A sales inbox or social media profile is usually a poor fit.

The file should be practical, public, and maintained.

How to explain it to clients

Use simple language:

"This file gives people a responsible way to report website issues. It does not claim anything about the entire site. It is one public contact signal. If we publish it, someone needs to own the inbox and renewal date."

That explanation keeps expectations clear. It also helps clients understand why the file belongs in an operational workflow, not just a launch checklist.

How Client Website Trust Check detects security.txt

The Client Website Trust Check makes a small public request to /.well-known/security.txt and reports whether the file is reachable. It treats the file as one trust signal, not as proof of broader site quality.

We make a small number of public requests to the domain you submit. We do not log in, scan plugins, or crawl the site.

Some signals are only visible if the site responds normally on the public URL being checked. Sites behind WAFs, geo-blocks, or aggressive bot protection may show unknown rather than missing.

For more on CertPilot's public-check approach and data-source boundaries, see the methodology page.

How security.txt fits with robots.txt and sitemap.xml

security.txt, robots.txt, and sitemap.xml are different files with different jobs:

• security.txt gives a public reporting contact.
• robots.txt gives crawler instructions.
• sitemap.xml helps search tools discover URLs.

Together, they show whether a site exposes basic public metadata. Agencies should check all three during launch QA and care-plan reviews, then document who owns each file.

Related Resources

• Website trust signals checker
• Client website trust checklist
• Agent-friendly web page checklist
• Monitor DNS changes on client websites

Frequently Asked Questions

What is security.txt for agencies?

security.txt for agencies is a practical client-site contact file that tells researchers where to send reports. Agencies should know how to create it, where it lives, and who owns the contact path. The file is useful only when the client has a monitored channel and a response process.

Is security.txt required for every client website?

No. It is optional. Some clients will want it because they have an internal team or support process. Others may not be ready because nobody owns the inbox or triage path. Agencies should recommend it when the client can maintain it responsibly.

Where should security.txt be published?

Publish it at /.well-known/security.txt on the public domain. Some sites also redirect /security.txt, but the .well-known path is the standard location. Serve it over HTTPS and keep the contact and expiry details current.

What fields should a small client include?

A small client should usually start with Contact and Expires. If they have a reporting policy, add Policy. If they operate in specific languages, add Preferred-Languages. Keep the file short and avoid fields the client will not maintain.

Who should receive reports from security.txt?

The contact should go to a monitored inbox or intake process owned by the client or their technical provider. Avoid personal addresses unless there is a clear continuity plan. For agency-managed care plans, decide whether the agency triages first or whether reports go directly to the client.

How often should agencies review security.txt?

Review it at launch, during care-plan renewal, and before the Expires date. Also review it after domain moves, hosting changes, client team changes, or support-process changes. A stale contact file can confuse the people it is meant to help.