Congress regulated connected devices by deciding what agencies may buy

The week

On December 4, 2020, the IoT Cybersecurity Improvement Act of 2020 was signed into law after passing both chambers with bipartisan support. Its approach was distinctive. It did not tell manufacturers what to build. It told the federal government what it could buy.

The devices in question fill every federal office building, and most of them do not look like computers. The security camera above the door, the badge reader at the turnstile, the thermostat on the wall, the sensor that tracks humidity in a records room: each is a small computer connected to a network. Together they are known as the Internet of Things, or IoT, the broad family of everyday physical devices that now carry software and talk to other systems.

These devices are useful and cheap, and many of them are poorly secured. Some ship with default passwords nobody changes. Some never receive software updates. Because they are connected to the same networks as everything else, a weak camera can become a way into far more sensitive systems. For years, policymakers debated what to do about it.

The debate had a memorable trigger. In October 2016, the Mirai botnet, built largely from cameras and video recorders still using factory passwords, knocked major websites offline by flooding the internet infrastructure company Dyn. Senators Mark Warner and Cory Gardner introduced an earlier version of the bill in 2017, and it did not pass. The 2020 version, led in the House by Representatives Robin Kelly and Will Hurd, passed the House by voice vote in September 2020. The Senate passed it by unanimous consent on November 17.

The law defined its scope with care. A covered device had at least one sensor or actuator that interacts with the physical world and at least one network interface, and could function on its own. Conventional IT, such as laptops, smartphones and servers, was excluded, because other federal policies already governed it. The definition aimed squarely at the cameras, controllers and sensors that had fallen between existing rules.

The law directed the National Institute of Standards and Technology, or NIST, to develop standards and guidelines, including minimum security requirements, for federal use and management of IoT devices. NIST is the federal agency best known for technical standards and measurement science. The Office of Management and Budget, which oversees how federal agencies manage their operations and budgets, was to align agency policies with them.

The law set a timetable. NIST had 90 days to issue the device standards and guidelines, and OMB was then to review agency policies against them. NIST was to revisit the standards at least every five years. NIST did not start from scratch. In May 2020 it had published a core baseline of device security capabilities for manufacturers, covering device identification, configuration, data protection, access to interfaces, software updates and awareness of the device’s own security state.

NIST was also to publish guidelines for reporting and resolving security vulnerabilities in agency information systems, including by contractors and their subcontractors. A vulnerability is a weakness in software or hardware that an attacker could exploit. The guidelines concerned how such weaknesses are reported, by researchers or others, and how they get fixed.

Finally, and most consequentially, 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. Waivers rested with an agency’s chief information officer. Beyond national security and research, the third ground was that the device would be secured by alternative and effective methods. Congress had chosen to regulate through the purchasing department, and anyone who sells to government had reason to notice.

The prohibition was not immediate. It took effect two years after enactment, giving manufacturers and agencies until December 2022 to adjust.

The law fitted a pattern of federal moves that autumn. In September 2020, CISA had issued Binding Operational Directive 20-01, requiring agencies to publish their own vulnerability disclosure policies, and OMB had issued a companion memorandum on vulnerability management. Section 889 of the 2019 defense authorization act had already barred agencies from buying certain telecommunications and video surveillance equipment from named Chinese manufacturers. At state level, California’s connected-device security law, which requires reasonable security features such as unique passwords, had taken effect in January 2020. Device security was being addressed one buyer and one jurisdiction at a time.

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. First, though, comes the reason connected devices are such a stubborn security problem.

Computers that do not look like computers

A laptop or a server is obviously a computer. Organizations know to manage them: they install security software, apply updates and track who uses them. Connected devices are different because they do not feel like computers. A badge reader feels like part of the door. A camera feels like part of the building. A temperature sensor feels like part of the heating system. Yet inside each one is a small processor running software, and a network connection that links it to other systems.

Several features make these devices hard to secure:

• Long lives. A laptop is typically replaced after a few years. A building controller or a camera may stay on the wall for a decade or more.
• Limited updates. Many devices receive few software fixes, and some receive none after the manufacturer moves on to a newer model.
• Weak defaults. Devices often ship with standard passwords or open settings to make installation easy, and those settings are not always changed.
• Hidden ownership. They are frequently bought and installed by facilities or security teams rather than the IT department, so they may not appear in the lists IT uses to manage risk.

