I found a vulnerability in a finished product that uses your module inside it. Who should I report to?

If you identified a vulnerability that appears to be in the [COMPANY NAME] component (firmware, SDK, or protocol stack), please report to us at [PORTAL URL]. We will coordinate with our downstream OEM customer. If the vulnerability appears to be in the OEM customer's own integration code or product design, you should report primarily to that manufacturer. You can also report to both simultaneously — we will coordinate with each other.

How many OEM customers might be affected when you disclose a vulnerability?

We do not publicly disclose the number of OEM customers or which customer products use our components, as this is commercially sensitive and could help attackers target specific products. When we publish a security advisory, we include sufficient technical detail for OEM customers' engineering teams to assess their own exposure using the component and firmware version information.

Do your OEM customers have their own CRA obligations?

Yes. OEM customers who integrate our components into finished products that they place on the EU market are themselves manufacturers of products with digital elements and have their own independent CRA obligations — including their own CVD policy requirements under Article 13 and Article 14 notification obligations. Our obligations as a component supplier are in addition to, not instead of, their obligations as the finished product manufacturer.

What happens if your OEM customer does not apply a Critical patch?

We will escalate to that customer's executive security contact. We will not delay public advisory publication to accommodate a downstream customer's patch schedule. If a Critical vulnerability is publicly disclosed and an OEM customer has not patched their finished product, that is a compliance failure for that customer, not a reason to keep the vulnerability secret from the security community and end users.

Can you keep the vulnerability confidential permanently because it is in a component integrated into a certified product?

No. We will not agree to indefinite embargo of vulnerability information regardless of downstream certification requirements. If an OEM customer's product requires recertification before a patch can be deployed, that is a constraint on the customer's patch deployment timeline — not a reason to suppress the vulnerability disclosure indefinitely. We will publish an advisory within 90 days of the original report, with interim mitigation guidance.

← All templates

Free Template

OEM Manufacturer CVD Policy Template

A CVD policy template for OEM suppliers who face a two-sided challenge: receiving vulnerability reports from researchers AND notifying downstream OEM customers who integrate their components. Addresses CRA Article 13 obligations for the OEM role in the supply chain and downstream customer notification processes.

Article 13 · Article 14 · Article 17 · Article 18

ForOEM manufacturers who supply hardware or software components to other manufacturers (system integrators, white-label customers) and need to handle both inbound researcher reports and outbound notification to their downstream customers

CRA Articles

Article 13Article 14Article 17Article 18

Policy Statement & OEM Context

Article 13, Article 17, Article 18

[COMPANY NAME] designs and manufactures [DESCRIPTION OF PRODUCTS, e.g. embedded computing modules, wireless communication modules, hardware security modules, industrial communication components] that are supplied to other manufacturers (system integrators and OEM customers) for integration into their finished products.

This Coordinated Vulnerability Disclosure (CVD) Policy reflects our unique position as an OEM supplier: we receive vulnerability reports from security researchers about our components, and we have an obligation to notify our downstream OEM customers who have integrated those components into their own products.

This policy is published in compliance with Article 13 of the EU Cyber Resilience Act (Regulation (EU) 2024/2847). As a supplier of components to downstream manufacturers, [COMPANY NAME] operates in the supply chain role described in CRA Articles 17 and 18, which place obligations on both us and our downstream customers regarding vulnerability notification and handling.

[COMPANY NAME] commits to:

Operating a public CVD programme to receive and respond to inbound researcher reports
Notifying downstream OEM customers of confirmed vulnerabilities in components we supply to them
Coordinating disclosure timelines with both researchers and downstream customers
Meeting Article 14 notification obligations where applicable

Note

Explicitly acknowledging the two-sided OEM role — both receiving reports and notifying downstream customers — demonstrates supply chain awareness to both researchers and regulators. The CRA Articles 17 and 18 references signal that you have read the supply chain provisions and are not just treating the CVD policy as a researcher-facing document.

Scope (Components Supplied to Downstream Integrators)

Article 13(4), Article 17

This policy covers the following [COMPANY NAME] components and software:

| Component | Type | Supplied To | Supported Versions | |-----------|------|-------------|--------------------| | [COMPONENT 1] | [Hardware module / Firmware / SDK] | [OEM customers] | [Version X.x and later] | | [COMPONENT 2] | [Communication module] | [System integrators] | [Firmware 2.x and later] | | [SDK / LIBRARY 1] | [Software library] | [OEM software customers] | [Version 3.x and later] | | [REFERENCE DESIGN 1] | [Hardware reference design + firmware] | [ODM customers] | [All supported revisions] |

Downstream integration contexts in scope: This policy applies regardless of what finished product our component is integrated into by an OEM customer.

Not covered by this policy:

