[kube-system]

NIST isn't a bunch of dummies that don't know this. The requirements posed are not micromanagement of device design; some address your concern exactly... like a requirement that developers provide contact information to report vulnerabilities and that devices makers just can't ignore authentication entirely.

But this is IoT stuff we're talking about here, not Lenovo/Cisco... but ReoLink/PETLIBRO/eufy/roborock/FOSCAM/Ring/iRobot/etc. Security (or the lack of it) in the IoT world is a whole different ball game. It isn't uncommon for IoT devices to be EOL on release date, or just lack authentication or encryption entirely.

[timewizard]

> NIST isn't a bunch of dummies that don't know this

They've provided thorough definitions and a label that implies they've all been understood by the manufacturer. It doesn't mean that this solves any real world problem.

> Security (or the lack of it) in the IoT world is a whole different ball game.

Those can be described as IoT devices. They're more appropriately categorized as "consumer electronics" and often have a firmware update right out of the box. That's what makes this badging program an absurd idea with no meaningful outcome. This segment is not going to care.

This isn't "Energy Star" where the purchased product does not have additional functionality which can be exposed or exploited through software and no third party testing can be exhaustive enough to prevent the obvious exploit from occurring.

Even to the extent they can it then enforces a product design which cannot be upgraded or modified by the user under any circumstances. Worse the design frustrates the users ability to do their own verification of the device security.

It's a good idea applied to the wrong category of products and users.

[kube-system]

> Those can be described as IoT devices. They're more appropriately categorized as "consumer electronics"

IoT devices are a subset of a much broader 'consumer electronics' category.

> and often have a firmware update right out of the box.

From major, established, mature companies, yes. Many device manufacturers in this category never issue firmware updates. Which is precisely why this is one of the requirements.

> This segment is not going to care.

Some may, some may not. The federal government will care, because they will be forced by law to comply.

> no third party testing can be exhaustive enough to prevent the obvious exploit from occurring.

Of course, no cybersecurity compliance plan can prevent exploits from occurring. If you try to address cybersecurity in that way, you will fail, anyway. The point is to place controls in place which are achievable, measurable, and help to mitigate risk.

> Even to the extent they can it then enforces a product design which cannot be upgraded or modified by the user under any circumstances.

NIST's requirements require the opposite of this.

[timewizard]

> because they will be forced by law to comply.

Which means the program will have zero value outside of federal purchasing offices. They will not evaluate the criteria or care about the reality of the offering, they'll see the sticker, and know it's "default approved."

Is this a good outcome?

> mitigate risk

A sticker cannot do this.

[kube-system]

> zero value outside of federal purchasing offices

I can’t guarantee much but I can guarantee a non zero number of non federal purchasers will consider the sticker.

>> mitigate risk

> A sticker cannot do this.

Correct. The sticker itself doesn’t mitigate the risk. The adherence to the requirements necessary to qualify for the sticker do.