security.txt and a vulnerability disclosure channel: the Annex I duty you can meet in an hour

Among the Cyber Resilience Act's obligations there is one that costs an hour of work and is done once and for all: a channel through which people can report a vulnerability to you. It is required by Annex I, Part II of Regulation (EU) 2024/2847 — and although it sounds formal, in practice it is one email address and one text file on your website. Let's do it.

What exactly the CRA asks

Annex I Part II describes the vulnerability-handling process, and part of it is a contact address for reporting vulnerabilities — a place where a security researcher, a customer or anyone else can tell you they found a hole in your product. Without such a channel you learn about a problem by accident and late; with it you have defined where reports go and who reads them.

It's not just a "paper" duty. It is the first link in the chain that, for an actively exploited vulnerability, ends in a 24-hour report under Article 14 — and that chain has to start somewhere.

Step 1: a public address

Set up an address that is obviously meant for security reports. By convention this is security@your-domain. It doesn't have to be a new mailbox — it can forward into an existing team inbox — but it should be clear who watches it and how quickly they respond. The key is that a message doesn't end up in nobody's inbox.

Step 2: /.well-known/security.txt

So that whoever wants to report something finds the contact without guessing, there is a standard, RFC 9116: a text file at a fixed path, /.well-known/security.txt, on your domain. Researchers look for it automatically. It contains a few fields; for a small product these are enough:

1. Contact: — where to write, e.g. mailto:security@your-domain (you can also list a form URL).
2. Policy: — a link to your reporting policy (see CVD policy).
3. Preferred-Languages: — the languages you can communicate in, e.g. en, sk.
4. Canonical: — the canonical URL of the file itself, https://your-domain/.well-known/security.txt.
5. Expires: — until when the file is valid; at most a year ahead is recommended, so you refresh it regularly.

Optionally add Encryption: (a link to your PGP key) if you want to receive encrypted reports. That's it — plain text, no code.

Common mistakes

A few things worth getting right from the start:

1. Don't forget Expires. Without it the file does not formally conform to RFC 9116; with it, remember to refresh it before it lapses.
2. The address must be watched. A channel nobody reads is worse than none — it creates a false impression that you have a process.
3. A link to a policy, not a legal essay. Policy: should point to a short "how reporting works with us" page, not a long document.
4. Placement at /.well-known/. The file belongs exactly here; a copy elsewhere does not replace it (even though the web root was historically tolerated).

An example of what it can look like

The actual file is short. For a company on the domain example.com it might contain:

1. Contact: mailto:security@example.com
2. Policy: https://example.com/security-policy
3. Preferred-Languages: en, sk
4. Canonical: https://example.com/.well-known/security.txt
5. Expires: 2027-09-24T00:00:00.000Z

That's all. You save the file at https://example.com/.well-known/security.txt so it's available at exactly that path.

How to verify it

Setting the file up is one thing, verifying it's reachable is another. A quick check from the command line: curl https://example.com/.well-known/security.txt should return the file's contents (not a 404 and not a redirect to another page). Also check the server serves it as text/plain and that Expires is in the future. And finally the most important thing: send a test email to the address in Contact: and confirm it really reaches a person who can respond.

How it fits with the rest

security.txt is the visible tip of a process that has two more parts: a CVD policy (how you handle reports — a separate article with a template) and advisories (how you publish a fixed vulnerability — also separate). Together they form what is called coordinated vulnerability disclosure, and the CRA wants them in place throughout the support period.

FAQ

1. Is an email enough without security.txt? An address is required, but security.txt is the standard way for researchers to find it automatically (RFC 9116). We recommend both.
2. Where does the file go if we have several domains? On the domain under which you make the product available; if there are several, consider security.txt on each relevant one.
3. Must we accept encrypted reports? You don't have to; the Encryption: field is optional. If you omit it, at least communicate securely by ordinary means.
4. How often to refresh the file? Before the Expires: field lapses — which is why at most a year ahead is recommended.

Why it's worth doing now

A reporting channel is one of the few CRA duties you complete in an hour and that applies earliest — it's part of the "five steps" we recommend doing right away. On top of that, you'll need it in the technical documentation (Annex VII asks for evidence of a contact address) and customers ask for it in questionnaires. One hour of work that pays off in three places at once.

Key point

A reporting channel is the cheapest CRA duty with the best value for money: an hour of work that pays off forever. It has two parts — a public address (typically security@your-domain) that someone actually watches, and a /.well-known/security.txt file per RFC 9116 with Contact, Policy, Preferred-Languages, Canonical and Expires fields. Annex I, Part II requires it as a contact address for reporting vulnerabilities, and it's the first link in the chain that, for an actively exploited vulnerability, ends in Article 14 reporting. Verify availability (curl the path, text/plain, Expires in the future) and above all that the message reaches a person who can act. You'll need the channel in three places at once: for the reporting itself, in the technical documentation (Annex VII asks for evidence of a contact address), and in supplier questionnaires. One hour that comes back threefold.

How CRAguard helps

CRAguard can host your reporting channel for you: a public page with a form, a /.well-known/security.txt with the correct fields, and delivery of reports to you with an acknowledgement to the reporter. You don't have to configure anything on your own infrastructure. Find out whether the CRA applies to you, or join the waitlist — we'll let you know at launch.

This article is informational and not legal advice. It is based on Regulation (EU) 2024/2847 (Annex I Part II), the RFC 9116 standard and the European Commission's guidance of 27 July 2026.