Can legacy NAC meet industrial control needs for deterministic latency, protocol fidelity, and auditable segmentation without risking downtime or noncompliance? Security and operations teams face brittle inventories, invasive agents, and coarse VLAN rules that complicate migrations. Decision-makers need protocol-level controls, measurable performance baselines, and costed migration plans before approving PoCs or procurement.
For OT environments, identity-based microsegmentation and ZTNA designed for protocol-aware, agentless controls are viable alternatives to legacy NAC. A practical approach maps OT protocols to identity and flow rules. It then runs latency and availability tests and delivers a PoC with vendor-neutral evaluation and an ROI model to ensure compliance and minimal disruption to critical control systems.
Summary of the process
This section lists the end-to-end steps needed to move from legacy NAC to an identity-and-flow model in OT. Each step is short and actionable for quick decisions.
Discovery and passive baseline
Collect assets, flows, and control cycle timings with passive taps and UEBA to avoid touching operations. This creates the dataset for policy design.
Pilot in a control cell
Pick one representative control cell and run visibility plus monitor-only policies. This keeps risk low while validating rules.
Policy design and review
Translate protocol semantics into identity+flow policies and review with control engineers. Policies include function-code limits, time windows, and rate caps.
Staged enforcement and HA testing
Enforce low-risk rules first, run latency and failover tests, then expand enforcement. Always maintain a rollback path.
Measure ROI and compliance
Quantify prevented risky flows, downtime avoided, and map controls to IEC 62443 and NERC CIP for procurement evidence.
Keep the pilot small and measurable with clear stop criteria.
Step 1: discovery and baseline
The discovery phase produces the single source of truth for assets and flows. Passive capture avoids touching controllers and gives timing baselines for each device class.
Sensors and data collection
Place network TAPs or SPANs at plant demarcation points and critical switches to capture traffic without adding latency. Store PCAPs and parse Modbus, DNP3, PROFINET, and OPC-UA transactions.
Timing and control loop baselines
Measure PLC scan times, I/O update jitter, and SCADA poll rates before changing the network. Record baseline metrics for each device class for later comparison.
Asset inventory and identity sources
Create an inventory that ties device serials, firmware, ports and operator roles to certificate or hardware identity when available. This inventory supports certificate lifecycle and role mapping.
A passive baseline that captures at least 14 days of representative operations usually yields stable control-loop metrics and reveals 90 percent of transient maintenance flows.
Step 2: pilot and policy design
Select a pilot that has representative devices and manageable risk. The pilot validates policy syntax, enforcement points, and operational handoffs.
Pilot scope and stakeholders
Choose one line, substation, or process cell that includes PLCs, an HMI, and a historian. Include plant operators, control engineers, and the network team in planning.
Translate protocol semantics into policy fields
Map common OT protocol elements to policy fields: source identity, destination identity, allowed function codes, max transaction rate, and allowed time windows. This avoids brittle MAC/IP rules.
Sample policy fields
Each policy contains source cert, destination cert, allowed methods, rate limit, and logging level. Policies must be human readable and machine enforced.
policy_name: "modbus_plc_readonly"
source_identity: "scada-server-cert"
destination_identity: "plc-02-cert"
allowed_function_codes: [1,2,3]
max_requests_per_second: 5
audit: true
PoC flow
1. Discover
Passive TAPs, inventory, timing baseline
2. Pilot
Monitor-only policies, operator sign-off
3. Enforce
Staged blocking, HA tests, ROI measurement
Step 3: enforce, test, measure
Enforce rules in stages, test carefully, and compare performance against baseline. Document every test and keep clear rollback triggers.
Enforcement modes and placement
Place enforcement at the plant edge, at protocol proxy points, or in switch TCAM depending on latency needs. Use hardware offload when available to cut added latency.
Latency and availability tests
Measure added latency per device class by replaying baseline traffic through enforcement points. Aim for thresholds listed below and log deviations.
High-speed I/O should see less than 1 ms added latency and jitter under 0.5 ms. HMI interactions should add under 5 ms. Historian transfers may tolerate up to 10 ms added latency.
This method does not work if the environment is truly air-gapped, has only a handful of unmanaged devices, or lacks any asset inventory and network visibility.
Errors that ruin the result
The most common mistake at this point is treating OT like IT and applying 802.1X or endpoint-agent models across plant devices without accounting for headless devices and timing constraints. This causes outages and operator pushback.
Skipping failover, HA and timing tests assumes enforcement is transparent. That assumption is rarely true. Always run controlled failover drills and measure control loop behavior.
Choosing vendors by demo only
Choosing based on feature lists or vendor demos that use clean testbeds leads to surprises in production. Require a PoC with live protocol traffic and HA scenarios.
Weak policy governance
Deploying enforcement without a POA&M, policy templates, and rollback SOPs causes long outages during maintenance windows. Policies must be owned by control engineering and security.
Comparing microsegmentation, ZTNA and proxies
Microsegmentation, ZTNA, and protocol proxies each provide different strengths. Select combinations based on protocol needs, latency tolerance, and manageability.
Microsegmentation strengths
Microsegmentation enforces per-flow rules close to the data plane and can be low-latency when hardware offload exists. It excels at isolating east-west traffic within a plant.
ZTNA / SDP strengths
ZTNA gives secure session-based access for remote operators and third parties and cuts the attack surface for engineering connections. Combine it with jump hosts for privileged sessions.
Protocol proxy strengths
Proxies understand application semantics and can restrict function codes or methods. They give the deepest protocol control and clear audit trails for compliance.
Key difference: protocol proxies enforce application semantics like Modbus function-code whitelists, while microsegmentation enforces flow pairs; both are needed to meet strict IEC 62443 segmentation and access requirements.
| Solution |
Protocol Support |
Agentless |
Latency Impact |
HA |
Compliance Mapping |
| Microsegmentation (switch/SDN) |
Modbus, DNP3 via DPI; PROFINET limited without vendor support |
Often agentless |
Low with hardware TCAM |
High with redundant controllers |
Good for network segmentation clauses |
| ZTNA / SDP |
Session-based; supports Modbus/TCP via gateways |
Agentless for access sessions |
Moderate for session brokers |
High with clustered gateways |
Strong for remote access controls |
| Protocol proxies / gateways |
Excellent for Modbus, DNP3, OPC-UA, PROFINET |
Usually agentless |
Variable; can be low if hardware accelerated |
Depends on vendor clustering |
Best for function-code enforcement and audit |
| Legacy NAC (802.1X, MAC/IP) |
Limited protocol semantics |
Often agent-based |
Low to moderate |
Varies |
Weak for IEC 62443 mapping |
Vendor evaluation and procurement checklist
Score vendors on protocol coverage, agentless design, HA, latency SLAs, manageability, and compliance outputs. Weight each category and require live PoC evidence.
Required POA&M and POE items
Require a Plan of Actions and Milestones (POA&M) and a Proof of Evidence (POE) that includes live latency numbers, HA diagrams, and sample audit exports. This stops buying features without production readiness.
Interview checklist for vendors
Ask for protocol testbeds using real Modbus/DNP3/OPC-UA traffic, documented latency impact, redundancy architecture, and traceability to IEC 62443 and NERC CIP clauses. Include at least two customer references in similar industries.
Scoring weights suggestion
Security coverage 20 percent, Performance/HA 20 percent, Deployment model 15 percent, Manageability 15 percent, Compliance traceability 15 percent, TCO 15 percent. Prefer vendors scoring above four on average.
Ask vendors to run your PoC traffic through their enforcement points and to provide measured deltas for control loop timing, not just synthetic benchmarks.
ROI, funding and compliance mapping
A simple ROI model compares avoided downtime, reduced incident response costs, and compliance savings against capital and operational spending. Phased purchases shorten payback.
Inputs: number of devices, expected incident reduction, average downtime cost per hour, license and hardware costs, deployment labor. Outputs: payback months, annualized savings, and NPV.
Typical payback and funding
Expect payback between 12 and 36 months depending on scale and risk profile. Consider subscription models or phased CAPEX to OPEX transitions to spread cost and link spend to pilot outcomes.
Compliance mapping
Map controls and evidence to IEC 62443 and NERC CIP clauses to support procurement and audits.
Operational case notes and lessons learned
This works well in theory. In practice the key failure modes are overlooked maintenance flows, insufficient operator training, and immature certificate lifecycle management. Planning for those three items reduces outages.
Anonymous case example
A common case: a manufacturing plant applied switch-based ACLs without function-code checks and caused intermittent stoppages during a maintenance update. Adding a protocol proxy and staged enforcement restored stability and cut unplanned downtime.
Practical nuances
The most frequent omission is not defining normal maintenance flows, which leads to false positives. Capture and document maintenance tools, mobile engineering IPs and remote sessions in the inventory.
Evidence and authorities
Use guidance from NIST SP 800-82 (2015) for ICS constraints and NIST SP 800-207 (2020) for Zero Trust design choices when preparing compliance artifacts. The evidence points to this recommendation: start small, measure precisely, and expand only when the pilot shows stable latency and clear operator buy-in.
Actionable synthesis and next steps
For teams ready to move, start with a 6 to 12 week PoC that includes discovery, pilot, and enforcement phases. Produce policy templates, test scripts, and compliance mapping as deliverables for procurement.
Deliverables to produce in 12 weeks
A 12-week PoC should deliver a signed inventory, monitor-only policy set, enforcement plan with rollback triggers, latency and HA test results, and a costed ROI model. These artifacts support procurement and regulatory audits.
Quick validation checklist
Validate that certificate-based identities or hardware identifiers exist for critical devices. Ensure passive baseline covers typical cycles and require vendors to run your traffic through their enforcement points during PoC.
Decision criteria to proceed
Proceed to full rollout if the pilot meets latency thresholds, HA failover times are below one control cycle, and operators sign off on policy behavior. If these criteria fail, expand pilot scope or adjust enforcement placement.
For teams ready to budget a PoC, request a tailored PoC scope with timeline and cost estimates from a vendor-neutral auditor to ensure objective evaluation and regulatory traceability.
Keep the pilot small and measurable with clear stop criteria.
Frequently asked questions
Can ZTNA replace NAC entirely in OT?
ZTNA can replace access functions for sessions and remote users, but in OT a hybrid approach combining microsegmentation, ZTNA, and protocol proxies usually works best. Each layer addresses different threat vectors.
How much latency will enforcement add?
Expected added latency: high-speed I/O under 1 ms, HMI interactions under 5 ms, historian transfers under 10 ms. Measure with baseline replay and vendor PoC to confirm plant-specific numbers.
What standards should be referenced for guidance
Reference IEC 62443 for segmentation and access control, NERC CIP for bulk electric systems, and NIST SP 800-207 for Zero Trust architecture guidance. These give audit paths for procurement and regulators.
What is a realistic PoC timeline?
A realistic PoC runs 6 to 12 weeks: 2 weeks discovery, 2 to 4 weeks pilot and monitor-only tests, and 2 to 6 weeks for staged enforcement and HA tests. This timeline fits most sites.
How to avoid outages during rollout?
Avoid outages by using passive discovery, monitor-only policy validation, staged enforcement, and documented rollback procedures. Require operator sign-off before each enforcement step.
How to map controls to IEC 62443 and NERC CIP?
Map segmentation, least privilege, secure communications, and logging to specific clauses and required evidence. Produce a one-page traceability matrix attaching logs and policy exports to each clause.
Closing checklist and resources
The checklist below prepares teams for a procurement-ready PoC and migration.
Migration checklist
- Passive asset and flow inventory completed.
- Baseline timing metrics captured for all device classes.
- Pilot cell selected with operator and control-engineer sign-off.
- Policy templates created for Modbus, DNP3, PROFINET, and OPC-UA.
- Vendor PoC requires live traffic, latency numbers, HA diagrams and compliance exports.
- ROI model and funding plan drafted for phased rollout.
Useful references
NIST SP 800-207 (Zero Trust, 2020) and NIST SP 800-82 (ICS guide, 2015) give architectural and ICS-specific guidance. Department of Energy and CISA advisories add operational context and maturity models.
Which OT environments benefit most from these
Environments with networked PLCs, HMIs, and remote engineering access benefit most. These setups need protocol-aware controls and identity-based sessions to cut attack surface.