An organization with hundreds of unmanaged connected devices resembles an office building where every tenant can install a side door, each with a lock of unknown quality, and nobody keeps a list of where the doors are. The front entrance might be superbly guarded, but the building is only as secure as its weakest unrecorded side door.

Scale compounds each of these features. A large campus can hold more connected devices than laptops, spread across dozens of models from many manufacturers, each with its own update method. Managing laptops is a single discipline with mature tools. Managing that variety of devices is many small disciplines, which is why it so often goes undone.

How a weak device becomes a breach

The attack paths are well understood. Automated scanners sweep the internet for device management pages and try factory passwords. A device reachable from the internet with a default password can be taken over in minutes, without any human attacker paying attention to the target. Mirai worked exactly this way, at enormous scale.

Inside a network, a compromised device is a foothold. Many buildings run cameras, controllers and workstations on one flat network, with no barriers between them. From a camera, an intruder can scan for file servers, capture traffic or reach management consoles. Devices rarely run security software, and few organizations collect their logs, so activity on them goes unseen.

Firmware brings its own risk. A flaw in the software inside a device may affect every unit of that model, across thousands of customers. Fixing it requires the manufacturer to ship an update and every owner to install it. Many owners never learn that the update exists. Cloud-managed devices add another dependency: the security of the manufacturer’s own management platform.

What the federal baseline asks of a device

NIST’s core baseline describes six capabilities. A device should have a unique identity that can be recognized on a network. Its configuration should be changeable by authorized users only. It should protect the data it stores and sends. Access to its interfaces should be limited to authorized people and systems. Its software should be updatable through a secure, controlled process. And it should be able to report on its own security state, for example by logging events.

The baseline is deliberately modest. It does not require a device to be invulnerable. It requires the basic means to manage a device securely over its life. A buyer who insists on those six capabilities can at least change passwords, apply fixes, restrict access and see when something goes wrong. Without them, every later control is improvised.

Security teams use the term baseline for a minimum set of security features a device should have: for example, the ability to change default passwords, to receive software updates securely and to protect the data it stores. The 2020 law’s central idea was that the federal government would only buy devices that met a baseline defined by NIST.

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. A manufacturer is unlikely to sell a secure camera to the government and a separate, less secure version of the same camera to a school district. The cheaper path is to make one product that meets the stricter standard, which is how a rule aimed at one customer can raise the floor for everyone.

The approach has precedent in federal technology policy, from cloud authorization to accessibility requirements. In each case, the government used its scale as a buyer to set expectations that then spread through the market. 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. An exception process is sensible, since some specialized equipment has no compliant alternative, but every exception is a small hole in the policy.

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. For a mid-sized city or a community bank, which has neither the staff nor the market power to write its own device standard, borrowing the federal one is an efficient shortcut.

What makes a baseline checkable at purchase

A baseline helps only if a buyer can tell whether a product meets it. There are three ways to know. The vendor can attest, which is cheap and relies on trust. The buyer can test, which is reliable and expensive. An independent lab can certify, which spreads the cost across all buyers but takes time to establish. In 2020 the federal device baseline rested mainly on vendor documentation and agency judgment, since no certification scheme yet existed for it.

Attestation still has value when it is specific. A vendor asked to state, capability by capability, how its product meets the baseline gives a buyer something to check during installation and to hold against it later. A generic statement that the product is secure gives nothing. Procurement teams should ask for the specific version.

Precedents and their record

The federal government has used its purchasing power this way before. FedRAMP, established in 2011, set a common security authorization for cloud services sold to agencies, and many state, local and private buyers came to treat it as a reference. Section 508 of the Rehabilitation Act requires accessible technology in federal purchases, which pushed accessibility features into mainstream products. Section 889 of the 2019 defense authorization act used procurement to exclude named suppliers of telecommunications and surveillance equipment.

The record is mixed in a useful way. Purchasing rules work best when compliance can be checked at the point of sale and the standard is stable. They work less well when compliance depends on behavior over years, such as issuing timely updates. The IoT law covered both kinds of obligation. Device capabilities are checkable at purchase. Vulnerability handling is a relationship that needs ongoing evidence.

