Congress regulated connected devices by deciding what agencies may buy

The IoT Cybersecurity Improvement Act set no rules for manufacturers. It set rules for one very large customer. That shifted vulnerability-handling duties onto contractors and exposed an older problem: agencies cannot apply device rules to devices they have not inventoried.

Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.

The week

On December 4, 2020, the IoT Cybersecurity Improvement Act of 2020 was signed into law after passing both chambers with bipartisan support. It directed the National Institute of Standards and Technology to develop standards and guidelines, including minimum security requirements, for federal use and management of Internet of Things devices. The Office of Management and Budget was to align agency policies with them. NIST was also to publish guidelines for reporting and resolving security vulnerabilities in agency information systems, including by contractors and their subcontractors. Agencies were barred from procuring or using IoT devices that did not comply with the standards, subject to waivers in defined circumstances, such as national security or research needs.

For years, debate about connected-device security stalled on one question: should the government regulate manufacturers directly? The December 2020 law sidestepped it. Rather than set rules for everyone who makes a connected camera, sensor or controller, Congress set rules for the federal government as a buyer. The approach has three parts worth separating: purchasing power as a policy instrument, duties placed on contractors, and the inventory problem that decides whether any device rule works in practice.

Purchasing power as a policy instrument

The federal government buys a great many connected devices. Building management systems, security cameras, badge readers, environmental sensors, medical equipment in federal health facilities and networked equipment in field offices all count. Requiring those purchases to meet NIST-defined security baselines gives manufacturers a reason to build the baselines in. Once a product line meets federal requirements, the same features are usually available to every customer, because maintaining two versions costs more.

The approach has precedent in federal technology policy, from cloud authorization to accessibility requirements. It avoids creating a new regulator. It can move faster than legislation aimed at a whole market. And it relies on standards bodies with technical credibility, which makes the requirements easier for engineers to accept.

It also has limits. It binds only products sold to the government, and a manufacturer with no federal customers has no obligation. Its reach into the wider market depends on how many manufacturers choose to standardize. Waivers, permitted for national security, research and other defined needs, can erode it if they are granted freely.

For state and local agencies, health systems and banks, the federal baseline became a useful reference even where it had no legal force. A procurement team could ask whether a product met the NIST device guidance instead of writing technical requirements from scratch. That saved effort and gave vendors a single target.

Duties placed on contractors

The second part drew less attention at the time. The law directed NIST to set guidelines for how contractors and subcontractors providing information systems to agencies receive and act on vulnerability reports, and how agencies handle them. In practice it moved coordinated vulnerability disclosure from good practice toward a condition of doing business with the federal government.

For vendors, that meant a public way for researchers to report problems, a process to triage and fix them, and a way to tell customers. Large technology companies mostly did this already. Smaller device makers and integrators often did not. The cost was modest compared with product engineering, but it required a named owner, and it created records that could be examined later.

For agency procurement officers, the law added a question to supplier evaluation: how does this vendor handle vulnerabilities after the sale? That concerns a supplier’s security practice over years, not a feature of one device. It needs different evidence, such as the vendor’s published disclosure policy, its record of advisories and its stated support period for each product.

Support periods matter more than they appear. A device that meets every baseline on delivery but receives no updates after two years becomes a liability inside a building expected to last decades. Contracts that specify a minimum period of security updates, and what happens at end of support, turn a vague promise into an obligation.

The inventory problem underneath

The third part decides whether any device rule works. An agency cannot check compliance for devices it does not know it has. Connected devices are often bought outside the IT budget by facilities, physical security or program offices, and installed by contractors. They may never appear in the agency’s asset inventory or network management tools.

The law’s prohibition applied at the point of procurement and use. That put weight on the chief information officer’s ability to see what was being bought and connected. It required coordination with acquisition offices and facilities teams that had not always treated these devices as IT. Each waiver added a governance task, because it needed justification, an owner and tracking.

The same problem exists in every regulated sector. Hospitals run large fleets of networked medical and building devices. Banks run cameras, ATMs and branch equipment. In each case, whether anyone knows the device exists, who maintains it and whether it can be patched or isolated matters more than its security features on paper.

Buyers outside the federal government can adopt the template without new legislation. A purchasing standard can name an existing security baseline, require a published vulnerability disclosure process and a minimum update period, and make entry in the asset inventory a condition of installation. The hard part is enforcement inside the organization. Finance, facilities and procurement teams need to recognize which purchases count as connected devices and route them for review before the contract is signed, not after the device is on the network. A simple flag in the purchasing system for anything with a network port catches most of them.

With hindsight

NIST published federal IoT device guidance in 2021, building on its earlier work on baseline device security capabilities. The law’s prohibition on agencies procuring noncompliant devices took effect two years after enactment, in December 2022. The procurement-first model spread. In 2024 the Federal Communications Commission created the U.S. Cyber Trust Mark, a voluntary labeling program for consumer connected devices drawing on NIST criteria. In health care, legislation enacted at the end of 2022 gave the Food and Drug Administration explicit authority over the cybersecurity of new medical devices.

Coordinated vulnerability disclosure is now a standard expectation for federal suppliers. The inventory problem proved the most stubborn. Federal directives on asset visibility, and later guidance on operational technology, kept returning to it. The law worked as intended where agencies already knew what they owned, and less well where they did not.

  • IoT
  • federal procurement
  • NIST
  • vulnerability disclosure
  • asset inventory