IoT Product CVD Policy Template

[COMPANY NAME] designs and manufactures [DESCRIPTION OF IoT PRODUCTS, e.g. smart home devices, connected sensors, wearable health monitors]. Our products are typically deployed in environments where users have limited visibility into software updates and where devices may remain in use for many years.

We take security vulnerabilities in our products seriously. This Coordinated Vulnerability Disclosure (CVD) Policy governs how we receive, assess, and respond to reports of security vulnerabilities across our IoT product portfolio.

This policy is published in accordance with Article 13 of the EU Cyber Resilience Act (Regulation (EU) 2024/2847) and reflects our commitment to ISO/IEC 29147.

Given the nature of IoT deployments — including constrained devices, OTA update dependencies, and diverse deployment environments — our response timelines and remediation approaches may differ from those applied to conventional software. We explain these differences openly in this policy.

This policy covers the following [COMPANY NAME] products and associated firmware versions:

| Product Name | Model Numbers | Supported Firmware | End of Support | |--------------|---------------|--------------------|-----------------| | [PRODUCT 1] | [MODEL A, B] | [Firmware 2.x and later] | [DATE] | | [PRODUCT 2] | [MODEL C] | [Firmware 1.5 and later] | [DATE] | | [PRODUCT 3] | [MODEL D, E, F] | [All active firmware] | [DATE] |

Associated cloud services and mobile applications:

• [APP NAME] for iOS and Android (all versions on actively supported OS versions)
• Cloud API at [API ENDPOINT]

Products not covered by this policy:

• Products at end-of-support (see [SUPPORT PAGE URL])
• Products manufactured by third parties sold under our brand without modification
• Vulnerabilities requiring physical hardware modification

For products approaching end-of-support, we publish a security support timeline at [LIFECYCLE URL]. We encourage owners of end-of-support devices to upgrade to a supported model.

To report a security vulnerability in any [COMPANY NAME] product, please use:

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

Email: [[email protected]] PGP encryption available — key fingerprint: [FINGERPRINT] Key available at: [KEY URL]

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

Please include in your report:

• The affected product name, model number, and firmware version
• A description of the vulnerability and its potential impact
• Steps to reproduce (including device configuration if relevant)
• Whether the vulnerability requires local network access or is remotely exploitable
• Whether a companion app or cloud service is involved
• Your contact information (optional — anonymous reports accepted)

We accept reports in [LANGUAGE(S)] and treat all reports as confidential. Please do not disclose vulnerability details publicly before coordinating with us.

[COMPANY NAME] applies standard CVSS 4.0 severity scoring to all reported vulnerabilities. For IoT products, we additionally assess the following factors that may affect priority and response approach:

OTA Update Feasibility

• Can the affected firmware be updated over-the-air (OTA) without user intervention?
• If OTA is not available, what is the update mechanism and what user action is required?
• Devices that cannot receive OTA updates require additional consideration — see the Firmware Update & Patching Process section.

Fleet Impact

• Estimated number of devices in the field running the affected firmware version
• Geographic distribution of the fleet (EU, North America, other)
• Whether vulnerable devices are concentrated in specific deployment types (e.g. industrial, healthcare, home)

Exploitation Difficulty in Real Deployments

• Does exploitation require the attacker to be on the same local network?
• Is the vulnerability exploitable from the internet?
• Does the companion app or cloud backend need to be involved?

Safety and Privacy Impact

• Could exploitation of this vulnerability cause physical harm to users?
• Does the vulnerability expose personal data (location, health, behavioural data)?
• Could the device be used as a pivot point into a broader home or enterprise network?

Our triage outcome and priority band will reflect all of these factors in addition to the CVSS base score.

[COMPANY NAME] commits to the following response milestones:

| Milestone | Commitment | |-----------|------------| | Acknowledgment | Within 48 hours of receipt | | Initial triage outcome | Within [5] business days | | Severity assessment shared with reporter | Within [10] business days | | Status update if no patch available | Every [30] days | | Patch or documented workaround | See target remediation times below | | Security advisory | Published upon or after patch availability |

Target Remediation Times (IoT-adjusted):

