Coordinated Vulnerability Disclosure: security.txt, the Cyber Resilience Act, NIS2, and How a Buyer Reads a Provider's Posture

For information; not legal advice.

An identity verification provider holds some of the most sensitive material a company can handle: photographs of identity documents, face images and the personal data read from them. When a researcher finds a weakness in the provider's systems, what happens next decides whether that weakness is fixed quietly, sold, published without warning, or left alone. A buyer cannot see the inside of the provider's security team. A buyer can, however, read what the provider has chosen to say in public about how it receives and handles reports, and can ask for more in writing.

This article explains the vocabulary of coordinated vulnerability disclosure, the small file format that lets an organisation announce its reporting channel, the parts of European law that now touch the subject, and a practical way to read a provider's posture from the outside. It does not rate any provider, and it makes no claim about the disclosure arrangements of the Company that publishes this site. It complements the buyer's guide to evaluating a verification provider's security and privacy, which covers contracts, subprocessors, retention and test evidence, and which does not go into how outsiders report weaknesses.

The vocabulary

The CERT Coordination Center at Carnegie Mellon University describes coordinated vulnerability disclosure as the process of gathering information from vulnerability finders, coordinating the sharing of that information between relevant stakeholders, and disclosing the existence of software vulnerabilities and their mitigations to various stakeholders including the public. Its guide says that vendors play a key role by providing fixes, but that they have no monopoly on the ability to discover vulnerabilities in their products and services, and that knowledge of a vulnerability can increase an adversary's advantage if the people who run the affected systems are left without a way to reduce the risk. The guide names the roles it works with: finders and reporters, vendors, and coordinators. The same three roles appear in the law discussed below, where the coordinator is a national team that acts as an intermediary.

Two international standards describe the vendor side of the process. The International Organization for Standardization and the International Electrotechnical Commission publish them as a pair, and their public abstracts say what each covers. The standard numbered 29147, in its second edition of 2018, provides requirements and recommendations to vendors on the disclosure of vulnerabilities in products and services, including guidelines on receiving reports about potential vulnerabilities and on disclosing remediation information. Its abstract says the goal of vulnerability disclosure is to reduce the risk associated with exploiting vulnerabilities, and that the standard applies to vendors who choose to practise disclosure. The standard numbered 30111, in its second edition of 2019, provides requirements and recommendations for how to process and remediate reported potential vulnerabilities in a product or service, and applies to vendors involved in handling vulnerabilities. One document is about the doorway and the public notice; the other is about the work that happens behind it. This article has read only the public abstracts and the catalogue entries of the two standards, not their full text, and it states no requirement from inside them.

A buyer should keep the two apart. A provider can publish a tidy reporting page and still have a weak handling process, and a provider can handle reports well and say little in public. The public side is the part a buyer can check without the provider's help.

The security.txt file

What RFC 9116 is

RFC 9116 defines a machine-readable text file, called security.txt, that an organisation can publish to describe its vulnerability disclosure practices. It was published in April 2022 as an informational document of the Internet Engineering Task Force, which means it is not an Internet Standards Track specification. Its abstract gives the reason: when researchers discover vulnerabilities, proper reporting channels are often lacking, and as a result vulnerabilities may be left unreported. The file exists to shorten the path from a finder to the right inbox.

Where it lives and what it covers

For web-based services, the file must be placed under the /.well-known/ path, for example at https://example.com/.well-known/security.txt. For legacy compatibility it may also sit at the top-level path or redirect to the well-known location, and if both exist the one under /.well-known/ is the one to use. The file must be served over HTTPS with the content type text/plain and the character set UTF-8. It applies only to the domain or address in the URI used to retrieve it, and not to its subdomains or parent domains. The specification adds that the file may also apply to products and services, and asks organisations to make the scope of their policy clear. That has a practical effect for a buyer: a file on the marketing domain of a provider does not automatically cover the host that serves the API. A buyer who wants to know about the API reads the file on that host, and reads the linked policy for what it says about scope before concluding that the API is in or out.

The fields

All fields are optional unless the specification says otherwise, and researchers must ignore fields they do not support. Two fields must always be present: Contact and Expires.

