Just last week, the Federal Trade Commission (FTC) released a staff report on the Internet of Things (IoT) outlining specific recommendations and its views on best practices that IoT developers should implement to protect consumer privacy and security of IoT devices.  The FTC defines IoT as devices – other than computers, smartphones and tablets – that “connect, communicate or transmit information with or between each other through the Internet.” 

In the IoT Report, the FTC staff devotes a significant amount of space for a discussion of the security implications stemming from the sharp rise in the number of IoT devices.  The Report’s authors note that there was “widespread agreement” during the FTC’s 2013 IoT Workshop that IoT developers should implement some form of reasonable security measures.  And, to that end, the Report identified six issues that begin to define the contours of what the FTC might consider “reasonable security measures” for IoT developers:

  • security by design;
  • internal security procedures;
  • monitoring of service providers;
  • defense-in-depth;
  • implementation of access control measures; and
  • continued monitoring for security vulnerabilities.  

Of course, the devil is in the details.  Take, for example, the FTC staff’s suggestion that IoT developers monitor for security vulnerabilities throughout an IoT device’s life cycle.  The FTC appropriately recognizes that context should drive both consumer expectations about security support and IoT developers’ obligations.  Yet, parts of the FTC’s discussion of IoT security– particularly relating to a developer’s decision to end its support for legacy devices – leave something to be desired. 

At a high level, it is difficult to criticize the FTC staff’s view that IoT developers should notify customers when it plans to end its support of a product.  For many IoT developers, the key will be when they must do so, and on that front, the FTC has provided scant guidance.  The FTC does not overtly state that developers must predict a product’s end-of-life at the outset.  This is a good thing, as setting an end-of-life date when a product is first marketed is a particularly fraught exercise.  Setting a distant date could expose the developer to an FTC  enforcement action if the developer is unable to provide support as promised.  At the same time, however, setting a close date may have repercussions in the market if consumers misperceive that the developer is engaging in planned obsolescence in order to drive future sales.  But, if a developer decides to defer setting a device’s end-of-life until later in the product’s life cycle, it is unclear how much advance notice consumers should reasonably expect to receive. 

In the absence of more specific guidance, IoT developers should expect the FTC to develop and then solidify its views in future enforcement actions.  And so, for the moment, IoT developers should tread lightly, carefully, and (above all else) reasonably.