Federal Communications Commission	FCC 23-65

Before the
FEDERAL COMMUNICATIONS COMMISSION
WASHINGTON, D.C. 20554


In the Matter of
Cybersecurity Labeling for Internet of Things	


)
)


PS Docket No. 23-239


 

NOTICE OF PROPOSED RULEMAKING

Adopted:  August 6, 2023	Released:  August 10, 2023

Comment Date: (30 days after date of publication in the Federal Register)
Reply Comment Date: (45 days after date of publication in the Federal Register)

By the Commission:  Chairwoman Rosenworcel and Commissioners Starks and Simington issuing separate statements.

Heading	Paragraph #
I.	INTRODUCTION	1
II.	BACKGROUND	3
A.	The Internet of Things (IoT) Landscape	3
B.	Public and Private IoT Security Efforts	5
III.	DISCUSSION	9
A.	Establishing a Voluntary Cybersecurity Labeling Program	9
B.	Eligible Devices or Products	10
C.	Oversight and Management of the Proposed IoT Cybersecurity Labeling Program	19
D.	Development of IoT Cybersecurity Criteria and Standards	27
E.	Administering the IoT Labeling Program	34
F.	Legal Authority	57
G.	Promoting Digital Equity	66
IV.	PROCEDURAL MATTERS	67
V.	ORDERING CLAUSES	73
APPENDIX A – IoT Product Criteria
APPENDIX B – Initial Regulatory Flexibility Analysis

I. INTRODUCTION
1. In this Notice of Proposed Rulemaking (NPRM), we propose measures to improve consumer confidence and understanding of the security of their connected devices – commonly known as Internet of Things (IoT) devices – that are woven into the fabric of their everyday lives. In launching this NPRM, we conclude our consideration of IoT cybersecurity labeling issues related to the Notice of Inquiry in ET Docket No. 21-232 and EA Docket No. 21-233, and close that proceeding as to those issues.  See Authorization Program; Protecting Against National Security Threats to the Communications Supply Chain through the Competitive Bidding Program, ET Docket No. 21-232, EA Docket No. 21-233, Notice of Proposed Rulemaking and Notice of Inquiry, 36 FCC Rcd 10578, para. 104 (2021) (Supply Chain NOI).  That NOI raised IoT cybersecurity labeling in the specific context of our existing equipment authorization program, and although we do not formally rule out building on our equipment authorization program at this stage, we believe that our proposals for a voluntary labeling program building on the efforts of NIST and others as reflected in this NPRM represent the most appropriate, and targeted, approach to IoT cybersecurity labeling that we want to explore at this time.  We believe that closing the Supply Chain NOI with respect to IoT cybersecurity labeling issues will focus commenters on this proceeding and spur comments that better reflect that distinct focus.  Thus, although we hereby incorporate relevant comments in those dockets into this proceeding, PS Docket 23-239, we also request that, going forward, interested parties use PS Docket 23-239 for any filings.  We direct OET to provide public notice of the closed issues in ET Docket Nos. 21-232, 21-233.
  Consumers have come to rely on the functionality and convenience of their smart devices, which run the gamut from home office routers to personal digital assistants, Internet-connected home security cameras, voice-activated shopping devices, Internet-connected appliances, fitness trackers, GPS trackers, medical devices, garage door openers, and baby monitors.  These devices bring enormous benefits by making our homes smarter and more efficient and making our lives easier.  But, with this increased interconnection comes risk, including the potential for nefarious actors to access and use these devices to their own ends.  With more than 25 billion connected IoT devices predicted to be in operation by 2030, Lionel Sujay Vailshery, Number of IoT connected devices worldwide 2019-2021, with forecasts to 2030 (Nov. 22, 2022), https://www.statista.com/statistics/1183457/iot-connected-devices-worldwide/ (last visited July 17, 2023); see also CTA, Public-Private Collaboration is Critical to Consumer IoT Security, U.S. Innovation, Says CTA (Mar. 22, 2021), https://www.cta.tech/Resources/Newsroom/Media-Releases/2021/March/IOT-Device-Security-White-Paper-Release (stating “the number of IoT devices worldwide will nearly triple by 2023, surpassing 40 billion units”).
 consumers need tools that allow them to understand the relative security risk that an IoT device or product may pose, to compare IoT devices, and to have a level of confidence whether the IoT devices they ultimately purchase meet certain cybersecurity standards.  Responsibly using smart devices takes informed consumers.
2. To provide consumers with the peace of mind that the technology being brought into their homes is reasonably secure, and to help guard against risks to communications, today we propose a voluntary cybersecurity labeling program that would provide easily understood, accessible information to consumers on the relative security of an IoT device or product, and assure consumers that manufacturers of devices bearing the Commission’s IoT cybersecurity label adhere to widely accepted cybersecurity standards.  In this regard, our cybersecurity labeling program would help consumers compare IoT devices and make informed purchasing decisions, drive consumers toward purchasing devices with greater security, incentivize manufacturers to meet higher cybersecurity standards to meet market demand, and encourage retailers to market secure devices.  The proposed IoT label would offer a trusted, government-backed symbol for devices that comply with IoT cybersecurity standards.
II. BACKGROUND
A. The Internet of Things (IoT) Landscape 
3. As the world continues to become even more interconnected, malicious cyber campaigns become bolder and continue to threaten our network security and privacy.  Today, there are a wide range of consumer IoT products on the market that communicate over wired and wireless networks.  These products are made up of various devices, and are based on many technologies, each of which presents a set of security challenges. Many IoT technologies exist today, as the field is constantly evolving, and new technologies are being developed all the time.  Some of the common technologies used by IoT devices include Zigbee, Bluetooth, Wi-Fi, Narrowband IoT (NB-IoT), LoRaWAN, Sigfox, Cellular IoT (e.g., 2G, 3G, 4G, 5G), and Thread.
  Consumer IoT products and their component devices are susceptible to a wide range of relatively common security vulnerabilities including the continued use of default passwords, lack of regular security updates, and weak encryption and insecure authentication.  Some IoT products and devices even lack any type of physical security. IoT devices are often installed in public spaces or remote locations, which makes them susceptible to theft, tampering, vandalism, or unauthorized access.  Therefore, it is important for IoT device developers, manufacturers, and security professionals to be aware of these risks and to consider taking appropriate physical security measures to protect IoT devices, such as implementing tamper-evident packaging, monitoring for signs of tampering or theft, using secure communication protocols to prevent unauthorized access, encrypting sensitive data stored on the device, and secure boot procedures.  It is also important that the Joint Test Action Group (JTAG) port or interface -- used for debugging and programming purposes – be disabled or physically locked prior to releasing the device or product into the market.  JTAG can be a potential security risk, as it provides a backdoor into the device that could be exploited by attackers.
  These vulnerabilities can be exploited by attackers to gain unauthorized access to the device or its data, launch denial of service (DoS) attacks, A Denial of Service (DoS) attack is a type of cyber-attack that aims to disrupt the normal operation of a network, server, or website by flooding it with large amounts of traffic or by exploiting vulnerabilities in the application or operating system or using a botnet to automate the attack.
 use the device as part of a larger botnet, A botnet is a network of Internet-connected devices that have been infected with malware and are under the control of a malicious actor.  Once a device is infected, it becomes part of the botnet and can be used to carry out a variety of malicious activities, including launching a DoS attack, spreading spam emails, and stealing sensitive data.
For example, the Mirai botnet that used IoT devices to launch one of the largest distributed denial-of-service (DDoS) attacks to date was powered by a list of 61 default passwords.  Following the release of the botnet’s source code by its creator, security researchers noticed that the botnet leverages a list of more than 60 combinations of usernames and weak default passwords to scan the Internet for insecure IoT devices.  See Marcos Colon, Mirai Botnet Propagates By Leveraging Weak Default Passwords (Oct. 4, 2016), https://www.scmagazine.com/news/content/mirai-botnet-propogates-by-leveraging-weak-default-passwords.
 or use the device as an interference generator. Zhifei Xu et al., Inaudible Attack on Smart Speakers With Intentional Electromagnetic Interference, Vol. 69 IEEE Transactions on Microwave Theory and Techniques (2021).
  Compromised devices could also be forced to transmit at times and intervals selected by the attacker to interfere with other devices, either causing them to function improperly or causing a denial of service. See SimpliSafe Alarm Bypassed With a $2 Device From Amazon, YouTube, (Aug. 7 2019), https://www.youtube.com/watch?v=UlNkQJzw4oA where a transmitter (potentially any compromised IoT device transmitting on the correct frequency) suppressed the alarm of a security system by transmitting on the same frequency.  Or more generally where increased traffic by a compromised device can raise the noise environment degrading communication for other devices.  Wetzker, Ulf & Splitt, Ingmar & Zimmerling, Marco & Römer, Kay & Boano, Carlo Alberto. (2016).  Troubleshooting Wireless Coexistence Problems in the Industrial Internet of Things. 10.1109/CSE-EUC-DCABES.2016.167.

4. The proliferation of consumer IoT devices has opened the door to cyberattacks on consumer products that can have serious privacy and national security consequences, ranging from theft of personal information to disruption of critical infrastructure.  In just the first six months of 2021, for example, it was estimated “that more than 1.5 billion attacks have occurred against IoT devices.” David Paul, IoT Devices See More Than 1.5bn Cyberattacks so Far This Year, DIGIT NEWS, (Sept. 13, 2021), https://www.digit.fyi/iot-security-kaspersky-research-attacks/.
  Cybersecurity vulnerabilities in IoT products and their devices also open a gateway to larger and more significant intrusions that may threaten national security. Trend Micro, IoT Security Issues, Threats, and Defenses (July 22, 2021), https://www.trendmicro.com/vinfo/us/security/news/internet-of-things/iot-security-101-threats-issues-and-defenses.

B. Public and Private IoT Security Efforts
5. Significant work has already been conducted in the realm of IoT cybersecurity. We observe that NIST issued several guidelines on cybersecurity for Internet-connected devices, stressing an engineering-based approach that builds security systems directly into IoT technology.  See, NIST, Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure System, NIST Special Pub. 800-160 (Nov. 2016), https://doi.org/10.6028/NIST.SP.800-160.  See also NIST, NISTIR 8259, Foundational Cybersecurity Activities for IoT Device Manufacturers at 15 (2020), https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8259.pdf.  The Department of Homeland Security (DHS) also recently released its own cybersecurity policy for IoT devices, delineating six strategic principles that it believes will help stakeholders stop unauthorized intruders from tampering with connected devices.  See U.S. Dept. of Homeland Security, Strategic Principles for Securing the Internet of Things (IoT), Version 1.0 (Nov. 15, 2016), https://www.dhs.gov/securingtheIoT.  NIST and the National Telecommunications and Information Administration (NTIA) developed a risk management framework for addressing cybersecurity issues.  See NIST, Framework for Improving Critical Infrastructure Cybersecurity (2014), https://www.nist.gov/sites/default/files/documents/cyberframework/cybersecurity-framework-021214.pdf.  The Communications Security, Reliability, and Interoperability Council IV (CSRIC IV) developed a segment-specific analysis of the application of the Cybersecurity Framework, as well as recommendations for voluntary efforts to address cybersecurity concerns.  See CSRIC IV, Working Group 4, Cybersecurity Risk Management and Best Practices, Final Report (2015), https://transition.fcc.gov/pshs/advisory/csric4/CSRIC_IV_WG4_Final_Report_031815.pdf.  In addition, the Commission’s Technical Advisory Council issued its report on applying security to consumer IoT devices.  See Federal Communications Commission Technical Advisory Council (FCC TAC), Cybersecurity Working Group, Technical Considerations White Paper (2015), https://transition.fcc.gov/oet/tac/tacdocs/reports/2015/FCC-TAC-Cyber-IoT-White-Paper-Rel1.1-2015.pdf.  See also FTC Report on Internet of Things Urges Companies to Adopt Best Practices to Address Consumer Privacy and Security Risks (Jan. 27, 2015), https://www.ftc.gov/system/files/documents/reports/federal-trade-commission-staff-report-november-2013-workshop-entitled-internet-things-privacy/150127iotrpt.pdf (proposing privacy and cybersecurity best practices associated with IoT); U.S. Dept. of Health and Human Services, Radio Frequency Wireless Technology in Medical Devices: Guidance for Industry and Food and Drug Administration Staff (Aug. 14, 2013), http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm077272.pdf (guidance to the industry on considerations for the safe and effective development and use of RF technology in medical devices).
  There are also ongoing efforts to address IoT security labeling across both private and public sectors.  In the private sector, for example, the Consumer Technology Association (CTA) convened an IoT working group tasked with supporting the advancement of the consumer IoT industry, Consumer Technology Association CES, IoT Working Group, https://www.cta.tech/Membership/Member-Groups/IoT-Working-Group (last visited July 17, 2023).
 and produced a white paper addressing the current regulatory approach to IoT. ANSI/CTA, Standard Baseline Cybersecurity Standard for Devices and Device Systems ANSI/CTA-2088-A (May 2022), https://shop.cta.tech/products/https-cdn-cta-tech-cta-media-media-shop-standards-2020-ansi-cta-2088-a-final-pdf.  See also Consumer Tech Association, Smart Policy to Secure our Smart Future: How to Promote a Secure Internet of Things for Consumers (2021), (available at https://www.cta.tech/Resources/Newsroom/Media-Releases/2021/March/IOT-Device-Security-White-Paper-Release) (CTA Cybersecurity White Paper); see also Supply Chain NOI, 36 FCC Rcd 10578, para. 104 (the Commission sought comment on the CTA Cybersecurity White Paper).
  CTA has also convened with various organizations to discuss IoT baseline security capabilities. Council to Secure the Digital Economy, The C2 Consensus on IoT Device Security Baseline Capabilities (2019), https://csde.org/wp-content/uploads/2019/09/CSDE_IoT-C2-Consensus-Report_FINAL.pdf; see also Council to Secure the Digital Economy, The C2 Consensus on IoT Device Security Baseline Capabilities – 2021 Supplement (2021), https://csde.org/wp-content/uploads/2021/04/C2-Tech-Report_2021_final.pdf.
  In addition, researchers at Carnegie Mellon University (CMU) conducted significant research into consumer IoT purchasing and concluded there is a need to “provide consumers with readily accessible information to help them make informed decisions about what they bring into their homes.” Carnegie Mellon University, CyLab presents IoT privacy and security label research at White House summit (Oct. 19, 2022), https://www.cylab.cmu.edu/news/2022/10/19-cylab-presents-at-white-house-iot-security-summit.html.
  International efforts have also advanced in the IoT labeling space. For example, in June 2018, the European Telecommunications Standards Institute (ETSI) published the European standard (i.e., EN 303 645) that specifies cybersecurity requirements for consumer IoT devices and products to provide a common baseline for IoT security across the European Union.  The standard defines a set of 13 high-level provisions for IoT device manufacturers to ensure the security and privacy of their products.  These provisions cover several areas, including secure communication, access control, and software updates.  Compliance with the standard is voluntary. See, ETSI, Cyber Security for Consumer Internet of Things: Baseline Requirements (2020), https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf.  In October 2020, the Cyber Security Agency of Singapore (CSA) launched its baseline cybersecurity requirements for IoT devices and products.  To date, CSA has accredited 14 third party labs, including Underwriters’ Laboratories (UL), to test and certify IoT devices and products that meet its standards. See, e.g., Cyber Security Agency of Singapore, Updates, https://www.csa.gov.sg/our-programmes/certification-and-labelling-schemes/cybersecurity-labelling-scheme/updates (last visited July 17, 2023).
 
6. In May 2021, Executive Order No. 14028 also emphasized the importance of IoT cybersecurity, noting the “persistent and increasingly sophisticated malicious cyber campaigns that threaten the public sector, the private sector, and ultimately the American people’s security and privacy.” Exec. Order No. 14028, Improving the Nation’s Cybersecurity, 86 Fed. Reg. 26633, 26633 (May 12, 2021) (IoT Executive Order).
  Indeed, securing the Internet of Things forms a significant pillar in the recently-released National Cybersecurity Strategy, which noted in particular the need to advance the goals of the EO’s IoT labeling efforts so that “consumers will be able to compare the cybersecurity protections offered by different IoT products, thus creating a market incentive for greater security across the entire IoT ecosystem.” National Cybersecurity Strategy at 3.2, p. 20, https://www.whitehouse.gov/wp-content/uploads/2023/03/National-Cybersecurity-Strategy-2023.pdf (Mar. 2, 2023); see also IoT Cybersecurity Improvement Act of 2020, 15 U.S.C. § 278g-3a to § 278g-3e (establishes minimum cybersecurity requirements for IoT technology procured by the U.S. government and directs federal agencies to only procure devices that comply with NIST guidelines (NIST SP 800-213 and 213A) and establishes vulnerability reporting requirements for products sold to the U.S government).