Field	What it says	Why a buyer cares
`Contact`	A way to reach the organisation about a vulnerability: an email address, a telephone number or a web page; more than one may be listed, the first being the most preferred	Shows that a channel exists and which one the provider prefers
`Expires`	The date after which the data in the file is stale and should not be used; the specification recommends a value less than a year in the future	A past date means nobody has maintained the file
`Policy`	A link to where the vulnerability disclosure policy is located	Leads to the rules a finder is asked to follow
`Encryption`	A key that finders can use to encrypt their report	Shows that confidential reports are expected
`Acknowledgments`	A link to a page that thanks finders	Shows that reports have led to recognition
`Canonical`	The canonical locations of the file	Lets a signature authenticate where the file lives
`Preferred-Languages`	The natural languages the organisation prefers for reports	Matters for a finder who does not write English
`Hiring`	A link to the organisation's security-related job openings	Of little use to a finder; it says only that the organisation recruits for security work

The specification also recommends that the file be digitally signed with an OpenPGP cleartext signature, and says that checking the key behind the signature is always the researcher's responsibility. It warns that retrieval of the file and of the resources it points to may involve redirects, and that researchers should check that those redirects are not malicious.

A minimal file looks like this. The addresses are placeholders and belong to the documentation domain used in the RFC.

Contact: mailto:security@example.com
Expires: 2027-06-30T23:59:59Z
Policy: https://example.com/disclosure-policy.html
Encryption: https://example.com/pgp-key.txt
Canonical: https://example.com/.well-known/security.txt

What the file does not tell you

A security.txt file is a notice of a channel. It does not promise a response time, protection for a finder, a reward, or a fix. It does not say that anyone reads the mailbox. Its absence does not prove that a provider has no process either; many providers take reports only through a private channel for customers or a registered programme. Treat the file as one inexpensive signal in a larger picture, and not as a verdict.

What European law now says

The Cyber Resilience Act

Regulation (EU) 2024/2847, called the Cyber Resilience Act, was adopted on 23 October 2024 and published in the Official Journal on 20 November 2024. It sets horizontal cybersecurity requirements for products with digital elements, defined as software or hardware products together with their remote data processing solutions. Three of its provisions concern disclosure.

Vulnerability handling requirements. Part II of Annex I lists duties that manufacturers must meet. Among them are to put in place and enforce a policy on coordinated vulnerability disclosure, and to take measures to facilitate the sharing of information about potential vulnerabilities, including by providing a contact address for the reporting of vulnerabilities. Another duty is to share and publicly disclose information about fixed vulnerabilities once a security update is available. Annex II requires that a product be accompanied by the single point of contact where vulnerabilities can be reported and where the manufacturer's coordinated vulnerability disclosure policy can be found. A recital adds that manufacturers should also consider publishing their security policies in machine-readable format, which is the use case that RFC 9116 serves, and that bug bounty programmes may be part of a disclosure policy.

Reporting of actively exploited vulnerabilities. Article 14 obliges a manufacturer to notify any actively exploited vulnerability it becomes aware of, and any severe incident affecting the security of the product, to the national team designated as coordinator and to the European Union Agency for Cybersecurity, ENISA, through a single reporting platform. The notification comes in stages, and the stages differ for the two cases. For an actively exploited vulnerability: an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. For a severe incident: an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report within one month after the incident notification. This is a duty to authorities about actively exploited vulnerabilities and about severe incidents that affect, or are capable of affecting, the security of the product, whether or not anyone exploited a weakness on purpose. It is different from the doorway for researchers, and a buyer should not confuse the two.

Voluntary reporting. Article 15 lets manufacturers and other natural or legal persons notify a vulnerability in a product, on a voluntary basis, to the national coordinator or to ENISA, and says that where a person other than the manufacturer notifies an actively exploited vulnerability or a severe incident, the coordinator must inform the manufacturer without undue delay. It also says that voluntary reporting does not impose additional obligations on the person who reports that they would not otherwise have had.

