security.txt under RFC 9116 and BSI TR-03183-3: a guide for manufacturers

A security.txt file is a small text file at /.well-known/security.txt on the manufacturer's website. It tells security researchers, customers and authorities where to report a vulnerability. Regulation (EU) 2024/2847 requires such a contact address in Annex I, Part II, point (6), and a single point of contact in Article 13(17), but does not prescribe a format. BSI TR-03183-3, a technical guideline from the German Federal Office for Information Security (BSI), fills that gap: a security.txt file under RFC 9116 as the minimum requirement, plus an OpenPGP signature, an expiry date no more than one year ahead and two functional mailboxes, psirt@ for products and csirt@ for your own IT.

Free toolsecurity.txt generatorEnter your domain and get a ready-made file under RFC 9116 and TR-03183-3. Every field explained, checked before download. Runs in the browser, no sign-up.Create the file Free toolsecurity.txt checkerIs your file already online? The checker tests retrieval, structure, expiry date, links, keys and signature against RFC 9116 and TR-03183-3, and tells you how to fix each finding.Check the file

What does the Regulation require, and from when?

Three provisions of the Regulation concern the reporting address. Annex I, Part II, point (6), requires manufacturers to provide a contact address for reporting vulnerabilities they discover. Annex I, Part II, point (5), requires a coordinated vulnerability disclosure policy, which the security.txt file points to. Article 13(17) calls for a single point of contact that enables users to communicate "directly and rapidly" with the manufacturer, including to report vulnerabilities. It must be easily identifiable, appear in the information and instructions to the user under Annex II, and allow users to choose their preferred means of communication.

According to the Commission guidance C(2026) 5252 (paragraph 210), the obligations in Annex I, Part II apply to products placed on the market from 11 December 2027. The reporting address still matters today: the reporting obligation under Article 14 has applied since 11 September 2026 and starts when the manufacturer becomes aware. Without a working address, you learn about a vulnerability later than you need to. The Regulation does not specify the format. In Germany, BSI TR-03183-3 "Vulnerability Reports and Notifications" (version 1.0.0, 20 August 2025) is the benchmark. It is voluntary, a harmonised standard (prEN 40000-1-3) has not yet been published in the Official Journal, and there is no evidence that market surveillance will use the TR as its benchmark. It is, however, the only description from a public authority, and a file that meets it also meets RFC 9116.

What is security.txt and where does the file go?

RFC 9116 is an IETF publication from April 2022, an RFC in the Informational category. It sets out how a website announces its security contacts in machine-readable form: in a plain-text file in the format "field name: value", one entry per line, with comments starting with a hash sign. The file sits at /.well-known/security.txt and is served over HTTPS; tools used by security researchers and authorities read it automatically. The TR additionally requires (section 4.2.1) HTTPS with at least HTTP/1.1 and plain text in ASCII or UTF-8, and under section 4.2.11 that firewalls and DDoS protection do not block retrieval by checking services; the content type text/plain is prescribed by RFC 9116.

In section 4.5, the TR also requires a reporting web page, linked from the home page and usable without JavaScript or a login. The security.txt file points to it.

Which fields belong in it?

RFC 9116 defines eight fields, two of which are mandatory. The TR makes four more mandatory, also requires a signature and adds a field from the CSAF standard, the format for machine-readable security advisories. The table shows both levels.

The signature

Section 2.3 of RFC 9116 recommends signing the file with OpenPGP (clearsign: the readable file with the signature attached). The TR makes this mandatory in section 4.2.10: under RFC 9580, preferably with a dedicated key whose validity must not exceed five years. The signature proves that the file comes from the manufacturer and not from an attacker trying to divert reports.

Which roles and response times sit behind the address?

A security.txt file is only as good as the mailbox behind it. In sections 4.3 and 4.4, the TR describes what running it involves.

• Two roles. A PSIRT (Product Security Incident Response Team) for vulnerabilities in products, a CSIRT (Computer Security Incident Response Team) for your own infrastructure. Each gets a functional mailbox, psirt@ and csirt@, and its own OpenPGP key. Except in microenterprises, the two roles must not be held by a single person (section 4.3.1). Reports must at least be processed in English.
• Web form. Under section 4.3.3 there has to be a form that also allows anonymous reports. It supplements e-mail; it does not replace it.
• Daily test. The TR recommends testing the mailboxes and the form every day with an automated test message.
• Response times. Under section 4.4.8, the reporter receives a response within 5 working days that is not automatically generated. Detailed feedback follows within 10 working days: confirmation or rejection, follow-up questions, or an explanation of the delay with a commitment to a further update within 10 working days. This does not apply to anonymous reports.
• Four-eyes principle. Under section 4.4.7, no analyst may close a report alone.
• Disclosure. Under section 4.4.10, a confirmed vulnerability is published within 90 days, extendable once by 90 days in consultation with the national CSIRT, which in Germany is CERT-Bund.

These time limits come from the TR alone; neither the Regulation nor the Commission guidance sets response times for reporting addresses. Article 14 is a separate matter: for an actively exploited vulnerability, the 24-hour deadline runs from awareness, regardless of working days (see When does the 24-hour deadline start?).

What does a complete file look like?

The following example for a fictitious manufacturer contains all the mandatory and recommended fields of the TR. Only the signature is missing; OpenPGP wraps it around the file when you sign.

# Our canonical URI
Canonical: https://www.example-machinery.com/.well-known/security.txt

# Our security addresses
Contact: mailto:psirt@example-machinery.com
Contact: mailto:csirt@example-machinery.com
Contact: https://www.example-machinery.com/security-contact

