What is security.txt, and how do you set it up correctly?

Suppose a security researcher finds a vulnerability in your web application. Does that person know where to report it? For many Dutch organizations, the answer is no. The next question is whether and how the report will reach the security team. A security.txt file solves that problem. Below, you’ll learn what it should contain, where it should be placed, and what often goes wrong in practice.

What is security.txt?

Security.txt is a text file on your web server that specifies how someone can report a security issue to your organization. The format is defined in RFC 9116, published in April 2022 by Edwin Foudil and Yakov Shafranovich.

The structure is similar to robots.txt: a fixed location on your domain, a fixed format, and a file that can be read by both humans and scripts. Each line consists of a field name, a colon, and a value. Lines that begin with a hash sign are comments.

Why should you include a security.txt file?

Otherwise, the person reporting the issue will have to look elsewhere. Someone who discovers a vulnerability in your customer portal has four options: they can keep searching until they find the right person, send an email to the general email address, give up, or post their findings on social media. Only with the first option will you be the first to know.

Ethical hackers, security researchers, and technically savvy customers regularly report vulnerabilities to companies that aren’t equipped to handle them at all. Here’s what happens: the report comes in to info@, sits there for two weeks, and the reporter concludes that you apparently aren’t interested. Out of frustration or concern about the vulnerability, the reporter may then decide to go public—something you’ll likely want to avoid.

There’s also an internal benefit. By creating a security.txt file, you force yourself to determine in advance who will handle reports, within what timeframe a response will be provided, and who will decide on an emergency patch. You’ll want to have that discussion before the first report comes in.

Where should the file be located?

On https://jouwdomein.nl/.well-known/security.txt. That is the only correct location according to RFC 9116. There are three requirements associated with it:

• The file must be accessible via HTTPS.
• It must be served as text/plain, with UTF-8 character encoding.
• If there is also a file in the webroot (/security.txt), then according to the RFC, the version at /.well-known/ takes precedence. You can use that old location as a redirect, so that anyone who still tries to access it will end up in the right place.

If you work with multiple domains or standalone subdomains, each domain where someone might find a vulnerability needs its own file. Use the “Canonical” field to point to where the original should be located.

What fields are included in a security.txt file?

Two fields are required:

• Contact – where you send the report. An email address (mailto:), a phone number (tel:), or a web form (https:). This field may appear multiple times; the order indicates your preference.
• Expires – the date on which the information in this file is considered outdated. This field may appear exactly once.

The rest is optional:

• Encryption – a link to your public key, so that a reporter can send the details in encrypted form.
• Policy – a link to your CVD policy or responsible disclosure page.
• Acknowledgments —a page where you thank your contributors.
• Preferred Languages – the languages in which you would like to receive notifications. You may select only one option.
• Canonical —the place where this file belongs.
• Hiring – a link to your security job openings.

What does a good security.txt file look like?

# Meldingen over de beveiliging van onze systemen zijn welkom.
Contact: mailto:security@jouwdomein.nl
Contact: tel:+31-88-1234567
Expires: 2027-09-01T00:00:00.000Z
Encryption: https://jouwdomein.nl/pgp-key.txt
Policy: https://jouwdomein.nl/responsible-disclosure
Acknowledgments: https://jouwdomein.nl/hall-of-fame
Preferred-Languages: nl, en
Canonical: https://jouwdomein.nl/.well-known/security.txt

Note the address listed under “Contact.” A shared mailbox like security@ will continue to function even if a colleague leaves, whereas a personal email address will quietly become inactive after a year.

Why does security.txt have an expiration date?

Because outdated contact information is worse than no contact information at all. Anyone who sends an email to an address that no one checks anymore will assume the message was delivered. The “Expires” field shows when the file was last checked, and the RFC recommends setting the date to less than one year in the future.

Therefore, make sure to add the expiration date to the calendar of the person in charge of management, or have your hosting provider include the file in their annual maintenance. An expired security.txt file is a sign to researchers that the rest of the site is likely out of date as well.

Do you need to sign your security.txt file with PGP?

The RFC recommends an OpenPGP signature, in combination with the Canonical field, so that a reporter can verify that the file truly comes from you and is in the correct location. This allows the reporter to verify that the file has not been tampered with. Keep in mind, nothing is more confusing than an incorrect signature. Therefore, start with a correctly filled-out file that includes a current address and a valid “Expires” date.