When it applies. The Regulation applies from 11 December 2027, but Article 14 applies from 11 September 2026, and the chapter on the notification of conformity assessment bodies applies from 11 June 2026. As of the date of fetching, 28 October 2026, the reporting duties of Article 14 therefore apply, and the remaining requirements, including those of Annex I, are still some way off. A buyer who reads a provider's disclosure page before December 2027 should not expect it to cite the Regulation as the basis; many will not need to.

Whether it covers a verification service is a legal question. The Regulation is about products. Its recitals say that cloud solutions count as remote data processing solutions only if they meet the definition, and that websites which do not support the functionality of a product, or cloud services designed and developed outside the responsibility of a product manufacturer, fall outside it. They add that the NIS2 Directive applies to cloud computing services such as software as a service. Whether a particular verification offering is a product with digital elements, a service under NIS2, both, or neither depends on facts that this article cannot judge. The reader who needs the answer should ask counsel and should not infer it from the vocabulary of a provider's web page.

The NIS2 Directive

Directive (EU) 2022/2555, the NIS2 Directive, dates from 14 December 2022 and was published in the Official Journal on 27 December 2022. Three provisions matter here.

A coordinator in every Member State. Article 12(1) requires each Member State to designate one of its computer security incident response teams as a coordinator for coordinated vulnerability disclosure. That team acts as a trusted intermediary that facilitates the interaction between the person reporting a vulnerability and the manufacturer or provider, at the request of either party. Its tasks include identifying and contacting the entities concerned, assisting the people who report, and negotiating disclosure timelines and managing vulnerabilities that affect several entities. Member States must ensure that people can report anonymously where they ask for it, and that the team follows up diligently and protects the reporter's anonymity. For a finder who does not trust a provider, or cannot reach it, this is the fall-back route.

A European vulnerability database. Article 12(2) tasks ENISA with developing and maintaining a European vulnerability database, in which entities can disclose and register publicly known vulnerabilities on a voluntary basis. The European Commission announced the launch of the European Vulnerability Database on 13 May 2025. ENISA's own page describes it as aggregating, storing, enriching and publishing known vulnerabilities for public use, drawing on advisories from national response teams and vendors, and says that ENISA has been a CVE Numbering Authority since January 2024. A buyer can look up a provider's products or its main components there, and in the national and vendor sources the database draws on. This article could not open the database itself, whose pages need a browser script, and so it describes the database only from the two sources above.

Vulnerability handling as a security measure. Article 21(2) lists the measures that essential and important entities must include in their risk management, among them supply chain security, including security-related aspects of the relationship with direct suppliers, and security in the acquisition, development and maintenance of systems, including vulnerability handling and disclosure. A customer that falls under NIS2 therefore has its own reason to ask a verification provider how it handles vulnerabilities. Whether the customer falls under the Directive is, again, a legal question.

Reading a provider's posture from outside

What can be checked in an hour

Every item below needs only a browser or a command-line client and the public address of the provider. None of it needs an account, and none of it involves testing the provider's systems. Do not probe a provider's systems to find out whether a policy is real; that is what a policy is there to regulate.

Evidence	Where to look	What a good sign looks like	What it still leaves open
A reporting channel on the right host	The well-known path of the host that serves the API, and of the main domain	A `Contact` that is a monitored mailbox or a web form, and a future `Expires`	Whether anyone answers
A policy page	The `Policy` link, or the footer of the provider's site	States scope, what to include in a report, what the provider will do and in what order	Whether the provider keeps to it
Language on legal treatment of finders	The policy page	Wording that says finders who act in good faith and follow the policy will not be pursued	Whether the wording holds in a dispute; read it as a statement of intent
A stated response practice	The policy page	Stated targets for acknowledgement and for updates	A target is not a record
Recognition of finders	An acknowledgments page or a list in the advisories	Named finders, dated entries	Silence is not a failing, since finders can ask to stay unnamed
Public advisories	The provider's security pages, or the databases that collect advisories	Advisories for its own products, with fixed versions and descriptions	A provider with no public advisories may have had none, or may not publish them
Identifier assignment	Whether the provider assigns identifiers for its own vulnerabilities, or has them assigned for it	A route to identifiers exists	A provider without products that others install may never need one
Contract language	The agreement and its security annex	A duty to tell the customer about vulnerabilities that affect its data, and to say how fast	Cannot be read from outside; ask for it