# Our OpenPGP keys
Encryption: https://www.example-machinery.com/.well-known/psirt-example-machinery.asc
Encryption: https://www.example-machinery.com/.well-known/csirt-example-machinery.asc

# Our preferred languages
Preferred-Languages: en, de

# Our security policy
Policy: https://www.example-machinery.com/security-policy

# Our security advisories
CSAF: https://www.example-machinery.com/.well-known/csaf/provider-metadata.json

# Our security acknowledgements page
Acknowledgments: https://www.example-machinery.com/security-acknowledgments

Expires: 2027-10-01T00:00:00.000Z

The comments follow the wording the TR specifies, the PSIRT address comes before the CSIRT address, each Encryption field points to a key file, and Expires is less than a year in the future. The security.txt generator creates your own file in this structure from your domain and addresses.

How do you check your file?

1. Check retrievalRequesting https://your-domain.com/.well-known/security.txt must return status 200 and the content type text/plain, without a redirect. On the command line: curl -sI https://your-domain.com/.well-known/security.txt.
2. Read the fields and dateAre all of the TR's mandatory fields present, Contact in the right order, Canonical identical to the actual location, Expires in the future and no more than one year away? Put a quarterly review date in the calendar.
3. Check the signatureWith gpg --verify against the published key. The key must be retrievable from the Encryption address and its fingerprint must appear on the reporting page.
4. Use checking servicesThe TR names findsecuritycontacts.com and internet.nl as crawlers that must be able to reach the file. Both show formal errors.
5. Test the mailboxes and the formSend test messages to psirt@, csirt@ and through the form: do they reach a person who reads them? The TR recommends doing this daily and automatically.

Common mistakes

An analysis of the one million most-visited domains by uriports, dated 24 January 2025, shows how rarely the file is correct: only 1.25 per cent of domains had a security.txt file, and only 44 per cent of those complied with the RFC. In 45 per cent Expires was missing, in 13 per cent it had expired, and in 20 per cent it was too far in the future. In 26 per cent, Canonical did not match the actual location. Only 11 per cent were signed, and half of those signatures were invalid.

• Wrong location. The file is only at /security.txt, not under /.well-known/.
• http only, or a redirect. The file can only be reached unencrypted or redirects to an HTML page. Tools then read nothing.
• Expired Expires. Set up once and forgotten. From the expiry date onwards, the content is considered unreliable. Also lower-case "t" and "z" in the date, where the TR requires upper case.
• Canonical points elsewhere. For example to the domain without www, while the file sits under www.
• Encryption points to a page instead of the key. The TR requires a direct download of the .asc file.
• The mailbox exists but nobody reads it. The mistake with the worst consequences: if a report sits unread for three weeks, you have some explaining to do.
• The spam filter throws out genuine reports too. The file brings beg bounty e-mails and advertising with it. Discard them automatically and you lose genuine reports as well; how to sort them is explained in Spam in the security mailbox.

How do large manufacturers do it?

Three publicly accessible files, as of 7 October 2026, show the range. Siemens separates the roles as the TR does (productcert@ for products, cert@ for infrastructure), with two keys, Canonical, Policy, a CSAF entry and a Hall of Thanks, but no visible signature. Bosch serves the file signed, with a comment for each field, Contact as a form address, Hall of Fame, Policy and Hiring. SAP limits itself to Contact and Expires: compliant with the RFC, but without Canonical, Policy, languages or signature, and with the expiry date more than a year away. For a mid-sized manufacturer, the Bosch file is the most useful model.

What this means in practice

The file itself can be written in an hour. The work lies in running it: two mailboxes that someone reads, a form that works, an expiry date that someone extends, and a response within 5 working days written by a person. For a manufacturer with 80 employees and no security department, that means: name the roles, arrange cover, put review dates in the calendar. CRA Response Center monitors the mailbox behind the security.txt file, classifies every incoming report and alerts the people responsible by SMS and e-mail when a report is important. Assessment and notification remain with the manufacturer.

Free templatesCRA Reporting KitReporting playbook, awareness record, notification templates for the ENISA platform, call chain and deadline calculator. Six Word templates, two Excel workbooks and a handbook, free by e-mail.Request the kit

Frequently asked questions

Further reading

• security.txt generatorCreate the file under TR-03183-3 in your browser, with checks and a draft CVD policy.
• Setting up security.txtCreate the file, configure the server, sign and renew it, step by step on security-txt.eu.
• security.txt examplesAnnotated files: minimal under RFC 9116, complete under TR-03183-3, signed, and with common errors.
• Coordinated vulnerability disclosure policyThe document the Policy field points to: what belongs in it and what reporters expect.
• PSIRT for SMEsWho reads the mailboxes, who assesses, who replies, and how to manage with only a few people.
• The first 24 hoursWhat happens when an actively exploited vulnerability comes in through the reporting address.

Sources

• Regulation (EU) 2024/2847, Article 13(8) and (17), Annex I, Part II, Publications Office of the EU, 20 November 2024.
• BSI TR-03183-3 Vulnerability Reports and Notifications, version 1.0.0, German Federal Office for Information Security (BSI), 20 August 2025.
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure, IETF, April 2022.
• OASIS CSAF 2.0, Requirement 8: security.txt, OASIS, 2022.
• Commission guidance C(2026) 5252, Annex, paragraph 210, European Commission, 27 July 2026.
• security.txt in 2025, analysis of the top 1 million domains, uriports, 24 January 2025.
• security.txt files of Siemens, Bosch and SAP, accessed 7 October 2026.