7. In this respect and pursuant to that EO, Id.
 in 2022 the National Institute of Standards and Technology (NIST) issued a White Paper that identified labeling criteria for cybersecurity capabilities of IoT consumer devices, informed by existing consumer product labeling programs and input provided by diverse stakeholders, and issued a summary report about creating a cybersecurity labeling program for consumer IoT products. See NIST, Recommended Criteria for Cybersecurity Labeling for Consumer IoT Products (Feb. 4, 2022), https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.02042022-2.pdf; (NIST Cybersecurity White Paper) and NIST, Cybersecurity Labeling for Consumers: Internet of Things (IoT) Devices and Software (May 24, 2022), https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/cybersecurity-labeling-consumers-0 (NIST IoT Cybersecurity Criteria for Consumer Labeling Program Overview).
  Additionally, NIST produced a final report, Profile of the IoT Core Baseline for Consumer IoT Products (NISTIR 8425), which identifies cybersecurity capabilities commonly needed for the consumer IoT sector, thereby providing a starting point for what consumers should consider when purchasing IoT products. NIST, NISTIR 8425, Profile of the IoT Core Baseline for Consumer IoT Products (Sept. 20, 2022), https://csrc.nist.gov/publications/detail/nistir/8425/final (NISTIR 8425).
  From these efforts, NIST identified key elements of a labeling program, including encouraging innovation, and being practical and not burdensome, among other elements. NIST, IoT Cybersecurity Criteria for Consumer Labeling Program Overview (last updated May 24, 2022), https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/cybersecurity-labeling-consumers-0.
  In addition, NIST initiated a pilot IoT cybersecurity labeling program, in which it solicited contributions from stakeholders regarding how current and future-planned labeling efforts could align with the NIST recommendations. See Report for the Assistant to the President for National Security Affairs (APNSA) on Cybersecurity Labeling for Consumers: Internet of Things (IoT) Devices and Software A summary review of labeling actions called for by Executive Order (EO) 14028: Improving the Nation’s Cybersecurity at p. 7 (May 10, 2022) (available at https://www.nist.gov/system/files/documents/2022/05/24/Cybersecurity%20Labeling%20for%20Consumers%20under%20Executive%20Order%2014028%20on%20Improving%20the%20Nation%27s%20Cybersecurity%20Report%20%28FINAL%29.pdf). See also NIST Recommendation Criteria (relying upon the NISTIR 8259 family of documents, e.g., NISTIR 8259, NISTIR 8259A, and NISTIR 8259B).
  NIST describes a potential program that would educate the public on IoT cybersecurity capabilities, thereby allowing and enabling consumers in the marketplace to make informed choices about their IoT purchases. See NISTIR 8425 at 16; see also NIST, Consumer Cybersecurity Labeling Pilots:  The Approach and Contributions, https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/consumer-cybersecurity-labeling-pilots (last updated May 24, 2022); IoT Executive Order.

8. The foregoing priorities and efforts, Commission experience guiding compliance assessment programs, See, e.g., 47 CFR Part 2, Subpart J (equipment authorization); 47 CFR § 20.19 (hearing aid compatibility); 47 CFR §§ 2.1091, 2.1093 (radiofrequency radiation exposure); Part 68 (connection of terminal equipment to the telephone network).
 and prior Commission action in this space (including the recent Spectrum Requirements for Internet of Things Notice of Inquiry, and efforts to address the potential for reprogrammed communications equipment to operate outside of authorized device parameters with the attendant risk of harmful interference See Spectrum Requirements for the Internet of Things, ET Docket No. 21-353, Notice of Inquiry, 36 FCC Rcd 14165 (2021); Supply Chain NOI, 36 FCC Rcd 10578, (2021); Report and Order, Order, and Further Notice of Proposed Rulemaking, FCC 22-84 (Nov. 11, 2022); Revision of Part 15 of the Commission’s Rules to Permit Unlicensed National Information Infrastructure (U-NII) Devices in the 5 GHz Band, ET Docket No. 13-49, First Report and Order, 29 FCC Rcd 4127, 4143, para. 54 (2014).
) provide important building blocks for our analysis and inform our proposals today.
III. DISCUSSION
A. Establishing a Voluntary Cybersecurity Labeling Program
9. We propose to establish a voluntary cybersecurity labeling program.  Given the nature of the IoT market, we believe that the success of a cybersecurity labeling program will be dependent upon a willing, close partnership and collaboration between the federal government, industry, and other stakeholders.  While this proposed program would be voluntary, entities that choose to participate in the Commission’s program would be required to ensure their IoT devices and products comply with the Commission’s program requirements we propose to codify in our rules.  As described below, we propose the use of certain baseline cybersecurity criteria and the development of product standards informed by those criteria, as well as the parameters for labeling of IoT products that conform with those standards and associated informational requirements.  IoT products qualifying for the program would be authorized to use the Commission’s proposed new distinctive label signifying their participation in the program and adherence to the standards set.  We anticipate that devices or products bearing the Commission’s cybersecurity label will be valued by consumers, particularly by those who may otherwise have difficulty determining whether a product they are thinking of buying meets basic security standards.  We seek comment on this proposed approach.
B. Eligible Devices or Products
10. We seek comment on the scope of IoT devices or products for sale in the United States that should be eligible for inclusion in the Commission’s labeling program.  To help inform our program’s scope, we observe that our practical goal is to provide consumers with a clear, easily understood indicator that the IoT devices displaying the Commission’s label satisfy certain baseline cybersecurity requirements and have specific cybersecurity capabilities.  In assessing scope, we seek to ensure that our program would be sufficiently inclusive to be of value to consumers in this regard.
11. We seek comment on whether to focus the program initially on IoT “devices” (as defined in this document) and specifically those wireless devices that intentionally emit radio frequency (RF) energy.  We begin by considering NIST’s definition of IoT devices.  NIST defines IoT devices as those devices that have at least one transducer (sensor or actuator) See NISTIR 8259 at 27 (defining a transducer as “[a] portion of an IoT device capable of interacting directly with a physical entity of interest”).
 for interacting directly with the physical world and at least one network interface (e.g., Ethernet, Wi-Fi, Bluetooth) for interfacing with the digital world. NIST Internal Report, NIST IR 8425, Profile of the IoT Core Baseline for Consumer IoT Products (Sept. 2020) at 23 (https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8425.pdf).
  We propose two modifications to the NIST definition for purposes of our labeling program.  First, we propose to add “Internet-connected” to our definition because, as NIST observes, a key component of IoT is the usage of standard Internet protocols for functionality, which expose IoT to related security threats and challenges caused by being Internet-connected. Id. at 1.
  Second, because the Commission’s relevant statutory authorities recognize the more extensive risks of harmful interference associated with devices that intentionally emit RF energy, See infra section IIIF, Legal Authority.
 we propose to include the premise that an IoT device must be capable of intentionally emitting RF energy.  In this respect, we are referring to an IoT device, with a wireless interface, that intentionally uses RF energy to communicate or interact with the physical world.  Accordingly, incorporating our modifications, we propose, for purposes of the IoT labeling program, to define an IoT device as:  (1) an Internet-connected device capable of intentionally emitting RF energy that has at least one transducer (sensor or actuator) for interacting directly with the physical world, coupled with (2) at least one network interface (e.g., Wi-Fi, Bluetooth) for interfacing with the digital world.  We seek comment on our proposed definition.
12. We propose to focus the scope of our program on intentional radiators that generate and emit RF energy by radiation or induction. 47 CFR § 15.3(o) (definition of “intentional radiator”); see generally 47 CFR § 15.3 for relevant definitions.  The Commission’s regulations governing RF devices can be found in Part 15 of our rules, 47 CFR §§ 15.1 et seq.
  Such devices – if exploited by a vulnerability – could be manipulated to generate and emit RF energy to cause harmful interference.  While we observe that any IoT device may emit RF energy (whether intentionally, incidentally, or unintentionally), in the case of incidental and unintentional radiators, the RF energy emitted because of exploitation may not be enough to be likely to cause harmful interference to radio transmissions. 47 U.S.C. § 302a(a)(1) (“The Commission may, consistent with the public interest, convenience, and necessity, make reasonable regulations . . . governing the interference potential of devices which in their operation are capable of emitting radio frequency energy by radiation, conduction, or other means in sufficient degree to cause harmful interference to radio communications; . . .”).
  We seek comment on this view.  Does this proposed definition unduly limit the devices that should be eligible for participation in the cybersecurity labeling program?  Are there specific unintentional radiators or incidental radiators that should be included in the program, or should they be included generally? Under our Part 15 rules, an “unintentional radiator” is “[a] device that intentionally generates radio frequency energy for use within the device, or that sends radio frequency signals by conduction to associated equipment via connecting wiring, but which is not intended to emit RF energy by radiation or induction” 47 CFR § 15.3(z).  An “incidental radiator” is “[a] device that generates radio frequency energy during the course of its operation although the device is not intentionally designed to generate or emit radio frequency energy.  Examples of incidental radiators are dc motors, mechanical light switches, etc.”  47 CFR § 15.3(n).  Certain digital and other devices are also exempted from “the specific technical standards and other requirements” of part 15, ostensibly due to the minimal risk of harmful interference that they pose.  47 CFR § 15.103.
  Alternatively, should we consider adding these devices to the program at a later date?  We also seek comment on any other ways in which our proposal might be limiting or should otherwise be expanded.  For example, would the exclusion of wired-only IoT devices impact the success, usefulness and effectiveness of this labeling program and confuse consumers, rather than adequately informing them on IoT devices with appropriate network security standards?
13. To ensure that our program is able to be of greatest value to the consumer, we also seek comment on whether we should focus our cybersecurity labeling program on to IoT “products,” rather than IoT devices as defined above.  For such purposes we could define an IoT product consistent with the NIST definition as follows:  An IoT device and any additional product components (e.g., backend, gateway, mobile app, etc.) that are necessary to use the IoT device beyond basic operational features. NIST, Recommended Criteria for Cybersecurity Labeling for Consumer IoT Products at 3-4 (2022), https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.02042022-2.pdf.
  We seek comment on this proposed definition of an IoT product eligible for an IoT label.
14. Further, we seek comment on whether a program that addresses products (as opposed to just devices) would be more consumer friendly, as the public may find it easier to understand that the product (as a whole) they are looking to purchase meets the IoT security standards, rather than trying to parse which devices (i.e., parts of the product) meet applicable standards.  Likewise, would limiting the label to devices create confusion with consumers who may not fully understand the label does not apply to the entire product?  If the program only encompasses devices, should we differentiate our labeling in situations where a product contains multiple devices, and some devices are labeled and some are not?  If so, how could we make this differentiation without causing consumer confusion?  How do we mitigate consumer confusion if a device label is used in a common packaging environment?  We seek comment on these issues.
15. We also seek comment on whether either definition fully accounts not only for the IoT device or product itself, but also the other components that make the IoT device functional and may be vulnerable to attack.  For example, there is a category of IoT devices that do not connect directly to the customer’s home Wi-Fi network; instead, they connect to an intermediate communication device (i.e., Wi-Fi Gateway) which connects to the home Wi-Fi network. See, e.g., Govee, Govee Wi-Fi Water Sensors Alarm, https://us.govee.com/products/wireless-water-leak-detector (last visited July 17, 2023).
  What are the risks and vulnerabilities inherent in the communication between these types of IoT devices or products and their environment? See Internet Research Task Force (IRTF), Request for Comments: 8576, Internet of Things (IoT) Security: State of the Art and Challenges (IETF RFC8576) (Apr. 2019), https://www.rfc-editor.org/rfc/pdfrfc/rfc8576.txt.pdf.
  Are there other IoT devices or products that similarly have vulnerabilities that would be outside the scope of our proposed definition?  Should such concerns be considered when adopting a definition for devices and/or products that would be eligible for the labeling program?  If so, how?
16. Finally, we recognize that IoT devices and products have proliferated not only in the non-enterprise space, but also in the workplace from office settings to field settings, from medical settings to industrial settings.  As such, we seek comment on whether to focus our IoT labeling program on consumer IoT devices or products intended for consumer use or include “enterprise” devices or products intended for industrial or business use, or to otherwise tailor the scope of devices and products covered by the labeling program based on their usage.  If commenters propose that the program include a broader array of devices or products beyond the non-enterprise setting, what additional considerations should we take into account for these products or devices, including the relative sophistication and specific needs of the purchasers of these devices?
17. IoT Products Excluded from the Commission’s Labeling Program.  Pursuant to the Secure and Trusted Communications Networks Act of 2019, Secure and Trusted Communications Networks Act of 2019, Pub. L. No. 116-124, 133 Stat. 158 (2020) (codified as amended at 47 U.S.C. §§ 1601-1609 (Secure Networks Act)).
 and the Commission’s rules, 47 CFR §§ 1.50002, 1.50003.
 the Commission’s Public Safety and Homeland Security Bureau (PSHSB) publishes and regularly updates a list of communications equipment and services produced or provided by specified entities (“Covered List”), which have been determined to pose an unacceptable risk to the national security of the United States or the security and safety of United States persons (“Covered List”). See List of Equipment and Services Covered By Section 2 of The Secure Networks Act, https://www.fcc.gov/supplychain/coveredlist (last updated Sept. 20, 2022).
  Beginning on February 6, 2023, the Commission no longer permits authorization of any applications for equipment certification of any equipment that has been identified as “covered” equipment on the Commission’s Covered List. 47 CFR § 2.903.  See, Protecting Against National Security Threats to the Communications Supply Chain through the Equipment Authorization Program, EA Docket No. 21-233; ET Docket No. 21-232, Report and Order, FCC 22-84 (2022).  In addition, as of February 6, 2023, new “covered” equipment can no longer qualify under part 15 rules as exempted from the need from an equipment authorization, and thus is prohibited from being imported, marketed, sold, or operated in the United States.  Id.
  This decision did not, however, revoke any previously authorized equipment that now constitutes “covered” equipment, although it may do so in the future. Id.
  In this proceeding, we propose to exclude from the labeling program any such previously authorized “covered” equipment.  We seek comment on this proposal.
18. In light of this prohibition, we similarly propose to exclude from the program any communications equipment that now, or in the future, has been placed on the Covered List.  We also propose to exclude any IoT device that is produced by an entity identified on the Covered List as producing “covered” equipment.  Furthermore, we propose to exclude from the Commission’s labeling program any device or product from a company named on the Department of Commerce’s Entity List, See, e.g., Bureau of Industry and Security, U.S. Department of Commerce, Supplement No. 4 to Part 744 – Entity List, https://www.bis.doc.gov/index.php/documents/regulations-docs/2326-supplement-no-4-to-part-744-entity-list-4/file (May 19, 2023).
 the Department of Defense’s List of Chinese Military Companies, See, e.g., Entities Identified as Chinese Military Companies Operating in the United States in Accordance with Section 1260H of the William M. (“Mac”) Thornberry National Defense Authorization Act for Fiscal Year 2021 (Public Law 116-283), Tranche 2, U.S. Department of Defense, https://media.defense.gov/2022/Oct/05/2003091659/-1/-1/0/1260H%20COMPANIES.PDF (Oct. 5, 2022).
 or similar lists. The cybersecurity label has the potential to convey important information about a device or product’s security. We find it could be harmful to consumers to portray such a message on devices or products made by companies that our sister agencies have identified publicly as part of their national security review. We seek comment on this proposal and on other government lists we should consider. How can the Commission ensure any such proposed exclusion is implemented?  Should applicants be required to include a written and signed attestation that the particular equipment for which they seek approval is not “covered” equipment (i.e., is not communications equipment that has been identified and placed on the Commission’s Covered List)?  Are there other products or categories of products that we should explicitly exclude from the program?
C. Oversight and Management of the Proposed IoT Cybersecurity Labeling Program
19. As discussed above, we believe that close partnership and collaboration between the federal government, industry, and other stakeholders is vital to ensuring the success of the proposed voluntary IoT cybersecurity labeling program.  Moreover, a collaborative environment that can leverage the expertise, incentives, and authority of various constituencies in this context would allow for the swift establishment and maturity of the program with broad industry and consumer acceptance that could adapt to a rapidly evolving threat landscape.  As such, we propose a public-private partnership in the oversight and administration of this labeling program, subject to ultimate Commission supervision.
20. In seeking comment on the proposed IoT labeling program, we note that NIST identified several key elements of a potential labeling program.  These include the use of certain recommended baseline product criteria (including both technical product criteria that promotes cybersecurity-related capabilities and non-technical criteria providing important product information), See, e.g., NIST, Recommended Criteria for Cybersecurity Labeling for Consumer Internet of Things (IoT) Products at 3-10 (2022), https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.02042022-2.pdf; NIST, Report for the Assistant to the President for National Security Affairs (APNSA) on
Cybersecurity Labeling for Consumers: Internet of Things (IoT) Devices and Software, A summary review of labeling actions called for by Executive Order (EO) 14028: Improving the Nation’s Cybersecurity at 4-5 (2022), https://www.nist.gov/system/files/documents/2022/05/24/Cybersecurity%20Labeling%20for%20Consumers%20under%20Executive%20Order%2014028%20on%20Improving%20the%20Nation%27s%20Cybersecurity%20Report%20%28FINAL%29.pdf (NIST Summary Report).
 the use or development of requirements and/or standards that are informed by the recommended product criteria, NIST, Recommended Criteria for Cybersecurity Labeling for Consumer Internet of Things (IoT) Products at 16 (2022), https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.02042022-2.pdf; NIST, A summary review of labeling actions called for by Executive Order (EO) 14028:  Improving the Nation’s Cybersecurity at 1 (2022), https://www.nist.gov/system/files/documents/2022/05/24/Cybersecurity%20Labeling%20for%20Consumers%20under%20Executive%20Order%2014028%20on%20Improving%20the%20Nation%27s%20Cybersecurity%20Report%20%28FINAL%29.pdf.
 the establishment of a conformity assessment program to assess whether particular products satisfy the developed requirements and/or standards, NIST, Recommended Criteria for Cybersecurity Labeling for Consumer Internet of Things (IoT) Products at 21 (2022), https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.02042022-2.pdf.
 and the creation of labeling requirements for IoT products (a single label indicating that a product has met the baseline standard, as well as a means to access additional label information for the specific IoT product) that will aid in IoT purchasing decisions by enabling comparisons among products and providing important information about cybersecurity considerations. Id. at 18-19.
  NIST also noted that “one size does not fit all,” and that multiple solutions might be offered. Id. at 1.

21. We propose to establish a program where the Commission would create and own a new distinctive trademark to be used in a voluntary program for IoT cybersecurity labeling and would take appropriate steps to authorize its overall use in a way that ensures the integrity of the mark and the label.  We also propose to have third parties play integral roles in the management and administration of the labeling program.  These entities would, for example, be authorized to conduct activities such as development of requirements or standards for consideration by the Commission, and assessment of IoT devices and products for conformity with those requirements or standards subject to supervision of the Commission.  Subject to Commission oversight, third parties could evaluate and authorize the use of the Commission’s trademark on an IoT device or product.  In this regard, we propose to incorporate and leverage the specialized expertise of third parties, where appropriate, into our standards, application and review procedures.
22. Oversight and Management of the Labeling Program.  In NIST’s White Paper on a cybersecurity labeling program for consumer IoT products, it discussed the need for management and oversight of the overall labeling program.  Specifically, it contemplated that there would be one entity (the “labeling scheme owner”) that would manage the labeling program, determine its structure and management, and perform oversight to ensure that the program is functioning consistently in keeping with overall objectives; further, this entity would be responsible for defining the conformity assessment requirements, developing the label and associated information, and conducting consumer outreach and education.” NIST, Recommended Criteria for Cybersecurity Labeling for Consumer IoT Products at 2 (2022), https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.02042022-2.pdf; see also NIST, IoT Product Criteria (May 24, 2022), https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/iot-product-criteria.
  We seek comment on the appropriate entity or entities to serve in the oversight and management of the labeling program.  Should the Commission be the scheme owner to oversee as well as manage the labeling program?  If the Commission takes on the role of overseeing the labeling program, should one or more third-party administrators, as detailed below, manage the tasks identified above or some portion of them? Or, should one or more third-party administrators be designated as the scheme owner(s), and if so, how should the Commission retain and exercise its oversight responsibilities?
23. Use of Third-Party Administrator(s).  We seek comment on how one or more third-party administrator(s) might be utilized to manage some or all of the functions outlined above as NIST ascribed to the labeling program scheme owner, or how such an entity, or entities, might otherwise manage all or some elements of the envisioned labeling program to ensure effectiveness, efficiency, consistency, and timely implementation, subject to ultimate Commission supervision.  We seek comment on the best approach for utilizing the respective levels of expertise that reside in the Commission, other federal government entities, industry, and other stakeholders.  In particular, we seek comment on whether there are existing stakeholders, public or private, who are well situated to convene and develop the IoT security standards among stakeholders as to a particular IoT device or product, or classes of IoT devices or products, to ensure the consistency and fair administration of the proposed labeling program.  Further, could a third-party administrator approve, or submit to the Commission for approval, more specific standards for conformance assessment of the proposed criteria, or for otherwise evaluating program applicants?  Could a third-party administrator set the requirements for testing laboratories?  Should the Commission consider designating a third-party administrator or other outside entit(ies) to authorize the use of the envisioned cybersecurity label, and if so, what oversight should it exercise, for example, to ensure the integrity of the mark and label?
24. If the Commission were to utilize one or more third-party administrator(s), we seek comment on how we should select such administrator(s).  What qualifications should a third-party administrator possess, and how should the Commission intake and evaluate applications?  What national security considerations are relevant to such qualifications? Should a third-party administrator(s) be required to have previous experience administering an IoT product or similar conformity assessment program?  Given the diversity in IoT devices and products, would it be preferable for third party administrators to have varying areas of expertise?  What level of control or oversight should the Commission retain, and what level of guidance should be provided?  Are there entities in this space that should be considered for this role and, if so, why?  Are there benefits to utilizing multiple third-party administrators versus a single administrator?  If there are multiple administrators, how could the Commission ensure standards are consistently applied across similar devices and avoid conflict among administrators?  How could the Commission reconcile the functionalities of each administrator to avoid conflict?  Are there other attributes or qualities that the Commission should require of an administrator?  For example, should the administrator be required to be a non-profit entity?  Should the administrator establish that it would be neutral and independent, with no conflicts of interest (financial or organizational) on the part of the organization or its officers, directors, employees, contractors, or significant subcontractors?  Should we direct PSHSB, coordinating with the Office of the Managing Director and the Office of Engineering and Technology, to develop and implement a selection or qualifications review process?  The Commission has exercised its right to delegate authority in other circumstances involving such technical matters.  See, e.g., Facilitating Shared Use in the 3100-3550 MHz Band, Second Report and Order and Order on Reconsideration and Order of Proposed Modification, 36 FCC Rcd 5987, para. 163 (2021) (Commission delegated to the Wireless Telecommunications Bureau (WTB) authority to develop and implement a clearinghouse selection process and the authority to seek notice and comment on what adjustments to the procedures adopted by the Commission would be required to tailor them to the relocation in the proceeding); see also Amendment of Part 2 of the Commission's Rules to Allocate Spectrum Below 3 GHz for Mobile and Fixed Services to Support the Introduction of New Advanced Wireless Systems, Ninth Report and Order and Order, 21 FCC Rcd 4473, 4518, para. 83 (2006) (Commission delegated “to the WTB the authority to select one or more entities to create and administer a neutral, not-for-profit clearinghouse to administer the cost-sharing plan for the [Fixed Microwave Service] incumbents in the 2.1 GHz band”).

25. Cybersecurity Labeling Authorization Bodies.  We seek comment on how IoT devices or products can demonstrate compliance with the IoT security standards, once they are developed.  In the context of the Commission’s existing equipment authorization process, Telecommunications Certification Bodies (TCBs), Telecommunications Certification Bodies (TCBs) are private entities that are recognized by the FCC to test and certify electronic devices on behalf of the FCC.  TCBs are responsible for testing electronic devices to ensure that they comply with FCC regulations related to radio frequency emissions and safety.  TCBs issue certifications to electronic device manufacturers that demonstrate compliance with FCC rules.
 which are accredited third parties recognized by the Commission,  47 CFR § 2.962(e).
 certify RF equipment based in part on testing for compliance with applicable technical RF requirements on behalf of the Commission and in accordance with the Commission’s rules and standards.  TCBs may then be subject to international Mutual Recognition Agreements which determine acceptance of their conformity assessment results by other countries.  We anticipate that we could draw from this type of program’s organizational structure to assess IoT devices and products for compliance with the IoT cybersecurity standards, once they are developed.  In the context of IoT labeling, instead of RF-based testing and certification, we envision that third parties with expertise in security and compliance testing, as described below, could fill this role.  We refer to these entities as Cybersecurity Labeling Authorization Bodies (CyberLABs) for purposes of this discussion.  We seek comment on this proposal.
26. CyberLABs Accreditation or Recognition.  We propose that the Commission or one of its authorized third-party administrators would evaluate, accredit, or recognize the CyberLABs based on their qualifications, resources, and procedures.  If the Commission were to authorize third party administrators to evaluate, accredit or recognize these entities, what oversight would the Commission exercise over these entities or over the process?  We seek to ensure that CyberLABs have the necessary expertise and resources to properly test and assess IoT devices and products compliance with the IoT security standards.  To become accredited or recognized for the proposed IoT labeling program, we propose that a CyberLAB submit an application demonstrating that it meets the following requirements:
· Qualifications:  The CyberLAB has technical expertise in cybersecurity testing and conformity assessment of IoT devices and products.
· Resources:  The CyberLAB has the necessary equipment, facilities, and personnel to conduct cybersecurity testing and conformity assessment of IoT devices and products.
· Procedures:  The CyberLAB has documented procedures for conformity assessment.
· Continued competence:  Once accredited or recognized, CyberLABs would be periodically audited and reviewed to ensure they continue to comply with the IoT security standards and testing procedures. In addition to periodic audits, the FCC or its third-party administrator would also conduct random inspections of CyberLABs to ensure that they are complying with the IoT security standards and testing and label authorization procedures.  Additionally, existing standards, e.g., ISO/IEC 17025 could be leveraged for developing qualifications for a CyberLAB.  General requirements for the competence of testing and calibration laboratories, ISO/IEC 17025:2017 (Nov. 2017) (available at https://www.iso.org/standard/66912.html).

We seek comment on this proposed process and accompanying qualifications.  Are they an appropriate fit for our objectives?  Are there other options we should consider?  For example, could device manufacturers be allowed to perform testing and self-assessment subject to review by a third-party administrator or other entity?  What additional qualifications, if any, should we seek in a CyberLAB seeking to perform such as testing and conformity assessments?  What additional controls might be necessary, if any, to ensure a CyberLAB remains impartial when testing and assessing IoT devices and products with relevant standards? Should the Commission take into account any national security considerations, or adopt Character Qualifications for CyberLABs? See e.g., Policy Regarding Character Qualifications in Broadcast Licensing, Report, Order and Policy Statement, 102 FCC 2d 1179 (1986), recon. granted in part and denied in part, 1 FCC Rcd 421 (1986) (“Character Policy”).
  If so, what should these include?  Would this accreditation or recognition process impact our existing, or future, Mutual Recognition Agreements and, if so, how might it be remedied to avoid such impact? See Equipment Authorization – Mutual Recognition Agreements, https://www.fcc.gov/general/equipment-authorization-mutual-recognition-agreements for a list of current equipment authorization Mutual Recognition Agreements.
  Should CyberLABs be located only in the United States?  If the Commission should consider CyberLABs located outside the United States, what additional scrutiny, if any, should these entities be given during the Commission’s accreditation process?  Given the sensitive information that will be shared with CyberLABs, should accreditation or recognition include reviewing CyberLABs internal security practices? If requested by participating firms, should CyberLABs be required to provide information on their own security or internal practices to firms?
D. Development of IoT Cybersecurity Criteria and Standards
27. Applying the Baseline NIST Criteria.  We seek comment on the adoption of the NIST’s recommended IoT criteria as the basis for the proposed labeling program. See Appendix A (describing the NIST criteria).
  The NIST IoT criteria are based on product-focused cybersecurity outcomes, rather than specific requirements.  NIST contemplates that “the outcome-based approach allows for the flexibility required by a diverse marketplace of IoT products” and the “role of the scheme owner is critical to ensure that supporting evidence demonstrates that the product meets the expected outcomes.” NIST, Recommended Criteria for Cybersecurity Labeling for Consumer Internet of Things (IoT) Products at 14 (Feb. 4, 2022), https://doi.org/10.6028/NIST.CSWP.02042022-2.
  The NIST criteria include: (1) asset identification; (2) product configuration; (3) data protection; (4) interface access control; (5) software update; (6) cybersecurity state awareness; (7) documentation; (8) information and query reception; (9) information dissemination; and (10) product education and awareness. NIST White Paper at 4-10 (Feb. 4, 2022); NIST Summary Report at 4. 
  NIST has noted that while the first six of these criteria generally concern certain technical product criteria, the last four concern non-technical product criteria. NIST Summary Report at 4-5.
  How could NIST’s IoT criteria, such as product configuration, interface access control, product education and awareness, data production, asset identification, software updates, cybersecurity state awareness, documentation, information and query reception, etc., be leveraged to inform minimum IoT security requirements and standards in a manner that is suitable for conformity assessments (e.g., for technical-related testing and non-technical verification) in appropriate circumstances, or for self-attestation in others?  Are there other criteria we should consider?  Are there separate criteria that should be considered for higher risk IoT devices or classes of devices?
28. Standards Development Based on NIST Criteria.  We recognize that this conformity assessment program must be based on IoT security standards and testing requirements that the IoT devices and product must satisfy to be eligible to receive and use the label.  We propose that the IoT security standards be developed jointly with the industry and other stakeholders.  In this regard, there may be a number of expert Standards Development Organizations (SDOs), industry groups and government agencies that have both the technical expertise and other requisite experience to contribute to this task.  We seek comment on whether the Commission or an outside entity is in the best position to convene these stakeholders, and to timely develop the more specific detail that would allow the consistent and replicable testing necessary to ensure the outcome based NIST IoT labeling criteria are fulfilled.  Would the Federal Advisory Committee Act (FACA) Federal Advisory Committee Act (FACA) of 1972, Pub. L. 92-463, 86 Stat. 770 (Oct. 6, 1972); Pub. L. 105-153 111 Stat. 2689 (Dec. 17, 1997) (codified at 5 U.S.C. ch. 10); 41 CFR pt 102-3 (Federal Advisory Committee Management).
 limit the Commission’s ability to convene these stakeholders?  We seek comment on this proposal. 
29. We propose that the IoT security requirements and standards would be developed and implemented through the following process:
· Collecting information:  Conduct research, consult with experts, and review existing standards such as those developed and in use by international organizations. 
· Establishing requirements:  Informed by the new data, develop requirements that will help meet NIST core baseline criteria.
· Develop the standard:  With the requirements established, the standard can be developed. This will involve creating a document that outlines the requirements in a clear and concise manner and a clear mapping between the standards and the device or product criteria.
· Reviewing and improving:  Ensure that the standard is comprehensive, clear, and suitable for lab testing.
· Implementation:  Conduct training, testing, and monitoring to ensure that the requirements are satisfied.
We seek comment on the scope of this work and on this proposed process.  What additional factors should be included or otherwise factored into this process?  How can the Commission ensure that the views of small, women- and minority-owned businesses, including small IoT manufacturers, are considered in this process?  Considering the amount of work that the industry, NIST, and international community have already completed in this area, how could this work be leveraged to promote the swift development of standards for IoT cybersecurity labeling?  How long might this work take to complete?  We seek comment on the shortest but most thorough path to accomplishing this work and the minimum amount of time it should take to develop the standards.  We recognize there are other IoT security standards already available and seek comments on whether and why the Commission should consider their adoption.  Are there standards for particular IoT devices or classes of IoT devices that are already sufficiently mature such that they could be readily – or more quickly – adopted?  Should the program start with those devices or products?
30. We recognize that while the IoT cybersecurity label would not constitute a guarantee that the participating IoT product can withstand every single cyberattack, it should provide meaningful assurance to consumers that the IoT devices and products that display the label satisfy certain minimum cybersecurity standards and have specific cyber capabilities that demonstrably reduce relevant vulnerabilities appropriate to the class of device.  As such, while participation in the IoT labeling program would be voluntary, the Commission proposes to require those who choose to participate to adhere to the specific standards described above, and as recognized by the Commission.
31. We observe that in other contexts, the Commission periodically incorporates by reference various standards established by standards-setting bodies including, Incorporating external standards within the Commission’s rules has been a longstanding practice that reflects our desire, where appropriate and consistent with the Administrative Procedure Act and other statutes, to harmonize the rules with international standards and aligns the Commission’s rules with general federal agency guidance which urges government agencies to use industry-developed standards rather than develop their own.  See, e.g., Procedure for measuring electromagnetic emissions from digital devices, GEN Docket No. 89–44, Further Notice of Proposed Rule Making, 6 FCC Rcd 600, 601, paras. 7-8 (1991); see also OMB Circular A-119, Federal Participation in the Development and Use of Voluntary Consensus Standards and in Conformity Assessment Activities (updated Jan. 27, 2016), https://www.whitehouse.gov/omb/information-for-agencies/circulars/.  See also 47 CFR §§ 2.910, 2.950, 15.38.  See generally Administrative Conference of the United States, Recommendation 2011-5, Incorporation by Reference.
 but not limited to, the American National Standards Institute (ANSI), Accredited Standards Committee C63 (ANSC C63), American National Standards Institute, Accredited Standards Committee C63 is a standards organization that is responsible for developing electromagnetic compatibility (EMC) measurement standards and testing procedures.  ANSC C63’s standards are published by the American National Standards Institute under the ANSI nomenclature.  The Commission’s rules have referenced various versions of ANSC C63-originated standards for more than a quarter century.
 and the International Organization for Standardization; and the International Electrotechnical Commission. The International Organization for Standardization (ISO) is an independent, non-governmental international organization that develops voluntary international standards.  See ISO, https://www.iso.org/home.html (last visited July 17, 2023).  The International Electrotechnical Commission (IEC) develops international standards for all electrical, electronic, and related technologies.  See International Electrotechnical Commission, https://www.iec.ch (last visited July 17, 2023).
  As the Commission has noted, use of industry-based standards in this context is intended to ensure the integrity of the measurement data associated with an equipment authorization.  We recognize that, in addressing cybersecurity standards, timely adoption and speed are a prime benefit of a multi-stakeholder, industry-led approach, which militate in favor of a more streamlined process than the full Commission-level review described above.  Accordingly, we propose if standards are developed by outside bod(ies), that they submit the IoT security standards for acceptance by the Commission prior to utilization for testing and other conformity evaluation.  In this regard, we propose to direct PSHSB to place the standards on Public Notice for comment in accordance with the rulemaking requirements of the Administrative Procedure Act and, subsequent to reviewing any comments received, accept the standards as proposed or with amendments as warranted by the record.  Is this sufficient, or do commenters believe a Commission-level rulemaking is needed?  Alternatively, could an outside body adopt the standards and attest their conformity with the broader NIST criteria in a manner acceptable to the Commission, without the need for further action by the Commission?  What other streamlined processes might be appropriate for prompt review and validation of IoT security standards?
32. Conformity Assessments.  We seek comment on the process for assessing conformity of consumer IoT products and devices under the Commission’s IoT labeling program.  While we expect that third-party assessment (testing and other required assessment via CyberLAB, as discussed above) would provide an avenue for conformity assessment, we propose that other approaches also be considered.  For example, NIST describes how different IoT conformity assessment activities could be leveraged to demonstrate that consumer IoT devices conform to technical requirements, either exclusively or in combination.  In addition to third-party testing, assessment activities could also include the supplier’s declaration of conformity/self-attestation of the consumer IoT device where a statement is issued based on a comprehensive review that an IoT device or product comply with the IoT security standards. NIST, Recommended Criteria for Cybersecurity Labeling for Consumer Internet of Things (IoT) Products at 21 (2022), https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.02042022-2.pdf.
  While the Commission’s equipment authorization program has evolved over the years, as currently administered the program includes two procedures for equipment authorizations – certification and Supplier’s Declaration of Conformity (SDoC). Self-certification/attestation and SDoC are two different methods by which one can demonstrate compliance with regulations and standards.  Self-certification is a process in which the manufacturer/supplier takes full responsibility for ensuring that their product is compliant, and they may conduct their own testing and evaluation to ensure compliance.  SDoC is a document issued by a supplier of a product stating that the product complies with the relevant regulations and standards.  In this process, the supplier typically relies on the testing and evaluation conducted by an accredited third-party laboratory such as a TCB.
  Relevant technical RF-based standards listed in section 2.910 of the Commission’s rules are incorporated by reference in Part 2. 47 CFR § 2.910.
  The rules specify the obligations of the “responsible party” (e.g., the manufacturer or importer), including warranting that each unit of equipment marketed under the grant of certification or SDoC is materially identical to the unit that was tested or measured. 47 CFR §§ 2.906 - 2.1077.
  We seek comment on the extent to which any of these same procedures may be appropriate for the IoT labeling program.  Are there other alternative procedures that are more suitable for the IoT labeling program context?
33. Third-Party Compliance Testing and Assessment.  We propose that conformity assessments for IoT devices and products be based on compliance assessment (any testing and other requisite assessment) that includes supporting documentation and data submitted by the manufacturer or importer of the IoT device or product in question to a third-party such as a CyberLAB, and that the third party administrator could authorize the use of the IoT security label only for devices that meet the established IoT security standards.  Should all IoT devices or products be required to pursue third party compliance assessment, or are there classes of IoT devices or products that should allow for self-attestation?
E. Administering the IoT Labeling Program
34. Commission to Obtain Trademark.  We propose that the Commission utilize a certification mark to identify those products that meet the Commission’s IoT labeling requirements.  A certification mark is a type of trademark that is used to show consumers that particular goods and/or services, or their providers, have met certain requirements. 15 U.S.C. § 1127; United States Patent and Trademark Office, Mark applications, https://www.uspto.gov/trademarks/apply/certification-mark-applications (last visited July 17, 2023).
  Specifically, the mark indicates that:  (1) the owner of the mark controls who may use the mark; (2) the owner of the mark has determined that the user complies with a specific standard described by the owner of the mark; and (3) the owner of the mark does not itself produce the goods or services covered by the mark. 15 U.S.C. § 1064(5); Trademark Manual of Examining Procedure (TMEP) § 1306.01(a).
  The Commission has applied for a mark with the United States Patent and Trademark Office (USPTO), and as the owner of the mark, should this proposal be adopted, will ensure that the IoT products and devices bearing the mark meet FCC-approved cybersecurity labeling program requirements.  We also seek comment on whether the Commission should permit outside entities to authorize use of the mark where the terms of the program are met and what measures are necessary to ensure that the Commission is effectively controlling the use of the mark for purposes of trademark law.
35. Commission IoT Label.  We propose to implement a single binary label with layering. NIST, Recommended Criteria for Cybersecurity Labeling of Consumer Software at 25 (2022), https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.02042022-1.pdf (recommending that “a binary label (a single label indicating a product has met a baseline standard) should be adopted for a software cybersecurity label”).
  Under a binary label construct, products or devices will either qualify to carry the label or not qualify (i.e., not be able to carry the label) The ENERGY STAR program provides a single binary label if products meet the energy efficiency requirements set forth in ENERGY STAR product specifications.  For example, with the ENERGY STAR program, “[i]f the rated home is 15% more energy efficient than a home built to the 2004 International Residential Code (IRC), then it receives the label; if it is not more than 15% more efficient than the 2004 IRC, then it does not receive the label.”  Department of Energy, Rating Review Process (June 1, 2010), https://www.energy.gov/sites/prod/files/2013/11/f5/existing_labels.pdf.
 and “layers” of the label would include the Commission’s IoT mark representing that the product or device has met the Commission’s baseline consumer IoT cybersecurity standards and a scannable code (e.g., QR code) directing the consumer to more detailed information of the particular IoT product.  QR codes have become increasingly popular as a way to provide quick access to information, such as website URLs, product information, and contact details.  QR codes are made up of black and white squares arranged in a square grid and can represent much more information than traditional barcodes.

36. We seek comment on where authorized program participants should affix the security IoT label.  If the Commission’s program addresses devices (rather than products), should it be affixed on each IoT device or on the product packaging?  Should equipment that includes a user display screen be permitted to display the label on the user display screen rather than on the device itself?  Should there be limitations or prescriptions on how companies and third-party resellers can use the mark in advertising or sales displays, products or websites?  We also seek comment on other approaches with regard to what the label should display and where the label should be placed. The OPEN Government Data Act, Title II of the Foundations for Evidence-Based Policymaking Act of 2018, Pub. L. No. 115-435 (2019), requires agencies to use a machine-readable format when making data publicly available.  See 44 U.S.C. § 3506(b)(6); id. §§ 3502(17), (20), (22) (defining “data asset,” “open Government data asset,” and “public data asset”).  The term “machine-readable,” when used with respect to data, means “data in a format that can be easily processed by a computer without human intervention while ensuring no semantic meaning is lost.”  44 U.S.C. § 3502(18).

37. Layered Information.  We seek comment on the use of a QR code or URL to enable consumers to access more detailed information about the device or product, including specific security information, such as the device manufacturers’ level of support, software update history, privacy policy, and similar information.  To provide consumers with uniform information and minimize the potential for consumer confusion, we propose that there be a single IoT device or product registry associated with the Commission’s IoT cybersecurity labeling program, and that any QR code or URL included with the FCC IoT mark provide a link to the IoT product’s specific webpage within this IoT registry.  We propose to prohibit any additional QR codes or URLs be placed in connection with the Commission’s IoT mark.  We believe that this would help ensure the integrity of the Commission’s IoT label.  If third parties are authorized by the Commission to grant use of the cybersecurity IoT label, should the Commission also permit them to generate and specify the QR code and the URL that can be placed next to the FCC IoT mark and require them to prevent the program participants from affixing other QR codes or URLs next to the FCC mark?  Should the use of the IoT mark be prohibited without the associated QR code or URL?  What information must a company include if they reference the IoT mark in product listings or descriptions?  What alternative approaches should we consider?
38. QR Code.  We propose that the FCC IoT label include a QR code that contains consumer-friendly information that is available without Internet connection in addition to a URL to the device’s or product’s registry page, which is discussed below. While we think the use of a QR code is appropriate in conjunction with the layered labeling approach we are proposing here, we acknowledge that we previously rejected its use in other contexts, such as the required labeling under our equipment authorization rules.  We are not proposing to revisit those decisions in the context of this proceeding.  Similarly, we intend our proposals to operate distinct and separate from the provisions for the electronic labeling of radiofrequency devices contained in our equipment authorization rules (47 CFR § 2.935), and seek comment on whether we need to adopt or modify our rules accordingly.
  In order to prevent consumer confusion and allow for easy comparison among devices or products, we also propose that the information contained within the QR code for each certified device or product be uniform and include information that is helpful to non-expert, home users of IoT devices and products.  In this way, the label would be able to impact consumer purchasing decisions, which are oftentimes made under time pressure while the consumer is at the store choosing between products.  We propose the QR code include a description of the device’s security (e.g., easy to understand explanation of what security standards the device meets, and how these standards protect the consumer).  We also propose the QR code include a statement that while the label indicates the device or product meets certain cyber security criteria that reduce risk, it does not eliminate risk entirely and the label does not imply product endorsement by the label program and that the consumer is encouraged to visit the product registry linked by the URL provided therein to get the most up-to-date security and other information related to the IoT device or product.  We seek comment on this proposal and what additional or other information should be embedded in the QR code to be of benefit to consumers.
39. Given the static nature of the information stored in the QR code, we urge commenters to consider the types of information that would be appropriate for consumer decision-making without needing to have the information stored in the QR code updated.  Alternatively, the QR code could merely provide a link to the IoT registry page for the device or product in question, discussed below.
40. We propose to require that the manufacturer disclose the guaranteed minimum support period for an IoT device or product, during which the manufacturer commits to identify and patch security vulnerabilities in the product. See NIST, Recommended Criteria for Cybersecurity Labeling for Consumer IoT Products, at 10 (Feb. 4, 2022), https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.02042022-2.pdf.
  While we recognize the length of such a support period is at the discretion of the manufacturer, and may even be zero, we seek comment on the benefits and drawbacks of requiring a manufacturer to disclose, via the label or associated registry entry, the length of time that an IoT device or product would be supported, and the level of support provided.  Should they also be required to disclose whether all or only critical patches will be supported, the regularity with which such patches are made available, whether they are automatically deployed, or what additional steps a consumer may need to take to remain secure when support ends?  Should we require the manufacturer to provide notice when that support ends?  How can we ensure this information is meaningful to consumers? We seek comment on these options and any alternatives to help provide consumers with necessary, accurate, and timely information.
41. IoT Registry.  We propose the use of an IoT registry where the public may access a catalog of devices or products that are approved pursuant to the Commission’s IoT labeling program.  This IoT registry would be accessible via the Internet and serve as a one-stop reference for the public to understand which products in the market bear the IoT label (e.g., consumers could check the registry before they shop).  The IoT registry could contain IoT security-related information that is sortable and searchable by manufacturer or brand, device or product vendor, device or product name, model number, firmware/software build version, and other identifying variables, such as a unique asset identification number.  We seek comment on this approach.  Are there any similar product registries that have already been established or that are being initiated, and that might be leveraged for these purposes?  Should the Commission consider selecting and overseeing a third-party IoT registry administrator, and if so, how could such an administrator be funded?  Should there be more than one administrator or more than one registry, and if so, how should we ensure that accurate, up to date, and complete information is contained in each of them?  Should it be the same third-party administrator contemplated to manage the other aspects of the labeling program as described herein?
42. The QR code and/or the URL associated with the IoT label would include a link to the IoT registry, which would provide detailed information on the IoT product through the product’s webpage within the IoT registry.  We seek comment on what information should be included within the IoT registry and associated with the QR codes.  If the URL is the sole piece of information associated with the QR code, how should registry information be presented or organized to ensure consumer-friendliness?
43. We propose that, among other information, the IoT registry might provide the following information for each approved device or product:  1) how to operate the device securely (e.g., basic cyber hygiene to include changing default passwords) and, if applicable, what level of security the device or product has achieved; 2) whether the product’s security settings are protected against unauthorized changes, including disabling its security; 3) where the device was manufactured; and 4) when the registry information for the device was last updated.  What other information should be included? Would the information included in the CMU IoT Security and Privacy Label (CMU Label) be an appropriate model for each IoT product’s listing provided within the IoT registry? See, generally, Carnegie Mellon University, IoT Security & Privacy Label, iotsecurityprivacy.org; see also, Pardis Emami-Naeni, Yuvraj Agarwal, & Lorrie Cranor, Carnegie Mellon University, CMU IoT Security and Privacy Label, https://iotsecurityprivacy.org/downloads/CMU_IoTLabel_handout.pdf.
  CMU Labels are divided into three major sections: 1) security mechanisms, 2) data practices, and 3) more information, with various data fields under these sections (e.g., security updates, access control, sensor type, privacy policy, manufacturer contact information, and platform compatibility). In the security mechanisms section, certain key security information such as security updates, access control, vulnerability disclosure and management, encryption and key management are disclosed.  In the data practices section, certain privacy related information such as types of sensors used, data storage policy, and data retention policy and other privacy policy are disclosed.  In the more information section, additional information such as phone number and email address for the device manufacturer and information on product compatibility is provided.
  CMU Labels often link to external sites, such as manufacturers’ websites, to provide more detailed information.  Would linking to external websites, over which the Commission would have no oversight or control, be appropriate for the Commission’s IoT labeling program and the IoT registry?  How could we ensure the content of the information provided in the external links is accurate and up-to-date?  Are there additional exemplary labels that the Commission should consider?  What other additional details should be disclosed to inform consumers of cybersecurity risks underlying the IoT product?  What details can potentially be omitted?  How can the Commission otherwise ensure the information provided in the IoT registry is meaningful and understandable by consumers?