Questions for the provider

Put these in writing. The wording of the answer, and what the provider declines to answer, say as much as the content.

Where do outside researchers report a vulnerability in your service, and who reads that channel?
Is there a published policy, and which of your hosts and products does it cover?
What do you acknowledge within what time, and how often do you update a finder?
How do you decide when to disclose publicly, and who decides?
Do you accept reports through your national coordinating team when a finder asks for an intermediary?
How do you tell customers about a vulnerability in the service that could affect their data, and in what form and time?
How do you handle a vulnerability in a component you did not write, such as a library or a hosting layer?
Which standards or frameworks does your handling process follow, and can we see the part that applies to us under a confidentiality agreement?
Have you taken part in an independent test of the service, and will you share the scope and the status of the findings?
If a finder reports a flaw that exposes personal data, who is told, and in what order?

The last question joins this article to the one on incident notification deadlines, because a vulnerability that has been exploited against personal data is also a data breach with its own deadlines.

Weak signals and what they mean

A few patterns are worth noticing, with the caution that none of them is conclusive.

A reporting address that bounces, or a file whose Expires date is long past, means the notice is stale.
A policy that forbids all disclosure without conditions, and gives the finder no route, may push finders towards the national coordinating team, or towards publishing, because nothing else is on offer.
A page that lists a channel but no scope leaves a finder guessing which of the provider's hosts are covered.
An answer that points to a general-purpose security mailbox shared with sales or support suggests that reports may sit in a queue with other mail.
A refusal to say anything about handling, citing confidentiality, is a reason to ask for the process under a confidentiality agreement and not by itself a reason to leave.

What not to conclude

The absence of public reports is not evidence of good security. A provider that nobody has examined has no reports. A long list of acknowledged finders is not evidence of poor security; it may show that many people looked and that the provider answered. Counts of reports, bounties paid or advisories published do not compare across providers, since no common definition exists in the sources used here. This article gives no benchmark number for any of them.

For the engineer: publishing your own file

If you run a service and want to publish a reporting channel, the steps are short.

Choose a mailbox or a form that a person monitors, and name an owner for it.
Write the policy page: scope, what a report should contain, what you will do, and how you treat finders who follow the policy.
Publish the file under the well-known path on every host in scope, over HTTPS, as plain text.
Set Expires to a date less than a year ahead, and put the renewal in a calendar.
Consider signing the file and listing its canonical location, as the specification recommends.
Test the channel from outside by sending a report to yourself and measuring how long it takes to reach a person.
Decide in advance how a report turns into a fix, a notice to customers and, where the law requires it, a notice to an authority.

Where this sits in a verification flow

An integration with a verification provider puts the provider's systems between your users and your decision, and it puts images of identity documents and faces into the provider's care. How that provider hears about weaknesses is therefore part of your supplier review, alongside the contract, the subprocessors and the evidence of testing. Use the questions above with any provider you evaluate, including NeuroVision, and send yours through the contact page so that the answers come back in writing.

Sources

All sources were fetched on 28 October 2026.

RFC 9116, A File Format to Aid in Security Vulnerability Disclosure, Internet Engineering Task Force, April 2022, published through the RFC Editor.
Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 (Cyber Resilience Act), Official Journal of the European Union, 20 November 2024, via the Publications Office.
Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 (NIS2 Directive), Official Journal of the European Union, 27 December 2022, via the Publications Office.
Information technology, Security techniques, Vulnerability disclosure (edition 2, 2018), catalogue entry and abstract, International Organization for Standardization.
Information technology, Security techniques, Vulnerability handling processes (edition 2, 2019), catalogue entry and abstract, International Organization for Standardization.
EU launches a European vulnerability database to boost its digital security, European Commission press release, 13 May 2025.
Vulnerability Services, European Union Agency for Cybersecurity.
The CERT Guide to Coordinated Vulnerability Disclosure, CERT Coordination Center, Software Engineering Institute, Carnegie Mellon University.