CSIRTs Inherit Europe’s Missing security.txt Before Article 14

A 14 August scan of European software vendors found 374 of 492 reachable sites had no security.txt file. That is 76% of the live sample, two weeks before the EU’s 24-hour vulnerability clock starts.

The file is how a researcher is supposed to find a private inbox. When it is missing, the report tends to land on a national CSIRT desk, a public post, or a customer thread, and that is still awareness under the Cyber Resilience Act.

374 Reachable Vendors Still Have No Inbox

CRA Incident Drill, an independent research project, requested /.well-known/security.txt on 623 domains taken from the europealternatives.com directory of European SaaS and software companies. The check was a single GET, up to three redirects, with an eight-second timeout, on 14 August 2026.

A file counted as present only on HTTP 200 with a Contact line, which dropped SPA catch-alls that return 200 for every path. Unreachable names were left out of the percentages.

The authors publish aggregates, not the vendor list, because naming the dark domains would help attackers first. They also note that some firms take reports through bug-bounty platforms or a published security mailbox. The scan measures RFC 9116 adoption, not every possible inbox.

Article 14 Starts 15 Months Before a Contact Address

From 11 September 2026, makers of products with digital elements sold in the EU must report actively exploited flaws and severe incidents. The Commission’s CRA reporting page says they file an early warning within 24 hours of becoming aware, a fuller notice within 72 hours, and a final report later.

That duty is the first slice of Regulation (EU) 2024/2847 to apply. The Act entered into force on 10 December 2024. Most other rules, including Annex I’s essential cybersecurity requirements, apply from 11 December 2027.

Annex I Part II tells makers to enforce a coordinated disclosure policy and to provide a contact address for reports. That contact duty is 15 months after the 24-hour clock. Until then, the standard doorbell is still optional, while the legal timer is not.

When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported.

RFC 9116, A File Format to Aid in Security Vulnerability Disclosure, IETF

Edwin Foudil and Yakov Shafranovich published that diagnosis in April 2022. The Commission’s own CRA summary adds that reporting covers products already on the Union market, including those placed there before 11 December 2027, which matches the Article 69(3) carve-out the scan cites.

THE REPORTING CALENDAR

1. April 2022: RFC 9116 defines security.txt as a known-location contact file.
2. 10 December 2024: The Cyber Resilience Act enters into force.
3. 11 June 2026: Chapter IV rules on notifying conformity assessment bodies apply.
4. 11 September 2026: Article 14’s 24-hour, 72-hour and final-report duties apply.
5. 11 December 2027: Annex I’s disclosure policy and contact-address duties apply with the rest of the product rules.

Awareness, not the birth of the flaw, starts the timer. A researcher who cannot find a private channel still creates that awareness when the note reaches a CERT, a journalist, or a customer.

Mail for 374 Vendors Lands on CSIRT Desks

National Computer Security Incident Response Teams already sit in the middle of this traffic. Under NIS2, member states must let people report flaws to a designated CSIRT, which then finds the vendor, helps the reporter, and negotiates disclosure when several parties are hit.

Article 14 now sends manufacturer filings to the same desks. A maker reports once through ENISA’s Single Reporting Platform. The notice goes to the CSIRT of the member state of the maker’s main establishment and, except in rare cases, to ENISA at the same time. That first CSIRT then shares the file with CSIRTs in other states where the product is sold.

ENISA’s August FAQ already tries to spare those teams extra work. Makers should register on the platform when they have a notice to file, it says, so CSIRTs are not asked to validate idle accounts. The same FAQ says CSIRT validation of a company’s representative happens after first access, in parallel with reporting, and should not block a filing.

The scan’s 374 silent vendors do not wait for that form. A researcher who cannot find Contact: still writes a national CSIRT because that is the path NIS2 already advertised. After 11 September the CSIRT may be both the first reader of the bug and the legal inbox for the company’s 24-hour warning.

Open-source stewards sit in a thinner version of the same duty, to the extent they are involved in products with digital elements. Voluntary reports of flaws, threats, incidents and near misses are due to open on the platform after the same date, which gives researchers a third door when the vendor has none.

Germany’s BSI Found the File on 1.8 Percent

Among European SaaS names the 24% hit rate looks poor as a CRA headline. Against the open web it is a high-water mark, and the CSIRT problem is still the 374 domains that sit below it.

On 6 August Germany’s Federal Office for Information Security said only 1.8 percent of German website operators publish the file, in measurements for its Cyberdome project. The agency told operators the effort is small and pointed to the 11 September reporting duties. The 2025 Web Almanac, using HTTP Archive data, put adoption at 1.82 percent of desktop websites and 1.72 percent of mobile sites, up from 1 percent in 2024.

About a quarter of those published files still fail a full RFC check because they omit a valid Expires date. Contact itself is almost universal when a file exists. The gap is getting the file onto the host, then watching the mailbox it names.

What a Researcher Does When Nobody Answers

