Security.txt RFC 9116 check — check your security contact file online

9 findings in a 10-line file, and the one that matters most is that the vulnerability contact point expired 75 days ago: that is what security.txt Lint returns for a platform maintainer who ships software into the EU and has not opened /.well-known/security.txt since the day it was written.

Since 11 September 2026, Article 14 of the EU Cyber Resilience Act (Regulation (EU) 2024/2847) has been in force for reporting. When a vulnerability in your product is actively exploited, three clocks start: an early warning to your CSIRT and ENISA within 24 hours, a vulnerability notification within 72 hours, and a final report within 14 days. The penalty ceiling for getting the reporting duty wrong is 15 million euro or 2.5% of worldwide annual turnover.

Every one of those clocks starts when the report reaches you. There is one machine-readable place a stranger looks for where to send it: the security.txt file at /.well-known/ on your domain. RFC 9116 is short and blunt about what makes that file real. Contact is mandatory and must be a URI. Expires is mandatory, must be a full RFC 3339 timestamp, and if the timestamp has passed, the file MUST be ignored. A researcher's tooling does not argue: it reads the date, drops the file, and the researcher falls back to a public post. Your 24-hour clock then starts from a tweet you did not see.

What the linter reads

security.txt Lint applies 13 rules inside VS Code, each reported on the line where the problem is:

• Expires missing, not RFC 3339, already past, or more than 365 days out
• Contact missing, or written as [email protected] with no mailto: scheme, which is not a URI
• http:// where RFC 9116 requires https://
• Expires, Canonical or Preferred-Languages repeated, when each may appear once
• Canonical pointing anywhere other than the /.well-known/security.txt path scanners actually fetch
• CSAF pointing at an advisory index instead of a provider-metadata.json URI
• Contacts:, Policy-URL: and other unregistered field names, which parsers drop in silence
• lines with no colon, which are not parsed at all
• Policy absent, which leaves the reporter with no disclosure process to follow

The sample file shipped with the extension is ten lines long and looks fine to a human eye. The linter returns 9 findings on it: 5 errors and 4 warnings. The first error is the date arithmetic no chatbot can do for you, because it does not know what today is: Expires ran out on 2026-06-30, which was 75 days before the lint.

Free, and the next job

Linting the file you have open is free and complete. All 13 rules, every line number, no key, no watermark, no limit on how many times you run it. The same engine runs in the browser, so you can paste in a file from a server you have not cloned.

The next job is different in scope and in what you keep. A company that ships more than one product has more than one security.txt: one per domain, one per white-label deployment, one buried in a static site repository. The full version sweeps every security.txt in the workspace in one pass and writes a dated JSON report you keep and attach to an audit file or a customer security questionnaire. It is 29 dollars once, one licence key per person or team seat. A security consultant reviewing a disclosure contact and policy starts around 150 dollars an hour, and that review is a snapshot that goes stale on the day the Expires value passes.

Run it on your own file first. If it comes back clean, you have lost thirty seconds. If it comes back with an expired Expires line, you have learned that for two months nobody could tell you your product was being exploited.