44. We further ask whether such IoT registry might also be used by retailers to assist them with choosing products that carry the IoT label for sale in their stores and whether retailers may use the registry to confirm that the products that they market legitimately bear the FCC’s IoT label.  If so, should the registry maintain different sets of information for general consumers and retailers?  What additional information would retailers want to see but is not relevant to general consumers?
45. Updating Information.  We seek comment on how to ensure consumers are not misled by the meaning of the IoT label and can obtain up-to-date information about their device or product.  Unlike other labeling programs, such as the Commission’s Broadband Consumer Label, Empowering Broadband Consumers Through Transparency, CG Docket No. 22-2, Report and Order and Further Notice of Proposed Rulemaking, FCC 22-86 (2022) (Broadband Label Order).
 or the ENERGY STAR label, Dept. of Energy, How a Product Earns the ENERGY STAR Label, https://www.energystar.gov/products/how-product-earns-energy-star-label (last visited July 17, 2023).
 the Commission’s labeling program addresses cybersecurity risk, which is constantly changing and requires constant updating.  For example, if a new vulnerability is discovered, the product would remain unsecure until that newly discovered vulnerability is patched.  We propose that consumers be made aware of any vulnerabilities or updated product information through the IoT registry.  That way, once the product’s webpage within the IoT product registry is updated to indicate that the authorization to use the mark is outdated, and/or the device is no longer maintained/updated, the consumer can understand this information by accessing the webpage using the QR code and/or the URL provided next to the FCC IoT label.  Should we impose a duty on manufacturers or importers of the IoT devices and products to notify the IoT registry operator when they become aware of an unpatched vulnerability that poses security risks to their IoT devices and products?  Are there other events that should trigger IoT product manufacturers or importers to notify the registry operator that their IoT registry device or product page should be updated?