How the template reaches other sectors

Outside the federal government, the reference works through each sector’s own oversight. Banks and credit unions answer to examiners who review third-party risk management, and the federal banking agencies issued joint guidance on third-party relationships in 2023. Device suppliers fall within that program like any other vendor. Health systems answer to HIPAA, which requires a risk analysis covering all systems that hold patient data, including connected medical devices. State agencies answer to their own procurement codes and chief information security officers.

These regimes do not name the federal device baseline. Each, though, asks the organization to show that it assessed supplier risk on reasonable grounds. Citing a published federal baseline is an easy way to show that.

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.

Coordinated vulnerability disclosure is a structured way of handling the discovery of a security flaw. An outside researcher, a customer or an employee finds a weakness. Instead of publishing it immediately, which would alert attackers, or keeping it to themselves, which would leave it unfixed, they report it privately to the vendor. The vendor confirms it, develops a fix and then tells customers, often in a public notice called a security advisory.

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. Those records cut both ways: they demonstrate diligence, and they make it visible when a reported flaw sat unaddressed.

Researchers gain from the arrangement too. A researcher who finds a flaw and cannot reach anyone at the vendor faces a poor choice between silence and public disclosure. A clear reporting channel gives a third option. Vendors with working programs tend to hear about flaws privately and early, and their customers see fixes before attackers see the details.

What a disclosure program contains

A credible program has a few parts. A published policy says which products are in scope, how to submit a report and what the vendor commits to in return, often including a promise not to pursue legal action against good-faith researchers. An intake channel receives reports reliably, whether a dedicated address, a web form or a platform. A triage process confirms the flaw, rates its severity and assigns an engineer. Larger vendors obtain identifiers for each flaw through the CVE system, so customers can track it across tools.

The output is the advisory: a notice to customers describing the flaw, affected versions, the fix and any interim mitigation. Timelines matter. Many programs commit to acknowledging a report within days and to publishing a fix or advisory within a stated period. Buyers can ask for those commitments in writing and check the vendor’s history against them.

The management platform behind the device

Many devices are now configured and monitored through the manufacturer’s cloud service rather than a local console. That shifts part of the security question from the device to the platform. A buyer should know how administrators sign in to the platform, whether it supports the buyer’s own single sign-on and multifactor authentication, and whether its logs can be exported to the buyer’s monitoring tools. It should also know where recorded data, such as video, is stored and who at the vendor can reach it.

For federal buyers, a cloud platform that holds agency data may also fall under cloud authorization rules. For others, the platform belongs in third-party risk review alongside the device. A device that meets every baseline can still be exposed through a weak management platform shared by thousands of customers.

Who owns the flaw in a white-label device

Many connected devices are built by one company and sold under another’s brand. Integrators then install them with their own software and settings. When a flaw is found, it may sit with the original manufacturer, the brand owner or the integrator’s configuration. A disclosure requirement that names only the seller can leave the actual fix in limbo. Contracts should say who receives reports, who fixes which layer and who tells the customer.

Small suppliers feel this most. A regional integrator that installs access-control systems may never have run a disclosure program. For it, the law meant building one, or relying on the manufacturer’s and saying so clearly. Either choice can work. Silence on the question does not.

The agencies’ own side

The contractor duties mirrored what agencies were being asked to do themselves. Under CISA’s 2020 directive, each agency had to publish a vulnerability disclosure policy covering its internet-facing systems and accept reports from the public. Agencies thus learned to run the same process they would expect from suppliers. That symmetry helps a buyer judge a supplier’s answers, because the buyer has done the work itself.

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 rather than 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. The buyer is evaluating a relationship as well as a 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. An asset inventory is the organization’s list of the technology it owns and runs: what it is, where it is, who is responsible for it and what software it uses. It sounds basic, yet it is one of the hardest disciplines in technology management to keep accurate.

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. A facilities manager replacing the building’s heating controls is thinking about energy efficiency and comfort rather than network security, and the purchase may look to the finance system like any other building maintenance contract.

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. Patching means installing a software fix. Isolating means placing a device on its own segment of the network, so that if it is compromised the intruder cannot easily move on to more valuable systems.

