The mission of this group is to bring together utility professionals in the power industry who are in the thick of the digital utility transformation. 


Why the IoT Cybersecurity Improvement Act will probably fade away

Tom Alrich's picture
Supply chain Cyber Risk management - emphasis on SBOMs and VEX documents Tom Alrich LLC

I provide consulting services in supply chain cybersecurity risk management and am now primarily focused on software bills of materials (SBOMs) and VEX (Vulnerability Exploitability eXchange). I...

  • Member since 2018
  • 371 items added with 120,048 views
  • Sep 2, 2021

My last two posts have discussed the two mandatory cybersecurity “regulations” – the IoT Cybersecurity Improvement Act of 2020 and the IoT device “labeling” requirement in the May 12 Executive Order - that were promulgated within about six months of each other (under two very different presidents) recently. At first, it might seem that these couldn’t be more different. Here are some of the differences:

  1. The Act is a law, approved by both houses of Congress and by the president. The EO is simply an order that can’t in itself override a law and could be overridden by another law, if Congress were inclined to pass one.
  2. The Act focuses entirely on IoT devices, while the EO is a sprawling attempt to improve cybersecurity in the federal government, on many different fronts.
  3. The Act focuses entirely on federal agencies, requiring them to incorporate cybersecurity concerns into their procurement terms and conditions for IoT devices. Of course, there’s no doubt that the intention of the Act was to have the Feds set a standard for private industry, but there’s not a word in the Act itself about that. On the other hand, the device labeling provision in the EO, while also aiming directly at procurement by federal agencies, repeatedly speaks of “education” and “consumers”. For example, paragraph (s) of section 4 includes the phrase “educate the public on the security capabilities of Internet-of-Things (IoT) devices and software development practices”. And paragraph (t) says that the labeling program should be “compatible with existing labeling schemes that manufacturers use to inform consumers about the security of their products” (you can read both paragraphs in full in my previous post).
  4. The Act seems to be a variation on a fairly familiar theme: require federal contractors to be assessed against a new standard that would be developed by NIST (and has been. More on that in a moment). On the other hand, just the name “device labeling” was a signal that this is a very different type of cybersecurity regulation than has been seen previously in the US – although it has been used to a limited degree in Europe and Southeast Asia.

I had also considered these to be two very different regulations. However, when I recently sat down to look at them carefully, I began to see more similarities than differences. In fact, I’ve decided the two are so similar that I really doubt they’ll both be enforced. Since I see all of the momentum as being behind the EO, and since I haven’t seen any signs at all that anybody’s even preparing to enforce the Act (OMB is in charge of enforcing both regulations, since they’re the regulator/whip-wielder for federal agencies), I don’t think it will be long before the Act either officially or unofficially sleeps with the fishes.

So why do I think the Act and the device labeling requirement are so similar? Two things:

  1. The “meat” behind both the Act and the EO is requiring federal agencies to require contractors to be assessed based on a standard (or framework) to be developed by NIST. Even though the mechanism for this assessment is called a “device label” in the EO, if you dig into it and look into how the “requirements” for the “label” will be developed, they’ll be specified by NIST, just as the framework for the assessments under the Act will be specified by NIST. Since the subject of both the label and the framework is overall cybersecurity of IoT devices and they’re both developed by the same agency, does anyone doubt that they’ll be substantially the same?
  2. But if you do doubt this, you should put that aside now. Another thing I realized as I was studying the two “requirements” was that the framework behind both of them will be the same: NISTIR 8259D. Folks, when you’re talking about two different regulations, they can’t be any more similar than if they’re both based on exactly the same set of “requirements”.[i]

Maybe you now see why I came to believe that both the EO and the Act can’t stand. They require the same organizations (federal agencies) to take the same actions (require suppliers of IoT devices to be assessed for cybersecurity), with respect to the exact same subject matter (NISTIR 8259D). One often hears about redundancy in federal programs (I’ve sometimes mentioned the Department of Redundancy Department), but believe it or not, there are people who do watch for these things and flag them.

So why do I think the Act will fade away? Mainly because I haven’t heard anything about it being enforced, even though it gave OMB a six-month deadline to start the process (which would have probably passed in July, if not June). On the other hand, there’s been a lot of activity on the IoT device labeling requirement. NIST has scheduled a two-day conference (virtual, natch) for September on this and the other device labeling requirement, found in Section 4 paragraph (u) of the EO, on secure development practices for consumer software.

And just as in the case of SBOMs, NIST – this time in conjunction with the Chair of the FTC as well as representatives of other agencies – must make final decisions on the program by early February, 270 days after the date of the EO. Since a lot more decisions are due then, that will be a busy time around NIST. They might not be able to celebrate Groundhog Day next year.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. Nor are they shared by the National Technology and Information Administration’s Software Component Transparency Initiative, for which I volunteer as co-leader of the Energy SBOM Proof of Concept. If you would like to comment on what you have read here, I would love to hear from you. Please email me at

[i] BTW, I think that NISTIR 8259D is quite good. I hope to discuss it in more depth one of these months.


No discussions yet. Start a discussion below.

Tom Alrich's picture
Thank Tom for the Post!
Energy Central contributors share their experience and insights for the benefit of other Members (like you). Please show them your appreciation by leaving a comment, 'liking' this post, or following this Member.
More posts from this member

Get Published - Build a Following

The Energy Central Power Industry Network is based on one core idea - power industry professionals helping each other and advancing the industry by sharing and learning from each other.

If you have an experience or insight to share or have learned something from a conference or seminar, your peers and colleagues on Energy Central want to hear about it. It's also easy to share a link to an article you've liked or an industry resource that you think would be helpful.

                 Learn more about posting on Energy Central »