46. We seek comment on these proposals, and on any other ways to ensure consumers have up-to-date information regarding IoT devices or products labeled under the program, as well as have an understanding that the FCC cybersecurity label is not a guarantee against all cybersecurity threats.  What additional information might be warranted to help minimize the potential for customer confusion?
47. Application/Renewal.  We propose that IoT label applicants file for renewal each year, together with supporting evidence that the products still meet the FCC’s IoT requirements, as tested and administered by the CyberLABs or as self-attested.  In this regard, we seek to ensure consumers have up-to-date information regarding the participating device or product, and to address end-of-life issues for devices previously approved, but that no longer warrant continued authorization to use the label.  Should the label include the specific date, or the year, the label was awarded to help notify consumers how fresh the authorization is?  Should the FCC IoT labels on the device or product have an expiration date?  How do we ensure consumers are aware of when a device with an FCC IoT label is no longer maintained and/or updated by manufacturers, and may no longer meet up-to-date cybersecurity requirements?
48. We seek comment on this proposal to employ a renewal process.  Should the Commission consider other timeframes on a shorter or longer basis?  Should there be an event in the product’s life-cycle or a security event that should trigger the applicant to file for an early renewal?  When would such an event trigger early renewal, versus filing updated information with the program administrator and updating the IoT registry?  Similarly, are there incidents or developments that might warrant the removal of the IoT cybersecurity label, and what might those circumstances be?  After the IoT device or product is authorized for the first time, what supporting documents should the program participants provide to validate and renew their authorization to use the label?  Must it be retested annually?  How should the IoT registry reflect that an authorization to use the label is out of date?
49. We also seek comment on the interplay between the proposed IoT cybersecurity labeling program and our current equipment authorization rules.  Given that the review process for the proposed program will likely not be administered in the same manner, and by the same entities, as are involved in our equipment authorization program, we propose that they generally operate in a distinct manner.  However, given that equipment subject to the requirements of our equipment authorization rules must satisfy those rules before they can be manufactured and sold in the United States, we propose that approval be granted under the cybersecurity labeling program only after any applicable requirements of the equipment authorization rules have been satisfied for the relevant device or product.  We seek comment on these proposals and on any other ways in which we should address the potential interplay between the proposed IoT cybersecurity labeling program and our current equipment authorization rules.
50. Costs.  The Commission permits TCBs to establish and assess fees for processing equipment authorization applications and conducting other Commission-required tasks. 47 CFR § 2.962(f)(3).
  We anticipate that similarly situated third parties in this program may wish to charge for their services and seek comment on whether there is any oversight the Commission needs to exercise over such charges.  Further, we propose, that when a proposed grant of labeling authority is submitted to the FCC for action it should be accompanied by an application fee pursuant to our authority under section 8 of the Communications Act. 47 U.S.C. § 158.  Section 8(c) of the Act requires the Commission to, by rule, amend the application fee schedule if the Commission determines that the schedule requires amendment so that: (1) such fees reflect increases or decreases in the costs of processing applications at the Commission or (2) such schedule reflects the consolidation or addition of new categories of applications.  47 U.S.C. § 158(c).  Section 8(c) of the Act does not mandate a timeframe for making any such amendments under section 8(c).  If the Commission determines that the application fee schedule may require an amendment pursuant to section 8(c), the Commission will initiate a rulemaking to seek comment on any proposed amendment(s) to the application fee schedule.  We do so here.
  We propose to follow the fee calculation methodology adopted by the Commission in the 2020 Application Fee Report and Order. Amendment of the Schedule of Application Fees Set Forth in Sections 1.1102 through 1.1109 of the Commission’s Rules, MD Docket No. 20-270, Report and Order, 35 FCC Rcd 15089, 15127, para. 115-117 (2020).  Application fees are adjusted every two years to reflect changes in the Consumer Price Index.  See, e.g., Amendment of the Schedule of Application Fees Set Forth in Sections 1.1102 through 1.1109 of the Commission’s Rules, MD Docket No. 20-270, Order, FCC 22-94 (2023).
  We seek comment on this proposal and any changes or modifications we should consider here.
51. Investigation, Disqualification, and Enforcement.  Ensuring that the label remains a trusted and valuable resource to purchasers requires that the integrity of the devices and products bearing the label is maintained.  As such, we seek comment on how to enforce the labeling program requirements.  To the extent that non-Commission entities are better situated to perform, and receive approval to perform, certain functions, should they also be required to conduct a certain number of random audits of the certified IoT devices and products to confirm that they are in compliance?  Are there types of market surveillance that should be conducted, and by whom?  Should we allow consumer or third-party complaints?  Should the Commission or other entities accept and process such complaints?  What should the Commission’s role be in audit and oversight?  For any non-compliance, we could rely on a combination of enforcement procedures such as administrative remedies under the Communications Act (e.g., show cause orders, revocation proceedings, forfeitures, consent decrees, cease and desist orders, 47 U.S.C. § 312(b).
 and penalties 47 U.S.C. § 503(b)(1).
) or civil litigation for breach of contract or trademark infringement, in which the Department of Justice (DOJ) would participate. 28 U.S.C. §§ 516, 519.
  As noted above, we also seek comment on what, if any, additional measures are necessary to ensure that the Commission is effectively controlling use of the certification mark for purposes of trademark law.  What enforcement measures would be appropriate for firms that falsely put the IoT certification mark or label on their products?  How would it be enforced if firms are outside of the United States?  In the more contractual context of the ENERGY STAR program, EPA has set out certain Disqualification Procedures that it would apply if a product fails third-party verification testing, or if it fails subsequent Department of Energy (DOE) appliance testing or in the event of product nonconformity. See Disqualification Procedures ENERGY STAR® Products, (Last updated: Feb. 28, 2018) https://www.energystar.gov/sites/default/files/asset/document/Disqualification_Procedures_0.pdf.
  In particular, this process gives the ENERGY STAR Partner notice and an opportunity to dispute the assessment with EPA before a formal disqualification decision is made. Id. at 1.
  The Disqualification Procedures specify certain steps that ENERGY STAR Partners must take in the event of a disqualification (e.g., removing references to ENERGY STAR in the product labeling, marketing, etc.). Id. at 2.
  Should we adopt a similar disqualification procedure under our rules?  What enforcement measures would be appropriate in addition to revoking authorization to use the IoT label?  What procedures or consequences should apply where a device or product was certified under one set of standards but is not capable of meeting a new or updated standard adopted later?  How should the participants address the products that have the IoT security labels affixed to their products when their products become non-compliant?  If an applicant is denied authority to use the Commission’s IoT label, should they be able to appeal that decision?  We also seek comment on any recordkeeping and audit requirements for compliance review purposes. See, e.g., 47 CFR § 2.2.938 (imposing record retention requirements for certain categories of documents related to equipment authorizations); 47 CFR § 2.962(g) (requiring TCBs to engage in post-market surveillance).