Finding what is already there

Building an inventory of connected devices takes several methods, because each sees only part of the picture. Passive network monitoring watches traffic and identifies devices by their behavior, without touching them. Active scanning probes the network directly, finding more but risking disruption to fragile equipment. Network switches, address assignment logs and network access control systems record what has connected. Purchase records and facilities contracts show what was bought. A physical walk-through finds what none of the others can.

The methods disagree, and reconciling them is the work. A device seen on the network but absent from purchase records may have arrived with a contractor. A device in purchase records but never seen on the network may be offline, retired or on a separate network nobody monitors. Each discrepancy is a question for a named owner. Over time, the reconciliation becomes routine, and new discrepancies get smaller.

When a device cannot be fixed

Some devices can never meet the baseline. They are too old, their maker no longer supports them, or replacing them would disrupt a clinical, physical or financial process. For these, isolation is the fallback. The device goes on its own network segment, allowed to talk only to the systems it needs. Remote access goes through a controlled gateway. Monitoring watches the segment’s boundary. These steps lower the risk without removing it, and a replacement date should still be set.

A device’s life, from request to retirement

Each stage in the life of a single connected device is a chance to get security right or wrong.

The request. A program office, a facilities team or a security group decides it needs new equipment. At this stage the request usually describes a business need, such as better coverage of a parking lot, rather than a technology. Nobody may treat it as an IT purchase at all.

The purchase. Procurement compares vendors, mostly on price, features and delivery dates. This is the moment of greatest influence over the supplier. Questions about security baselines, vulnerability handling and support periods cost nothing to ask here and are very hard to add later.

The installation. A contractor mounts the device, connects it and configures it. Default passwords are either changed or left alone. The device is either placed on its own segment of the network or dropped onto the main one. It is either recorded in the asset inventory or not.

The years of service. The device runs unnoticed, often for many years. Updates arrive, or they do not. Flaws are discovered by researchers and announced by the vendor, or the vendor goes silent. Staff change, and the person who knew the device existed moves on.

Who owns the device once it is installed

Ownership splits three ways after installation. Facilities or the program office owns the device and its purpose. IT owns the network it connects to. Security owns monitoring and response. Each assumes one of the others handles updates. A short written agreement for each device class settles who approves updates, who schedules them around building or clinical operations and who decides when a device must be isolated.

Update timing is a practical constraint. A badge system cannot go down during a shift change, and a building controller update may need an engineer on site. Agreeing maintenance windows in advance prevents the common outcome, which is that updates wait indefinitely because no time is ever convenient.

The retirement. Eventually the device is replaced. If it was never recorded, it may simply be left connected and forgotten, an unlocked side door that nobody remembers is there.

Retirement has its own security step. Devices store credentials, network settings and sometimes recorded data. Before disposal, they should be reset or sanitized according to an accepted method, such as those in NIST’s media sanitization guidance, and removed from the inventory with a record of how.

The 2020 law concentrated on the second stage, the purchase, because that is where a buyer’s influence is greatest. The inventory problem lives in the third and fifth stages, which is why it proved so much harder to solve with a purchasing rule alone.

Outages, costs and audit findings

The law and the problem it addresses connect to several familiar concerns for a senior leader.

Risk and resilience. A compromised connected device can be the first step in a wider attack. It can also be the target itself: a building system that stops working, cameras that go dark, or medical equipment that must be taken offline. These are operational disruptions as much as data breaches.

Cost. Buying a cheaper device with no update commitment can be the more expensive choice over the device’s life, once the cost of replacing it early, isolating it or managing an incident is counted. Procurement decisions made on purchase price alone tend to push costs into later budgets.

Counting the full cost

The full cost of a connected device has several layers beyond its price. Installation and configuration come first. Network work follows, including a separate segment where needed. Over the device’s life come update labor, monitoring, support renewals and the cloud subscription many devices now require. At the end come early replacement if support ends, secure disposal and, sometimes, an incident. Comparing vendors on this fuller basis often changes the ranking, and it gives finance teams a reason to support the security requirements.