RFC 9116 defines a machine-parsable vulnerability disclosure format at a single well-known path. The Contact field must always be present and must use a URI, such as mailto:security@example.com or an https form. Encryption keys belong at a URI, not pasted into the file. A policy field can point at the actual disclosure rules, which are a separate document from the doorbell.

A watched file is still a process. A published Contact that nobody reads is a decoy, and that is already how some long vendor chases go: a first note to the listed mailbox, a second from a corporate address, a LinkedIn ping to a CISO, then a national CERT, then a coordinator listing the vendor’s status as unknown months later.

THE USUAL ESCALATION

• First lookup: GET https://domain/.well-known/security.txt and use the Contact URI if it is there.
• Fallback hunt: security@, a /security page, or a bug-bounty form, which the scan does not count.
• Personal chase: a named security lead on LinkedIn when the mailbox is silent.
• Coordinator: a national CSIRT or CERT/CC, which is the NIS2 path and, after 11 September, a likely start of awareness.
• Voluntary SRP: a report of a flaw, threat, incident or near miss through ENISA’s platform once that door opens.

Each extra hop burns calendar time the 24-hour rule does not give back. If a CSIRT notice or a public write-up is the first thing the vendor cannot deny seeing, the early warning is already late, and it is already public.

ENISA Is Still Testing the Reporting Platform

Article 16 told ENISA to build a single electronic entry point so a maker files once. The Commission’s 23 August reporting page says functional and security testing are under way, and that the Single Reporting Platform will be live by 11 September 2026. ENISA’s FAQ, updated 3 August, says the same go-live and that a testing period is expected first.

WHAT WE KNOW

• Go-live: ENISA says the platform is scheduled to be operational by 11 September 2026, the day Article 14 applies.
• Login: company representatives will use an EU Login account; CSIRTs validate who may file for a given maker after first access.
• No API yet: large filers may script their own workflows, but ENISA will not offer application programming interfaces at this stage.
• Help desk: cra-srp-helpdesk@enisa.europa.eu is the contact published for questions the FAQ does not cover.

WHAT IS UNCONFIRMED

• Public URL: ENISA said the dedicated address would be posted on its SRP page before launch; that URL was not on the 3 August FAQ.
• Day-one load: whether CSIRT validation queues stay out of the way when many first filings arrive together is still an operational question.

A delayed-dissemination delegated act from December 2025 lets a CSIRT hold back sharing with other teams on cybersecurity grounds. That is a sharing brake, not a filing brake. ENISA also says the duty does not cover exploited flaws a maker already knew about before 11 September.

Fifteen days remain, and the 374 vendors without a standard inbox are still on the clock the moment a researcher, a customer, or a CSIRT makes them aware. CRA Incident Drill’s published curl loop is one request per domain; it still prints “missing” on three names out of four in that European list.

Frequently Asked Questions

What is a security.txt file?

It is a plain text file at https://example.com/.well-known/security.txt that tells researchers how to report a flaw. RFC 9116 requires a Contact field that uses a URI (mailto, tel, or https) and an Expires date; the 2025 Web Almanac found that about 25 percent of published files still omit a valid expiry and so are not fully valid even when Contact is present.

When do the Cyber Resilience Act’s Article 14 reporting rules start?

They apply from 11 September 2026, 21 months after the Act entered into force on 10 December 2024. Most other CRA duties, including Annex I’s essential cybersecurity requirements, apply from 11 December 2027, and Chapter IV on notifying conformity assessment bodies applied from 11 June 2026.

Does Article 14 apply to products already on the market?

Yes. The Commission’s CRA summary says reporting covers all products with digital elements made available on the Union market, including those placed there before 11 December 2027. ENISA’s FAQ adds that makers do not have to report exploited flaws they already knew about before the reporting rule itself applies.

Who receives an Article 14 notification?

The maker files once through ENISA’s Single Reporting Platform. The notice goes to the CSIRT of the member state of the maker’s main establishment and, except in rare cases, to ENISA at the same time, and that CSIRT then shares it with CSIRTs in other member states where the product is available. A December 2025 delegated act sets when a CSIRT may delay that extra sharing on cybersecurity grounds.

Is a security.txt file required on 11 September 2026?

No. Article 14 requires a report after the maker becomes aware of an actively exploited flaw or a severe incident. The Annex I duties to enforce a coordinated disclosure policy and to provide a contact address apply from 11 December 2027 with the rest of the product rules, so the file is still the lookup path researchers use, not the 11 September legal test.

Disclaimer: This article is news reporting and analysis of a published scan and of public EU and national guidance. It is informational only and is not legal advice, compliance advice, or a determination of whether any company is in or out of scope of the Cyber Resilience Act. Readers who need to design a disclosure policy, a reporting workflow, or a filing under Article 14 should consult a qualified EU product-security or regulatory lawyer, and where relevant their national CSIRT, before acting. Figures, platform status and legal dates reflect the sources as of 27 August 2026 and may change as ENISA’s Single Reporting Platform and Commission guidance are updated.