| Internet-Draft | security.txt Product Security | September 2026 |
| Bruhns | Expires 14 March 2027 | [Page] |
This document registers two new fields for the security.txt file format defined in RFC 9116: "Product-Security" and "Product-Security-Policy". They allow an organisation to publish a dedicated contact and disclosure policy for vulnerabilities in the products it manufactures, distinct from the contact for vulnerabilities in its own web presence and infrastructure. The fields are optional and fully backward compatible with existing security.txt parsers.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 14 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
RFC 9116 [RFC9116] defines security.txt as a machine-readable file that tells security researchers where to report security issues. Its "Contact" field is deliberately generic: it does not distinguish between a vulnerability in the organisation's website and a vulnerability in a product the organisation sells.¶
For many organisations these are handled by different teams. Website and infrastructure issues are typically owned by IT operations; product vulnerabilities are handled by a Product Security Incident Response Team (PSIRT) and follow a separate coordinated vulnerability disclosure (CVD) process with its own timelines and, increasingly, regulatory reporting obligations.¶
Recent regulation has made this distinction more relevant. The EU Cyber Resilience Act [CRA] requires manufacturers to publish a contact address and a CVD policy for their products, and national guidance such as [BSI-TR-03183-3] recommends fulfilling that requirement by means of the security.txt file. As a result, a single security.txt file is now expected to serve two audiences with different needs, and reporters have no reliable way to tell which "Contact" entry is intended for which purpose.¶
This document defines two optional fields that make the product-security contact and policy explicit while leaving the semantics of existing fields unchanged.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The terms "field", "field name", and "field value" are used as defined in Section 2 of [RFC9116].¶
"Product" is used in the sense of a hardware or software product supplied by the organisation to third parties, as opposed to the organisation's own web presence, infrastructure, or internal systems.¶
Both fields follow the general syntax of Section 2 of [RFC9116]: a field name, a colon, optional whitespace, and a field value, terminated by a line ending. Field names are case-insensitive.¶
The "Product-Security" field indicates a means of contacting the organisation about security vulnerabilities in products it manufactures or maintains. The value MUST be a URI as defined in [RFC3986]. The same schemes and constraints apply as for the "Contact" field in Section 2.5.3 of [RFC9116]; in particular, "https" and "mailto" URIs are expected, and web URIs MUST use "https".¶
The field MAY appear more than once. When it does, the order of the entries indicates the organisation's order of preference, with the first entry being the preferred one.¶
If the organisation operates a PSIRT or equivalent function, the first "Product-Security" entry SHOULD be the functional mailbox or reporting endpoint of that function.¶
The presence of a "Product-Security" field does not change the meaning of the "Contact" field. Reporters who cannot determine whether an issue relates to a product or to infrastructure SHOULD use "Contact".¶
The "Product-Security-Policy" field indicates a link to the organisation's coordinated vulnerability disclosure policy for its products. The value MUST be an "https" URI.¶
The linked policy SHOULD describe at least: the scope of products covered, how reports are acknowledged and triaged, expected response times, the organisation's approach to public disclosure and embargo periods, whether anonymous reports are accepted, and any assurances given to good-faith reporters. [ISO29147] provides guidance on the content of such policies.¶
The field MUST NOT appear more than once.¶
The following ABNF [RFC5234] extends the grammar in Section 4 of [RFC9116]. The rules "uri", "unstructured-field", "eol", and "WSP" are imported from that document.¶
product-security-field = "Product-Security" ":" *WSP uri eol product-security-policy-field = "Product-Security-Policy" ":" *WSP uri eol¶
Implementations parsing security.txt files MUST treat these fields as extension fields in the sense of Section 2.5 of [RFC9116] when they do not recognise them.¶
A manufacturer whose IT department handles website issues and whose PSIRT handles product issues:¶
Contact: mailto:security@example.com Product-Security: mailto:psirt@example.com Product-Security: https://example.com/psirt/report Product-Security-Policy: https://example.com/psirt/cvd-policy Expires: 2027-09-10T22:00:00.000Z Preferred-Languages: en, de Canonical: https://www.example.com/.well-known/security.txt¶
An organisation whose single security team handles both, and that wishes to make the product policy discoverable without duplicating contacts:¶
Contact: mailto:security@example.com Product-Security-Policy: https://example.com/security/product-cvd Expires: 2027-09-10T22:00:00.000Z¶
Section 2.5 of [RFC9116] requires implementations to ignore fields they do not recognise. Files that use the fields defined here therefore remain valid security.txt files for all conforming parsers, and existing "Contact" entries continue to work unchanged.¶
Organisations SHOULD continue to provide at least one "Contact" entry that accepts product-related reports, so that reporters using tools unaware of this specification are still able to reach the organisation.¶
The security considerations of [RFC9116] apply in full. In particular, the fields defined here are only as trustworthy as the server delivering the file, and an attacker who can modify the file can redirect product vulnerability reports. Organisations SHOULD sign the file as described in Section 2.3 of [RFC9116] and SHOULD ensure that the "Canonical" field is present so that reporters can detect copies served from unexpected locations.¶
Separating product-security contacts from infrastructure contacts may make it easier for an attacker to identify the PSIRT mailbox for phishing or denial-of-service purposes. This information is normally public in any case and the benefit of reliable routing of reports is judged to outweigh this risk.¶
IANA is requested to add the following entries to the "security.txt Fields" registry established by Section 6.2 of [RFC9116], following the Expert Review procedure of [RFC8126].¶
Product-Security¶
Contact for reporting vulnerabilities in the organisation's products¶
Yes¶
This document¶
current¶
IETF¶
Product-Security-Policy¶
Link to the organisation's coordinated vulnerability disclosure policy for its products¶
No¶
This document¶
current¶
IETF¶