Search every question across sub-FAQs

Teams should treat Default Passwords under the UK PSTI Act as a source-linked operating decision: confirm whether the product is a relevant connectable product and which manufacturer, importer, distributor, statement-of-compliance, vulnerability-disclosure, password, support-period, or OPSS enforcement route is relevant, assign the team that can change the process, and keep evidence showing the action and review trigger.

The safest first step is to classify the product and supply-chain role before deciding whether the duty belongs to the manufacturer, importer, distributor, or all of them.

Useful evidence is not just a product-security policy. Keep the source, product facts, password and vulnerability-disclosure proof, support-period statement, supply-chain role mapping, and statement-of-compliance approval together.

The common failure pattern is using a generic IoT security claim without proving the PSTI product scope, exact responsible role, customer-facing support information, and statement-of-compliance record.

Teams should treat ETSI Evidence under UK PSTI Act as a source-linked operating decision: confirm whether the product is a relevant connectable product and which manufacturer, importer, distributor, statement-of-compliance, vulnerability-disclosure, password, support-period, or OPSS enforcement duty is triggered, assign the team that can change the process, and keep evidence showing the action and review trigger.

The safest first step is to classify the product and supply-chain role before deciding whether the duty belongs to the manufacturer, importer, distributor, or all of them.

Useful evidence is not just a product-security policy. Keep the source, product facts, password and vulnerability-disclosure proof, support-period statement, supply-chain role mapping, and statement-of-compliance approval together.

In practice, the deliverable should let a reviewer see the product scope, the relevant duty, the evidence used to support the decision, and the final approval or statement of compliance for the product.

The common failure pattern is using a generic IoT security claim without proving the PSTI product scope, exact responsible role, customer-facing support information, and statement-of-compliance record.

A product is only excepted if it is listed as an excepted product in schedule 3 to the PSTI Regulations; otherwise, if it is an internet-connectable product or a network-connectable product, it is a relevant connectable product and may be in scope of the regime.

To make the call, check the product against the definitions in section 5 of the PSTI Act and then confirm whether any schedule 3 excepted-product category applies before treating it as in scope.

Useful evidence is not just a product-security policy. Keep the source, product facts, password and vulnerability-disclosure proof, support-period statement, supply-chain role mapping, and statement-of-compliance approval together.

The common failure pattern is using a generic IoT security claim without proving the PSTI product scope, exact responsible role, customer-facing support information, and statement-of-compliance record.

Teams should treat importer and distributor duties under the UK PSTI Act as supply-chain controls, not abstract policy. Importers must not make a relevant connectable product available unless it is accompanied by a statement of compliance, and they must retain a copy of that statement; distributors must also not make the product available unless it is accompanied by a statement of compliance.

In practice, the importer should verify the product comes with the required statement of compliance and keep their copy on record, while the distributor should confirm that the product they make available is accompanied by that statement before sale or onward supply.

Useful evidence is not just a product-security policy. Keep the source, product facts, password and vulnerability-disclosure proof, support-period statement, supply-chain role mapping, and statement-of-compliance approval together.

The common failure pattern is using a generic IoT security claim without proving the PSTI product scope, exact responsible role, customer-facing support information, and statement-of-compliance record.

Teams should treat an OPSS Notice as a formal enforcement step from OPSS under the PSTI Act. The notice may require a business to take action within a specified period, stop non-compliant activity, arrange a recall, or pay a monetary penalty, so the first task is to identify the notice type, the deadline, and the exact duty or product covered.

The safest first step is to classify the product and supply-chain role before deciding whether the duty belongs to the manufacturer, importer, distributor, or authorised representative. Then record who owns the response, what evidence the notice asks for, and whether representations or an appeal are available.

Useful evidence is not just a product-security policy. Keep the source, product facts, password and vulnerability-disclosure proof, support-period statement, supply-chain role mapping, and statement-of-compliance approval together.

The common failure pattern is using a generic IoT security claim without proving the PSTI product scope, exact responsible role, customer-facing support information, and statement-of-compliance record.

Teams should treat Relevant Connectable Products under UK PSTI Act as a source-linked operating decision: confirm whether the product is a relevant connectable product and which manufacturer, importer, distributor, statement-of-compliance, vulnerability-disclosure, password, support-period, or OPSS enforcement duty is triggered, assign the team that can change the process, and keep evidence showing the action and review trigger.

The safest first step is to classify the product and supply-chain role before deciding whether the duty belongs to the manufacturer, importer, distributor, or all of them.

Useful evidence is not just a product-security policy. Keep the source, product facts, password and vulnerability-disclosure proof, support-period statement, supply-chain role mapping, and statement-of-compliance approval together.

The common failure pattern is using a generic IoT security claim without proving the PSTI product scope, exact responsible role, customer-facing support information, and statement-of-compliance record.

Teams should treat Statement Of Compliance under UK PSTI Act as a source-linked operating decision: confirm whether the product is a relevant connectable product and which manufacturer, importer, distributor, statement-of-compliance, vulnerability-disclosure, password, support-period, or OPSS enforcement duty is triggered, assign the team that can change the process, and keep evidence showing the action and review trigger.

The safest first step is to classify the product and supply-chain role before deciding whether the duty belongs to the manufacturer, importer, distributor, or all of them.

Useful evidence is not just a product-security policy. Keep the source, product facts, password and vulnerability-disclosure proof, support-period statement, supply-chain role mapping, and statement-of-compliance approval together.