Security vulnerabilities can never be completely avoided. This applies to web applications as well as to connected devices, APIs, cloud services, IoT platforms, and gateways. Therefore, what matters is not only how securely systems are developed, but also how a company responds when a vulnerability is discovered. This is precisely where a professional CVD process comes into play.
Coordinated Vulnerability Disclosure (CVD) refers to the systematic and coordinated handling of reported security vulnerabilities. For a company, this means providing a transparent channel through which external discoverers can report vulnerabilities. Internally, predefined processes are then followed to review, prioritize, and resolve these reports, and to communicate the results accordingly.
CVD plays a pivotal role, particularly in IoT security. Since vulnerabilities in this area are usually not limited to a single application, they often affect complex ecosystems: devices in use, interfaces, backend systems, portals, and third-party integrations. A reliable, structured approach to addressing such vulnerabilities is therefore the foundation of any modern security organization.
What a CVD Process Can Do
A CVD process ensures that a reported vulnerability does not get lost somewhere within the company but is handled in a structured manner. Ideally, a person who discovers the problem reports it confidentially to the affected company via a transparent but secure channel. There, the report is reviewed, technically classified, and prioritized. This is followed by assessment, remediation, and—if appropriate—a coordinated disclosure.
Above all, coordination between the person reporting the issue and the company is crucial. This is not about uncontrolled disclosure, but rather a regulated exchange of information. That is precisely the essence of Coordinated Vulnerability Disclosure in IoT and other digital product environments.
Those who wish to follow established standards will find in ISO/IEC 29147 and ISO/IEC 30111 a proven framework. ISO/IEC 29147 describes how vulnerability reports from external sources should be received and communicated. ISO/IEC 30111 covers the internal aspects—namely, assessment, prioritization, remediation, and follow-up. For the German market, the BSI provides additional practical guidance on professional vulnerability management.
Why Companies Need a Clear Process
Many organizations are already investing in technical security measures such as hardening, monitoring, access controls, segmentation, and penetration testing. This makes sense—but it still doesn’t answer the organizational question: What exactly happens when third parties report security vulnerabilities?
This is exactly where problems often arise in practice. A report ends up in general support, is treated as a standard ticket, or never reaches the right people. The person who submitted the report receives no response. Internally, it’s unclear who is responsible. And valuable time is lost.
A well-functioning CVD process prevents exactly that. It ensures that reports are received at the right place, evaluated by experts, and processed in a structured manner. Companies that handle security vulnerabilities professionally not only reduce risks—they also build trust among customers, partners, and the security community.
Why the CVD Process Is Especially Important in the IoT Sector
Vulnerabilities are often particularly critical in IoT security. A problem is rarely limited to a single component. For example, if device access is inadequately secured, an API has weaknesses, or the update function is vulnerable, this can have repercussions for the entire system architecture.
In addition, many IoT solutions run in production environments for years. A vulnerability is therefore not just an IT issue; it can also affect availability, data security, operational processes, or—in extreme cases—physical processes.
The Standard ETSI EN 303 645 addresses precisely this area. It explicitly requires manufacturers of connected devices to have a vulnerability disclosure policy —that is, a publicly communicated process through which vulnerabilities can be reported. ETSI EN 303 645 Vulnerability Disclosure is therefore already a concrete benchmark for IoT products on the European market.
Added to this is the growing regulatory pressure stemming from the Cyber Resilience Act, which will place greater responsibility on manufacturers of products with digital components to systematically manage and report vulnerabilities in the future. For IoT companies, establishing a CVD process is no longer an optional measure, but rather a concrete component of regulatory and operational security.
What the vulnerability reporting process looks like in practice
It all starts with a clear reporting process. Anyone who discovers a vulnerability must be able to immediately identify where and how to report it.
The security.txt file has proven effective in this context—a standardized file that companies make available at /.well-known/security.txt. RFC 9116 defines this standard and specifies which fields a security.txt file should contain: among other things, a security contact, a link to the disclosure policy, and optional information about PGP keys and expiration dates. Anyone wishing to set up a security.txt file will find the authoritative technical basis in RFC 9116.
Example of a security.txt file:
When a report is received, the speed of response is crucial. An acknowledgment of receipt should be sent within 24 to 48 hours. This does not require a final assessment—in many cases, a brief acknowledgment, the name of a contact person, and a general outline of the next steps are sufficient.
Then the actual assessment begins: Is the report plausible? Which systems or products are affected? How high is the risk? For the risk assessment, the Common Vulnerability Scoring System (CVSS) has become the standard; it is maintained by FIRST and enables a standardized assessment of severity.
This is followed by prioritization and remediation. Not every vulnerability is automatically critical, but each report should be evaluated in a transparent manner. As a rough guideline, remediation often takes up to 90 days—significantly less for critical vulnerabilities.
Once a vulnerability has been fixed, a coordinated release may be advisable. The CVE program is available for this purpose. A CVE entry provides a unique, publicly referenceable identifier for a vulnerability and facilitates communication with customers, partners, and the security community.
What a Good Vulnerability Disclosure Policy Should Include
An effective CVD process requires not only internal procedures but also clear external communication. This includes a vulnerability disclosure policy. Anyone wishing to create a vulnerability disclosure policy should include at least the following in it:
how external parties can report security vulnerabilities,
what information is helpful to include in a report,
how the company handles incoming reports,
what response times are targeted,
and under what conditions a coordinated release takes place.
ISO/IEC 29147 provides specific guidance on how such a policy should be structured and what communication processes between companies and reporters are appropriate. A good vulnerability disclosure policy creates reliability for both sides.
This is technically supplemented by an accessible security.txt file in accordance with RFC 9116 — ideally with a dedicated security contact such as security@unternehmen.de and a PGP key for confidential communication.
Why Safe Harbor Is Part of It
One point that many companies underestimate: A CVD process only works well if external parties are willing to report vulnerabilities responsibly in the first place.
That is often the crux of the problem. Security researchers are frequently unsure whether a report could be interpreted against them legally at a later date. Without a clear assurance from the company, a risk remains—which leads many to refrain from reporting or to opt for public disclosure instead.
That is why a Safe Harbor vulnerability reporting clause in the disclosure policy is useful. It makes it clear that the company will not take legal action against individuals who act in good faith and adhere to the established rules. This typically includes reporting vulnerabilities confidentially, not misusing any data, and not conducting destructive testing.
Such a clause is not a free pass—but it significantly lowers the barrier to responsible reporting and makes reporting vulnerabilities more reliable and secure for external parties.
Bug Bounty vs. CVD: What's the Difference?
Anyone who looks into this topic will often come across both terms. The difference between a bug bounty and a CVD is actually clearer than it seems at first glance.
A CVD process describes the structured organizational framework through which external individuals can report security vulnerabilities and companies can address them professionally—without necessarily providing financial compensation.
A bug bounty program goes a step further: It offers financial rewards for reporting vulnerabilities, is often organized through specialized platforms, and has clearly defined scope rules.
For many companies, it makes sense to first set up an internal CVD process and establish a clear vulnerability disclosure policy. Only then does the question arise as to whether a bug bounty program is appropriate and organizationally feasible. In many cases, a well-implemented CVD process is entirely sufficient to start with, especially for SMEs.
Is a CVD process only for large companies?
No. A CVD process is actually particularly valuable for SMEs. Since these companies often lack the resources to hire specialists, clear guidelines help them address security vulnerabilities in a structured manner, even when staff are pressed for time.
Even smaller providers are now part of complex digital value chains. They operate customer portals, cloud services, device management systems, and interfaces with partners. Consequently, a vulnerability in these areas can also have far-reaching consequences. Companies that establish a CVD process early on strengthen their responsiveness, professionalism, and future viability.
CVD as Part of Modern Security Management
A CVD process is more than just a guideline on a website. It demonstrates how professionally a company handles vulnerabilities. No one expects absolute perfection. What matters is whether reports are systematically recorded, assessed, prioritized, and resolved.
As part of its vulnerability management approach, the BSI recommends exactly that: clear processes for receiving, assessing, and addressing vulnerability reports. Combined with standards such as ISO/IEC 29147, ISO/IEC 30111, ETSI EN 303 645 and technical guidelines such as RFC 9116 , this provides a solid framework that organizations of all sizes can implement.
Anyone who wants to handle security vulnerabilities professionally therefore needs:
a clearly visible safety contact,
a clear vulnerability disclosure policy,
a publicly accessible security.txt file in accordance with RFC 9116,
defined internal responsibilities,
a transparent risk assessment based on CVSS,
and a clear policy on coordinated publication through the CVE program.
Conclusion
A professional CVD process helps companies report, assess, and remediate security vulnerabilities in a structured manner and communicate them in a controlled way. Instead of relying on chance, improvisation, or informal channels, a Coordinated Vulnerability Disclosure (CVD) process establishes a transparent framework for the secure handling of security vulnerabilities.
Especially in the field of IoT security, this is now an essential component of professional security organizations—not only because of the technical complexity, but also because of growing regulatory requirements such as ETSI EN 303 645 and the Cyber Resilience Act.
Anyone who wants to establish a CVD process within their company and develop an appropriate vulnerability disclosure policy will not only improve their own responsiveness. They will also strengthen compliance, trust, and the long-term sustainability of their security organization.