Contracts and suppliers. For companies that sell to government, the law changed what customers would ask for. Vendors without a disclosure process or a stated support period found themselves at a disadvantage. For any organization, it offered a template for what to ask of its own suppliers.

Regulators and auditors. Examiners and auditors increasingly ask organizations to show that they know what technology they run. An incomplete inventory is a finding in its own right, and it undermines confidence in every other control.

How the problem differs by organization

Hospitals have the largest and most sensitive device fleets. Infusion pumps, imaging systems and patient monitors sit alongside building controls, and clinical engineering teams, rather than IT, often own them. Medical devices carry their own regulatory regime under the FDA, and replacing them is costly and clinically disruptive. Isolation and careful inventory therefore matter more there than in most sectors.

Banks and credit unions run ATMs, branch cameras, alarm systems and environmental controls. Payment card terminals also fall under card industry security standards for merchants and service providers. Device risk reaches examiners through third-party and information security reviews, and the expectation is that the institution can show what it runs and who maintains it.

Counties and cities run courthouses, jails, water plants and emergency communications centers. Where a device touches criminal justice information, the FBI’s CJIS Security Policy can apply to the systems involved. Many local governments rely on a single integrator for cameras and access control across all their buildings, which concentrates both convenience and risk in one contract.

Federal agencies had the law itself, plus directives on asset visibility and the FedRAMP regime for cloud services that many devices now depend on. Their challenge was scale and dispersion: field offices, leased buildings and equipment bought locally under small purchase authorities.

The case against buying your way to security

The approach has serious critics. A purchasing rule can become a checkbox: a vendor attests to the baseline, the contracting officer files the attestation, and nobody checks how the device is installed. Waivers can become routine. Market power varies, and many device categories have too few federal buyers to move manufacturers. Critics also note that manufacturers selling mainly to consumers face no federal obligation at all, which is why other jurisdictions chose to regulate makers directly.

Those criticisms are fair, and the hindsight supports some of them. Still, the procurement route had advantages the alternatives lacked in 2020. It required no new regulator, set a standard engineers respected and moved faster than a market-wide mandate could. It also gave every other large buyer a template it could adopt without waiting for legislation. A purchasing rule and a direct rule on makers are complements. The first is available to any buyer today.

Borrowing the federal template

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, rather than after the device is on the network. A simple flag in the purchasing system for anything with a network port catches most of them.

Contract clauses that carry the weight

The template becomes real in contract language. A useful set of clauses covers the following:

• Conformance with a named device baseline, with the vendor’s supporting documentation attached.
• A published vulnerability disclosure policy, with stated timelines for acknowledging reports and issuing fixes.
• A minimum period of security updates for each product, and notice well before end of support.
• Notice to the buyer within a stated time of any security incident affecting the product or its management platform.
• A software bill of materials on request, so the buyer can check exposure when a component flaw is announced.
• The buyer’s right to change all credentials and to test the device’s security.

Few buyers will win every clause from every supplier. Asking for all of them, and recording which ones a supplier refused, gives security and procurement teams a basis for comparing vendors and for justifying a higher price.

Where a buyer starting from zero should begin

A buyer with no device program can start small and still make progress within a few months. First, add the network flag to the purchasing system and agree which teams review flagged purchases. Second, adopt a named baseline and a short set of contract clauses for new purchases only. Third, run a discovery exercise on one building or campus, reconcile it against purchase records and isolate what cannot be fixed. Then expand site by site.

That order puts the cheapest, highest-yield step first. It stops the problem from growing while the harder work of finding what already exists proceeds. It also produces early evidence for auditors and boards: a policy, a set of contracts and one site’s reconciled inventory.

Say a county is replacing the access-control system at its courthouse. Under its old habits, the facilities department would pick a vendor on price and features, and the IT team would learn about it when the installer asked for a network connection. Under a better approach, the purchase request is flagged automatically because the system connects to the network. Before signature, the security team checks three things: that the product meets the named baseline, that the vendor publishes a way to report vulnerabilities, and that the contract commits to security updates for a stated period with a clear plan at end of support. Each reader and controller is entered into the asset inventory, with the facilities manager named as owner, before it is switched on. If a waiver is needed because no compliant product fits the courthouse’s requirements, it is written down with a justification, an owner and an expiry date.

