Last updated at Tue, 23 Jul 2019 18:53:36 GMT

Back in March, we blogged about the IoT Cybersecurity Improvement Act of 2019 and shared a number of concerns over the language as it was drafted at the time. In general, we were and continue to be, extremely supportive of both the goal of encouraging IoT manufacturers to build their offerings secure-by-design, and the approach of leveraging the buying power of the U.S. federal government to encourage positive change in the market. Our challenge in supporting the bill lay in the drafting details, which we won’t rehash here, but if you’re interested, we recommend reading that post first.

So, why a second blog post? Well, in recent weeks, both the House (H.R.1668) and Senate (S.734) versions of the bill have gone through markup in their relevant committees. As a result of amendments during their markups, the bills now look quite different from their original language in March, and now, from each other.

Each bill has made improvements, but the Senate version now includes a problematic new section that undermines the bill’s purpose of improving federal IoT security, as we detail below.

If these bills move forward, we hope that this post and other similar efforts will help Congress keep what’s working and address what’s not.

Changes to H.R.1668

The revised House bill has addressed some of our major concerns, namely:

PLC definitions

It has improved the definitions section so that programmable logic controls (PLCs) are no longer referenced as an example of “general-purpose computing devices” (which they are not), and instead are now only exempted as follows:

“(iv) programmable logic controller with an industrial control system specifically not designed for connection to the internet;”

In general, we’re not huge fans of PLCs being called out for exemption since they are an important and evolving class of technology in manufacturing and critical infrastructure, and are just as vulnerable as other classes of technology. Importantly though, the bill’s new language avoids creating a dangerous definitional precedent by positioning PLCs in the wrong category of technology as a “general-purpose computing device.” This is the biggest improvement of the new version of the House bill.

That said, the exemption is a little strange and seems to be trying to get at technology that was not designed to connect to the internet that has since been wired up through some clever hardware and software modifications. These kinds of systems are both prevalent and a huge cybersecurity challenge in critical infrastructure and manufacturing environments, so we would prefer to see security requirements apply to them. While we can appreciate that they are not strictly “Internet of Things” devices and may not be covered by a bill focusing on IoT, it’s important to understand that this distinction is somewhat irrelevant given we’re talking in general about classes of technologies that operate in a physical space and connect to the internet, whether by original design or otherwise. The potential for remote abuse of these technologies remains, whether they satisfy the current definition of IoT or not. It’s also worth bearing in mind that definitions in tech evolve over time as understanding of the technology and related risks evolves.

Device exemptions

The March version of the bill included a subclause in Section 2 that allowed for “interested parties” to petition OMB to get additional types of devices exempted. We felt this would likely create unintended negative consequences in terms of a competitive disadvantage for startups, which may lack the lobbying firepower to successfully petition for exclusion of their devices. We were also confused why the statute would allow for petition for tech to be exempted, but not added.

The new version of the bill now moves that subclause into being its own section, Section 5, and expands it by adding reporting requirements and clarification that the petition process can only be used on a limited basis when certain conditions are met:

“(b) GRANTS OF PETITION.—The Director of OMB shall grant a petition under subsection (a)—

  • (1) on a limited basis;
  • (2) in a timely manner;
  • (3) only if the interested party demonstrates that
    • (A) the procurement of such a covered device with limited data processing and software functionality would be unfeasible; or
    • (B) the procurement of a covered device that does not meet the standards promulgated by the Director of OMB under this Act is necessary for national security or for research purposes.”

This does help clarify the situation of when petitions would be permitted, and more importantly, puts parameters in place for how it can be applied, hopefully reducing the likelihood of this being abused by those with more robust lobbying resources.

The section still only allows for requests for exemption, not inclusion. We recognize that OMB itself can add new technologies with no need for a petition process, and we hope they will stay abreast of technological development to ensure the appropriate technologies are sufficiently covered by security requirements for procurement.

The net of these changes is that the marked-up House version of the bill has come a long way in addressing some of the issues of the March version, but it still has some challenges. Yet, we do think it’s better now than the Senate version.

Changes to S.734

In general, many of the changes to S.734 focus on tightening up the language—pieces have moved around somewhat and superfluous wording has been removed, but for the most part, the bulk of the bill has remained the same in its aims, approaches, and requirements. The important changes are as follows:

Covered devices