52. Conversely, where a program participant has received authorization to utilize the Commission's IoT Label and has appropriately maintained the device’s security measures, does this represent an indicium of reasonableness that might serve as a defense or safe harbor against liability for damages resulting from a cyber incident, e.g., data breach, denial of service, malware?  While we clarify that we do not intend at this time for the labeling program in and of itself to preempt otherwise existing law, re there other affirmative measures that the Commission should consider adopting that should be afforded to devices that have achieved and maintained a Commission IoT security label?
53. Consumer Education.  We expect that the success of this program will rely upon a robust education campaign with shared responsibilities among the scheme owner, manufacturers, retailers, industry, and non-profit security groups to promote label recognition, brand trust, and transparency of what the Commission’s IoT cybersecurity label means.  We seek comment on whether the education campaign used should be comprised of the consumer education materials recommended by NIST, NIST, Recommended Criteria for Cybersecurity Labeling for Consumer Internet of Things (IoT) Products at 19-20 (Feb. 4, 2022), https://doi.org/10.6028/NIST.CSWP.02042022-2.
 which include providing consumers online access to information addressing:
· Intent and Scope:  What the label does and does not mean, including addressing potential misinterpretations (e.g., stating that meeting the label security criteria reduces risk but does not eliminate it entirely, and that labeled products are not necessary more secure than unlabeled products); and a statement that the label does not imply product endorsement by the Commission;
· Product Criteria:  The cybersecurity properties that must be met for a device to have the Commission label and how and why these properties were selected; including information on how the criteria address security risks both to the consumer and to others for common intended uses of the products;
· A glossary of applicable technical terms written in plain English;
· General information about conformity assessment and how cybersecurity properties are evaluated;
· Declaration of Conformity:  The device’s specific declaration of conformity to the IoT security standards, including the date the label was last awarded;
· Scope:  The kinds of devices eligible for the label and an easy way for consumers to identify labeled devices;
· Changing applicability:  The current state of device labeling as new cybersecurity threats and vulnerabilities emerge;
· Security considerations for end-of-life IoT devices and implications for functionality if the device is no longer connected;
· Expectations for consumers:  The responsibility consumers share in securing the device software and how their actions (or inactions) can impact the device’s software cybersecurity; and
· Contact information for the labeling program and information on how consumers can lodge a complaint regarding a product label.
54. The Commission seeks comment on anticipated costs of such a consumer education campaign particularly with regard to upfront costs that will be incurred to start the program.  We also seek comment on mechanisms for conducting the outreach consistent with the constraints on federal outreach A number of appropriations riders apply to agency outreach and publicity efforts.  See, e.g., Division E - Financial Services and General Government Appropriations Act, 2023, Title V—Independent Agencies, Federal Communications Commission, Salaries and Expenses of the Consolidated Appropriations Act, 2023 –Pub. L. No. 117-328 (12/29/22) (sections 630, 631, 715 and 718 contain limitations on publicity).
 and the possibility of public or private partnerships that may facilitate a consumer education campaign.
55. Integrity of the National Government-based IoT Cybersecurity Label.  We seek comment on ways to avoid consumer confusion between the government-based IoT cybersecurity label and existing and future IoT cybersecurity labeling schemes such as UL and IoT Security Trust Mark. See UL Solutions IoT device security rating program at https://www.ul.com/services/ul-verified-iot-device-security-rating and IoT Security Trust Mark certification program at https://iotsecuritytrustmark.org/.
  What features and assurances can the Commission’s label provide to improve customer awareness of the security of a given IoT device?  Alternatively, should the FCC label act as an aggregator for other labeling programs ensuring that these programs meet the IoT security standards in addition to any wider or sector specific security needs the scheme owners feel necessary.  What about other labeling programs in other countries?  How should the Commission coordinate and engage with other international bodies maintaining labeling programs to develop recognition of the Commission’s IoT Label, and where appropriate, mutual recognition of those international labels? Our proposal seeks to implement this program for devices or products for sale in the United States.  What steps, if any, should we take to ensure the FCC label is not mistaken for compliance with IoT security or RF-emission standards in other countries?
56. Accessibility.  The Commission emphasizes its continued commitment to ensuring that the labeling program is accessible and usable by individuals with disabilities.  With respect to the Commission’s Broadband Consumer Label, in 2022, the Commission noted that the Consumer Advisory Committee (CAC) determined that participating providers can best ensure accessibility to printed and online information by relying on well-established legal requirements included in the Americans with Disabilities Act and by following the guidance developed by the Web Accessibility Initiative. FCC 22-7, para. 27.
  We seek comment on whether relying on these guidelines provides the best likelihood of ensuring that consumers with disabilities will be able to access necessary information about their IoT devices or products.  We seek comment on how best to ensure that any adopted IoT cybersecurity label is accessible to persons with disabilities.
F. Legal Authority
57. We tentatively conclude that the Commission has authority to adopt the proposed IoT labeling program.  In particular, section 302(a) of the Communications Act authorizes the FCC “consistent with the public interest, convenience, and necessity, [to] make reasonable regulations (1) governing the interference potential of devices which in their operation are capable of emitting radio frequency energy by radiation, conduction, or other means in sufficient degree to cause harmful interference to radio communications; . . .” 47 U.S.C. § 302a(a).
  While this program would be voluntary, entities that elect to participate would need to do so in accordance with the regulations the Commission adopts in this proceeding, including but not limited to the IoT security standards, compliance requirements, and the labeling program’s operating framework.  We tentatively conclude that the standards the Commission proposes to apply when administering the proposed labeling program fall within the scope of “reasonable regulations… governing the interference potential of devices….” Id.
  We seek comment on this reasoning.
58. The Commission has exercised authority in other contexts to secure both software and firmware to prevent unauthorized modification that would compromise a device or the data it transmits.  For example, in adopting technical rules for the Citizens Broadband Radio Service (CBRS), the Commission required end user devices to “contain security features sufficient to protect against modification of software and firmware by any unauthorized parties” and required that such devices “be able to protect the communication data that are exchanged between these elements.” Amendment of the Commission’s Rules with Regard to Commercial Operations in the 3550- 3650 MHz Band, GN Docket No. 12-354, Report and Order and Second Further Notice of Proposed Rulemaking, 30 FCC Rcd 3959, 4033-4034, para. 240 (2015).
  The Commission adopted a further obligation for identified security vulnerabilities to be resolved on a going-forward basis, and encouraged industry to develop best practices for end-to-end security that can be validated through the certification process. Id.
  By way of further example, in the 5 GHz band, the Commission, noting the potential for reprogramming of unlicensed national information infrastructure (U-NII) devices to operate outside of authorized device parameters, similarly adopted security measures requiring manufacturers to prevent software changes that would result in this outcome. Revision of Part 15 of the Commission’s Rules to Permit Unlicensed National Information Infrastructure (U-NII) Devices in the 5 GHz Band, ET Docket No. 13-49, First Report and Order, 29 FCC Rcd 4127, 4143, para. 54 (2014).
  Declining to mandate specific software security measures, the Commission required manufacturers instead to document their methods. Id.  See also 47 CFR §§ 2.1033(b)(13) (requiring applications for certification of scanning receivers to describe the methods used to comply with requirements that they be incapable of being modified in a way that would allow them to receive cellular frequencies), 15.407(i) (requiring U-NII devices to contain security features to protect third parties from reprogramming a device to operate outside the parameters for which it was certified; providing a non-exclusive list of means for doing so).
  In addition, the Commission’s rules require security protocols and procedures to ensure the integrity of transmission related between and among white space devices and databases. See 47 CFR § 15.713(1).

59. Our proposed labeling program rules are intended to ensure that IoT devices have implemented certain minimum cybersecurity protocols to prevent their being hacked by bad actors who could cause the devices to cause harmful interference to radio communications. See also 47 U.S.C. § 333 (“No person shall willfully or maliciously interfere with or cause interference to any radio communications of any station licensed or authorized by or under this chapter or operated by the United States Government.”).
  As noted above, in the 5 GHz context, the Commission identified concerns about security vulnerabilities that could, if exploited, lead equipment to operate outside established parameters, with the associated risk that doing so could cause harmful interference.  As also noted above, interference issues also could arise if security vulnerabilities were exploited to use a device as an interference generator, or to transmit at times and intervals selected by the attacker to interfere with other devices. See supra para. 12.
  We anticipate that this could be a more pervasive risk, and we seek comment on that predictive judgment.  Furthermore, under the Act, the Commission’s other obligations in this regard can encompass not only the prevention of interference to other devices, but the need to mitigate against the risk of interference to covered equipment. See id.  See also Principles for Promoting Efficient Use of Spectrum and Opportunities for New Services; Promoting Efficient Use of Spectrum through Improved Receiver Interference Immunity Performance; ET Docket Nos. 23-122, 22-137, Policy Statement, FCC 23-27 (April 20, 2023).
  In this regard, and in considering the potential need to encompass not only devices but, ultimately, products in order to adequately secure the IoT ecosystem and empower consumer choices, we believe such an approach is reasonable under sections 333 and 302(a) of the Act.
60. In particular, we also seek comment on the authorities that would support including additional IoT products and devices within the proposed IoT labeling Program.  For example, section 302(a)(2) of the Act provides the Commission with the authority to adopt reasonable regulations “establishing minimum performance standards for home electronic equipment and systems to reduce their susceptibility to interference from radio frequency energy.” 47 U.S.C. § 302a(2).
  Does this authority support reasonable regulations that may include the regulations proposed herein?  Section 333 states:  “No person shall willfully or maliciously interfere with or cause interference to any radio communications of any station licensed or authorized by or under this chapter or operated by the United States Government.” 47 U.S.C. § 333.
  Does this authority, possibly coupled with other provisions, provide a basis for the Commission’s proposed action?  Is our proposal necessary or reasonably ancillary to the execution of our implementation of any or all of these statutory responsibilities? See 47 U.S.C. § 154(i); Comcast Corp. v. FCC, 600 F.3d 642 (D.C. Cir. 2010).

61. Is it reasonable for our labeling program to not only guard against the risk that covered devices and products cause harmful interference, but also to guard against other risks, including the risk of interference to those covered devices and products consistent with policy goals underlying sections 302(a)(2) and 333 of the Act?  For example, we tentatively conclude that the Commission’s authority to adopt “reasonable regulations” to guard against harmful interference under section 302 of the Act authorizes a labeling program that applies a set of criteria or standards that address not only risks of harmful interference from the products or devices subject to labeling but also other harms, such as the risk of harmful interference to such products or devices—particularly where the relevant criteria or standards were designed or intended to be applied as a package or collectively.
62. We also tentatively conclude that our authority under section 302(a)(1) of the Act to adopt reasonable regulations consistent with the public interest to guard against interference provides us flexibility to tailor the proposed labeling program in other ways.  For example, we believe that, in adopting reasonable regulations consistent with the public interest under section 302, we have authority to exclude equipment from the Covered List from participating in the voluntary labeling program, consistent with the objectives of sections 2(a) and (d) of the Secure and Trusted Communications Networks Act of 2019. 47 U.S.C. § 1601(a), (d).
  We further tentatively conclude that our section 302 authority likewise enables us to rely on third parties in carrying out the implementation details of the proposed labeling program.  In particular, section 302(e) of the Act authorizes the Commission to delegate equipment testing and certification to private laboratories, and we note in that regard that the Commission already has relied in part on third parties in carrying out its equipment authorization rules.  We also seek comment on whether our authority to adopt reasonable regulations in the public interest to carry out the objectives of section 302 authorizes us to rely on a third party IoT registry administrator as well as rely on third parties to perform some of the functions described above.
63. We also seek comment on whether section 301 of the Act also provides the Commission with authority to include in its labeling program IoT products and devices that might receive harmful interference from an unauthorized cyber event.  We also recognize, for example, that cyberattacks utilizing IoT vulnerabilities may not only give rise to harmful interference concerns, but can also effectuate physical threats to the world around us – degrading wireless networks, for example, changing service settings on our smart appliances, or – more catastrophically – shutting down an industrial control system.  Are there additional authorities that support the inclusion of additional IoT products and devices that do not emit RF externally for purposes of communications, such as unintentional or incidental radiators, or wired-only IoT?
64. We seek comment broadly our legal authority under the Communications Act, or any other source, to implement the proposed voluntary IoT labeling program, including its authority pursuant to Titles II and III as well as its authority under section 4(i) of the Communications Act, as amended, to “perform any and all acts, make such rules and regulations, and issue such orders, not inconsistent with this chapter, as may be necessary in the execution of its functions" 47 U.S.C. § 154(i).
 which includes “the purpose of promoting safety of life and property.” 47 U.S.C. § 151.
 
65. We further seek comment on how the Commission may utilize enforcement authorities under the Act, including the potential imposition of penalties under section 503 and cease and desist orders under section 312 for those entities that voluntarily participate in the labeling program, but fail to continue to comply with the Commission’s regulations.  Would participants in the labeling program already be holders of authorizations within the meaning of section 503(b)(5) of the Act, or are there steps the Commission should take to structure the labeling program so that participation would itself satisfy that provision?  Are there any additional avenues for enforcement or oversight of the program's participants or of a third-party security certifying body?  What trademark remedies are available to the Commission?  Are there other agencies that might contribute to program enforcement?
G. Promoting Digital Equity 
66. The Commission, as part of its continuing effort to advance digital equity for all,84 including people of color, persons with disabilities, persons who live in rural or Tribal areas, and others who are or have been historically underserved, marginalized, or adversely affected by persistent poverty or inequality, invites comment on any equity-related considerations85 and benefits (if any) that may be associated with the proposals and issues discussed herein.  Specifically, we seek comment on how our proposals may promote or inhibit advances in diversity, equity, inclusion, and accessibility, as well as the scope of the Commission’s relevant legal authority.
IV. PROCEDURAL MATTERS
67. Paperwork Reduction Act.  This document contains proposed new and modified information collection requirements.  The Commission, as part of its continuing effort to reduce paperwork burdens, invites the general public and the Office of Management and Budget (OMB) to comment on the information collection requirements contained in this document, as required by the Paperwork Reduction Act of 1995, Public Law 104-13.  In addition, pursuant to the Small Business Paperwork Relief Act of 2002, Public Law 107-198, see 44 U.S.C. § 3506(c)(4), we seek specific comment on how we might further reduce the information collection burden for small business concerns with fewer than 25 employees.
68. Ex Parte Rules - Permit-But-Disclose.  This proceeding this Notice initiates shall be treated as a “permit-but-disclose” proceeding in accordance with the Commission’s ex parte rules. 47 CFR §§ 1.1200 et seq.
  Persons making ex parte presentations must file a copy of any written presentation or a memorandum summarizing any oral presentation within two business days after the presentation (unless a different deadline applicable to the Sunshine period applies).  Persons making oral ex parte presentations are reminded that memoranda summarizing the presentation must (1) list all persons attending or otherwise participating in the meeting at which the ex parte presentation was made, and (2) summarize all data presented and arguments made during the presentation.  If the presentation consisted in whole or in part of the presentation of data or arguments already reflected in the presenter’s written comments, memoranda or other filings in the proceeding, the presenter may provide citations to such data or arguments in his or her prior comments, memoranda, or other filings (specifying the relevant page and/or paragraph numbers where such data or arguments can be found) in lieu of summarizing them in the memorandum.  Documents shown or given to Commission staff during ex parte meetings are deemed to be written ex parte presentations and must be filed consistent with Rule 1.1206(b).  In proceedings governed by Rule 1.49(f) or for which the Commission has made available a method of electronic filing, written ex parte presentations and memoranda summarizing oral ex parte presentations, and all attachments thereto, must be filed through the electronic comment filing system available for that proceeding, and must be filed in their native format (e.g., .doc, .xml, .ppt, searchable .pdf).  Participants in this proceeding should familiarize themselves with the Commission’s ex parte rules.
69. Regulatory Flexibility Act.  The Regulatory Flexibility Act of 1980, as amended (RFA), See 5 U.S.C. § 603.  The RFA, 5 U.S.C. §§ 601–612, was amended by the Small Business Regulatory Enforcement Fairness Act of 1996 (SBREFA), Pub. L. No. 104-121, Title II, 110 Stat. 857 (1996).
 requires that an agency prepare a regulatory flexibility analysis for notice and comment rulemakings, unless the agency certifies that “the rule will not, if promulgated, have a significant economic impact on a substantial number of small entities.” Id.
  Accordingly, the Commission has prepared an Initial Regulatory Flexibility Analysis (IRFA) concerning the possible impact of the rule and policy changes contained in this Notice of Proposed Rulemaking.  The IRFA is set forth in Appendix B.  Written public comments are requested on the IRFA.  Comments must be filed by the deadlines for comments on the Notice indicated on the first page of this document and must have a separate and distinct heading designating them as responses to the IRFA.
70. Filing Requirements—Comments and Replies.  Pursuant to sections 1.415 and 1.419 of the Commission’s rules, 47 CFR §§ 1.415, 1.419, interested parties may file comments and reply comments on or before the dates indicated on the first page of this document.  Comments may be filed using the Commission’s Electronic Comment Filing System (ECFS).  See Electronic Filing of Documents in Rulemaking Proceedings, 63 FR 24121 (1998).
· Electronic Filers:  Comments may be filed electronically using the Internet by accessing the ECFS:  https://www.fcc.gov/ecfs/.
· Paper Filers:  Parties who choose to file by paper must file an original and one copy of each filing.
· Filings can be sent by commercial overnight courier, or by first-class or overnight U.S. Postal Service mail.  All filings must be addressed to the Commission’s Secretary, Office of the Secretary, Federal Communications Commission.
o Commercial overnight mail (other than U.S. Postal Service Express Mail and Priority Mail) must be sent to 9050 Junction Drive, Annapolis Junction, MD 20701.
o Postal Service first-class, Express, and Priority mail must be addressed to 45 L Street, NE, Washington, DC 20554.
· Effective March 19, 2020, and until further notice, the Commission no longer accepts any hand or messenger delivered filings.  This is a temporary measure taken to help protect the health and safety of individuals, and to mitigate the transmission of COVID-19. See FCC Announces Closure of FCC Headquarters Open Window and Change in Hand-Delivery Policy, Public Notice, 35 FCC Rcd 2788 (2020).

