Summary

  • RFC 9116 makes a vulnerability-reporting route discoverable and gives its published coordinates an expiry, but it does not prove that the route delivers, acknowledges or enters an owned triage process.
  • A disclosure-channel receipt should bind the fetched file and its expiry to a safe end-to-end probe, delivery result, acknowledgement, queue owner, escalation targets and retest triggers without containing a real vulnerability.

Analysis

A security engineer opens /.well-known/security.txt and sees a contact address, a policy link and an Expires value eleven months away. The file is syntactically sound. HTTPS works. A scanner marks the domain green. Then a researcher sends a carefully prepared report and receives a permanent delivery failure because the alias was retired during a mail migration.

Nothing in that sequence makes the file fraudulent. It reveals a narrower problem: document freshness and service availability were treated as the same fact.

RFC 9116 solves an important discovery problem. It gives researchers a predictable place to find vulnerability-reporting information. A valid file must contain at least one Contact field and exactly one Expires field. For web services it belongs under /.well-known/security.txt, is served over HTTPS and uses UTF-8 plain text. The IANA registry records security.txt as a permanent well-known URI, with the IETF as change controller. Those are interoperability properties. They let a person or tool locate and parse the publisher's declared route.

The standard is equally clear about staleness. Expires identifies the moment after which the contents should not be used, and RFC 9116 recommends setting it less than a year ahead. The security considerations warn that incorrect or outdated information can cause reports to miss the organization or reach the wrong contact. Indeed, the document says no file may be better than stale information.

But an unexpired date remains a statement made by the publisher. It says, in effect, “we intend these coordinates to remain current until this time.” It is not a delivery receipt from the mail system, a successful form submission, an acknowledgement from a case platform or evidence that a human owns the queue.

Two clocks, five boundaries

The file carries a publication clock. An operator creates or refreshes it, chooses an expiry and perhaps signs it. The disclosure operation carries a service clock. A report enters through email or a form, is acknowledged, assessed, routed to a system owner, escalated and eventually resolved or declined. Refreshing the first clock does not advance the second.

That distinction creates five boundaries worth preserving.

First is discovery: can the canonical file be fetched from the correct host, and does it identify the intended scope? RFC 9116 says a file applies only to the domain or IP address from which it is retrieved, not automatically to parents or subdomains. A central policy can cover more, but the connection must be explicit.

Second is transport: does the preferred Contact route accept a non-sensitive message from outside the organization? A web form may render but fail after submission. An email alias may exist internally while external gateways reject it. A third-party platform may receive a case but stop forwarding notices to the customer.

Third is confidentiality: if an Encryption field points to a key, can a reporter retrieve the intended material and identify the current fingerprint? RFC 9116 deliberately says the field points to a key rather than embedding one, and places responsibility for judging authenticity on the researcher. An accessible URL alone does not prove that the on-call team can decrypt what arrives.

Fourth is acknowledgement: does a submission generate a durable case identifier or human receipt within the declared service target? This is where the reporting party learns that delivery became custody. A generic autoresponse is useful only if it corresponds to a monitored queue and can be reconciled to the eventual case.

Fifth is handling: who owns initial assessment, out-of-scope routing, internal coordination, escalation and closure? A reporting address can work perfectly while the case sits unassigned. CISA's Binding Operational Directive 20-01 illustrates the difference for covered U.S. federal civilian agencies. It requires procedures for tracking reports to resolution, coordinating remediation, assessing impact, handling out-of-scope reports and communicating with reporters. It also calls for target timelines covering acknowledgement, initial assessment and resolution. Those obligations are not part of RFC 9116, nor are they universal law.

They show why a publication artifact and an operating process must be examined separately.

A receipt, not a staged vulnerability

The repair should be small enough to maintain. A disclosure-channel receipt begins with the canonical retrieval URI, the file fingerprint, fetch time and stated expiry. It records the host or service scope and the preferred contact selected according to the file's ordering. If a form or encryption key is involved, it records the form version or key fingerprint seen during the test.

Next comes a synthetic probe identifier. The probe contains no vulnerability, exploit, personal data or secret. Its subject and body say plainly that it is an authorized routing check and explain how to close it. The receipt records submission time, transport acceptance or failure, acknowledgement time and case identifier where one exists. It names the current queue owner and backup, plus the service targets for initial assessment, escalation and outcome communication.

The receipt should not manufacture a passing result. A mail server's 250 response proves acceptance by that hop, not delivery to an analyst. A form confirmation proves the application returned a page, not that a case was persisted. An autoresponder proves a rule fired, not that an accountable person saw the probe. Each observation stays separate.

Nor should testing become abusive. A monthly stream of fake critical reports would damage the very operation being tested. Frequency should follow change and risk: after a mail-domain migration, form release, identity-provider change, supplier handover, encryption-key rotation, policy rewrite or team reorganization; otherwise at a modest interval shorter than the file's expiry. The test needs prior authorization from the receiving team and a recognisable marker so it cannot be confused with a genuine disclosure.

The Expires line still matters

Adding a receipt does not demote RFC 9116. The standard file remains the public discovery surface. Its expiry provides a crucial upper bound on reliance and forces periodic review. Canonical, Policy, Preferred-Languages and Encryption can reduce ambiguity for researchers. A digital signature can add evidence about the file's integrity and origin.

The receipt asks a different question: when did the declared route last complete the minimum path from public discovery to organisational custody? The answer may be “file valid, email accepted, no acknowledgement,” or “form received, case created, backup owner missing.” Partial results are more useful than one green badge because they show where control stopped.

A compact status line can therefore read: “canonical file fetched 2026-09-07; expires 2027-03-01; preferred contact probe accepted; case acknowledged in 14 minutes; queue owner confirmed; escalation test not performed.” Each clause has its own evidence and observation time. None claims that a real vulnerability will be valid, correctly prioritised or remediated.

Sources

  1. RFC 9116 — A File Format to Aid in Security Vulnerability Disclosure
  2. IANA Well-Known URIs registry
  3. CISA Binding Operational Directive 20-01