Abstract. On 21 September 2026, the National Institute of Standards and Technology (NIST) released the initial public draft of Special Publication (SP) 800-82 Revision 4, its Guide to Operational Technology (OT) Security. This article compares the draft with the 2011 original and its three revisions. It then maps each major topic to the standards and methods practitioners already use: ISA/IEC 62443, the NIST Cybersecurity Framework (CSF) 2.0, IEC 61511, ISA-TR84.00.09, NERC CIP, SP 800-53, and Idaho National Laboratory's Cyber-Informed Engineering. For each topic we give technical guidance for site implementation, then contrast the view of a skeptical practitioner with that of a standards body. The draft makes real progress in three areas: consequence-driven defense, separation of management and operational networks, and credential separation. It stays thin on safety instrumented systems, on zero trust below Purdue Level 3, and on supply chain guidance an asset owner can act on. We also argue that the Purdue model describes an idealized layered stack, which few real facilities resemble. Finally, we ask whether the draft reduces risk or mainly describes it, and outline how business impact analysis (BIA), MITRE Crown Jewels Analysis (CJA) and Threat Assessment and Remediation Analysis (TARA) would move it toward reduction. We conclude that the guide sets direction, but whether a site is resilient depends on onsite execution built into daily operations. Comments on the draft close 30 November 2026.
Rev. 4 is the largest restructuring of the guide since the original 2011 publication, and it will be cited by regulators, insurers and auditors for the rest of this decade. We read it against the three prior revisions and against the standards and methods it sits beside, then wrote down what we would actually tell an asset owner to do on site.
For each topic we summarize the draft, list the related standards and methods, give our technical advice, and close with two views: the skeptical practitioner and the standards body.
How Rev. 4 changes the shape of the guide
Rev. 4 reorganizes the whole document around the CSF 2.0. Section 3 implements the Govern function, Section 4 covers Identify, Protect, Detect, Respond and Recover, and Section 5 covers architecture. New sector profiles cover Building Automation and Control Systems (BACS), food and agriculture, freight rail, maritime vessels, and water and wastewater. A new section on Industrial Internet of Things (IIoT) and cloud convergence describes three integration patterns. In the final publication, the threat and organization appendices move to web resources, and the SP 800-53 OT overlay and the Risk Management Framework (RMF) appendix become separate documents.
1. Governance and the CSF 2.0 structure
In the draft. OT risk belongs in enterprise risk management (ERM), aligned with NIST IR 8286r1. Executive leadership holds ultimate accountability. Organizations maintain a risk register and document each risk response.
Related standards. CSF 2.0 Govern (GV.OC, GV.RM, GV.RR, GV.SC, GV.OV); ISA/IEC 62443-2-1:2024 for the asset owner security program; ISO/IEC 27001 for management system structure; NERC CIP-003 for program and policy obligations in the bulk electric system.
Technical advice. Use IEC 62443-2-1 as the backbone of the OT program and CSF 2.0 as the reporting language to the board. Maintain one control map that traces each site practice to both, so the plant is not answering two questionnaires for the same evidence. Put OT risks on the enterprise register with a named operational owner, usually the site or operations manager, not only the security function.
Practitioner hot take. CSF gives the board a vocabulary. It does not tell the instrument technician what to do on Tuesday. A restructure around NIST's own frameworks is not the same as deeper OT engineering content.
Standards body view. Boards, insurers and regulators already speak CSF. Putting OT inside Govern is how the program gets budget and a seat in enterprise risk. That is a precondition for anything else in the guide happening.
2. Consequence-driven defense and Cyber-Informed Engineering
In the draft. Section 2.3 redefines defense in depth as independent barriers across people, process, technology and the physical system. Cyber controls are weighed against engineering countermeasures such as relief valves, hardwired interlocks and manual procedures. It cites Cyber-Informed Engineering (CIE) from Idaho National Laboratory (INL).
Related standards. INL CIE and Consequence-driven Cyber-informed Engineering (CCE); the US Department of Energy National CIE Strategy; process hazard analysis (PHA), hazard and operability study (HAZOP) and layer of protection analysis (LOPA) under IEC 61511; ISA-TR84.00.09 for cybersecurity within the functional safety life cycle.
Technical advice. Bring cyber scenarios into the existing PHA and LOPA revalidation cycle instead of running a parallel cyber risk assessment that operations never reads. For each high-consequence scenario, identify the safeguards that cannot be changed through a network, such as mechanical overspeed trips, relief devices and hardwired permissives. Record them in the risk register as barriers with an owner and a test interval. When a barrier is digital, ask what writes to it and from where.
Practitioner hot take. This is the most valuable section in the draft. It also asks security teams to attend PHA meetings and learn the process, which is where most programs fall down.
Standards body view. The draft points to CIE rather than reproducing it, which keeps the guide within scope. Reviewers should ask for a worked example that carries one scenario from consequence through to barrier and control.
3. Safety instrumented systems
In the draft. Section 2.4.5 describes the safety instrumented system (SIS), safety instrumented functions (SIFs) and integrated control and safety systems (ICSS). It refers to IEC 61511 and encourages a risk-based assessment. The text is essentially unchanged from Rev. 3.
Related standards. IEC 61511-1 requires a security risk assessment of the SIS (clause 8.2.4) and a design that is resilient against the identified security risks (clause 11.2.12). ISA-TR84.00.09 gives the method. IEC 62443-3-2 supplies the zone and conduit model to place the SIS in its own zone. The TRITON incident of 2017 remains the reference case.
Technical advice. Put the SIS in its own zone with a dedicated conduit to the basic process control system (BPCS) that carries read-only data where the vendor architecture allows it. Keep the SIS engineering workstation dedicated, physically controlled and disconnected when not in use. Monitor and alarm on key switch position, program mode, logic download and firmware change. Treat every ICSS design as requiring vendor confirmation of independence between control and safety functions, in writing.
Practitioner hot take. This is the weakest part of the draft relative to the threat. The only pointer to ISA-TR84.00.09 sits in an appendix that is leaving the document.
Standards body view. NIST avoids duplicating IEC 61511 and ISA work. A short subsection on SIS security risk assessment and engineering access to logic solvers would still be in scope and should be requested.
4. Asset inventory and criticality
In the draft. Section 4.1.1 covers establishing an inventory and assigning criticality and function. Our reading of secondary coverage is that the draft favors passive discovery for older or sensitive devices.
Related standards. CSF 2.0 ID.AM; IEC 62443-2-1; CISA's August 2025 guidance, Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators; NERC CIP-002 categorization and CIP-010 baseline configuration.
Technical advice. Start passive. Then add vendor-supported, read-only queries over native protocols and read-only SNMP where the device supports them, because firmware versions, module serial numbers and installed options rarely appear on the wire unprompted. Never issue write function codes during discovery. Reconcile what the network shows against the engineering drawings, I/O lists and the maintenance management system, and record each asset's function in the process, because criticality comes from function, not from IP address.
Practitioner hot take. An inventory that does not know what an asset does in the process is a spreadsheet. A passive-only bias made sense in 2015. Safe active querying through the protocols the vendor already uses is mature in 2026, and often it is the only way to get the attributes a vulnerability match needs.
Standards body view. Conservative language protects the guide against the reader who runs an IT scanner against a controller. The fix is to state the conditions under which active, read-only methods are acceptable.
5. Vulnerability and patch management
In the draft. Section 4.2.3.1.3 covers software and firmware patch management. Secondary coverage indicates the CISA Known Exploited Vulnerabilities (KEV) catalog is recommended as a better prioritization basis than scores alone.
Related standards. CISA KEV; Stakeholder-Specific Vulnerability Categorization (SSVC); CVSS 4.0; IEC TR 62443-2-3 for patch management in industrial automation and control systems; IEC 62443-4-1 for supplier secure development; NERC CIP-007 R2, which requires evaluating applicable patches at least every 35 days.
Technical advice. Triage on three questions: can an attacker reach the vulnerable interface, what is the process consequence if it is exploited, and is exploitation known or easy. Many OT exposures never receive a Common Vulnerabilities and Exposures (CVE) identifier, such as unauthenticated writes over Modbus or unauthenticated logic downloads, so track insecure-by-design functions as findings in their own right. Prefer mitigation through conduit restriction now and schedule the patch into the next planned outage, with a documented rollback.
Practitioner hot take. KEV is weighted toward IT. Counting CVEs on controllers that are reachable only from one engineering workstation wastes the team's time.
Standards body view. KEV is a defensible, public, evidence-based filter that small operators can use without a vendor. It needs a consequence and exposure layer on top, which the guide can describe without endorsing a product.
6. Identity, remote access and dual approval
In the draft. Section 4.2.1 adds separation of duties and dual approval, system and service accounts, IT/OT identity convergence, privileged access management and remote access controls. It keeps IT and OT credentials separate.
Related standards. IEC 62443-3-3 foundational requirements FR1 (identification and authentication control) and FR2 (use control); SP 800-53 AC-5, AC-3(2) and CM-5(4) for separation of duties and dual authorization; NERC CIP-005 R2 for interactive remote access through an intermediate system with multi-factor authentication (MFA), and R3 for vendor remote access.
Technical advice. Run OT identity in its own directory with no trust relationship to the corporate domain, or with a one-way trust that has been reviewed by someone who understands the attack paths. Broker every vendor session through a jump host in the OT demilitarized zone (DMZ), with session recording, time limits and approval from the operator on shift. Require two people for logic downloads to SIS and high-consequence BPCS controllers. Inventory and rotate service accounts embedded in historians, OPC servers and backup tools.
Practitioner hot take. Credential separation and dual approval are the most useful concrete changes in the draft. A domain-joined OT environment that accepts enterprise credentials is still one of the most common findings on site.
Standards body view. These map cleanly to controls auditors already test, which is why they can be written as firm recommendations.
7. Management plane architecture
In the draft. Section 5.2.1 separates management network architecture from operational network architecture, with tables of system management functions, example controls and architectural patterns. Section 5.4.4 introduces out-of-band (OOB) management.
Related standards. IEC 62443-3-2 zones and conduits; ISA-95 and the Purdue reference model; the 2024 CISA, NSA and partner guidance on living-off-the-land techniques; NERC CIP-005 electronic security perimeters.
Technical advice. Create a management zone for patch servers, backup, directory services, jump hosts and network management. Permit management protocols such as RDP, WinRM, SMB and SSH into operational zones only from that zone. Alert on management traffic that originates anywhere else. Treat OOB paths as conduits with their own identity, logging and a default-disabled state, and do not build them on unmanaged cellular modems.
Practitioner hot take. This is correct and overdue, because recent campaigns abuse legitimate management tools far more than they exploit controllers. The risk is that a site implements it as one more VLAN with the same domain admin account in every zone.
Standards body view. The draft itself warns in Section 2.4.6 that cellular and vendor connections bypass controls. Reviewers should ask NIST to state the same requirement for OOB paths so the two sections agree.
8. Zero trust by Purdue level
In the draft. Section 5.3 applies zero trust principles. Secondary coverage indicates the draft recommends starting at Purdue Levels 3 to 5 and the OT DMZ, because many controllers and human-machine interfaces (HMIs) cannot support the technology.
Related standards. NIST SP 800-207 and SP 1800-35; CISA Zero Trust Maturity Model 2.0; IEC 62443-3-2 zones and conduits; protocol security extensions such as CIP Security for EtherNet/IP and the OPC UA Sign and SignAndEncrypt modes.
The Purdue model deserves its own caveat. It describes one homogeneous, layered stack. Most real facilities look more like a row of grain silos at a port: crane control, the terminal operating system, reefer monitoring, gate access, shore power and building automation, each from a different vendor with its own levels, joined sideways by shared fiber, flat VLANs, vendor remote access and cellular modems.
Technical advice. At Levels 3 to 5, apply identity-aware access and per-session authorization. At Levels 1 and 2, where devices cannot authenticate, apply protocol-aware enforcement on the conduit that permits read functions and blocks write, program and firmware functions except from the named engineering workstation during an approved work window. Use controller run-mode locks or key switches, signed project files where the platform supports them, and the native protocol security your installed base already has.
Practitioner hot take. Zero trust that stops at Level 3 is IT zero trust placed in front of OT. The attacks that change physical outcomes happen at Levels 1 and 2.
Standards body view. Starting where the technology works is honest and phased. The guide should define zero trust outcomes for devices that cannot authenticate, so the phrase means something below the DMZ.
9. Monitoring and detection
In the draft. Section 4.3 adds device and service logging, time synchronization, network baselining, threat intelligence and emerging detection capabilities.
Related standards. NERC CIP-015-1 internal network security monitoring, approved by the Federal Energy Regulatory Commission (FERC) in 2025; MITRE ATT&CK for ICS; NIST IR 8428 on digital forensics and incident response for OT; IEEE 1588 Precision Time Protocol and NTP for time.
Technical advice. Baseline each conduit rather than the whole network. Alert first on engineering actions: program downloads, mode changes, firmware updates, new master stations and new protocol function codes. Correlate those alerts with work orders and permits to work, so an approved change is closed automatically and an unapproved change stands out. Fix time sources before building correlation, because evidence with drifting timestamps will not hold up in an investigation.
Practitioner hot take. An alert with no work order context is noise. Integrating operations into detection is the detection program, and it is the part tools rarely deliver.
Standards body view. Baselining and time synchronization are new and specific. The guide could add a short list of high-value OT events, mapped to ATT&CK for ICS, as a starting set.
10. Incident response, recovery and analog backups
In the draft. Sections 4.4 and 4.5 cover response and recovery, prioritizing human and environmental safety before restart. Section 5.4 adds fault tolerance, redundancy, analog backups and graceful degradation to manual operation.
Related standards. NIST SP 800-61r3 (2025, aligned to CSF 2.0); NIST IR 8428; IEC 62443-2-1; INL CCE; site emergency response and process safety management procedures.
Technical advice. Keep verified, offline copies of controller logic, configurations and system images, and restore them on representative hardware at a set interval. Decide in advance who has authority to isolate a plant network and under what conditions. Drill manual operation with real staffing assumptions, including night shift. Write restart criteria with operations so the process returns only after a safety review of instrument and logic integrity.
Practitioner hot take. Manual operation that has not been exercised in years is an assumption, not a recovery plan. The people who knew how to run it by hand are retiring.
Standards body view. Graceful degradation is now written as a design goal, which strengthens the hand of engineers who ask for it at the project stage. The guide should add test frequency and proficiency expectations.
11. Supply chain, SBOM and firmware integrity
In the draft. Section 3.3 covers vetting suppliers, defining required supplier practices and managing risk across product life cycles. Secondary coverage indicates software and hardware bills of materials (SBOM, HBOM) and signed firmware are referenced.
Related standards. IEC 62443-4-1 (secure product development) and 62443-2-4 (service provider requirements); CISA SBOM minimum elements and its 2025 draft update; Vulnerability Exploitability eXchange (VEX); CycloneDX and SPDX formats; the CISA HBOM framework; CISA Secure by Demand guidance for OT owners and operators (January 2025); NERC CIP-013; the EU Cyber Resilience Act (CRA), whose reporting obligations apply from 11 September 2026.
Technical advice. Require SBOM and VEX at delivery, signed firmware with documented key management, published end-of-support dates and a vulnerability disclosure commitment with response times. Validate a sample of delivered firmware with binary analysis to confirm the SBOM reflects what actually ships. Put remote access terms, data ownership and patch delivery obligations into the contract, because the procurement stage is the only point of real leverage.
Practitioner hot take. An SBOM is a supplier's claim, and the binary is the evidence. An owner-operator cannot act on an SBOM for a fifteen-year-old controller without help, and the draft does not yet explain what that help looks like.
Standards body view. NIST cannot mandate supplier behavior, but it can set procurement expectations that federal buyers will copy into contracts. Clear minimum attestation content would make those expectations enforceable at contract signature.
12. Cloud, IIoT and data governance
In the draft. Section 2.4.6 describes telemetry-to-cloud, edge gateway and remote access patterns, with shared responsibility, availability, data governance, network boundaries and device life cycle. It states that safety, protection and time-critical control functions should generally remain capable of local operation.
Related standards. NIST SP 800-213 and IR 8228 for IoT; the Industry IoT Consortium security maturity model; CISA and international partner guidance on secure connectivity for OT; IEC 62443 conduit requirements for external connections.
Technical advice. State local operation of safety and control as a requirement in the purchase specification, with a tested fallback when the cloud or the WAN is lost. Use outbound-only connections from an edge broker in the DMZ. Write data ownership, residency, retention and deletion into the contract before deployment. Survey the site for cellular modems that vendors installed without telling anyone.
Practitioner hot take. The word "generally" should not apply to a safety function. The data governance paragraph is a welcome first step toward operator data sovereignty, and it needs more than one paragraph.
Standards body view. NIST guidance avoids mandatory language, but it can state that safety functions should not depend on external services without the hedge.
13. Post-quantum cryptography
In the draft. Section 4.2.2.2.1 asks organizations to consider post-quantum cryptography (PQC), given decades-long OT asset lives.
Related standards. FIPS 203, 204 and 205 (2024); NIST IR 8547 (draft) on the transition timeline, which proposes deprecating quantum-vulnerable algorithms by 2030 and disallowing them by 2035; NSA CNSA 2.0.
Technical advice. Inventory where cryptography actually exists in the OT estate: firmware signing, VPNs, OPC UA certificates, remote access and PKI. Require cryptographic agility in procurement for assets bought from now on. Do not prioritize a brownfield PQC retrofit ahead of inventory, segmentation and access control.
Practitioner hot take. Most installed OT has no cryptography to migrate. Firmware signing keys are where PQC matters first, because a forged update is a durable compromise.
Standards body view. Raising PQC now is right for equipment that will still be in service in 2045. Framing it as a procurement requirement keeps it proportionate.
14. Sector profiles
In the draft. New profiles cover BACS, food and agriculture, freight rail, maritime vessels, and water and wastewater.
Related standards. BACS: Unified Facilities Criteria (UFC) 4-010-06 and BACnet Secure Connect. Maritime: IACS Unified Requirements E26 and E27 for ships contracted from July 2024, the US Coast Guard cyber rule for the Marine Transportation System published in January 2025, and IMO guidance on maritime cyber risk management. Water: America's Water Infrastructure Act of 2018 risk and resilience assessments and EPA guidance. Rail: TSA security directives. Agriculture: GNSS integrity and positioning, navigation and timing (PNT) guidance.
Technical advice. Use the profile as a starting map, then apply the sector's binding rules on top. On vessels, align the E26 and E27 documentation with the onboard asset inventory so class surveys and security operations use the same records. In buildings, settle ownership of the BACS network between facilities, IT and the landlord before commissioning, and verify default credentials were changed before handover.
Practitioner hot take. The profiles are useful, but electric power, pipelines, chemical and manufacturing, the core 800-82 audience, get none.
Standards body view. Those sectors have mature, dedicated regimes. The profiles fill gaps rather than duplicate them, and the draft should say so explicitly.
15. The overlay, the RMF and the packaging
In the draft. The SP 800-53 Rev. 5 OT overlay (Appendix E) and RMF guidance (Appendix F) become separate documents. The threats and organizations appendices become web resources.
Related standards. SP 800-53 Rev. 5 and its 5.2.0 release; SP 800-53B baselines; SP 800-37 Rev. 2.
Technical advice. Keep current control mappings and audit evidence referenced to Rev. 3 until the final Rev. 4 and the separate overlay are published. Record the exact version of any web resource you cite.
Practitioner hot take. The overlay is the part federal agencies and auditors actually use. Moving it out leaves the guide as the explanation while the requirements live in a document with no date yet.
Standards body view. Decoupling lets the overlay track 800-53 releases without reopening the guide. Ask for DOI-stamped, versioned releases of every web resource and for the overlay to publish alongside the final guide.
16. Does Rev. 4 explore risk, or reduce it?
In the draft. Section 3 sets up a risk register, risk responses and an OT risk management life cycle. Section 4.1.3 covers system-level risk and vulnerability assessment, including OT impacts, threat characterization and a likelihood evaluation table. Sections 4 and 5 then supply a large catalog of controls and architecture patterns, and Section 2.3 argues for a consequence-driven mindset.
Our assessment. The draft explores risk thoroughly. It describes threats, vulnerabilities, predisposing conditions, controls and architectures in more breadth than any previous revision. What it does less well is connect them. There is no worked path from a business or process consequence, to the few systems that can produce it, to the attack paths that reach those systems, to the barriers that stop them, to evidence that the barriers work. Without that chain, a site reading the guide will tend to implement the controls that are easiest to deploy rather than the ones that remove the worst outcomes. The likelihood table also sits uneasily beside the consequence-driven language in Section 2.3: for targeted attacks on OT, likelihood estimates are weak, and a register driven by them can rank a severe, low-frequency scenario below a nuisance.
Related standards. NIST IR 8286D on using BIA to inform risk prioritization, and SP 800-34 on contingency planning; MITRE CJA for mission dependency mapping; MITRE TARA for selecting countermeasures against specific attack vectors; INL CCE, whose first phases (consequence prioritization and system-of-systems analysis) cover similar ground for OT; IEC 62443-3-2 for the detailed risk assessment of each zone and conduit; IEC 61511 PHA and LOPA; ISO/SAE 21434, which uses the same acronym TARA for threat analysis and risk assessment at the product level and is useful when assessing what a vendor delivers.
What would make it better.
- Start with a BIA for the operation, not the IT estate. For each process or service, record the safety, environmental, regulatory and financial impact of losing it or having it manipulated, the maximum tolerable downtime (MTD), the recovery time objective (RTO), and how long the site can run in manual or degraded mode. Those figures decide which systems deserve the deepest controls and set the targets that recovery testing must meet.
- Map the crown jewels. Use CJA, or CCE system-of-systems analysis, to trace each high-impact function down to the specific controllers, safety systems, engineering workstations, historians, networks and people it depends on. In most facilities this produces a short list, often a few dozen assets, whose compromise creates the outcomes the BIA ranked highest. Everything else still matters, but it does not set the priority.
- Run TARA against that short list. For each crown jewel, enumerate the realistic attack vectors, using ATT&CK for ICS as a checklist, including vendor remote access, the management plane, removable media and supply chain. Score them on the site's own criteria, select countermeasures from the Rev. 4 catalog and the overlay, and record why each was chosen and what it costs.
- Carry cyber into the safety case. Treat a credible cyber scenario as an initiating cause in the PHA and LOPA revalidation, and only take credit for a barrier when it is independent of the systems an attacker would control.
- Measure the reduction. Record residual risk per scenario before and after treatment, barrier test results, the share of crown-jewel conduits with enforced rules, the time to detect an unapproved engineering action, and how recently manual operation and restoration were exercised. Define the events that force a reassessment, such as a new remote access path, a control system migration or a change to the process.
Practitioner hot take. As written, Rev. 4 is an excellent catalog organized by CSF function. A catalog explores risk; a prioritization method reduces it. The sites that make measurable progress are the ones that know their crown jewels before they buy anything.
Standards body view. NIST keeps its guides method-neutral on purpose, and IR 8286D already links BIA to enterprise risk. A short appendix with one worked example, BIA to crown jewels to TARA to barrier to metric for a single scenario, would show the method without mandating it. A minimum set of risk reduction evidence would give auditors something better to test than control counts.
The work is on site
Rev. 4 is a better guide than Rev. 3. The public commentary and feedback on the draft are worth reading alongside it, because they carry information a reader can weigh: thoughtful critique, nuance, edge cases, and the places where a site may want to follow the guidance closely and the places where it may not. After all, this is guidance, not gospel. A plant does not become safer because a guide was revised. Whether a site is resilient depends on whether the inventory matches what is in the cabinet, whether the vendor's remote session was approved by the operator on shift, whether the alert on a logic download was matched to a work order, and whether anyone has run the process by hand this year.
Engineering is cyber, but not all cyber is engineering. A firewall rule, a finding or a compliance score only matters when it keeps the process safe and functional. That means security work has to fit into the daily operational routine: rounds, permits to work, maintenance windows and turnarounds, instead of arriving as a separate program with its own calendar.
Where DacTAPE fits
Digital Twins, analytics and the rest of the digitalization agenda all assume something most sites do not yet have: an accurate, contextualized record of what is installed, how it is connected and what it is doing. DacTAPE is the functional layer that comes before the Digital Twin. It runs on premise, at the site, and does three jobs in one place: the cyber work, the asset inventory and the contextualization that ties the two to the process.
Acquisition without disturbing the process. A Hub and its Remotes collect through passive protocol dissection, read-only SNMP polling and agentless Windows enrollment, without touching controller logic. Where a site already owns a monitoring tool or an earlier inventory project that ended up in its own silo, that investment becomes a source rather than a write-off. The platform is vendor-agnostic, so a terminal with six different vendors gets one view, not six.
An inventory both engineering and security trust. Identity resolution and a reversible merge review reconcile what the network shows into one record per asset, with every merge accounted for and undoable. Each record carries the attributes that matter on site: vendor, model, firmware, lifecycle and patch state, where it sits in the topology and what it talks to. Vulnerability matching is reported in evidence bands, so triage starts from what is actually installed and reachable rather than from a list of CVEs.
Context that glues events together. A finding on its own is noise. DacTAPE ties findings and events to the asset, its place on a Purdue-model topology and the packet evidence behind them, with context-driven alerting on top. The head electrician offshore, the OT engineer, the auditor and the remote security operations center (SOC) look at the same record and see the same evidence. The output does not have to be cyber: the same data serves diagnostics, standard operating procedures and compliance.
Built for the people working there. The interface is written for the doer first, in the vocabulary of the trade, with clear actions and proof of work their supervisors can see. Leadership gets status, reports and compliance evidence from the same records, mapped across frameworks, and an outbound API feeds the tools a site already runs. The appliance is offline by design and makes no outbound connection unless you choose to configure one.
Whichever framework your auditor brings, the site needs the same thing underneath it: an accurate picture of what is installed, what it does in the process, and what changed. That picture is also what any future Digital Twin will be built on. We aim to make it safe and functional.
Talk to us. If you are commenting on Rev. 4, preparing for a 62443 or CIP review, or want an inventory your engineers will use, contact us at www.dactape.ca.
Sources: NIST SP 800-82 Rev. 4 initial public draft; Rev. 4 pre-draft call for comments; NIST SP 800-82 Rev. 3.