A practical guide to clauses 5.2 and 5.3 for consumer IoT vulnerability intake, security-update mechanisms, support-period publication, and assessment evidence.
Based on ETSI EN 303 645 V3.1.3 and ETSI TS 103 701 V2.1.1. Use it as implementation and assurance guidance, not for legal interpretation.
Structured answer sets in this page tree.
Cited legal and guidance references.
Publish the vulnerability-reporting route and the , then connect both to the product's intake, monitoring, remediation, update, isolation, replacement, and user-notification evidence. EN 303 645 clauses 5.2 and 5.3 define the outcomes with a mix of shall and should provisions; TS 103 701 supplies the separate assessment method.
Clause 5.2 starts with a public . EN 303 645 says the manufacturer shall make the policy publicly available and that it shall include contact information for reporting issues plus timelines for initial acknowledgement and status updates until reported issues are resolved.
The same clause says disclosed vulnerabilities should be acted on in a timely manner and manufacturers should continually monitor for, identify, and rectify vulnerabilities in products sold or produced and associated services operated during the . Timeliness is incident-specific. The explanatory text describes 90 days as a conventional completion period for a software solution, including patches and notification; it is not a fixed deadline for every report, and hardware or deployed-device fixes can take longer.
Clause 5.3 says software components not made immutable for security reasons should be securely updateable. The device shall have a unless a resource constraint determined by the use case prevents one. Secure installation means measures that prevent an attacker from misusing the mechanism.
Where the relevant update feature exists, V3.1.3 addresses simple installation, an automatable secure mechanism, activation of automatic updates with user consent during initialization, post-initialization update checks, controls for automatic updates and notifications, cryptography, timely delivery, authenticity and integrity, trust relationships for network delivery, user notices, and disruption notices. It also states that the manufacturer shall publish the and that the model designation shall be clearly recognizable. Devices that cannot be updated have separate recommendations for publishing the rationale and replacement support, isolation, and hardware replacement.
Treat EN 303 645 as the provision source and TS 103 701 as the assessment method. EN 303 645 says what the manufacturer, device, or update process should or shall do. TS 103 701 describes how a Supplier Organization and Test Laboratory structure the assessment of a Device Under Test through identification, ICS, , test planning, conceptual tests, functional tests, and PASS, FAIL, or INCONCLUSIVE verdicts.
A public product page can state a support period and vulnerability reporting route. A non-public evidence pack should show the entries, design details, public-document locations, test observations, and confirmations that a TS 103 701 assessor would need to evaluate those claims.
This guide helps connect public policy text, update architecture, support-period statements, IXIT entries, and release evidence before an assessment or procurement review.
Convert secure-update and vulnerability-disclosure provisions into accountable evidence requests and assessment milestones.
Use cited ETSI material to resolve scope, applicability, support-period, and TS 103 701 evidence questions before implementation.
Review product scope, public policy text, update evidence, owners, and next compliance actions with Sorena.
Review this checklist before making an EN 303 645 claim in a product page, procurement response, assessment workbook, or release gate. Each item should be tied to a specific product model, associated service, firmware stream, and support period.
Use concrete, versioned evidence: public URLs, release records, update-mechanism descriptions, cryptographic details, user-notification screenshots, component inventories, vulnerability triage procedures, and assessor-ready references.
Claims weaken when they mix provision language, evidence language, and marketing language. Avoid saying a product is conformant unless the scope, DUT, ICS support claims, evidence, test groups, and assessment outcome are clear.
Also avoid treating secure updates and vulnerability disclosure as isolated paperwork. EN 303 645 links security updates to vulnerability handling, support periods, user communication, associated services, and third-party components.
"Manufacturers are expected to exercise due care for all software and hardware components used in the product"
"For every "N/A" a justification shall be given in the "Detail" column by the SO."