· During the time the Commission’s building is closed to the general public and until further notice, if more than one docket or rulemaking number appears in the caption of a proceeding, paper filers need not submit two additional copies for each additional docket or rulemaking number; an original and one copy are sufficient.
71. People with Disabilities.  To request materials in accessible formats for people with disabilities (braille, large print, electronic files, audio format), send an e-mail to fcc504@fcc.gov or call the Consumer & Governmental Affairs Bureau at 202-418-0530 (voice).
72. Additional Information.  For further information regarding the Notice, please contact Erika Olsen, Acting Chief, Cybersecurity and Communications Reliability Division, Public Safety and Homeland Security Bureau, (202) 418-2868, or by email to erika.olsen@fcc.gov; or James Zigouris, Attorney-Advisor, Cybersecurity and Communications Reliability Division, Public Safety and Homeland Security Bureau, (202) 418-0697, or by email to james.zigouris@fcc.gov.
V. ORDERING CLAUSES
73. Accordingly, IT IS ORDERED that pursuant to Sections 1, 2, 4(i), 4(n), 301, 302, 303(b), 312, 333, and 503, of the Communications Act of 1934, as amended, 47 U.S.C. §§ 151, 152, 154(i), 154(n), 301, 302a, 303(b), 312, 333, 503; the IoT Cybersecurity Improvement Act of 2020, 15 U.S.C. § 278g-3a to § 278g-3e; that this Notice of Proposed Rulemaking IS hereby ADOPTED.
74. IT IS FURTHER ORDERED that the Office of the Secretary, Reference Information Center, SHALL SEND a copy of this Notice of Proposed Rulemaking, including the Initial Regulatory Flexibility Analysis, to the Chief Counsel for Advocacy of the Small Business Administration.

						FEDERAL COMMUNICATIONS COMMISSION




						Marlene H. Dortch
						Secretary

APPENDIX A
Within the scope of a consumer IoT product, the following baseline product criteria are recommended by NIST to define the cybersecurity outcomes expected of IoT products and IoT product developers as part of a consumer IoT product labeling program.  Most criteria concern the IoT product directly and are expected to be satisfied by software and/or hardware means implemented in the IoT product.  Some criteria apply to the IoT product developer rather than to the IoT product directly.  These criteria are expected to be satisfied through actions and supported by assertions and evidence from the developer rather than from the IoT product itself.
Product criteria are recommended to apply to the IoT product overall, as well as to each individual IoT product component (e.g., IoT device, backend, companion app), as appropriate. Given the nature of consumer IoT product, it is expected that all IoT products should satisfy all technical product criteria since they will, in most cases, be finished products intended for direct plug-and-play use.  Individual IoT product components, though, may be more likely to not require certain criteria (e.g., based on lack of applicability).
  A scheme owner has the flexibility to adapt the product criteria and determine appropriate supporting evidence.  Though NIST recommends that all criteria apply to every IoT product, some components may not be able or need to support all criteria.  That might be the case due to product risk considerations, product development (e.g., cybersecurity tasks delegated via contracts and supply chain), nature of the components to form the product (e.g., backends may be highly distributed), or limitations of IoT components (e.g., devices may be constrained, companion software apps may have limited access and functionality).
1. Asset Identification:  The IoT product is uniquely identifiable and inventories all of the IoT product’s components.
· The IoT product can be uniquely identified by the customer and other authorized entities (e.g., the IoT product developer).
· The IoT product uniquely identifies each IoT product component and maintains an up-to- date inventory of connected product components.
Cybersecurity utility: The ability to identify IoT products and their components is necessary to support asset management for updates, data protection, and digital forensics capabilities for incident response.
2. Product Configuration:  The configuration of the IoT product is changeable, there is the ability to restore a secure default setting, and any and all changes can only be performed by authorized individuals, services, and other IoT product components.
· The customer can change the configuration settings of the IoT product via one or more IoT product components.
· The IoT product applies configuration settings to applicable IoT components.
Cybersecurity utility:  The ability to change aspects of how the IoT product functions can help customers tailor the IoT product’s functionality to their needs and goals.  Customers can configure their IoT products to avoid specific threats and risk they know about based on their risk appetite.
3. Data Protection:  The IoT product and its components protect data stored (across all IoT product components) and transmitted (both between IoT product components and outside the IoT product) from unauthorized access, disclosure, and modification.
· Each IoT product component protects data it stores via secure means, including the ability to delete or render inaccessible data stored that is either collected from or about the customer, home, family, etc.
· When data is sent between IoT product components or outside the product, protections are used for the data transmission.
Cybersecurity utility:  Maintaining confidentiality, integrity, and availability of data is foundational to cybersecurity for IoT products. Customers will expect that data is protected and that protection of data helps to ensure safe and intended functionality of the IoT product.
4. Interface Access Control:  The IoT product and its components restrict logical access to local and network interfaces – and to protocols and services used by those interfaces – to only authorized individuals, services, and IoT product components.

· Each IoT product component controls access (to and from) all interfaces (e.g., local interfaces, network interfaces, protocols, and services) in order to limit access to only authorized entities. At a minimum, the IoT product and its components shall:

a. Use and have access only to interfaces necessary for the IoT product’s operation. All other channels and access to channels are removed or secured.
b. For all interfaces necessary for the IoT product’s use, access control measures are in place (e.g., unique password-based multifactor authentication).
c. For all interfaces, access and modification privileges are limited.

· The IoT product executes means via some, but not necessarily all, components to protect and maintain interface access control. At a minimum, the IoT product shall:

a. Validate that data sent to other product components matches specified definitions of format and content.
b. Prevent unauthorized transmissions or access to other product components.
c. Maintain appropriate access control during initial connection (i.e., on-boarding) and when reestablishing connectivity after disconnection or outage.
Cybersecurity utility: Inventorying and controlling access to all internal and external interfaces to the IoT product will help preserve the confidentiality, integrity, and availability of the IoT product, its components, and data by helping prevent unauthorized access and modification.
5. Software Update:  The software of all IoT product components can be updated by authorized individuals, services, and other IoT product components only by using a secure and configurable mechanism, as appropriate for each IoT product component.
· Each IoT product component can receive, verify, and apply verified software updates.
· The IoT product implements measures to keep software on IoT product components up to date (i.e., automatic application of updates or consistent customer notification of available updates via the IoT product).
Cybersecurity utility:  Software may have vulnerabilities discovered after the IoT product has been deployed; software update capabilities can ensure secure delivery of security patches.
6. Cybersecurity State Awareness:  The IoT product supports detection of cybersecurity incidents affecting or affected by IoT product components and the data they store and transmit.
· The IoT product captures and records information about the state of IoT components that can be used to detect cybersecurity incidents affecting or affected by IoT product components and the data they store and transmit.
Cybersecurity utility:  Protection of data and ensuring proper functionality can be supported by the ability to alert the customer when the device starts operating in unexpected ways, which could mean that unauthorized access is being attempted, malware has been loaded, botnets have been created, device software errors have happened, or other types of actions have occurred that was not initiated by the IoT product user or intended by the developer.
7. Documentation:  The IoT product developer creates, gathers, and stores information relevant to cybersecurity of the IoT product and its product components prior to customer purchase, and throughout the development of a product and its subsequent lifecycle.
· Throughout the development lifecycle, the IoT product developer creates or gathers and stores information relevant to the cybersecurity of the IoT product and its product components, including:
a. Assumptions made during the development process and other expectations related to the IoT product, including:
i. Expected customers and use cases.
ii. Physical use, including security of the location of the IoT product and its product components (e.g., a camera for use inside the home that has an off switch on the device vs. a security camera for use outside the home that does not have an off switch on the device), and characteristics.
iii. Network access and requirements (e.g., bandwidth requirements).
iv. Data created and handled by the IoT product. 
v. Any expected data inputs and outputs (including error codes, frequency, type/form, range of acceptable values, etc.).
vi. The IoT product developer’s assumed cybersecurity requirements for the IoT product.
vii. Any laws and regulations with which the IoT product and related support activities comply.
viii. Expected lifespan and anticipated cybersecurity costs related to the IoT product (e.g., price of maintenance), and length and terms of support.

b. All IoT components, including but not limited to the IoT device, that are part of the IoT product.
c. How the baseline product criteria are met by the IoT product across its product components, including which baseline product criteria are not met by IoT product components and why (e.g., the capability is not needed based on risk assessment).
d. Product design and support considerations related to the IoT product, for example:
i. All hardware and software components, from all sources (e.g., open source, propriety third-party, internally developed) used to create the IoT product (i.e., used to create each product component).
ii. IoT platform used in the development and operation of the IoT product, its product components, including related documentation.
iii. Protection of software and hardware elements implemented to create the IoT product and its product components (e.g., secure boot, hardware root of trust, and secure enclave).
iv. Consideration of the known risks related to the IoT product and known potential misuses.
v. Secure software development and supply chain practices used.
vi. Accreditation, certification, and/or evaluation results for cybersecurity- related practices.
vii. The ease of installation and maintenance of the IoT product by a customer (i.e., the usability of the product).
e. Maintenance requirements for the IoT product, for example:
i. Cybersecurity maintenance expectations and associated instructions or procedures (e.g., vulnerability/patch management plan).
ii. How the IoT product developer identifies authorized supporting parties who can perform maintenance activities (e.g., authorized repair centers).
iii. Cybersecurity considerations of the maintenance process (e.g., how customer data unrelated to the maintenance process remains confidential even from maintainers).
f. The secure system lifecycle policies and processes associated with the IoT product, including:
i. Steps taken during development to ensure the IoT product and its product components are free of any known, exploitable vulnerabilities.
ii. The process of working with component suppliers and third-party vendors to ensure the security of the IoT product and its product components is maintained for the duration of its supported lifecycle.
iii. Any post end-of-support considerations, such as the discovery of a vulnerability which would significantly impact the security, privacy, or safety of customers who continue to use the IoT product and its product components.
g. The vulnerability management policies and processes associated with the IoT product, including:
i. Methods of receiving reports of vulnerabilities (see Information and Query Reception below).
ii. Processes for recording reported vulnerabilities.
iii. Policy for responding to reported vulnerabilities, including the process of coordinating vulnerability response activities among component suppliers and third-party vendors.
iv. Policy for disclosing reported vulnerabilities.
v. Processes for receiving notification from component suppliers and third- party vendors about any change in the status of their supplied components, such as end of production, end of support, deprecated status (e.g., the product is no longer recommended for use), or known insecurities.
Cybersecurity utility:  Generating, capturing, and storing important information about the IoT product and its development (e.g., assessment of the IoT product and development practices used to create and maintain it) can help inform the IoT product developer regarding the product’s actual cybersecurity posture.
8. Information and Query Reception:  The ability of the IoT product developer to receive information relevant to cybersecurity and respond to queries from the customer and others about information relevant to cybersecurity.
· The IoT product developer can receive information related to the cybersecurity of the IoT product and its product components and can respond to queries related to cybersecurity of the IoT product and its product components from customers and others, including:
a. The ability of the IoT product developer to identify a point of contact to receive maintenance and vulnerability information (e.g., bug reporting capabilities and bug bounty programs) from customers and others in the IoT product ecosystem (e.g., repair technician acting on behalf of the customer).
b. The ability of the IoT product developer to receive queries from and respond to customers and others in the IoT product ecosystem about the cybersecurity of the IoT product and its components.
Cybersecurity utility:  As IoT products are used by customers, those customers may have questions or reports of issues that can help improve the cybersecurity of the IoT product over time.
9. Information Dissemination:  The IoT product developer broadcasts (e.g., to the public) and distributes (e.g., to the customer or others in the IoT product ecosystem) information relevant to cybersecurity.
· The IoT product developer can broadcast to many/all entities via a channel (e.g., a post on a public channel) to alert the public and customers of the IoT product about cybersecurity relevant information and events throughout the support lifecycle.  At a minimum, this information shall include:
a. Updated terms of support (e.g., frequency of updates and mechanism(s) of application) and notice of availability and/or application of software updates.
b. End of term of support or functionality for the IoT product.
c. Needed maintenance operations.
d. New IoT device vulnerabilities, associated details, and mitigation actions needed from the customer.
e. Breach discovery related to an IoT product and its product components used by the customers, associated details, and mitigation actions needed from the customer (if any).
· The IoT product developer can distribute information relevant to cybersecurity of the IoT product and its product components to alert appropriate ecosystem entities (e.g., common vulnerability tracking authorities, accreditors and certifiers, third-party support and maintenance organizations) about cybersecurity relevant information, for example:
a. Applicable documentation captured during the design and development of the IoT product and its product components.
b. Cybersecurity and vulnerability alerts and information about resolution of any vulnerability.
c. An overview of the information security practices and safeguards used by the IoT product developer.
d. Accreditation, certification, and/or evaluation results for the IoT product developer’s cybersecurity-related practices.
e. A risk assessment report or summary for the IoT product developer’s business environment risk posture.
Cybersecurity utility:  As the IoT product, its components, threats, and mitigations change, customers will need to be informed about how to securely use the IoT product.
10. Product Education and Awareness:  The IoT product developer creates awareness of and educates customers and others in the IoT product ecosystem about cybersecurity-related information (e.g., considerations, features) related to the IoT product and its product components.
· The IoT product developer creates awareness and provides education targeted at customers about information relevant to cybersecurity of the IoT product and its product components, including:
a. The presence and use of IoT product cybersecurity capabilities, including at a minimum: 
i. How to change configuration settings and the cybersecurity implications of changing settings, if any.
ii. How to configure and use access control functionality (e.g., set and change passwords).
iii. How software updates are applied and any instructions necessary for the customer on how to use software update functionality.
iv. How to manage device data including creation, update, and deletion of data on the IoT product.
b. How to maintain the IoT product and its product components during its lifetime, including after the period of security support (e.g., delivery of software updates and patches) from the IoT product developer.
c. How an IoT product and its product components can be securely re-provisioned or disposed of.
d. Vulnerability management options (e.g., configuration and patch management and anti-malware) available for the IoT product or its product components that could be used by customers.
e. Additional information customers can use to make informed purchasing decisions about the security of the IoT product (e.g., the duration and scope of product support via software upgrades and patches).
Cybersecurity utility:  Customers will need to be informed about how to securely use the device to lead to the best cybersecurity outcomes for the customers and the consumer IoT product marketplace.


2
	Federal Communications Commission	FCC 23-65

APPENDIX B
 
Initial Regulatory Flexibility Analysis

1. As required by the Regulatory Flexibility Act of 1980, as amended (RFA), 5 U.S.C. § 603.  The RFA, 5 U.S.C. §§ 601 – 612, has been amended by the Small Business Regulatory Enforcement Fairness Act of 1996 (SBREFA), Pub. L. No. 104-121, Title II, 110 Stat. 857 (1996).
 the Commission has prepared this Initial Regulatory Flexibility Analysis (IRFA) of the possible significant economic impact on a substantial number of small entities by the policies and rules proposed in this Notice of Proposed Rulemaking (Notice).  Written public comments are requested on this IRFA.  Comments must be identified as responses to the IRFA and must be filed by the deadlines for comments on the Notice, including this IRFA, to the Chief Counsel for Advocacy of the Small Business Administration (SBA). 5 U.S.C. § 603(a).
  In addition, the Notice and IRFA (or summaries thereof) will be published in the Federal Register. Id.

A. Need for, and Objectives of, the Proposed Rules
2. In the Notice, we propose a voluntary cybersecurity labeling program for the Internet of Things (IoT) to improve consumer confidence and understanding of security for IoT devices and/or products.  Such IoT devices and products are susceptible to a wide range of security vulnerabilities, which can be exploited by attackers to gain unauthorized access to an IoT device or IoT product and its data.  Accordingly, providing consumers with a label certifying that an IoT device and/or product satisfies certain baseline cybersecurity standards and has specific cybersecurity capabilities allows a consumer to understand the relative security risk that an IoT device and/or product may pose when making a purchase.  We seek comments on the scope of the proposed cybersecurity labeling program, including comments on proposed definitions of an IoT device and an IoT product.  We also seek comments on specific technical criteria for the cybersecurity labeling program, including whether other criteria in addition to the IoT Criteria developed by the National Institute of Standards and Technology (NIST), NIST, Recommended Criteria for Cybersecurity Labeling for Consumer IoT Products (2022), https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.02042022-2.pdf; see also NIST, IoT Product Criteria (May 24, 2022), https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/iot-product-criteria.
 should be considered, and whether and how to develop administrable standards.  Finally, we invite comments on how to administer the cybersecurity labeling program, the appropriate means to fund the costs of running the program, and what program auditing, enforcement, disqualification and certification revocation processes and procedures should be put in place to ensure that the labeling program is a trusted and valuable resource that consumers can reply upon to assess the security of the IoT devices and/or products that exhibit the label.
B. Legal Basis
3. The proposed action is taken under authority found in sections 1, 2, 4(i), 4(n), 301, 302, 303(b), 312, 333, and 503 of the Communications Act of 1934, as amended, 47 U.S.C. §§ 151, 152, 154(i), 154(n), 301, 302a, 303(b), 312, 333, 503; and the IoT Cybersecurity Improvement Act of 2020, 15 U.S.C. § 278g-3a to 278g-3e.
C. Description and Estimate of the Number of Small Entities to Which the Proposed Rules Will Apply
4. The RFA directs agencies to provide a description of, and where feasible, an estimate of the number of small entities that may be affected by the proposed rules and policies, if adopted. 5 U.S.C. § 603(b)(3).
  The RFA generally defines the term “small entity” as having the same meaning as the terms “small business,” “small organization,” and “small governmental jurisdiction.” 5 U.S.C. § 601(6).
  In addition, the term “small business” has the same meaning has the term “small business concern” under the Small Business Act. 5 U.S.C. § 601(3) (incorporating by reference the definition of “small-business concern” in the Small Business Act, 15 U.S.C. § 632).  Pursuant to 5 U.S.C. § 601(3), the statutory definition of a small business applies “unless an agency, after consultation with the Office of Advocacy of the Small Business Administration and after opportunity for public comment, establishes one or more definitions of such term which are appropriate to the activities of the agency and publishes such definition(s) in the Federal Register.”
  A “small business concern” is one which:  (1) is independently owned and operated; (2) is not dominant in its field of operation; and (3) satisfies any additional criteria established by the SBA. 15 U.S.C. § 632.

