Skip to main content
U.S. flag

An official website of the United States government

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS
A lock ( ) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

IoT Non-Technical Supporting Capabilities: You Talked, We Listened

Concept of online communication or social networking. Wooden cubes with speech bubbles linked to each other with lines.
Credit: Shutterstock/Cagkan Sayin

As part of our ongoing community engagement following the publication of four IoT cybersecurity draft documents in December 2020, NIST conducted a quartet of roundtable discussions in June 2021 focused on draft NISTIR 8259B, IoT Non-Technical Supporting Capability Core Baseline. The roundtables spanned four weeks, and addressed the four core capabilities defined in NISTIR 8259B as well as general discussions on applying the baseline:

  • June 8:  Documentation
  • June 15:  Information Reception and Dissemination
  • June 22:  Education and Awareness
  • June 29:  Applying the non-technical capabilities baseline

This blog provides a brief summary of takeaways that we heard at the four roundtable sessions. These takeaways are the ideas, observations, and suggestions that came up during the roundtables. The roundtables were not forums for developing consensus and these do not represent formal positions taken by attendees or participants. These takeaways provide important feedback to the program, and serve as a basis for future conversations with the community. NIST considers all feedback and makes no commitments to acting on any specific feedback.

  • Support for NISTIR 8259B Non-Technical Supporting Capabilities. Roundtable participants across the four sessions were generally supportive of all four of the capabilities described in the NISTIR 8259B baseline. There was widespread agreement that each capability was valuable, regardless of the customer audience or use case for any particular IoT product; however, these capabilities would likely need to be tailored for specific audiences and use cases.
  • General Need to Improve Consumer Security Awareness. A view consistently expressed was that efforts to raise consumers’ awareness of their role in IoT device security were important and valuable. If the manufacturer is already informing the customer how to get a product working, why not also inform the consumer about how to get it up and working securely. Ideas to do this ranged from basic approaches such as labeling devices with a warning to change the default password to more sophisticated or broader approaches, such as providing information via on-line videos (e.g., on YouTube) or smartphone apps.
  • IoT Product Owners Need Vulnerability and Patching Information. Roundtable participants placed considerable emphasis on the need for IoT device customers, both enterprise and consumer, to have accessible means to learn about IoT product vulnerabilities and patches, and asserted that consumers, in particular, needed manufacturers to provide guidance describing where to find such information. For enterprises, some participants suggested that information feeds from Information Sharing and Analysis Centers (ISACs) would be a good source of information for IoT product customers regarding vulnerabilities and patches, and noted there are ISACs focused on many different industry and government sectors; the National Council of ISACs is a good starting point for further information.
  • Need to Consider Secure Device Re-Provisioning or Retirement. Attendees identified the re-provisioning of an IoT device as an important consideration for non-technical supporting capabilities.  When the initial user ceases to use a device, several concerns arise regarding the consequences of it being adopted by a subsequent user or in secure disposal.  These include both the security of the initial user’s data and device configuration (customers need to know how to wipe a device and reset it to a default configuration where their data cannot be exposed, and access to their systems is removed) and security for the secondary owner (who needs to be informed of how to properly set the device up securely and be connected to the manufacturer’s flow of information regarding vulnerabilities, update patches, and other security concerns). A secondary user may not have the original documentation and may not know where to go to find more information.
  • Desire for a Centralized Reporting Facility. The participants expressed a desire for a single place where customers could report issues with their IoT devices in a straightforward, relatively non-technical manner. The intent was that not only specific security issues but also unusual or anomalous behavior could be reported. Supporters of this concept suggested that centralized reporting could enable quicker discovery of issues with IoT products.
  • Need for Structured Documentation. Participants identified a need to receive IoT device  documentation in a structured, standardized, consistent layout and format. For enterprise customers, standardized documentation could be ingested, parsed, indexed, and incorporated into automatic documentation and help systems. The ability to readily query documentation, or to create automated user guides or decision trees to aid in addressing support questions was identified as a benefit of structured documentation. For consumers, standardized documentation layouts can help in locating information and understanding what is needed to be done to secure the device.
  • Possible Role For Third Parties in Education and Awareness.  Participants recognized that providing training material in diverse forms for a variety of customers could present a significant burden for manufacturers. A number of other participants in the IoT ecosystem were suggested as potential intermediaries that could reformulate comprehensive manufacturer documentation into education and awareness materials for different customer categories. In particular, industry associations and retailers were noted as candidates; some participants pointed to the home improvement sector as an example, where it is common for retailers to provide customer education of various forms. Attendees suggested the same could happen for IoT products. A related concept offered was that investment in educational material should be proportional to the risk of a particular IoT product or class of products for a class of customers, with the suggestion that industry associations might be appropriate third parties to help align education against potential risk.
  • Manufacturers Need to Improve Their Handling of Customer Input. Roundtable attendees expressed concerns that identifying appropriate contacts within manufacturers to address customer input about security concerns and unexpected device behaviors can be very challenging. Manufacturer response to customer and security researcher input is not always clear or traceable.
  • Supply Chain Information Should be Gathered By The Shipping Manufacturer. Participants recognized that gathering product security information from the multiple organizations commonly involved in a product’s supply chain is a notable challenge. There was general agreement that different subcomponent manufacturers should be held to the same standards for providing information as the shipping manufacturer. There was a suggestion that this accountability should occur during the design of the IoT device for which multiple subcomponents need to be integrated. Participants also felt that standards for specifications would be helpful; such standards should indicate what information the manufacturer must produce in documentation and perhaps that could address what is needed for the customer without additional coordination.
  • Enhanced Security Could be a Market Advantage. Roundtable attendees recognized that enterprises are generally better prepared than consumers to utilize complex or detailed security documentation for a product. However, there was also sentiment that security improvements could improve security across all markets. An example was offered that a capability intended for enterprise customers, Manufacturer Usage Description (MUD) files, could lead to ecosystem improvements if home router vendors added MUD support to their products and advertising the resulting enhanced security as an advantageous feature.


NIST extends our thanks to those who participated in these roundtable sessions and provided feedback on NISTIR 8259B and related topics. These are all valuable insights for understanding various points of view on the non-technical cybersecurity baseline for IoT. While many of these thoughts go well beyond NIST’s mission and the scope of the draft NISTIR 8259B, it is always helpful to get feedback. Stay tuned as NIST moves to take the next steps on NISTIR 8259B.

About the author

Barbara Cuthill

Barbara Cuthill received her PhD in Computer Science from the University of Connecticut. Her career at the National Institute of Standards and Technology has spanned the Advanced Technology Program, the Technology Innovation Program and the National Strategy for Trusted Identities in Cyberspace National Program Office. She is currently the Deputy Program Manager for the NIST Cybersecurity for IoT Program.


Add new comment

Enter the characters shown in the image.
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.
Please be respectful when posting comments. We will post all comments without editing as long as they are appropriate for a public, family friendly website, are on topic and do not contain profanity, personal attacks, misleading or false information/accusations or promote specific commercial products, services or organizations. Comments that violate our comment policy or include links to non-government organizations/web pages will not be posted.