Operational technology security has to protect the process as well as the system. A patch decision can affect a production application, an engineering workstation or the visibility operators rely on. An access decision can give a contractor a path into the same environment. Teams need a coordinated way to assess these changes and retain the evidence behind them.
NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, provides guidance for securing OT while considering performance, reliability and safety. Published in September 2023, it superseded Rev. 2. Its scope includes industrial control systems and other systems that monitor or influence the physical environment, including building automation and transportation.
Revision status checked 10 November 2026: Rev. 3 remains the final publication. NIST has also published an initial public draft of Rev. 4, with comments due 30 November 2026. A public draft should be tracked separately from the final guidance used for an approved baseline.
What changed from Rev. 2?
Rev. 3 broadens the focus from industrial control systems to OT, updates its treatment of threats, risk management and architectures, and adds tailoring guidance and an OT overlay for NIST SP 800-53 Rev. 5. These changes give teams a more current starting point for reviewing their security programme. The guide is not a product certification or a universal checklist that can be completed by installing one tool.
NIST SP 800-82 Rev. 3 summarized
The guide connects understanding the operational environment, managing risk, designing protective architecture and operating a security programme. Patch management is one part of that wider picture. Physical protection, people, suppliers, remote access, monitoring, incident handling and restoration also matter.
Read the official guide and its document-structure overview for the full detail. The table below is an editorial reading aid: the questions are suggested review prompts, not NIST control wording.
| Section | Main subject | A useful question for your team |
|---|---|---|
| 1 · Introduction | Purpose, scope and intended readers. | Which sites and operational systems are included in our review? |
| 2 · OT Overview | System types, architectures and differences between OT and IT. | Which physical processes and application dependencies are we protecting? |
| 3 · OT Cybersecurity Program Development | Governance, responsibilities, policies, training, maintenance, incident response and recovery. | Who owns the programme and the decisions made at each site? |
| 4 · Risk Management for OT Systems | Risk assessment and application of the Risk Management Framework to OT. | How do we evaluate operational consequences and authorize risk treatment? |
| 5 · OT Cybersecurity Architecture | Defence in depth, segmentation, separation and architecture considerations. | Which communications are necessary, approved and monitored? |
| 6 · Applying the Cybersecurity Framework to OT | OT considerations across Identify, Protect, Detect, Respond and Recover. | How do day-to-day activities contribute to the security outcomes we need? |
| Appendices C–F | Threat context, reference organisations, security tools and the OT control overlay. | Which supporting material helps us select, tailor and review controls? |
Recommended reading path: Managers can begin with the executive summary and programme-development discussion. Engineers can use the OT overview and architecture sections to review the environment. Risk and assurance teams can examine the risk-management discussion and Appendix F alongside the relevant control publications. These are suggested starting points; the sections work together.
Why OT changes the security decision
Imagine an engineering workstation that is missing an operating-system update. A security analyst sees a remediation task. The application owner also needs to understand whether the update affects the engineering tool, communication driver or supported recovery procedure. Both perspectives belong in the same decision.
- Physical consequence: Identify what loss of visibility, incorrect information or interrupted control could mean for the process.
- Timing and availability: Establish when the system can be changed and what operational checks are needed afterwards.
- Compatibility: Review the installed automation application, vendor guidance and representative test results.
- Lifecycle: Keep support status, recovery media and replacement planning visible alongside the patch backlog.
For example, a routine update on a general office device and a change to a workstation supporting a continuous process may need different approval paths. Do not infer that every legacy device is safe to scan, reboot or patch using the same method. Agree the method with the people responsible for that environment.
The Cybersecurity Framework and OT overlay explained
Section 6 of Rev. 3 uses the five-function Cybersecurity Framework structure shown below. The suggested activities and evidence are examples for a site discussion; they are not a complete control assessment.
| Function | Example team activity | Example evidence |
|---|---|---|
| Identify | Understand assets, ownership, dependencies and exposure. | Scoped inventory and risk register. |
| Protect | Control access, maintain systems and protect information. | Access approvals, configuration baselines and patch records. |
| Detect | Review events and investigate unusual activity. | Log sources, monitoring rules and reviewed events. |
| Respond | Coordinate investigation and contain an incident safely. | Response procedures, contacts and decision records. |
| Recover | Restore agreed services and learn from the event. | Recovery exercises, restoration checks and improvement actions. |
Keep framework versions clear. Rev. 3 was published in 2023. CSF 2.0 followed in February 2024 and includes Govern as a sixth function. An organisation using CSF 2.0 should maintain an explicit mapping to that version rather than relabel Rev. 3’s section headings or assume the category identifiers are identical.
What does Appendix F add?
The OT overlay provides OT-specific tailoring and supplemental discussion for NIST SP 800-53 Rev. 5. Its low-, moderate- and high-impact baseline context relates to system impact; those labels are not a product rating, maturity score or a Purdue network level. SP 800-53B provides the broader baseline and tailoring context.
For an assessment, document the selected control, its applicability, any tailoring decision, the implementation owner and the evidence used to evaluate it. If an operational constraint prevents an ordinary implementation, record the proposed alternative and its risk decision. A product feature can contribute to an implementation, but its presence alone does not establish that a control is effective.
Publication references: SP 800-82 Rev. 3, Section 6 and Appendix F; CSF 2.0; SP 800-53 Rev. 5; and SP 800-53B. The practical examples in this article are REPLIL commentary.
Turn the guidance into an operating workflow
The following is a practical REPLIL workflow example. It is not a reproduction of NIST’s control catalogue, and its steps should be adapted to your asset owners, engineering procedures and approved network design.
1. Build an inventory that explains operational importance
Start with the systems you are responsible for: operating systems, installed applications, hardware, supported network devices and the business functions they serve. Record ownership, location, application dependencies and the maintenance window. A list of IP addresses alone cannot explain whether an endpoint is a historian, an engineering station or a server that supports a critical workflow.
REPLIL IPM, the Industrial Patch Manager, brings software and hardware inventory together with patch status and vulnerability context. Use this information to establish which assets need review, then confirm operational priorities with the people who run the facility.
2. Separate a missing patch from an approved change
A missing update is a finding to evaluate. Before it becomes a deployment job, establish whether it applies to the installed build, whether the automation vendor has qualified it for the relevant application, and whether prerequisites or reboot requirements affect the change. Record the qualification source and its date. A qualified patch list should support a decision about the installed environment, rather than be treated as a blanket approval for every configuration.
Use REPLIL Private Repository to centralize supported vendor QPLs, firmware and support content, and IPM to correlate patch information with the environment. Vendor credentials and entitlement remain part of the acquisition process.
3. Check endpoint readiness and test application behaviour
Before scheduling a change, review pending reboot state, available storage, servicing health, recovery posture and current resource use. Decide who resolves a failed readiness check and when the endpoint is reassessed. A successful inventory scan does not mean that the endpoint is ready to install an update.
For validation, define observable application tests: can an operator open the required view, can the application connect to its expected service, and do key desktop or web workflows still complete? REPLIL OPS, the OT Patch Sandbox, supports isolated virtual or physical test replicas, application test cases, and review of service, registry and performance changes. Capture the baseline and compare results before planning production deployment.
4. Keep isolated-network delivery deliberate
Distinguish a physically air-gapped facility from a segmented, non-routed zone. For a connected upstream design, the OT Upstream Server initiates scheduled checks to the Enterprise Upstream Server over the approved path. For a disconnected design, use the site’s approved external-media transfer process. A strictly one-way link cannot carry a bidirectional HTTPS polling session; diode-based exchanges require a separately approved transfer design.
REPLIL PROXY supports IPM operations in non-routed zones through a controlled handoff and protocol break. REPLIL CONTROL EDGE provides a laptop-based option for standalone isolated systems. Neither workflow is a reason to remove a site’s isolation boundary.
5. Make remote access specific and accountable
Define the person, purpose, target asset, permitted actions and access window for each maintenance session. The approval should tell the operator what will happen and how access ends. Use REPLIL SRA/PAM for controlled remote access and privileged sessions, with MFA and Password Vault integration where configured. Keep session evidence linked to the relevant maintenance or change record.
6. Verify the outcome and retain useful evidence
Close the change only after checking installed state and the agreed operational tests. Retain the target inventory, qualification reference, readiness result, approval, execution record and post-change observations. For distributed facilities, REPLIL CMC, the Central Management Console, provides a central view of IPM posture and operational evidence. Site management actions remain subject to the configured IPM workflow and permissions.
Connect the review to evidence and ownership
For each review area, establish the operational question before choosing a report. Keep site procedures and technical records together so a reviewer can explain both the action and the reason for it.
- Asset visibility: Retain an inventory with owners, installed versions and relevant dependencies. IPM inventory can support this record; the site confirms operational importance.
- Patch and change control: Keep qualification, readiness, OPS test results, approval and post-change verification linked to the same scope.
- Access and credentials: Review user permissions, approved sessions and credential-use records. SRA/PAM, MFA and Password Vault support selected technical workflows; joiner, mover and leaver decisions still need an accountable owner.
- Monitoring: Define which events should reach the team, who reviews them and how a significant event is escalated. REPLIL Cyber RADAR supports log collection, retention and review for configured sources.
- Recovery: Retain recovery procedures, approved backups and the results of restoration exercises. Confirm application behaviour after restoration, not just that a machine starts.
- Multi-site oversight: Use CMC’s consolidated IPM posture alongside each site’s decisions and exceptions. A central dashboard helps coordinate review; it does not transfer every operational decision to the central team.
Illustrative example: one engineering-workstation update
Consider a fictional facility with an engineering workstation in an isolated zone. Its asset record identifies the operating-system build and automation application. A candidate update is missing, but the change owner first checks the relevant vendor qualification reference and its date.
The engineer reviews readiness and applies the candidate update to a representative test replica. The test cases cover application launch, expected service connectivity and a routine engineering workflow. The approver reviews those results, the intended maintenance window and the recovery plan before releasing the job.
For a supported non-routed deployment, IPM initiates the approved operation through IPM PROXY. After execution, the team checks installed state and repeats the agreed operational tests. The final record identifies successful targets, exceptions and follow-up owners. This example illustrates the relationship between evidence and decisions; it is not a description of a named customer deployment.
A first review you can run with your team
- Agree scope: Select one operational area and identify its owners, assets and dependencies.
- Trace a real change: Follow one recent patch or access request from finding through approval to verification.
- Check the boundary: Confirm that the documented communication and content-transfer paths match the actual workflow.
- Review one exception: Identify its owner, interim measures and next review date.
- Exercise recovery: Choose an approved scenario and confirm who performs and verifies the restoration.
- Record improvement actions: Assign owners and review dates, then use the official guide to examine the wider programme.
This is a proposed workshop sequence, not a NIST-prescribed timetable. Use the outcomes to identify gaps in information, responsibility or execution before turning them into a product-selection discussion.
Common questions about NIST SP 800-82 Rev. 3
Is it a standard, a regulation or a security guide?
It is a NIST Special Publication providing OT security guidance. Whether particular requirements are binding on your organisation depends on the applicable legal, regulatory, contractual and policy context. Refer to the publication’s authority statement and your own obligations rather than treating the entire guide as a universal regulation.
Does it cover only factories and control systems?
No. Its OT scope also includes systems such as building automation, transportation and physical access control. For a smart-city facility, start by identifying the actual operational systems and physical services involved, rather than assuming that every connected device has the same requirements.
Does every vulnerability require immediate patch deployment?
A practical site decision considers exposure, available fixes, vendor qualification, test evidence and the consequences of the change. If a change is deferred, retain an accountable risk decision and review date. Consult the guide’s patch-management discussion and applicable vendor guidance when defining that process.
Does a REPLIL capability mapping prove compliance?
No. A mapping identifies potentially relevant capabilities and evidence. The organisation still needs to establish scope, implementation, ownership and control effectiveness. Use the mapper as a starting point for discussion and keep the assessment conclusion separate from the product feature list.
A practical review checklist
- Scope: Which sites, assets and applications are included, and who owns them?
- Decision: What makes a change approved, deferred or rejected, and who signs off?
- Validation: Which application tests and recovery checks must pass?
- Access: Who can reach each asset, through which approved path, and for how long?
- Evidence: Can another reviewer trace the decision from finding to verified outcome?
How to use NIST alongside your existing programme
Use the official guide as the reference for your security review. Use your organisation’s policies, risk assessment and contractual requirements to decide how recommendations apply. REPLIL’s compliance mapping tool can help structure a product-capability discussion and record remarks; it does not replace a control assessment or establish certification.
For a deeper patch workflow, read our IEC 62443-2-3 patch management programme guide and air-gapped OT patch management guide. To discuss your environment, request a REPLIL walkthrough.
Primary references
- NIST SP 800-82 Rev. 3: official publication and revision status.
- NIST SP 800-82 Rev. 3: full guide, including the OT overlay and patch-management discussion.
- NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning.
Independent technical commentary. NIST does not endorse REPLIL or its products. Product capabilities support selected workflows; implementation, organisational procedures and operational decisions determine the outcome.
[…] restoration procedure, maintenance allowance, restart sequence, stop criteria and decision owner. NIST SP 800-82 Rev. 3 provides the wider OT security context: safety, reliability and operational constraints must remain […]