What is the difference between security.txt and a responsible disclosure page?

They go hand in hand and serve different purposes. A responsible disclosure page, also known as a Coordinated Vulnerability Disclosure (CVD), is a page on your website that outlines the ground rules: what you expect from a reporter and what they can expect from you. This page is written for people, is hosted at a URL of your choice, and can be as long as necessary.

Security.txt serves as the guide to that page. The file is located in a specified directory, is machine-readable, and contains little more than a contact address and a link to that page. A scanner, an investigation tool, or an AI assistant that determines where a report should be sent first checks /.well-known/security.txt.

That’s the main weakness of a standalone disclosure page: it can only be found if someone stumbles upon it in your footer or knows how to Google it. If it’s located in a logical spot, things usually go well, and the security.txt file is the icing on the cake. Do you already have a responsible disclosure page? Then you’ll be done in five minutes. Enter the URL of that page in the “Policy” field, the email address in the “Contact” field, and place the file in the correct location.

What do you include in the CVD policy you’re referring to?

The “Policy” field refers to your Coordinated Vulnerability Disclosure or Responsible Disclosure policy. It outlines what you expect from a reporter and what the reporter can expect from you. It should definitely include the following four components:

• The scope: which domains, applications, and systems are covered, and what types of attacks you specifically do not want (denial-of-service attacks, social engineering targeting your employees, downloading customer data).
• What you commit to: the number of business days within which you will send a confirmation of receipt, when you will provide substantive feedback, and the target resolution timeframe.
• Whether you provide credit or a reward, and where that credit will appear.
• A commitment not to take legal action against reporters who follow your rules. In the Netherlands,

The NCSC has published guidelines on this topic that you can use as a starting point.

Is security.txt required?

No. RFC 9116 has the status “Informational,” which means it is a widely accepted convention and not a standard that you are required to comply with.

The Cybersecurity Act—the Dutch implementation of NIS2, which has been in effect since August 15, 2026, for more than 8,000 organizations—does not mention security.txt anywhere. What the law does require is that you manage risks and report incidents to the CSIRT within 24 hours. A reporting channel that demonstrably works is part of that first requirement, and security.txt is the most cost-effective way to make that channel discoverable. The question is also coming up more and more frequently in ISO 27001 audits and supplier questionnaires.

What goes wrong in practice?

We keep finding the same errors on the websites we examine. A file with an “Expires” date that expired two years ago. A contact address for an administrator who now works elsewhere. A security.txt file located only in the webroot and not in /.well-known/. A Policy link pointing to a page that disappeared during the last website migration.

There’s an even more subtle one: a server that returns a clean HTML page with a 200 status code for every unknown URL. A scanner then reads a security.txt file that doesn’t exist, and you think the issue is resolved. That’s why you should always check the status code and the content type—not just what your browser displays.

Does a security.txt file increase your risk of being hacked?

The file does not contain any information that would be useful to an attacker. You are publishing a contact address, not version numbers or internal system names.

What you do get is noise. There’s a category of senders who circulate automated scan reports asking for a reward, even though there’s no actual vulnerability behind them. Therefore, agree in advance on who will review these messages and how you’ll distinguish between a legitimate report and a form letter. That’s a small price to pay to ensure that a researcher who does find a real vulnerability can reach you immediately.

How do you check if your security.txt file is correct?

Start with the basics and retrieve the file the way a scanner would:

curl -i https://jouwdomein.nl/.well-known/security.txt

You want to see a 200 status code, a “ Content-Type ” from text/plain, and an “Expires” date that’s in the future. After that, the most important test is the human one: send a test message to the address listed under “Contact” and see if someone responds within your own promised timeframe. A file that’s technically correct but ends up in a mailbox that no one opens is still a dead end.

A doorbell is not a lock

Security.txt ensures that you’re notified when someone finds something. It says nothing about what can be found. These two things go hand in hand: an organization that takes reports seriously but never conducts its own testing is, in effect, waiting for an outsider to do the work.

Want to know what vulnerabilities are already present in your environment? During a penetration test, our certified ethical hackers go beyond an automated scan: we manually search for what a scanner misses, and then explain to you in plain language where the vulnerabilities are. Schedule a consultation, and we’ll work with you to assess your current situation.