5. Small Businesses, Small Organizations, and Small Governmental Jurisdictions.  Our actions, over time, may affect small entities that are not easily categorized at present.  We therefore describe here, at the outset, three broad groups of small entities that could be directly affected herein. See 5 U.S.C. § 601(3)-(6).
  First, while there are industry specific size standards for small businesses that are used in the regulatory flexibility analysis, according to data from the Small Business Administration’s (SBA) Office of Advocacy, in general a small business is an independent business having fewer than 500 employees. See SBA, Office of Advocacy, What’s New With Small Business? (Mar 14, 2023), https://advocacy.sba.gov/2023/03/14/whats-new-with-small-business/.
  These types of small businesses represent 99.9% of all businesses in the United States, which translates to 30.7 million businesses. Id.

6. Next, the type of small entity described as a “small organization” is generally “any not-for-profit enterprise which is independently owned and operated and is not dominant in its field.” 5 U.S.C. § 601(4).
  The Internal Revenue Service (IRS) uses a revenue benchmark of $50,000 or less to delineate its annual electronic filing requirements for small exempt organizations. The IRS benchmark is similar to the population of less than 50,000 benchmark in 5 U.S.C. § 601(5) that is used to define a small governmental jurisdiction. Therefore, the IRS benchmark has been used to estimate the number small organizations in this small entity description.  See Annual Electronic Filing Requirement for Small Exempt Organizations — Form 990-N (e-Postcard), “Who must file,”
https://www.irs.gov/charities-non-profits/annual-electronic-filing-requirement-for-small-exempt-organizations-form-990-n-e-postcard.  We note that the IRS data does not provide information on whether a small exempt organization is independently owned and operated or dominant in its field.
  Nationwide, for tax year 2020, there were approximately 447,689 small exempt organizations in the U.S. reporting revenues of $50,000 or less according to the registration and tax data for exempt organizations available from the IRS. See Exempt Organizations Business Master File Extract (EO BMF), “CSV Files by Region,” https://www.irs.gov/charities-non-profits/exempt-organizations-business-master-file-extract-eo-bmf.  The IRS Exempt Organization Business Master File (EO BMF) Extract provides information on all registered tax-exempt/non-profit organizations.  The data utilized for purposes of this description was extracted from the IRS EO BMF data for businesses for the tax year 2020 with revenue less than or equal to $50,000 for Region 1-Northeast Area (58,577), Region 2-Mid-Atlantic and Great Lakes Areas (175,272), and Region 3-Gulf Coast and Pacific Coast Areas (213,840) that includes the continental U.S., Alaska, and Hawaii.  This data does not include information for Puerto Rico.

7. Finally, the small entity described as a “small governmental jurisdiction” is defined generally as “governments of cities, counties, towns, townships, villages, school districts, or special districts, with a population of less than fifty thousand.” 5 U.S.C. § 601(5).
  U.S. Census Bureau data from the 2017 Census of Governments See 13 U.S.C. § 161.  The Census of Governments survey is conducted every five (5) years compiling data for years ending with “2” and “7.”  See also Census of Governments, https://www.census.gov/programs-surveys/cog/about.html.
 indicate that there were 90,075 local governmental jurisdictions consisting of general purpose governments and special purpose governments in the United States. See U.S. Census Bureau, 2017 Census of Governments – Organization Tbl. 2. Local Governments by Type and State: 2017 [CG1700ORG02].  https://www.census.gov/data/tables/2017/econ/gus/2017-governments.html.  Local governmental jurisdictions are made up of general purpose governments (county, municipal and town or township) and special purpose governments (special districts and independent school districts).  See also Tbl. 2. CG1700ORG02 Table Notes_Local Governments by Type and State_2017.
  Of this number there were 36,931 general purpose governments (county See id. at Tbl. 5.  County Governments by Population-Size Group and State: 2017 [CG1700ORG05].  https://www.census.gov/data/tables/2017/econ/gus/2017-governments.html.  There were 2,105 county governments with populations less than 50,000.  This category does not include subcounty (municipal and township) governments.
, municipal and town or township See id. at Tbl. 6.  Subcounty General-Purpose Governments by Population-Size Group and State: 2017 [CG1700ORG06].  https://www.census.gov/data/tables/2017/econ/gus/2017-governments.html.  There were 18,729 municipal and 16,097 town and township governments with populations less than 50,000.
) with populations of less than 50,000 and 12,040 special purpose governments - independent school districts See id. at Tbl. 10. Elementary and Secondary School Systems by Enrollment-Size Group and State: 2017 [CG1700ORG10].  https://www.census.gov/data/tables/2017/econ/gus/2017-governments.html.  There were 12,040 independent school districts with enrollment populations less than 50,000.  See also Tbl. 4. Special-Purpose Local Governments by State Census Years 1942 to 2017 [CG1700ORG04], CG1700ORG04 Table Notes_Special Purpose Local Governments by State_Census Years 1942 to 2017.
 with enrollment populations of less than 50,000. While the special purpose governments category also includes local special district governments, the 2017 Census of Governments data does not provide data aggregated based on population size for the special purpose governments category.  Therefore, only data from independent school districts is included in the special purpose governments category.
  Accordingly, based on the 2017 U.S. Census of Governments data, we estimate that at least 48,971 entities fall into the category of “small governmental jurisdictions.” This total is derived from the sum of the number of general purpose governments (county, municipal and town or township) with populations of less than 50,000 (36,931) and the number of special purpose governments - independent school districts with enrollment populations of less than 50,000 (12,040), from the 2017 Census of Governments - Organizations Tbls. 5, 6, and 10.

8. Radio Frequency Equipment Manufacturers (RF Manufacturers).  There are several analogous industries with an SBA small business size standard that are applicable to RF Manufacturers.  These industries are Fixed Microwave Services, Other Communications Equipment Manufacturing, Radio and Television Broadcasting and Wireless Communications Equipment Manufacturing.  A description of these industries and the SBA small business size standards are detailed below.
9. Fixed Microwave Services.  Fixed microwave services include common carrier, See 47 CFR Part 101, Subparts C and I.
 private-operational fixed, See id. Subparts C and H.
 and broadcast auxiliary radio services. Auxiliary Microwave Service is governed by Part 74 of Title 47 of the Commission’s Rules.  See 47 CFR Part 74.  Available to licensees of broadcast stations and to broadcast and cable network entities, broadcast auxiliary microwave stations are used for relaying broadcast television signals from the studio to the transmitter, or between two points such as a main studio and an auxiliary studio.  The service also includes mobile TV pickups, which relay signals from a remote location back to the studio.
  They also include the Upper Microwave Flexible Use Service (UMFUS), See 47 CFR Part 30.
 Millimeter Wave Service (70/80/90 GHz), See 47 CFR Part 101, Subpart Q.
 Local Multipoint Distribution Service (LMDS), See id. Subpart L.
 the Digital Electronic Message Service (DEMS), See id. Subpart G.
 24 GHz Service, See id.
 Multiple Address Systems (MAS), See id. Subpart O.
 and Multichannel Video Distribution and Data Service (MVDDS), See id. Subpart P.
 where in some bands licensees can choose between common carrier and non-common carrier status. See 47 CFR §§ 101.533, 101.1017.
  Wireless Telecommunications Carriers (except Satellite) See U.S. Census Bureau, 2017 NAICS Definition, “517312 Wireless Telecommunications Carriers (except Satellite),” https://www.census.gov/naics/?input=517312&year=2017&details=517312.
 is the closest industry with an SBA small business size standard applicable to these services.  The SBA small size standard for this industry classifies a business as small if it has 1,500 or fewer employees. See 13 CFR § 121.201, NAICS Code 517312 (as of 10/1/22, NAICS Code 517112).
  U.S. Census Bureau data for 2017 show that there were 2,893 firms that operated in this industry for the entire year. See U.S. Census Bureau, 2017 Economic Census of the United States, Employment Size of Firms for the U.S.: 2017, Table ID: EC1700SIZEEMPFIRM, NAICS Code 517312, https://data.census.gov/cedsci/table?y=2017&n=517312&tid=ECNSIZE2017.EC1700SIZEEMPFIRM&hidePreview=false.
  Of this number, 2,837 firms employed fewer than 250 employees. Id.  The available U.S. Census Bureau data does not provide a more precise estimate of the number of firms that meet the SBA size standard.
  Thus, under the SBA size standard, the Commission estimates that a majority of fixed microwave service licensees can be considered small.
10. The Commission’s small business size standards with respect to fixed microwave services involve eligibility for bidding credits and installment payments in the auction of licenses for the various frequency bands included in fixed microwave services.  When bidding credits are adopted for the auction of licenses in fixed microwave services frequency bands, such credits may be available to several types of small businesses based average gross revenues (small, very small and entrepreneur) pursuant to the competitive bidding rules adopted in conjunction with the requirements for the auction and/or as identified in Part 101 of the Commission’s rules for the specific fixed microwave services frequency bands. See 47 CFR §§ 101.538(a)(1)-(3), 101.1112(b)-(d), 101.1319(a)(1)-(2), and 101.1429(a)(1)-(3).

11. In frequency bands where licenses were subject to auction, the Commission notes that as a general matter, the number of winning bidders that qualify as small businesses at the close of an auction does not necessarily represent the number of small businesses currently in service.  Further, the Commission does not generally track subsequent business size unless, in the context of assignments or transfers, unjust enrichment issues are implicated.  Additionally, since the Commission does not collect data on the number of employees for licensees providing these services, at this time we are not able to estimate the number of licensees with active licenses that would qualify as small under the SBA’s small business size standard.
12. Other Communications Equipment Manufacturing.  This industry comprises establishments primarily engaged in manufacturing communications equipment (except telephone apparatus, and radio and television broadcast, and wireless communications equipment). See U.S. Census Bureau, 2017 NAICS Definitions, “334290 Other Communications Equipment Manufacturing,” https://www.census.gov/naics/?input=334290&year=2017&details=334290.
  Examples of such manufacturing include fire detection and alarm systems manufacturing, Intercom systems and equipment manufacturing, and signals (e.g., highway, pedestrian, railway, traffic) manufacturing. Id.
 The SBA small business size standard for this industry classifies firms having 750 or fewer employees as small. See 13 CFR § 121.201, NAICS Code 334290.
  For this industry, U.S. Census Bureau data for 2017 shows that 321 firms operated for the entire year. See U.S. Census Bureau, 2017 Economic Census of the United States, Selected Sectors: Employment Size of Firms for the U.S.: 2017, Table ID: EC1700SIZEEMPFIRM, NAICS Code 334290, https://data.census.gov/cedsci/table?y=2017&n=334290&tid=ECNSIZE2017.EC1700SIZEEMPFIRM&hidePreview=false.
  Of that number, 310 firms operated with fewer than 250 employees. Id.  The available U.S. Census Bureau data does not provide a more precise estimate of the number of firms that meet the SBA size standard.
  Based on this data, we conclude that the majority of Other Communications Equipment Manufacturers are small.
13. Radio and Television Broadcasting and Wireless Communications Equipment Manufacturing.  This industry comprises establishments primarily engaged in manufacturing radio and television broadcast and wireless communications equipment. See U.S. Census Bureau, 2017 NAICS Definition, “334220 Radio and Television Broadcasting and Wireless Communications Equipment Manufacturing,” https://www.census.gov/naics/?input=334220&year=2017&details=334220 (last visited July 17, 2023).
  Examples of products made by these establishments are: transmitting and receiving antennas, cable television equipment, GPS equipment, pagers, cellular phones, mobile communications equipment, and radio and television studio and broadcasting equipment. Id.
  This industry comprises establishments primarily engaged in manufacturing communications equipment (except telephone apparatus, and radio and television broadcast, and wireless communications equipment). See U.S. Census Bureau, 2017 NAICS Definitions, “334290 Other Communications Equipment Manufacturing,” https://www.census.gov/naics/?input=334290&year=2017&details=334290.
  Examples of such manufacturing include fire detection and alarm systems manufacturing, Intercom systems and equipment manufacturing, and signals (e.g., highway, pedestrian, railway, traffic) manufacturing. Id.
  The SBA small business size standard for this industry classifies firms having 750 or fewer employees as small. See 13 CFR § 121.201, NAICS Code 334290.
  For this industry, U.S. Census Bureau data for 2017 shows that 321 firms operated for the entire year. See U.S. Census Bureau, 2017 Economic Census of the United States, Selected Sectors: Employment Size of Firms for the U.S.: 2017, Table ID: EC1700SIZEEMPFIRM, NAICS Code 334290,  https://data.census.gov/cedsci/table?y=2017&n=334290&tid=ECNSIZE2017.EC1700SIZEEMPFIRM&hidePreview=false.
  Of that number, 310 firms operated with fewer than 250 employees. Id.  The available U.S. Census Bureau data does not provide a more precise estimate of the number of firms that meet the SBA size standard.
  Based on this data, we conclude that the majority of Other Communications Equipment Manufacturers are small.
D. Description of Projected Reporting, Recordkeeping, and Other Compliance Requirements for Small Entities
14. The voluntary cybersecurity labeling program for IoT devices and/or products to provide consumers with accessible information on the relative security of these IoT devices and/or products that we propose in the Notice may impose new reporting, recordkeeping, notice or other compliance requirements on small entities that choose to participate in the program.  The requirements may include application or other conformance reporting, licensing, certification and/or other reporting obligations.
15. The proposals in the Notice build upon other actions the Commission has taken to protect and secure public safety.  Accordingly, the proposals being made in this Notice may require additional analysis and mitigation activities by small and other IoT manufacturers in order to satisfy certain technical criteria or standards for the ability to display an IoT cybersecurity label.  At this time, the Commission is not in a position to determine whether the requirements that may be adopted for participants in the proposed cybersecurity labeling program will require small entities to hire professionals in order to comply and cannot quantify the cost of compliance with the potential requirements and obligations that may result in this proceeding.  Among other things considered, we inquire about the options for the Commission to address the costs of running and administering the labeling program including whether there may be application fees charged by third-parties administering the program and whether there is oversight the Commission should exercise over such charges.  We seek comment on these issues and anticipate that the information we receive in comments will address these matters and any broader cost issues for small entities that may choose to participate in the proposed labeling program.
16. In light of the importance of mark integrity and the need to build consumer confidence and trust in the security of IoT devices and products that will display the Commission’s IoT label, regardless of the size of the entity seeking to participate in the proposed cybersecurity labeling program, adherence by all participants to the same Commission rules is necessary.  However, we expect that the comments we receive will help the Commission identify and evaluate relevant matters for small entities before adopting final rules for the labeling program, including any compliance costs and burdens that may result from the proposals and other matters discussed in the Notice.
E. Steps Taken to Minimize the Significant Economic Impact on Small Entities, and Significant Alternatives Considered
17. The RFA requires an agency to describe any significant, specifically small business, alternatives that it has considered in reaching its proposed approach, which may include the following four alternatives (among others):  “(1) the establishment of differing compliance or reporting requirements or timetables that take into account the resources available to small entities; (2) the clarification, consolidation, or simplification of compliance or reporting requirements under the rule for such small entities; (3) the use of performance rather than design standards; and (4) an exemption from coverage of the rule, or any part thereof, for such small entities.” 5 U.S.C. § 603(c).

18. The Commission’s development of a voluntarily cybersecurity labeling program for the IoT products and devices builds on the work of the National Institute of Standards and Technology (NIST) which produced labeling criteria for cybersecurity capabilities of IoT consumer devices. NIST, Cybersecurity Labeling for Consumers: Internet of Things (IoT) Devices and Software (May 24, 2022), https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/cybersecurity-labeling-consumers-0.
  Using the work of NIST as a foundation has the potential to minimize the economic impact on small entities for several reasons.  First, NIST took into account existing consumer product labeling programs and information provided by diverse stakeholders. Id.
  Next, two of the key elements NIST identified for labeling were encouraging innovation, and being practical and not burdensome. Id.
  Further, we believe building on the approach NIST developed for IoT cybersecurity labeling will provide a level of consistency with the requirements we establish for the entities subject to Commission regulation that choose to participate in the Commission’s cybersecurity IoT labeling program.
19. In the Notice, we consider and seek comment on various compliance requirements that the Commission could consider in advancing a voluntary cybersecurity labeling program.  More specifically, we considered the NIST definition for IoT devices which defines IoT devices as devices that have at least one transducer (sensor or actuator) for interacting directly with the physical world and at least one network interface (e.g., Ethernet, Wi-Fi, Bluetooth) for interfacing with the digital world, National Institute of Standards and Technology Internal Report 8425, Profile of the IoT Core Baseline for Consumer Products (Sept. 2020) at 23.
 and determined that we should propose an alternative definition.  Our proposed definition modifies the NIST definition to add “Internet-connected” because a key element of the IoT is the usage of standard Internet protocols for functionality, which exposes IoT devices to the security threats and challenges related to being connected to the Internet. Id. at 1.
  Our proposed definition also includes the requirement that devices must be capable of intentionally emitting radio frequency energy because the relevant scope of Commission’s statutory authorities focus on devices that intentionally emit radio frequency energy. 47 U.S.C. § 302(a)(1).

