How New NIST Guidelines Have Affected Manufacturers in the IIoT Sector

It has been over four months since NIST–the US National Institute of Standards and Technology–published IR 8259r1, an updated version of the core cybersecurity guidelines for manufacturers in the IoT sector. NIST IR 8259r1 replaced the 2020 version, drafted before AI became part of everyday life.

We can already assess how these guidelines will shape the IIoT sector. To give a brief preview: manufacturers that have supplied products to major clients for years are likely already compliant with NIST's core guidelines. However, several significant updates are worth noting. The most important change is that the guidelines now cover not just an individual device, but the entire product lifecycle: from development through support to end of life.

Below, I'll explain what else has changed and what you need to check to ensure your product complies with the guidelines.

What Exactly Has Changed

The overarching principle of the document remains unchanged: IoT must be 'securable', meaning the customer must be able to effectively manage cybersecurity within their environment. The term 'securable' was already used in the 2019 draft and the 2020 version, but here's what's new: in 2020, the focus was on a "securable IoT device," whilst in 2026 it is on a "securable IoT product." Earlier, the standard cared about one thing—was the device itself secure? Now it looks wider: the sensors, the gateway, the backend, the app the user actually touches.

The update added several elements to the document that weren't present six years ago. Four additions matter most if you build IoT products.

Manufacturer Cybersecurity

The 2020 edition included secure development practices, but in 2026, NIST separated the company's own cybersecurity posture into a distinct Activity 0, based on the premise that the manufacturer can also become the target of a cyberattack, with consequences that can affect customers. So Activity 0 asks how you spot threats and watch for attacks, what your plan is when something breaks, and how far down the supply chain your risk management actually reaches.

Cybersecurity Support Throughout the Entire Product Lifecycle

In the 2020 version, both post-market activities involved communication with the customer; in 2026, NIST separated ongoing support into a distinct Activity 6. Now the manufacturer's post-sale actions are addressed separately: fixing vulnerabilities and releasing updates, maintaining the product's securability after the end of mainstream support, and, at the end of the product lifecycle, securely decommissioning or retiring the product.

AI and Automated Solutions

The 2020 guidelines made no mention whatsoever of "artificial intelligence". The new checklist, however, includes a question about whether the product uses AI-based components or automated decision-making and, if so, what level of transparency and safeguards it requires to ensure the confidentiality, integrity, or availability of the IoT product's data and operation. For the customer, the very fact that certain product functions rely on AI becomes part of the cyber-risk assessment.

Cryptographic Flexibility for Long-Lived Devices

In 2020, NIST suggested accounting for the fact that, over a device's ten-year service life, it might be necessary to change the encryption algorithm or key length. In the 2026 edition, this recommendation was expanded: when selecting encryption modules, NIST explicitly suggests considering quantum-safe approaches, and for hardware-based capabilities – the ability to update, particularly in preparation for the future transition to post-quantum cryptography.

Recommendations or New Requirements?

Formally, NIST IR 8259r1 remains a recommendation, but for companies selling IoT products to corporate clients, this distinction is often blurred at the security review stage.

In my experience, large clients enquire about almost every aspect of an IoT product covered by NIST before finalizing a deal. If the very same questions appear time and again in the questionnaires and contracts of large clients, this effectively becomes a market requirement and a standard that the manufacturer must adhere to, regardless of whether NIST makes it mandatory.

This is where the practical value of IR 8259r1 lies: it sets out in a single document what corporate customers are most likely to ask you about and what is best to take into account whilst the product is still being developed.

What to Check

I imagine that for many manufacturers of IoT products, the NIST recommendations will come as no surprise, but I would still advise checking four things:

• Can you specify exactly which device sent the data, when, and to whom? NIST links asset management to the ability to distinguish each deployment of an IoT product from all others. In practice, this can be achieved, for example, by using a separate device certificate for each device, so that data and events in the system can be unambiguously linked to specific hardware.

• Can you reproduce the composition of a specific product version? NIST asks what inventory information the customer requires–internal software versions, patch status, known vulnerabilities–and whether they need on-demand access to this inventory. It also asks about the origin of software, hardware, and service components, citing the device's processor manufacturer as an example. To this end, the new edition explicitly mentions the HBOM (hardware bill of materials) alongside the SBOM.

  The practical value of this recommendation is that if a vulnerability is discovered tomorrow in a particular library, processor, or other component, you need to know exactly which versions of the product are affected.

• Is the support period specified, and can the customer verify it? NIST does not set a fixed support period. However, it recommends clearly stating its duration. This means that the contract for the sale or hire of equipment, or the installation certificate, must specify how many years of support are guaranteed and what happens thereafter. For example: three years of support, followed by replacement with a more up-to-date model at no cost to the customer, and a new support period
   
• Do you know who hosts and maintains your product's components? NIST assumes that a manufacturer may host the components of an IoT product themselves, outsource them to a third-party provider, or design the product to work with an external backend. In any of these scenarios, the manufacturer's cybersecurity posture and its working relationship with suppliers influence the product's securability.

What's Useful About This Year's Update?

I'd sum up the essence of the NIST recommendations in two words: transparency and discipline. There's nothing revolutionary in the updated recommendations themselves; well-prepared players were already doing all this anyway, but they're still worth studying. If nothing has surprised you, you're already following these recommendations; if it has, you've just learned what your next corporate client will ask you about. This is particularly true if you're new to the industry: it's a free guide to what will be expected of you in those very first questionnaires.

The more guidelines and frameworks like this appear, the more standardized client requests become. Everyone comes up with the same thing, and the market gradually evens out to a common standard. Those who think several years ahead are already living by these rules. The rest will learn when they receive their first serious questionnaire from a client.