CVD Policy Template for IoT Manufacturers

[COMPANY NAME] develops and manufactures connected devices and IoT products. We are committed to the security of our products throughout their supported lifecycle and maintain this Coordinated Vulnerability Disclosure (CVD) policy in compliance with the EU Cyber Resilience Act (Regulation (EU) 2024/2847) and ISO/IEC 29147.

Given the nature of embedded and connected devices - including long deployment lifespans, constrained update mechanisms, and physical access considerations - we place particular emphasis on timely firmware updates, clear end-of-support communication, and supply chain vulnerability coordination.

This policy covers all [COMPANY NAME] connected products, including:

• [PRODUCT LINE 1] (model [X], firmware [X.X] and later)
• [PRODUCT LINE 2] (hardware revision [Y], firmware [X.X] and later)
• Associated mobile applications (iOS and Android)
• Associated cloud services and APIs at [DOMAIN]
• OTA (over-the-air) update infrastructure

End-of-life products: Products that have reached end-of-support are excluded from this policy. See our product lifecycle page at [EOL URL]. For products within 12 months of EOL, we will continue to address Critical and High severity vulnerabilities.

Excluded from scope:

• Vulnerabilities requiring physical destruction of the device
• Vulnerabilities in third-party firmware stacks not distributed by [COMPANY NAME]
• Products modified from their factory configuration

Report vulnerabilities in [COMPANY NAME] products via:

Portal (preferred): [VULNERABILITY DISCLOSURE PORTAL URL] Email: [[email protected]] PGP key: Fingerprint [FINGERPRINT], available at [PGP KEY URL]

For hardware-specific or firmware vulnerabilities, please include:

• Device model and hardware revision (printed on device label)
• Firmware version (visible in device settings or [HOW TO FIND IT])
• Network configuration at time of discovery (local network / cloud-connected / air-gapped)
• Whether physical access to the device was required
• Reproduction steps including any tools or equipment needed

For supply chain or component-level vulnerabilities (e.g. a vulnerability in a chipset, RTOS, or third-party library), please include the component name and version if known.

[COMPANY NAME] commits to the following:

| Milestone | Target | |---|---| | Acknowledgment | Within 48 hours | | Initial triage and severity assessment | Within 5 business days | | Firmware update or mitigation plan | Within 30 days for Critical/High | | Status updates to reporter | At least every 30 days | | OTA firmware update release | As soon as practicable | | Security advisory publication | On or after firmware update |

Firmware update delivery: [COMPANY NAME] delivers security updates via OTA (over-the-air) firmware updates. Updates are pushed automatically to all devices running affected firmware versions where auto-update is enabled. For devices with auto-update disabled, customers are notified via [EMAIL / MOBILE APP NOTIFICATION / DASHBOARD].

Devices without OTA capability: For products that do not support OTA updates ([LIST MODELS]), security updates are delivered via [MANUAL DOWNLOAD PROCESS / SERVICE CENTRE PROCEDURE].

[COMPANY NAME] authorises security research conducted in good faith on our products in accordance with this policy. We will not pursue legal action against researchers who:

• Purchase or otherwise legitimately obtain [COMPANY NAME] products for testing
• Limit testing to their own devices or devices for which they have explicit owner permission
• Do not attempt to access other users' devices, cloud accounts, or data
• Do not perform denial-of-service attacks on production infrastructure or other users' devices
• Report findings to us before public disclosure
• Comply with applicable law

Physical hardware modification beyond normal operation (e.g. JTAG, UART, firmware extraction via chip-off) is permitted for research on owned devices, provided you do not use findings to access or harm other users' devices.

IoT products contain significant third-party components: chipsets, real-time operating systems (RTOS), communication stacks, and third-party libraries. [COMPANY NAME] maintains a Software Bill of Materials (SBOM) for its products and monitors component vulnerability feeds.

Where a reported vulnerability originates in an upstream component:

1. We will notify the upstream vendor or maintainer within [5] business days of confirming the vulnerability.
2. We will coordinate disclosure timing with the upstream party.
3. We will report to ENISA if the component vulnerability meets Article 14 thresholds, regardless of upstream remediation status.
4. We will publish our own advisory noting the upstream component CVE and our fix status.

If you discover a vulnerability that you believe originates in a component (e.g. a specific chipset or RTOS), please include the component name, manufacturer, and version in your report.

[COMPANY NAME] provides security support for each product for a minimum of [5] years from the date of last sale in the EU.

Our product end-of-life process:

• 12 months before EOL: We announce EOL status on our website and notify registered owners.
• At EOL: We cease regular software updates. Critical vulnerabilities may still receive patches at our discretion.
• Post-EOL: We publish a final advisory summarising known unpatched vulnerabilities for retired products to allow customers to make informed decisions about replacement.

Current EOL dates for all products are maintained at [EOL SCHEDULE URL].

For legacy products that cannot receive security updates: we recommend [NETWORK SEGMENTATION / REPLACEMENT / COMPENSATING CONTROLS].