20. Although we include in our definition devices that intentionally emit radio frequency energy, we considered whether there are unintentional radiators or incidental radiators that should be included in the program, and if so whether we should revise the definition to omit the word “intentional.” Alternatively, we inquire if we should consider adding unintentional or incidental radiating devices to the program at a later date.  In addition, while we refer to devices and products in the Notice, we inquire whether we should expand the proposed scope of our cybersecurity labeling program and definition of devices beyond IoT devices to apply to IoT products.  Under this expanded alternative we could define an IoT product as an IoT device and any additional product components (e.g., backend, gateway, mobile App) that are necessary to use the IoT device.  A further alternative we considered, is whether to limit our IoT labeling program to consumer IoT devices or products intended for personal use, or to include “enterprise” devices or products intended for industrial or business uses and any additional considerations that would need to be accounted for with such devices or products.  We seek comment on these inquiries and alternatives in the Notice, in addition to comments on our proposed definition.
21. Regarding the content and updating of the IoT label on the physical device, product, or packaging, we believe the simple approach we proposed in the Notice will result in cost savings which could minimize the impact of these requirements for small entities.  Our proposal is to have the physical device, product, or packaging simply indicate that the manufacturer participates in the FCC’s labeling program by having the FCC mark along with the related QR Code and/or the URL to the IoT registry.  The detailed information on the IoT device or product will be made available on the device or product’s webpage within the IoT registry using an QR Code and/or a URL.  When the device or product’s webpage within the IoT registry is updated to indicate for example, that the device or product’s authorization is outdated, and/or the device or product is no longer maintained or updated, using the QR Code and/or the URL provided next to the FCC mark the information can be accessed on the device or product’s webpage within the IoT registry.  Updating requirements for the device or product’s webpage within the IoT registry could alleviate the need for the Commission to adopt additional notification requirements which would increase costs for small entities.
22. We also considered and seek comment on alternatives on how to address the end-of-life issues for devices previously receiving authorization under the program.  For example, we considered whether the label should include the specific date, or the year the authorization was awarded, or an expiration date.  Further, we considered whether it would be sufficient to provide consumers with additional information via the QR Code regarding the current security status of a device, and whether the QR Code-linked website should indicate when the label was issued by the Commission, and when the information on the webpage last updated.
23. In the area of accessibility, to ensure that any IoT cybersecurity label information the Commission adopts is accessible to persons with disabilities, we considered an alternative that would alleviate the need for the Commission to establish and impose new accessibility requirements on small entities and other participants in the labeling program.  Consistent with our approach with broadband consumer labels in 2022, in the Notice we considered and seek comment on relying on the existing legal requirements in the Americans with Disabilities Act (ADA) and following the guidance developed by the Web Accessibility Initiative, which the Consumer Advisory Committee (CAC) determined is the best method to ensure accessibility to printed and online information is made available by providers. Empowering Broadband Consumers Through Transparency, Notice of Proposed Rulemaking, FCC 22-7, 2022 WL 273068, *7, para. 27 (Jan. 27, 2022).

24. Further, rather than proposing rules at this juncture, in the Notice we seek comment on costs associated with the proposed cybersecurity IoT labeling program, and on investigation, disqualification and enforcement processes to maintain the integrity of the devices or products that will be labeled under the program.  Our actions on all of these matters have the potential to minimize the impact of the cybersecurity IoT labeling program we adopt on small entities.
25. Regarding investigation, disqualification and enforcement, as discussed in the Notice, we considered and seek comment on whether to have random audits of IoT devices or products to confirm continued compliance; whether we should adopt disqualifications procedures similar to those adopted for the ENERGY STAR program by the Environmental Protection Agency (EPA); what additional non-compliance or disqualification measures would be appropriate in addition to authorization revocation, and whether there should be an appeal process available to applicants that are denied authority to use the IoT label.  Additionally, we seek comment on what recordkeeping and audit requirements could be adopted for purposes of compliance review.
26. The Commission expects to more fully consider the economic impact and alternatives for small entities following the review of comments filed in response to the Notice.  Having input from interested parties will allow the Commission to better evaluate options and alternatives to minimize any significant economic impact on small entities that may result from the proposed cybersecurity IoT labeling program and the inquiries and alternatives discussed in the Notice.  The Commission’s evaluation of this information will shape the final alternatives it considers to minimize any significant economic impact that may occur on small entities, the final conclusions it reaches and any final rules it promulgates in this proceeding.
F. Federal Rules that May Duplicate, Overlap, or Conflict with the Proposed Rules
27. None.

STATEMENT OF
CHAIRWOMAN JESSICA ROSENWORCEL

Re:	Cybersecurity Labeling for Internet of Things, PS Docket No. 23-239, Notice of Proposed Rulemaking (August 8, 2023)

There are so many new devices—from smart televisions and thermostats to home security cameras, baby monitors, and fitness trackers—that are connected to the internet.  In fact, right now there are estimates that there are 17 billion smart devices in the world, and that number is expected to increase to 25 billion by the end of the decade.  These technologies provide all kinds of benefits because they can make our lives easier and more efficient.  They allow us to do things like check who is at the front door when we are away, keep tabs on our health, and automatically adjust the thermostat, so we save on our energy bills. 
However, this increased interconnection brings more than just convenience.  It brings increased security risk.  After all, every device connected to the internet is a point of entry for the kind of cyberattacks that can take our personal data and compromise our safety.  That is true for the biggest connections to the largest businesses and the smallest connections to the devices in our homes. 
I believe it doesn’t have to be this way.  That’s because we can do more to make internet of things devices secure and help consumers make good choices about what they bring into their homes and businesses.  
This is exactly what we propose to do so with this rulemaking.  We propose to put in place the first-ever voluntary cybersecurity labeling program for connected smart devices.  We are calling it the U.S. Cyber Trust Mark.  And just like the “Energy Star” logo helps consumers know what devices are energy efficient, the Cyber Trust Mark will help consumers make more informed purchasing decisions about device privacy and security.  So when you need a baby monitor or new home appliance, you will be able to look for the Cyber Trust Mark and shop with greater confidence.  What’s more, because we know devices and services are not static, we are proposing that along with the mark we will have a QR code that provides up-to-date information on that device.  
This proposal builds on good work already done by government and industry because we will rely on the NIST-recommended criteria for cybersecurity to set the Cyber Trust Mark program up.  That means we will use criteria device manufacturers already know, and, when they choose to meet these standards, they will be able to showcase privacy and security in the marketplace by displaying this mark.  Over time, we hope more companies will use it—and more consumers will demand it.  

With this notice we seek input on how best to establish this voluntary labeling program, the scope of eligible devices, the mechanics of managing this program, how to further develop standards that could apply to different kinds of devices, how to demonstrate compliance with those standards, and how best to educate consumers.  

That is not a small task.  But it’s worth it.  Because the future of smart devices is big and the opportunity for the United States to lead the world with a global signal of trust is even greater.  I appreciate the interest my colleagues have expressed in this effort, look forward to the record that follows, and in the future seeing the Cyber Trust Mark in the marketplace.

2
STATEMENT OF
COMMISSIONER GEOFFREY STARKS

Re: 	Cybersecurity Labeling for Internet of Things, Notice of Proposed Rulemaking, PS Docket No 23-239.

Nearly 40 years ago David Nicols had a problem.  As a graduate student enrolled in Carnegie Mellon University’s computer science department he needed a caffeine hit, but it was a hike to reach the soda machine in his building, and it frequently ran out.  He wanted a tool to stop the trend of returning from his long walks empty-handed.  So, he did what any enterprising computer scientist would do—he solved the problem using technology.  He and some friends created an application that monitored the soda machine’s reserves and connected it to ARPANET, the Internet’s forerunner, so they could remotely view the soda availability and temperature.  In doing so, we now know, they actually created the very first Internet of Things (IoT) device. The Carnegie Melon University Computer Science Coke Machine, The ‘Only’ Coke Machine on the Internet, Carnegie Melon, available at https://www.cs.cmu.edu/~coke/history_long.txt. 
  It was a success, to say the least!  Another student followed suit, focusing on the nearby M&M machine, and it was off to the races. Jordan Teicher, The Little Known Story of the First IoT Device, IBM.com, Feb. 7, 2018, available at https://www.ibm.com/blog/little-known-story-first-iot-device/ (The Little Known Story of the First IoT Device).
 
From those humble beginnings, it’s now hard to imagine an electronic device that isn’t connected.  One manufacturer estimates that there are more than 20 billion IoT devices in active use around the world, Nokia Threat Intelligence Report Finds Malicious IoT Botnet Activity Has Sharply Increased, Press Release, Nokia.com, June 7, 2023, available at https://www.nokia.com/about-us/news/releases/2023/06/07/nokia-threat-intelligence-report-finds-malicious-iot-botnet-activity-has-sharply-increased/. 
 and it is estimated that spending on IoT surpassed $1 trillion dollars in 2022, and will be even higher this year. IDC Report: IoT Spending to Reach More than $1 Tillion by 2022, Finley Research (Last visited Aug. 8, 2023), available at https://finleyusa.com/idc-report-iot-spending-to-reach-more-than-1-trillion-by-2022/#:~:text=Telecom%2C%20Broadband-,IDC%20Report%3A%20IoT%20Spending%20to%20Reach%20More%20than%20%241%20Trillion,%24646%20billion%20spent%20last%20year. 
  On this front, I saw continued momentum firsthand when I visited this year’s Consumer Electronics Show earlier this year.  
The proliferation of IoT devices has, of course, led to many benefits in society.  At the same time, their use has elevated the United States’ risk profile due to their prevalence in our networks and physical world.  Without the right level of security, they constitute an attack plane that can introduce vulnerabilities, both individually or as part of a network of IoT devices working together, sometimes referred to as botnets.  This threat occurs due to the fact that historically, many IoT devices were created and deployed without necessary baseline cybersecurity protections, which bad actors can exploit. Alert, Secure New Internet-Connected Devices, Cybersecurity and Infrastructure Security Agency, Dec. 31, 2019, available at https://www.cisa.gov/news-events/alerts/2019/12/31/secure-new-internet-connected-devices. 
  Unprotected IoT devices and devices with simple or no security such as easily guessable default passwords are susceptible to malware 2022 Sonicwall Cyber Threat Report, Mid-Year Update, Sonicwall (Last visited Aug. 8, 2023), available at https://www.sonicwall.com/medialibrary/en/white-paper/mid-year-2022-cyber-threat-report.pdf (finding a 77% increase in malware attacks for IoT/Connected Devices in the first half of 2022). 
 and hacking, and can be used to create botnets that can wreak havoc on our networks.  These unsecure IoT devices when used maliciously can block access to the Internet and websites, waste network resources, and cause harm to people, businesses, and government alike.
Recognizing the problem, the United States government has taken steps to mitigate the risks and improve security.  Beginning in 2018, the Department of Commerce’s Botnet Report identified actions to protect devices and networks including the idea of a labeling program. A Report to the President on Enhancing the Resilience of the Internet and Communications Ecosystem Against Botnets and Other Automated, Distributed Threats, Action 5.2, Department of Commerce and Department of Homeland Security, May 22, 2018, available at https://www.commerce.gov/sites/default/files/2020-07/eo_13800_botnet_report_-_finalv2.pdf.
  President Biden drew on that approach when releasing his Executive Order on Improving the Nation’s Cybersecurity, EO 14028, requiring an IoT labeling pilot. Executive Order on Improving the Nation’s Cybersecurity, Sec. 4, Enhancing Software Supply Chain Security, The White House, Executive Order 14028, https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/.
  President Biden’s National Cybersecurity Strategy went further and included driving the development of secure IoT devices as a strategic objective. National Cybersecurity Strategy, Strategic Objective 3.2, The White House, Mar. 1, 2023, https://www.whitehouse.gov/wp-content/uploads/2023/03/National-Cybersecurity-Strategy-2023.pdf. 
  
That leads us to this proposal, which is the cumulation of a significant amount of work between our federal government partners, especially the National Institute of Standards and Technology (NIST), and private stakeholders.  I strongly support moving on the IoT cybersecurity label, and believe that it will ultimately help consumers identify how secure a device may be, and support safe networks.  As we develop the proposal, however, I look forward to closely reviewing the record to make sure we get it right.  I want to highlight two particular issues that are especially important. 
First, it is vital that the cybersecurity label program is as pro-consumer as possible.  We must ensure that our actions make it easier for consumers to quickly understand the information on the label and then make informed purchasing decisions.  Along those lines, we properly ask critical questions to ensure that the cybersecurity labeling program matches consumer expectations.  One important question is how the IoT cybersecurity labeling program should be scoped.  Specifically, should it be focused on products as a whole, or on subcomponent devices.  As we develop the record for guidance, it may also be useful for us to consider other successful government consumer education labeling programs, such as the Department of Energy’s ENERGY STAR program.  The item seeks comment on both approaches, and I will be closely reviewing the record to make sure we get this right.  I thank the Chairwoman and my fellow Commissioners for agreeing to my edits to ensure that the IoT cybersecurity label has the proper scope. 
Second, we must ensure that the IoT cybersecurity label protects Americans.  If insecure equipment becomes included in the IoT cybersecurity label, it will undermine network security and the public’s trust in the IoT cybersecurity labeling program.  Thus, it is vital that we do not place our stamp of approval on devices from producers that the United States government and its agencies have already identified publicly as part of a national security review.  I’m glad that the Chairwoman and my colleagues agreed to include a proposal to expand the list of products that will be excluded from access to the IoT cybersecurity label beyond the Commission’s List of Covered Communications Equipment and Services to also include companies named on the Department of Commerce’s Designated Entity List, the Department of Defense’s List of Chinese Military Companies, and similar lists.  I look forward to reviewing the record to further ensure that adversarial countries do not try to take advantage of the labeling program to harm our networks.  
The Commission has recently taken strong steps to protect the security of our networks, and now, with the IoT cybersecurity label, connected products and devices.  Last month, at my urging, the Commission for the first time explicitly required providers that deploy broadband networks receiving federal Universal Service funds to implement operational cybersecurity and supply chain risk management plans that reflect the latest NIST and government guidance.  This ensured that networks built with Universal Service Fund support are just as secure as those built with other support programs from other federal agencies.  It is also an important precedent that will signal to other providers that they should do the same, if they haven’t already done so.  Combined with our efforts to protect connecting products and devices, we can be confident that we are taking important and necessary steps to secure our networks.  But, there is more to do and I am committed to continuing to work with all stakeholders on any additional steps that we can take to protect our communications networks. 
Those Carnegie Mellon students didn’t know how their idea would flourish in the world when they just wanted a cold soda.  Indeed, as they were creating the first IoT device, they joked around about how your toaster was one day going to be on the Internet. The Little Known Story of the First IoT Device.  
  Thanks to this proposal, we are one step closer to helping consumers understand exactly what cybersecurity protections their connected toaster, and many other IoT devices, have enabled.  I thank the FCC staff that worked on this item for their hard work.


	Federal Communications Commission	FCC 23-65

STATEMENT OF
COMMISSIONER NATHAN SIMINGTON

Re: 	Cybersecurity Labeling for Internet of Things, PS Docket No. 23-239, Notice of Proposed Rulemaking

Cybersecurity vulnerabilities are inevitable. Even the best engineers, supported by sophisticated organizations and applying the best software development methodologies, cannot hope to eradicate every security flaw lurking in a modern software-powered device. A single one of these vulnerabilities can be enough to render access controls and other security mechanisms useless, allowing even amateur attackers to bypass them and gain illicit access to sensitive information and controls. Because any device is liable to be rendered insecure at any time by a newly discovered flaw, a responsible manufacturer should undertake to search for and patch vulnerabilities as quickly as possible. Otherwise, it might as well be putting ticking time-bombs into the homes and businesses of every one of its customers across the country.

Unfortunately, many device companies have fallen short. It often takes months for a fix to a serious vulnerability to make its way to end user devices, if the manufacturer bothers to release an update at all, and if the device was designed to be updateable in the first place. Manufacturers frequently pull the plug on support for a device well before consumers have stopped using it. The length of security support periods—the time period during which users can count on receiving timely security updates—is usually not communicated at the time of sale, and sometimes the end of support is not even announced, leaving even the most informed users unsure whether their devices are still safe to use. And many devices require manual installation of security updates, something very few consumers will ever do.

This is no mere academic concern. Attacks on unpatched devices are becoming more frequent and more dangerous. A recent FBI advisory warned of increasing cyberattacks against unpatched medical devices. https://www.ic3.gov/Media/News/2022/220912.pdf 
 Unpatched industrial control systems threaten the availability of critical infrastructure. https://www.darkreading.com/vulnerabilities-threats/cisa-warns-unpatched-vulnerabilities-ics-critical-infrastructure; https://www.cisa.gov/news-events/alerts/2023/03/21/cisa-releases-seven-industrial-control-systems-advisories; https://www.darkreading.com/ics-ot/unpatched-iot-ot-devices-pile-up-ics-cyberattacks
 The Mirai botnet, which at its peak consisted of over 600,000 compromised devices performing large-scale cyberattacks in unison, grew by scanning the internet for devices with unpatched vulnerabilities like IP cameras and routers and taking control of them. https://blog.cloudflare.com/inside-mirai-the-infamous-iot-botnet-a-retrospective-analysis/; https://www.scmagazine.com/news/unpatched-apache-tomcat-servers-spread-mirai-botnet-malware; https://www.theregister.com/2023/05/02/cisa_exploited_flaws_oracle_apache/
 And we have not yet seen the worst. An attacker could use unpatched vulnerabilities to take control of large numbers of mobile phones, turn their radios into signal jammers, and take down mobile networks. https://www.cise.ufl.edu/~traynor/papers/ccs09a.pdf 
 Botnets of commandeered high wattage devices like air conditioners, water heaters, and ovens could be used to disrupt the power grid and even cause large-scale blackouts. https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-soltan.pdf 
 And attacks on cyberphysical systems like automated cars, or on medical devices, can directly cause widespread property destruction, human injury, and death. 

The early days of the connected device industry are behind us, and the laissez-faire attitude that came with rapid innovation now threatens to thwart the industry’s progress into more serious domains where the stakes are higher. As we entrust technology with greater responsibility for our money, privacy, personal safety, and public order, we need to have greater confidence in its security. Otherwise, increasingly damaging cyberattacks will undermine faith in automated systems and prevent us from realizing the full gains in productivity and quality of life that the technological revolution promises. 

I am only able to support this initiative because it includes my proposal that the cybersecurity labels disclose the time period during which a device’s manufacturer commits to diligently issue security updates. A stamp of approval from the United States government for the security of your device should reflect the genuine confidence of the American people. You cannot possibly qualify for such an endorsement if you refuse to provide even this bare minimum of transparency. If you want this label on your product, you must earn it by taking responsibility for the security of your product, not just while you initially develop it, but for its entire lifespan. Requiring any less would make the United States government complicit in reckless conduct that endangers the safety and security of every American. I want to thank the Chairwoman and the other Commissioners for supporting my request that we include this provision.

I suspect that some manufacturers will choose to not pursue a label rather than commit themselves to doing the right thing. The United States government should be proud to deny such companies a label. Let the absence of a label serve as a warning: this device is not safe.
2