Search every question across sub-FAQs

EN 303 645 is the baseline requirements standard. Annex B classifies provisions as mandatory, recommended, conditional, and feature-dependent and lets the user record Y, N, or N/A. The detail field records implemented measures, reasons for non-support, or the rationale for N/A. Provision 5.0-1 separately requires a justification for each recommendation considered not applicable or not fulfilled.

TS 103 701 is the compatible assessment methodology. It defines the Device Under Test (DUT), Supplier Organization, Test Laboratory, ICS, IXIT, conceptual and functional tests, external evidence, and verdict rules. An evidence pack should therefore identify the DUT and software version, associated services and processes in scope, each ICS claim, supporting IXIT detail, applied test group or accepted external evidence, indications, and verdict.

The Supplier Organization completes DUT identification and the ICS, then supplies the necessary IXIT information for provisions claimed Y. The Test Laboratory checks the IXIT for completeness, consistency, and soundness with the supplier. It also verifies that no mandatory provision is claimed N and tests whether N/A claims match the provision's stated condition or feature.

The IXIT must be specific enough to select test methods, equipment, conditions, and instructions. A referenced document has to be supplied to the laboratory. Missing or insufficient information can produce INCONCLUSIVE at test-case level because the test cannot be properly executed; it should not be recorded as PASS merely because no failure was observed.

Sometimes, but only for the test group covered by the TS 103 701 external-evidence rules. Existing security certifications or third-party evaluations of parts of the DUT can reduce assessment effort. The Supplier Organization must identify the evidence in the relevant ICS detail field and provide the certificate, scope, test reports, and other information needed for verification.

The Test Laboratory decides whether the evidence is adequate for that test group. It checks whether the scope matches the objective, the prior test activities satisfy every test purpose, and the test depth or evaluation assurance level fits the baseline assessment. Evidence accepted for one component or test group does not establish an overall verdict for the whole DUT.

Verdicts roll up in a fixed order. A test group passes when every test case passes or accepted external evidence satisfies clause 4.7. Any failed test case fails its test group. The overall result passes only if the ICS is valid and every test group for a provision claimed Y passes; one failed applicable group produces FAIL, while an inconclusive applicable group produces INCONCLUSIVE when no fail criterion applies.

A security mailbox alone is not enough. Provision 5.2-1 says the manufacturer shall make the policy publicly available and include contact information for reporting issues, a timeline for initial acknowledgement of receipt, and timelines for status updates to the reporter until resolution.

For visitors, buyers, researchers, and assessors, the policy should make the reporting path visible without requiring private documentation. TS 103 701 turns that into both a conceptual and functional assessment: the test laboratory checks the publication route described in IXIT 2-UserInfo and verifies that the policy is publicly accessible.

Provision 5.2-2 recommends timely action. Its explanatory text says timing varies by incident and describes 90 days as a conventional completion point for a properly documented software vulnerability-management process, including patch availability and notification. It is not a mandatory universal remediation deadline, and hardware fixes or device rollouts can take longer.

Evidence should therefore define the action and time frame for each vulnerability type in IXIT 3-VulnTypes. TS 103 701 asks the laboratory to consider the public policy, severity and criticality, whether the issue affects firmware, hardware, or software, process steps and responsibilities, deployment route, and third-party involvement.

Provision 5.2-3 recommends that manufacturers continually monitor for, identify, and rectify vulnerabilities in consumer IoT products they sell, produce, or have produced and in associated services they operate during the defined support period. The recommendation is bounded by that period unless the manufacturer makes a longer commitment.

TS 103 701 maps this to IXIT 5-VulnMon. The assessment asks whether the described monitoring approach systematically gathers vulnerability information that could affect the device under test or its associated services, whether the identification approach determines applicability, and whether the rectification approach addresses or mitigates susceptibility.

Start with the edition. EN 303 645 V2.1.1 defined a constrained device through physical limits in processing, communication, storage, or user interaction. EN 303 645 V3.1.3 no longer defines or uses that category as a general applicability shortcut.

The current edition still recognizes resource limits where a provision says they matter. For example, provision 5.1-5 requires protection that makes successful brute-force attacks through network interfaces impracticable unless a resource constraint determined by the use case prevents implementation. Update provisions 5.3-14, 5.3-15A, and 5.3-15B apply to devices that cannot have their software updated, whether or not a team calls them constrained.

A resource constraint changes an answer only where the current provision or ICS condition makes that fact relevant. Provision 5.0-1 separately requires a justification for each recommendation considered not applicable or not fulfilled; it does not authorize a blanket exception from mandatory requirements.

For updates, distinguish three questions. Provision 5.3-2 requires a secure update mechanism unless a resource constraint determined by the use case prevents implementation. Provision 5.3-13 requires every manufacturer to publish the defined security-update support period. If a device cannot have its software updated, provision 5.3-14 recommends publishing the reason and hardware-replacement support period and method, while 5.3-15A and 5.3-15B recommend that the device be isolable and its hardware replaceable.

Keep the evidence close to the ICS and IXIT process used by ETSI TS 103 701. The supplier organization identifies the Device Under Test, completes the ICS, provides necessary IXIT information for provisions claimed as supported, and gives enough information for the test laboratory to check consistency and soundness.

For each resource-constraint or non-updateable-device decision, the evidence should answer four questions: what product fact changes the provision, which ICS condition or feature applies, what support value and detail are recorded, and what public disclosure or replacement procedure is required.

Use a provision-by-provision sequence: test the condition or feature first; record Y, N, or N/A with its rationale; provide the required IXIT detail for claims of support; then check whether a public support-period, no-update rationale, replacement method, isolation procedure, or hardware-replacement procedure is also expected.