IoT Cybersecurity Improvement Act 2020 – Business Perspective

But as with most legislation, the ability to strictly enforce the requirements laid out in HR 1668 is lagging. There is no governing process in place, such as the Cryptographic Module Validation Program (CMVP) that validates cryptographic modules to Federal Information Processing Standard (FIPS) 140-2 and 140-3.

This will of course change over time as the ability to verify catches up with the legislation. The responsibility for developing the verification process belongs to the Office of Management and Budget (OMB), and it has until December, 2022, two years after the legislation was passed, to have this mechanism in place.

As it stands now, the accepted path to compliance is a top down approach, with IoT device manufacturers adhering to the NIST guidance as it emerges, both technical (8259 A) and non-technical (8259 B).

While this infrastructure is being developed, the regulators are focused on creating awareness about the legislation, gaining acceptance from IoT technology providers, and securing endorsement from industry participants to exert pressure on the manufacturers.

However, there will likely be push-back as the regulations are being implemented.

The challenge lies in the current IoT product development processes that are designed to maximize innovation, commercialization and speed to market. The concern is that the top down approach being espoused by the legislation will slow things down, and increase costs and time to market.

Most IoT technology providers are using the fastest and most nimble development methods to bring new products to market such as agile software development. This is an iterative, fail fast and fail often model that is built for innovation, flexibility and speed, and is counter to a “one step at a time” top down approach. The question is, how do the requirements of the Cybersecurity Act, such as Secure by Design, documentation and procurement of security components work within an agile framework?

Everyone recognizes the need for security, but this must be balanced with not bogging down the pace of new and increasingly life changing technologies that are being made available in real world applications.

DevOps and DevSecOps must also reconcile how to evolve their technology architectures to support the new regulatory environment.

The likely result is that in the short term there will be push back, difficulty in verifying compliance and the normal confusion that occurs when new regulatory standards are introduced.

But in the longer term, once the growing pains are dealt with, the push to standardize IoT security rules and gain widespread adoption from IoT manufacturers will be good for all stakeholders.