What is the supplier's responsibility for IoT security, as distinct from the operator's or the architect's?
To make security built-in rather than optional — designing it in from the beginning, shipping it as functionality plus best-practice guidance, and working with users to improve the security of devices already connected.
The supplier's obligations:
- IoT security must be designed and architected from the beginning for all types of sensors, devices and platforms — it should not be an optional add-on feature.
- Provide built-in security functionality and guidance on best practices, so that architects can build secure systems easily. The reasoning given is blunt and commercial: IoT deployments do not scale without trust.
- Work closely with users to help improve the security of connected devices already in the field.
The reason this sits with the supplier rather than anyone else is a matter of timing and leverage. The decisions that determine whether a device can ever be secured — whether it has a unique key, whether its boot chain verifies, whether its firmware can be updated at all — are made before the product ships. No amount of diligence by the operator can add a trust anchor to hardware that was built without one.
The "guidance on best practices" clause is the underrated half. Architects integrating a device are not usually specialists in that device; a supplier that ships a secure product with no documentation of how to deploy it securely has solved only half of its problem.
Tip: "should not be an optional add-on feature" is the sentence to remember, because it is the one most often violated in practice — security as a paid tier, a configuration flag, or a later firmware release is the failure mode this clause names.
Go deeper:
NIST IR 8259 Rev. 1 — Foundational Cybersecurity Activities for IoT Product Manufacturers — the same obligations written as a standard: what a manufacturer should do before the product is sold, including the security information the customer needs to deploy it safely.