| Severity | Target (OTA-capable devices) | Target (non-OTA devices) | |----------|------------------------------|---------------------------| | Critical | [30] calendar days | [45] calendar days | | High | [60] calendar days | [90] calendar days | | Medium | [90] calendar days | [120] calendar days | | Low | [180] calendar days | Best effort |

IoT remediation timelines are longer than web software timelines due to the complexity of firmware build, test, and release processes. We will not use this as a justification for indefinite delays.

[COMPANY NAME] delivers security patches via the following mechanisms depending on product type:

OTA-capable products

For products with automatic OTA update capability, security patches are delivered automatically within [X] days of release. Users can verify their firmware version in [APP / DEVICE INTERFACE]. Critical security patches may be pushed with minimal advance notice to minimise exposure windows.

Products requiring manual update

For products that require manual firmware update:

1. We publish the firmware update at [DOWNLOAD URL]
2. We notify registered owners via [EMAIL / APP PUSH NOTIFICATION]
3. Update instructions are published at [SUPPORT URL]
4. For Critical vulnerabilities, we will contact major resellers and distribution partners to assist with customer notification

Workarounds for unpatched vulnerabilities

Where a patch is not yet available, [COMPANY NAME] will publish interim workarounds at [SECURITY ADVISORY URL] where technically feasible. Workarounds may include:

• Network segmentation or firewall recommendations
• Disabling affected features via the companion app or admin interface
• Configuration changes to reduce attack surface

Partial patch limitations

In some cases, a vulnerability may be inherent in hardware or a deeply integrated third-party component and cannot be fully remediated. In these cases, [COMPANY NAME] will clearly document the residual risk and available mitigations, and will factor the limitation into the product's end-of-life timeline if necessary.

[COMPANY NAME] maintains a product security support timeline at [SUPPORT PAGE URL].

Minimum security support period: [COMPANY NAME] commits to providing security patches for a minimum of [5] years from the date of last sale of each product model, in accordance with our CRA obligations.

End-of-support notification: We will notify customers and publish a public notice at least [12] months before the security support end date for each product.

Post-support vulnerability handling:

For products that have reached end of security support:

• [COMPANY NAME] will not issue security patches
• [COMPANY NAME] will publish a notification informing users of the security support end and recommending upgrade or device isolation
• We will still accept vulnerability reports for end-of-support products and will publish informational advisories where a significant vulnerability is reported, even without a patch
• We will indicate on the product support page whether any critical unpatched vulnerabilities are known

Legacy device isolation guidance: For end-of-support devices that cannot be replaced, we recommend: [ISOLATION GUIDANCE, e.g. placing on a dedicated VLAN, disabling internet connectivity, disabling remote access features].

Where a reported vulnerability affecting [COMPANY NAME] IoT products meets the Article 14 threshold — that is, it is actively exploited in the wild, or constitutes a severe security incident — [COMPANY NAME] will:

1. Submit an early warning to ENISA within 24 hours of becoming aware
2. Submit a full notification to ENISA within 72 hours including severity assessment and initial remediation actions
3. Submit a final report within 14 days including root cause analysis and mitigation measures

For IoT products, Article 14 notification is particularly relevant where:

• A vulnerability enables mass exploitation of a large device fleet
• A vulnerability enables attacker access to user home networks at scale
• A vulnerability in a safety-related function (e.g. door lock, alarm system) is actively exploited
• A vulnerability exposes sensitive personal data (health, location, behavioural data) for a significant number of users

Notifications are made to the ENISA Single Reporting Platform (SRP) or the relevant national CSIRT.

[COMPANY NAME] authorises good-faith security research on [COMPANY NAME] IoT products conducted in accordance with this policy.

We will not take legal action against researchers who:

• Follow this policy
• Use only devices they own or have explicit permission to test
• Limit testing to what is strictly necessary to confirm the vulnerability
• Do not access, intercept, or modify data from other users' devices
• Do not conduct testing that disrupts the devices of other users
• Report to us before any public or third-party disclosure

Note on cloud backend testing: Testing of [COMPANY NAME] cloud services or APIs may affect data belonging to other users. Please restrict cloud-side testing to accounts you control. If your research requires access to additional test infrastructure, contact us at [[email protected]] to arrange a dedicated test environment.

[COMPANY NAME] will work to understand and address the vulnerability report before requesting that researchers delay public disclosure.