Custom-developed firmware or software created specifically for a single OEM customer (covered by that customer's bilateral security agreement)
End products manufactured by OEM customers — vulnerabilities in the OEM customer's product as a whole should be reported to that manufacturer
Components at end-of-life (see [SUPPORT PAGE URL])
Vulnerabilities introduced by OEM customer modifications to our components

Note

The distinction between vulnerabilities in your component and vulnerabilities introduced by OEM customer modifications is legally and practically important. Making it explicit in the scope section prevents researchers from incorrectly routing reports to you for issues that are downstream customers' responsibility.

Reporting Channel

Article 13(1)

To report a security vulnerability in any [COMPANY NAME] component or software, please use:

Preferred: Submit via our vulnerability disclosure portal: [PORTAL URL]

Email: [[email protected]] PGP encryption: Key fingerprint [FINGERPRINT] | Available at [KEY URL]

security.txt: https://[YOUR-DOMAIN]/.well-known/security.txt

Please include in your report:

The affected [COMPANY NAME] component name, part number, and firmware/software version
Whether you encountered this vulnerability in a [COMPANY NAME] reference design or in a finished product from an OEM customer
A description of the vulnerability and its potential impact
Steps to reproduce
Whether you believe downstream OEM customer products may be affected

If you encountered this vulnerability in a finished product (i.e. a product manufactured by a company other than [COMPANY NAME] that uses our component internally): please also report directly to that manufacturer. We will coordinate with them, but they may have independent obligations to their customers and regulators.

We accept reports in [LANGUAGE(S)] and treat all reports as confidential.

Note

Guiding researchers to also report to the downstream OEM if they found the issue in a finished product is good coordination practice. It prevents situations where a researcher reports to you, you notify the OEM, but the researcher assumes silence means no action is being taken.

Triage & Severity Assessment

Article 13, Article 17

[COMPANY NAME] acknowledges all vulnerability reports within 48 hours of receipt and performs initial triage within 5 business days.

Triage includes:

Confirming the vulnerability exists in [COMPANY NAME] component code (not OEM customer additions)
Identifying all affected component versions and variants
Assessing CVSS 4.0 severity
Estimating downstream exposure — identifying which OEM customer product lines integrate the affected component version

OEM downstream exposure assessment:

For each confirmed vulnerability, we assess:

Number of OEM customers who have integrated the affected component version
Estimated number of end-user products in the field that contain the affected component
Whether the OEM customer's product integration or configuration mitigates or exacerbates the vulnerability
Whether any affected OEM customer products are deployed in regulated sectors (critical infrastructure, healthcare, etc.)

This exposure assessment determines the priority and process for downstream customer notification (see Section 5).

Response timeline commitments:

| Severity | Acknowledgment | Triage | Patch Target | |----------|---------------|--------|--------------| | Critical | 48 hours | 1 business day | [15] calendar days | | High | 48 hours | 3 business days | [30] calendar days | | Medium | 48 hours | 5 business days | [60] calendar days | | Low | 48 hours | 10 business days | [90] calendar days |

Note

The downstream exposure assessment is what makes OEM vulnerability management genuinely difficult — you may have hundreds of OEM customers integrating your component, each of whom has deployed it into different products with different risk profiles. Documenting that you perform this assessment demonstrates supply chain responsibility.

Downstream Customer Notification Process

Article 17, Article 18

Upon confirming a vulnerability of Medium severity or above, [COMPANY NAME] will notify affected downstream OEM customers according to the following process:

Notification timeline:

| Severity | Downstream Customer Notification | |----------|-----------------------------------| | Critical | Within [2] business days of confirmation | | High | Within [5] business days of confirmation | | Medium | Within [10] business days of confirmation | | Low | Included in next regular security bulletin |

Notification contents:

Each downstream customer notification includes:

[COMPANY NAME] component name and affected version(s)
Vulnerability description (technical, at a level appropriate for their engineering team)
CVSS base score and severity rating
Affected hardware and firmware/software configurations
Patch version or workaround
Estimated public disclosure date
Instructions for customers to assess their own product exposure
Contact for questions: [PSIRT EMAIL]

Customer NDA and embargo:

Downstream customer notifications are issued under mutual NDA and embargo until public disclosure. OEM customers must not publish information about the vulnerability before [COMPANY NAME]'s coordinated public disclosure date, which is coordinated with both the original reporter and affected customers.

Customer failure to apply patch:

If an OEM customer has not applied a patch within [30] days of availability for a Critical vulnerability, [COMPANY NAME] will escalate to that customer's executive security contact. We will not delay public disclosure to accommodate a customer's patch schedule.

Note

The downstream notification timeline and contents transform the OEM's supply chain responsibility from a vague obligation into a concrete operational commitment. The prohibition on delaying public disclosure for a slow-moving downstream customer is essential — otherwise a single large OEM customer can hold your entire disclosure process hostage.

Embargo & Coordinated Disclosure with Customers

Article 13, Article 17

Embargo management

[COMPANY NAME] manages a multi-party coordinated disclosure process that involves:

The original security researcher (if externally reported)
Downstream OEM customers who integrate the affected component
[COMPANY NAME]'s own PSIRT and engineering teams

Disclosure timeline:

Day 0: Vulnerability report received
Day 2: Internal triage complete; downstream customers notified (Critical) or notification scheduled
Day [X]: Patch available to downstream customers
Day [X+5]: Public security advisory published (or 90 days from Day 0, whichever is earlier for standard cases)

Embargo conditions:

OEM customers who receive advance notification are bound by the following embargo conditions:

Do not disclose vulnerability details to third parties outside your security team without [COMPANY NAME]'s consent
You may disclose to your own customers that a security update is pending, without disclosing technical details
You may disclose to your own regulators under confidentiality if legally required

Early disclosure by a downstream customer:

If an OEM customer publishes vulnerability information before the coordinated disclosure date, [COMPANY NAME] will accelerate public advisory publication to prevent a situation where partial information is in the public domain without [COMPANY NAME]'s complete advisory.

Reporter timeline rights:

[COMPANY NAME] will not use downstream customer coordination as justification to extend the coordinated disclosure timeline beyond 90 days from the original report date without the original reporter's explicit consent.

Note

Multi-party coordinated disclosure is significantly harder than bilateral disclosure. The OEM role adds a third party (downstream customers) to every disclosure. Setting firm rules about embargo conditions and the consequences of early disclosure by customers gives your PSIRT clear authority to manage the process.

Article 14 Reporting

Article 14, Article 17

Where a confirmed vulnerability in [COMPANY NAME] components meets the Article 14 threshold — actively exploited or constituting a severe security incident — [COMPANY NAME] will:

Submit an early warning to ENISA within 24 hours of becoming aware
Submit a full notification to ENISA within 72 hours
Submit a final report within 14 days

For OEM components, Article 14 thresholds are particularly relevant where:

The vulnerability is actively exploited across multiple OEM customer products simultaneously
The vulnerability is exploited in products deployed in critical infrastructure (even if [COMPANY NAME] is not the end product manufacturer)
The vulnerability enables supply chain-level attacks affecting a large number of downstream products

Coordinating Article 14 with downstream customers:

Where [COMPANY NAME] files an Article 14 notification regarding a component vulnerability, we will:

Notify affected downstream OEM customers of the notification before it is filed (where the 24-hour timeline permits)
Share a summary of the notification with affected customers to enable them to assess their own Article 14 or NIS2 obligations
Coordinate the public disclosure timeline with the Article 14 notification process

Downstream OEM customers who are themselves manufacturers of products with digital elements may have independent Article 14 obligations regarding the vulnerability in their finished products.

Note

OEM manufacturers face the most complex Article 14 scenario: a single component vulnerability may trigger Article 14 obligations simultaneously for both the OEM supplier (for the component) and multiple downstream manufacturers (for their finished products). Documenting your coordination process for this scenario demonstrates regulatory maturity.

Safe Harbour

[COMPANY NAME] authorises good-faith security research on [COMPANY NAME] components and reference designs conducted in accordance with this policy.

We will not take legal action against researchers who:

Follow this policy
Use components or systems they own or have explicit permission to test
Limit testing to what is strictly necessary to confirm the vulnerability
Report to us before any public or third-party disclosure

OEM customer products: Security research conducted on finished products manufactured by [COMPANY NAME]'s OEM customers is subject to those customers' own CVD policies, not this policy. [COMPANY NAME] cannot extend safe harbour protections to research conducted on OEM customer products.

Component availability for research:

[COMPANY NAME] makes [COMPONENT EVALUATION KITS / DEVELOPMENT MODULES] available for purchase through [DISTRIBUTION CHANNEL]. Security researchers may use these evaluation kits for research under this policy's safe harbour without needing special permission from [COMPANY NAME].

Note

The safe harbour boundary for OEM component research is important: you can only grant safe harbour for research on your own components, not on your customers' finished products. Making this explicit prevents researchers from relying on your safe harbour for research that requires the downstream customer's permission.

Use this template automatically in CVD Portal

CVD Portal generates your CVD policy, tracks acknowledgments, and creates an audit trail — free, forever.

Set up your free portal

Frequently asked questions

Ready to go beyond the template?

CVD Portal automates acknowledgments, tracks deadlines, and generates CSAF advisories — free.

Set up your free portal

Related templates

CRA-Compliant CVD Policy Template

A comprehensive CVD policy structured specifically for the EU Cyber Resilience Act. Addresses Articles 13 and 14 obligations including 24-hour early warning, 72-hour full notification, and coordinated disclosure timelines.

Contract Manufacturer CVD Policy Template

A CVD policy template for contract manufacturers and ODMs who manufacture products under brand owners' instructions. Addresses the CRA obligation question (brand owner vs. contract manufacturer), how to route inbound researcher reports to the correct party, and contractual obligations with brand owner customers.

Article 14 Early Warning Notification Template

A structured notification template for the CRA Article 14 24-hour early warning obligation. Designed to be submitted to ENISA (or the relevant national CSIRT) when a manufacturer discovers an actively exploited vulnerability or severe security incident.

Coordinated Disclosure Policy Template

A vendor-neutral CVD policy based on ISO/IEC 29147 and ENISA good practice, suitable for manufacturers who want to align with international standards rather than a purely CRA-framed document. Covers the full coordinated disclosure lifecycle from report intake through advisory publication and supply chain coordination.