Safeguard
Supply Chain Security•

NIST SP 800-82r4 Draft: What OT Buyers Will Ask Their Suppliers

NIST released the SP 800-82 Rev. 4 draft on 21 September 2026. It restructures OT security around CSF 2.0 and lists SBOMs, HBOMs and signed artifacts as supplier evidence.

Safeguard Security Team
Updated 5 min read

On 21 September 2026, NIST released the initial public draft of SP 800-82 Rev. 4, "Guide to Operational Technology (OT) Security," written by NIST and MITRE authors. Comments are due by 30 November 2026. The draft reorganizes OT security around the NIST Cybersecurity Framework 2.0, widens sector coverage, and spells out what OT operators should require from the vendors who supply their software, firmware and equipment.

What's affected

SP 800-82 is guidance, and Rev. 4 is a draft. It changes nothing on its own. It matters because operators, regulators and procurement teams use it as the reference for what good OT security looks like, and its supplier section is what vendors will see in questionnaires.

NIST lists these updates in the draft:

  • Expanded sector coverage, including building automation, water and wastewater, food and agriculture, freight rail, maritime vessels, and Industrial IoT with cloud convergence.
  • Restructuring around CSF 2.0, with risk management placed under the Govern function.
  • More on aligning OT risk with enterprise risk management, and a new appendix on adopting the Risk Management Framework.
  • Expanded guidance on asset management and on network monitoring and detection.
  • Architecture guidance on protecting system management functions and applying zero trust principles.

For suppliers, section 3.3 on cybersecurity supply chain risk management is the part to read. It says organizations should define the processes, technical mitigations and evidence expected from a supplier of any OT component, including:

  1. Criteria for secure software development and life cycle management.
  2. SLAs on how the supplier notifies and resolves vulnerabilities.
  3. Maintenance and support agreements that set acceptable methods for vendor remote access and make the vendor follow the operator's access control procedures on site.
  4. Technical mechanisms covering hardware and software components, "such as through HBOMs and SBOMs."
  5. Digital artifacts, such as digital signatures, to validate the authenticity of vendor-provided hardware, software and firmware.
  6. Incentives in supplier contracts that reward strong security practices.

It also tells operators to check whether products include unauthorized components, software, suppliers or regions, to control and audit remote access, to look for unauthorized communication devices such as cellular modems, and to consider how hard it will be to get updates over the product's life. For IIoT, it asks operators to evaluate default credentials, firmware update mechanisms, secure boot, vulnerability disclosure practices, vendor remote access and end-of-support risk before deployment.

Does this apply to you?

  1. You operate OT in any sector the draft covers. This is your reference document, and the comment period is your chance to shape it.
  2. You sell OT products or software that runs in OT environments, such as SCADA, historians, engineering workstations, PLC firmware, building management or IIoT gateways. Expect section 3.3's list to show up in your customers' requirements.
  3. You provide remote support or managed services into OT networks. The remote access and on-site access control items are aimed at you.
  4. You only build IT software with no OT customers. The draft has little direct bearing on you, though the supplier evidence list mirrors what IT buyers increasingly ask for too.

What to do now

  1. By 31 October 2026: read section 3.3 and section 2 for your sector. Note any requirement you cannot meet today.
  2. By 15 November 2026 (suppliers): confirm you can deliver an SBOM for each shipped software and firmware version, and an HBOM where you ship hardware.
  3. By 15 November 2026 (suppliers): make sure every release and update is signed, and document how customers verify signatures without internet access, since some OT sites have little or none.
  4. By 30 November 2026: send comments to NIST using the comment template on the publication page. Comments are due that day.
  5. Q1 2027 (suppliers): write down your vulnerability notification and resolution commitments as SLA terms you are willing to sign, and publish your end-of-support dates per product.
  6. Q1 2027 (operators): update procurement templates to ask for the six supplier items above, so the request is consistent across vendors.

Why it matters

OT buyers have always cared about availability and safety first. What this draft does is put software supply chain evidence, SBOMs, signed artifacts and vulnerability SLAs, alongside those concerns in NIST's OT security guide. Once it is final, "we'll provide that on request" stops being a good answer in an OT tender.

The draft also names the hard parts honestly: few suppliers in many sectors, vendors that need remote access, and the difficulty of getting updates over a product's life. An SBOM that is accurate on delivery day but never updated does not help with equipment that stays in service for many years. Suppliers who can keep component data current across the life of a product will stand out.

Try it yourself

If you are an operator, ask one OT vendor for the SBOM of the version you run. If you are a supplier, pick your oldest supported product and try to produce its SBOM today. Then import it and see which components carry known vulnerabilities.

Click through it at your own pace, or open it full screen.

Quick check

When are comments on the SP 800-82 Rev. 4 draft due?

30 November 2026, using the comment template linked from the publication page.

Which framework does Rev. 4 restructure around?

The NIST Cybersecurity Framework 2.0, with OT risk management placed under the Govern function.

Name two technical items the draft says organizations should expect from OT suppliers.

Any two of: SBOMs and HBOMs covering product components, digital artifacts such as signatures to validate authenticity, criteria for secure development, and SLAs for vulnerability notification and resolution.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.