Like the House bill, the original Senate bill included a definition of “covered device,” and the security requirements for federal procurement would apply to covered devices. However, the new version of the Senate bill removed this definition entirely. Instead, Sec. 3(a) of the bill tasks NIST with establishing guidelines for the procurement and use of federal “Internet of Things devices”—without defining that term. While the updated bill does not explicitly task NIST with defining the term, it seems NIST will have to determine the scope in order to develop appropriate guidelines. This may result in a broader scope of devices than the original bill’s list of “covered devices.” As proponents of secure-by-design technology, we would be supportive of a broader scope.

Turning the scope of “IoT devices” over to NIST sidesteps a contentious debate over what the bill should include and enables NIST to use its expertise and extensive past efforts on IoT security to come up with an appropriate definition.

Exempted devices

Gone too is that sub-clause about petitioning for devices to be exempted that we didn’t like in the original and still don’t much care for as a section in the House version of the bill.

So far, so good. You may be wondering why this updated version is concerning to us, then.


The entire challenge is rooted in a new section added into the updated version of S.734. Section 7, titled “Waiver”—cue the thriller movie music —is actually pretty baffling, as it seems to essentially void the entire rest of the bill. Here’s what it says:

“SEC. 7. WAIVER. The head of an agency may use an Internet of Things device without regard to any policies, principles, standards, or guidelines issued under this Act if the use of the Internet of Things device is—

  • (1) necessary for national security or for research purposes;
  • (2) appropriate to the function of the covered device;
  • (3) secured using alternative and effective methods; or
  • (4) of substantially higher quality or affordability than a product that meets such policies, principles, standards, or guidelines.”

We’re completely lost as to the rationale of subclause (2). It appears to provide a massive loophole that effectively voids the entire legislation by saying, “As long as you use this printer as a printer, never mind about all the security mumbo-jumbo we just proposed, please go right ahead as you were.” I’m guessing most of the tech the government is buying is expected to be used for the function for which the device was designed (unless it’s for one of the reasons covered by subclause (1)), so the application of this subclause would likely be broad.

Additionally, the provision seems to assume that secure-by-design standards are only relevant if the device is being used in unintended ways, which is certainly not the case. Whether these devices are being used for their designed function doesn’t hugely impact the likelihood of risk. Yes, if a device is used in unexpected ways, it may present additional risk, but given the imperfection of code (sorry, developers), there is a reasonable assumption of some inherent cybersecurity risk for all internet-connected devices, regardless of how they are being used.

Additionally, both subclauses (3) and (4) seem to be creating incentives that conflict with the goals of the bill; (3) for buyers to find non-standard, and thus less vetted, ways of purchasing technology; and (4) for buyers to purchase cheaper devices that do not meet security standards. Both subclauses undermine the principle of requiring security for federal systems and using the government’s buying authority to encourage behavioral change in IoT manufacturers and operators. I sympathize with the legitimate worry that secure device requirements will impact agency budgets, but these provisions are self-defeating.

Taken as a whole, the subclauses of this waiver section seem to cover enough ground to effectively make the legislation redundant in most scenarios. Not only is this a highly inadvisable approach to IoT security, it reduces the legislation to wasted effort. It seems pointless for the bill to require OMB and NIST to go to all the not-inconsiderable trouble of drafting, consulting on, and implementing complicated guidelines and policies for federal IoT procurement security - and then waive it all if cheaper devices are available or if you only use the device for “appropriate functions.”

Were it not for this addition, I think we would likely prefer the Senate version of the bill. However, with the addition of Section 7, we do not think the bill is ready for passage and we cannot support it.

What’s next?

Now that the House and Senate bills have been voted out of their respective Congressional Committees, they are one crucial step closer to the finish line. The House bill was referred to two committees, so it still needs to be approved by one more Committee (the Committee on Science, Space and Technology) before heading for a final vote on the House Floor. The Senate bill has cleared its only committee and could theoretically receive a final vote on the Senate Floor.

If both bills make it that far—which may be a heavy lift this summer given a packed legislative schedule and Congress’ annual August recess—the differences in the bills would need to be reconciled, and the reconciled bills would be voted on before they could be sent to the President for signature. The committee markup process and floor votes are the remaining opportunities for amendments to revise the bills and address any problems.

We very much hope the drafters will take this feedback into consideration and update the language to address these issues, particularly with regards to the Waiver section in the Senate version.