Where this goes wrong, it is mostly in the gaps between teams. Treating building and security equipment as “not IT” guarantees that nobody manages its security. Buying on purchase price alone, without regard to update periods and disclosure practice, shifts risk and cost into the future. Checking at installation instead of purchase gives away bargaining power, because once the contract is signed and the device is on the wall, the vendor has little reason to concede. Exceptions without expiry dates become permanent policy by default. And an inventory that has not been checked against what is actually on the network is a guess.

What every large buyer can ask of itself

A large buyer can test itself with a handful of questions:

1. How many connected devices do we run, such as cameras, badge readers, building controls and sensors, and how confident are we in that number?
2. Who buys these devices today, and does IT or security see the purchase before the contract is signed?
3. For our main device suppliers, how would a researcher report a flaw, and how many years of security updates do our contracts guarantee?
4. Which of our devices can no longer be updated, and are they separated from our most sensitive systems?
5. How many exceptions to our device standards are in force, who owns each one, and when do they expire?

The 2020 law showed that a government could raise device security without regulating an entire industry, simply by being a demanding customer. Every large organization is a customer too. The same approach is available to any of them, provided they know what they are buying and what they already own.

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. That two-year runway gave manufacturers and agencies time to adjust, and it meant the real test of the law came well after the headlines faded.

NIST’s 2021 guidance came as a set. SP 800-213 told agencies how to decide what security they needed from a device, and a companion catalog, SP 800-213A, listed the capabilities they could require. NIST also added a baseline of non-technical supporting capabilities, covering what manufacturers should document and communicate to customers. The vulnerability disclosure guidelines followed in final form in 2023 as SP 800-216.

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: a simple signal on the box that a product meets a recognized standard, so that buyers can choose security without needing to evaluate it themselves. 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, extending the logic of minimum expectations into one of the most sensitive categories of connected equipment.

Those later programs had their own origins. The May 2021 executive order on improving the nation’s cybersecurity directed NIST to start pilot labeling programs for consumer devices, which fed the FCC’s work. The FCC adopted its labeling rules in 2024, and the program launched in January 2025. The medical device provision, in force from March 2023, requires makers of “cyber devices” to submit plans for monitoring and disclosing vulnerabilities, a software bill of materials and a process for postmarket updates.

Events underlined the stakes. In March 2021, intruders accessed live feeds from a large number of cloud-managed security cameras sold by Verkada, including cameras in hospitals, schools and jails, using a credential found exposed online. The device in each building was no weaker than its neighbors. The weakness was in the vendor’s cloud management, which the purchasing baseline treated as outside the device.

Coordinated vulnerability disclosure is now a standard expectation for federal suppliers. What was once a sign of a mature vendor became a basic requirement for doing business with government, and many private buyers adopted the same expectation.

The inventory problem proved the most stubborn. Federal directives on asset visibility, and later guidance on operational technology, kept returning to it. Operational technology is the broader category of systems that control physical processes, from building controls to industrial equipment. The repeated return to inventory is telling. Policy can set excellent standards for what to buy, but it cannot by itself tell an organization what it already has plugged in.

Other jurisdictions chose the route Congress avoided. The United Kingdom’s product security regime, in force from April 2024, bans universal default passwords and requires manufacturers to publish disclosure policies and support periods for consumer devices. The European Union’s Cyber Resilience Act, which entered into force in December 2024, sets security obligations for products with digital elements, with most obligations applying from December 2027. Those laws bind makers directly, and they cover markets large enough to shape global product lines.

The most concrete of those directives came in October 2022. CISA’s Binding Operational Directive 23-01 required federal civilian agencies, from April 2023, to run automated asset discovery every seven days and vulnerability enumeration across discovered assets every 14 days. In 2024, CISA and international partners published guidance on building asset inventories for operational technology. Both documents treated inventory as the first control, on which the rest depend.

The law worked as intended where agencies already knew what they owned, and less well where they did not. Purchasing standards are powerful and cheap to adopt. Their value depends entirely on an accurate, maintained picture of what is on the network, and on purchasing processes that catch connected devices before they arrive.