Zero Trust Readiness Checklist for Industrial Environments

Zero Trust readiness for an industrial environment comes down to twelve domains you can score with evidence: asset inventory, network access control, human authentication, machine identity, authorization, segmentation, device protection, data protection, remote access, monitoring, incident response, and governance. If you cannot produce an artifact for a domain, a policy export, a log sample, a certificate chain, a diagram, you are not ready in that domain regardless of what you have purchased. This page is the checklist, the scoring rubric, and the deployment sequence that follows from your score.

Industrial environments make Zero Trust harder than IT does, and the checklist is built around that rather than pretending otherwise. Legacy PLCs cannot run agents. Production cannot tolerate downtime for a VLAN redesign. Vendor remote access often runs on shared credentials nobody has rotated in three years. Half the fleet has no 802.1X supplicant. Every domain below states what "ready" means when those constraints are real.

In essence, Zero Trust in industrial security means:

• Never trust any device or user by default, whether inside or outside the network perimeter.
• Always verify every access request with strong authentication and continuous evaluation, not a one-time admission check.
• Assume breach and design controls that limit blast radius when, not if, something gets in.

How to score this checklist

Score each of the twelve domains from 0 to 2:

The evidence rule is what makes the exercise useful. A domain scores 2 only if you can produce the artifact within one working day without building anything new. "We have MFA" is not evidence. A policy export showing which identities can reach which assets over which protocols, with a matching session log, is evidence. Assessors under CMMC and NERC CIP all ask the same question in different words: show me.

Maximum score is 24. Anything below 12 means you are still building foundations, and the deployment phases at the end of this page tell you where to start.

What is Network Access Control in a Zero Trust architecture?

Network Access Control is the function that decides whether a device or user gets onto the network, and what it is allowed to reach once admitted. In Zero Trust terms it is the enforcement layer. NIST SP 800-207 splits the architecture into a Policy Engine that makes the decision, a Policy Administrator that establishes or tears down the session, and a Policy Enforcement Point that sits in the data path and actually allows or blocks the traffic. NAC is how the Policy Enforcement Point shows up on an industrial network.

The distinction matters because NAC and Zero Trust are routinely confused. Zero Trust is the model. NAC is one of the mechanisms that makes the model real on a wire. A classic NAC deployment is not automatically Zero Trust: 802.1X authenticates a device at the moment it plugs in, then trusts it for the entire session, which is exactly the implicit-trust behavior Zero Trust exists to remove.

Where NAC sits in the Zero Trust control plane

An OT network that has an inventory but no PEP has visibility, not Zero Trust. An OT network with a PEP but no identity source has a firewall with extra steps.

Why classic NAC struggles in OT

This is the crux of NAC in industrial environments. The devices you most need to protect, PLCs, RTUs, protective relays, CNC controllers, drives, are precisely the devices that cannot participate in the authentication. Falling back to MAB gets them onto the network and gives you an inventory line item, but a spoofed MAC defeats it in seconds. The practical answer is to stop asking the asset to prove anything and put the enforcement in front of it. See how to secure SCADA systems without touching a controller for the protocol-level detail, and agent-free Zero Trust for why endpoint software is not coming to save this.

The twelve readiness domains

1. Asset inventory and classification

Ready means: every device that can put a packet on the OT network is in a single inventory, with owner, criticality, protocol, firmware version, and zone assignment, and the inventory updates itself.

• Every IT and OT asset is catalogued, including legacy controllers, engineering laptops, contractor devices, wireless bridges, and cellular modems
• Assets are classified by criticality and by safety impact, not only by IP range
• Discovery is passive or in-path, so it does not scan controllers that fail under active scanning
• The inventory has a last-seen timestamp and flags devices that appear without a change ticket
• Shadow connectivity is explicitly hunted: vendor 4G routers, forgotten dial-up, unmanaged switches

Maps to: CISA ZTMM Devices pillar, IEC 62443-3-2 zone identification, NIST 800-171 3.4 Configuration Management.

Most common failure: an inventory built once during a consulting engagement, exported to a spreadsheet, and never refreshed. It is stale within a quarter.

2. Network access control and admission policy

Ready means: nothing reaches a controller without passing an enforcement point that knows who or what is asking, and admission is deny-by-default.

• Deny-by-default is the baseline, with explicit allow rules, not allow-by-default with blocklists
• Every conduit between zones terminates at an enforcement point, not just at a routed interface
• Devices that cannot authenticate themselves sit behind an enforcement point that can
• MAB, where used, is treated as inventory signal only and never as an authentication control
• Admission decisions are re-evaluated during the session, not only at connection time
• Enforcement is highly available, with a defined behavior on failure that operations has signed off

That last item is where OT diverges hardest from IT. A NAC that fails closed and stops a batch is a NAC that gets ripped out after the first incident. Decide fail-open versus fail-closed per zone, write it down, and test it. High availability NAC deployment for continuous operations covers the failure modes in detail.

Maps to: NIST SP 800-207 PEP, CISA ZTMM Networks pillar, IEC 62443-3-3 SR 5.1 and SR 5.2, NIST 800-171 3.1 Access Control.

3. Human authentication and access management

Ready means: every human who touches an OT asset is authenticated against a real identity provider with phishing-resistant MFA, and the identity is bound to the session, not to a shared login.

• All interactive access uses named individual accounts, no shared operator logins
• MFA is enforced for every session into the OT environment, including local console access where feasible
• MFA method is phishing-resistant where it matters: FIDO2 or PIV over TOTP, TOTP over SMS
• Employees authenticate against the corporate identity provider, so a leaver loses access the day they leave
• Vendors and contractors authenticate against a separate identity path, anchored with MFA at the gateway, and their access is time-bounded
• Credential rotation is automated, and no OT credential lives in a shared spreadsheet or a wall-mounted laminate
• Privileged sessions require an additional approval step or a break-glass workflow with an audit trail

The multi-identity requirement is what most OT deployments get wrong. Internal staff belong in the corporate directory. External vendors do not, and forcing them in creates permanent accounts nobody deprovisions. A gateway that can broker several identity providers at once, corporate IdP for staff and independent MFA-anchored identity for vendors, resolves this without an account-sprawl problem. Practical guidance is in how to implement MFA in legacy OT environments and why your OT network has no identity layer.

Maps to: CISA ZTMM Identity pillar, IEC 62443-3-3 SR 1.1, SR 1.5, SR 1.7, SR 1.13, NIST 800-171 3.5 Identification and Authentication.

4. Machine identity and credentials

Ready means: devices and software processes have cryptographic identities that can be issued, rotated, and revoked, and no automated flow depends on a static shared secret.

• Machine-to-machine flows use certificates or short-lived tokens, not embedded passwords
• A certificate authority exists for the OT environment, with a documented issuance and revocation process
• Certificate lifetimes are short enough that revocation is not the only recovery path, and expiry is monitored
• Assets that cannot hold a certificate inherit one from the enforcement point in front of them
• Service accounts are inventoried, scoped to a single function, and cannot be used interactively
• Default vendor credentials have been changed or fronted, and you can prove which assets still carry them

This is the domain that the industry talks about least and fails most often. IEC 62443-3-3 SR 1.2 requires identification and authentication of software processes and devices, and SR 1.8 and SR 1.9 point directly at public key infrastructure. The industrial reality is that a 2009 PLC will never present a certificate. The workable pattern is credential inheritance: the enforcement point holds the strong, revocable identity, terminates the authenticated session, and speaks the native protocol to the controller on the protected side. The controller does not change. The identity becomes real anyway. See device identity in Zero Trust industrial networks and MFA for service accounts and industrial devices.

Maps to: CISA ZTMM Identity and Devices pillars, IEC 62443-3-3 SR 1.2, SR 1.8, SR 1.9, NIST 800-171 3.5.

5. Authorization and least privilege

Ready means: access is granted per identity, per asset, per protocol, and per time window, and you can export the full matrix.

• Policy is expressed as identity to asset, not as source subnet to destination subnet
• Protocol and function-level restrictions exist where the protocol allows, for example read-only Modbus function codes for a monitoring role
• Time-bounded access is the default for vendors, with automatic expiry rather than manual cleanup
• Standing privileged access has been eliminated or reduced to a named, reviewed exception list
• Access reviews run on a schedule and produce a signed artifact
• A single export shows the complete "who can reach what" matrix for the site

Subnet-based rules are the tell that a network is not actually Zero Trust. If the policy says 10.20.30.0/24 may reach the PLC VLAN, then anything that acquires an address in that range inherits the privilege, which is precisely the implicit trust the model removes.

Maps to: NIST SP 800-207 Policy Engine, IEC 62443-3-3 SR 2.1 authorization enforcement, NIST 800-171 3.1.1 and 3.1.2.

6. Segmentation, zones, and conduits

Ready means: the network is divided into zones with defined conduits, lateral movement between zones is blocked by policy, and you achieved it without a rewiring project.

• Zones are defined by function and risk, following IEC 62443-3-2, not by whatever the switch topology happened to be
• Every conduit between zones is documented, enforced, and monitored
• Microsegmentation reaches the individual asset for the crown jewels, not just the cell
• East-west traffic inside a zone is constrained, not implicitly trusted
• Segmentation was delivered as an overlay or in-path layer, so the underlay stayed intact and production kept running
• A current diagram exists that matches the enforced policy, and the two are checked against each other

The reason segmentation programs stall is that the classic answer is a VLAN redesign, and a VLAN redesign means an outage window that a continuous process plant will not grant. An overlay approach separates the policy from the cabling. See how to segment a flat OT network without VLANs or downtime and overlay networking versus VLANs.

Maps to: CISA ZTMM Networks pillar, IEC 62443-3-2 and 3-3 SR 5.1, SR 5.2, NIST 800-171 3.13 System and Communications Protection.

7. Device protection

Ready means: you know the security posture of every asset, you patch what can be patched, and you have a documented compensating control for everything that cannot.

• Firmware and software versions are tracked against known vulnerabilities, with a documented triage cadence
• A patch process exists that accounts for requalification and production windows, with a realistic time to patch per asset class
• Unpatchable assets have a named compensating control, and that control is enforced rather than described
• Physical ports on controllers and cabinets are controlled, including USB and engineering ports
• Engineering workstations, the highest-value target in most plants, have endpoint protection, disk encryption, and restricted network reach
• Device posture, where obtainable, is an input to the access decision rather than a report nobody reads
• Removable media policy exists and is technically enforced, not only written

Honesty matters here. Endpoint agents do not run on controllers, so "device protection" in OT means protecting the path to the device and hardening the few endpoints that can be hardened. Claiming device health attestation on a PLC is claiming something no product can do. The defensible position is that access to the unpatchable device is authenticated, authorized, minimal, and recorded, which is exactly what a compensating control needs to demonstrate. MFA for PLCs as a CMMC 3.5.3 compensating control documents that argument in the form assessors accept.

Maps to: CISA ZTMM Devices pillar, IEC 62443-3-3 SR 3.x system integrity, NIST 800-171 3.14 System and Information Integrity.

8. Data protection

Ready means: you know what data the OT environment produces, where it goes, who can read it, and it is encrypted in transit and at rest, including your own security telemetry.

• OT data flows are mapped: process data, historian archives, alarm records, engineering project files, backups
• Sensitive categories are classified, for example CUI in defense manufacturing, personal data under GDPR, operational data with commercial sensitivity
• Traffic crossing a conduit or an untrusted network is encrypted, and legacy plaintext protocols are tunnelled rather than exposed
• Data at rest is encrypted on historians, backups, and engineering workstations
• Session recordings and audit logs are themselves protected, tamper-evident, and access-controlled
• Data residency is known and controlled, including whether any security tooling ships telemetry off site or out of jurisdiction
• Engineering project files and controller backups are versioned and restorable, and the restore has been tested

Data residency deserves a line of its own. A Zero Trust deployment that improves access control while streaming session metadata to a foreign-jurisdiction cloud has traded one exposure for another, and for regulated operators that trade is increasingly hard to defend. Enforcement that runs on premise keeps the audit trail where the regulator expects it.

Maps to: CISA ZTMM Data pillar, IEC 62443-3-3 SR 3.1 communication integrity and SR 4.1 information confidentiality, NIST 800-171 3.13.

9. Remote access and third-party access

Ready means: every remote session, staff or vendor, is brokered, authenticated, scoped, recorded, and terminable in one click.

• No direct inbound path exists to any OT asset, every session routes through an intermediate enforcement point
• Vendor sessions are time-bounded, scoped to specific assets, and require MFA at the gateway
• Sessions are recorded at a level that lets you reconstruct what was done, not just that a connection occurred
• Active sessions are visible in real time and can be determined and disabled immediately
• Shared vendor accounts have been eliminated, each technician is individually identified
• The remote access path does not depend on a vendor cloud staying up for you to operate or to cut someone off

Third-party remote access is the highest-yield domain in this checklist. It is the most frequently exploited entry path into industrial networks, and it is also the domain where regulators have moved most concretely: NERC CIP-005 requires an Intermediate System for Interactive Remote Access, CIP-003-9 extends vendor remote access requirements to low-impact assets, and CIP-013 requires a supply chain risk management plan that covers vendor remote access. Full treatment in the secure OT remote access guide.

Maps to: CISA ZTMM Identity and Networks pillars, IEC 62443-3-3 SR 1.13 access via untrusted networks, NERC CIP-005 R2, NIST 800-171 3.1.12 through 3.1.14.

10. Monitoring, logging, and audit evidence

Ready means: every access decision produces a log, the logs reach a place operators actually watch, and the audit trail is admissible.

• Every allow and every deny is logged with identity, asset, protocol, timestamp, and outcome
• Logs are centralised, retained for the period your framework requires, and time-synchronised
• The audit trail is tamper-evident, so a compromised account cannot quietly rewrite it
• Anomaly detection covers OT protocols, not just IT traffic patterns
• Alerts have owners and a response path, rather than accumulating in an unread queue
• Compliance evidence exports on demand, as a by-product of running the system, not as a quarterly project

Monitoring is also where NERC CIP-015 internal network security monitoring lands, and an in-path enforcement point is a natural vantage for it because it already sees every session. Architecture patterns in OT microsegmentation and SIEM architecture. For what to measure over time, see key metrics to track Zero Trust adoption in OT.

Maps to: CISA ZTMM Visibility and Analytics, IEC 62443-3-3 SR 6.1 and SR 6.2, NERC CIP-015, NIST 800-171 3.3 Audit and Accountability.

11. Incident response and recovery

Ready means: you have an OT-specific incident plan, you have rehearsed it with operations in the room, and you can isolate an asset without stopping the plant.

• The incident response plan addresses OT scenarios specifically, with safety and production impact in the decision tree
• Isolation is a one-click action at the enforcement point, tested, with a known operational consequence
• Controller configurations and engineering project files are backed up offline and restore has been tested this year
• Roles are defined across IT security, OT engineering, and operations, and everyone knows who declares an incident
• Tabletop exercises run at least annually and include a vendor-access compromise scenario
• Regulatory notification timelines that apply to the site are documented, with a named owner and contact path

Maps to: IEC 62443-2-1 incident handling, NIST 800-171 3.6 Incident Response.

12. Governance, training, and change management

Ready means: Zero Trust has an owner, a budget, a review cadence, and the people running the plant understand why the controls exist.

• A named owner is accountable for OT security posture, with authority over both IT and OT stakeholders
• Policy changes go through change management, with rollback defined
• Operators and engineers receive OT-specific security training, not recycled IT phishing modules
• Vendors are contractually bound to the access model, with security requirements in procurement documents
• The checklist is re-scored quarterly and the score trend is reported to management
• Senior management receives regular reporting on OT security posture and signs off on accepted risks

Maps to: CISA ZTMM Governance, IEC 62443-2-1, NIST 800-171 3.2 Awareness and Training.

NAC implementation in Zero Trust: what you actually need

Implementing NAC as the enforcement layer of a Zero Trust architecture requires six components. Most industrial sites already have two or three of them and try to buy a seventh product instead of connecting what they own.

Two design decisions determine whether the result is Zero Trust or a firewall with a login page.

Where the enforcement point sits. At the switch port, enforcement depends on the device supporting 802.1X, which excludes most of the OT fleet. In front of the asset, enforcement covers everything, including the 2009 PLC, because the asset is not asked to participate. This is the argument for the in-path model described in what is an industrial proxy.

Whether the decision is continuous. A one-time admission check re-creates implicit trust for the rest of the session. Per-session brokering, with the session re-evaluated against policy and terminable mid-flight, is the property that makes it Zero Trust rather than NAC with a new logo.

For zone-level implementation detail, see IEC 62443 zone implementation with network access control and zone and conduit architecture with modern NAC solutions.

Deployment guidelines and phases

The score you produced above determines where you enter this sequence. The sequence itself is the same for every industrial site, and the governing constraint is that nothing in it may require a production stop.

Phase 0: assessment and planning

Map assets, flows, and zones before touching anything. Identify your regulatory scope early, because CMMC and NERC CIP each pull the design in a slightly different direction on logging retention and evidence format. Agree the target policy with operations, in writing, including what happens on enforcement failure per zone. Sequence the rollout by risk, not by convenience: the vendor remote access path and the engineering workstation segment usually top the list.

Phase 1: monitor-only deployment

Deploy the enforcement point in path but in observe mode. It sees every session and blocks nothing. This does two things: it produces the real traffic baseline, which is almost never what the documentation claims, and it builds operational confidence that the device in the path is not going to stop the line. Skipping this phase is the single most common cause of a failed OT security rollout.

Phase 2: pilot enforcement

Pick one cell that matters enough to be a real test but not enough to be a disaster, or pick a single vendor access path. Turn on enforcement. Run it through a complete production cycle, including a shift change, a maintenance window, and ideally a vendor intervention. Test the rollback. Train the operators who will call you at 3am. Only then move on. From unboxing to Zero Trust in 4 hours walks through what a first deployment looks like in practice, and phased NAC deployment in live manufacturing environments covers the manufacturing-specific sequencing.

Phase 3: incremental rollout

Expand one zone at a time, applying the same exit criteria each time. Resist the temptation to accelerate after two easy zones, because the difficult zones are difficult for reasons that show up late: an undocumented dependency, a vendor tool that hard-codes an IP, a protocol that behaves badly through any intermediary. Each zone gets its own baseline period, however short.

Phase 4: optimization and continuous review

Tighten from asset-level to function-level policy where the protocol supports it. Automate evidence export so compliance stops being a quarterly scramble. Re-score the twelve domains every quarter and report the trend. A score that stops moving is a program that has stopped.

What your score means

Common failure patterns

Buying the platform before fixing the inventory. Policy engines need to know what they are protecting. An unmaintained asset list produces policy that is wrong on day one and unfixable by month three.

Treating MAB as authentication. MAC allowlists are inventory, not security. A laptop with a spoofed MAC is on the controller network in under a minute.

Designing around a VLAN redesign. It requires downtime that will never be granted, so the project dies in the planning phase. Overlay and in-path approaches sidestep the dependency entirely.

Enforcing before observing. Skipping the monitor-only phase means the first enforcement action is also the first discovery of an undocumented flow, and it happens in production.

Solving IT identity and calling it done. MFA on the corporate VPN does nothing for the vendor dialling into a substation RTU or the technician at an HMI on the floor.

Shipping the audit trail off site without checking jurisdiction. For regulated operators, where the evidence lives is part of the compliance question, not an implementation detail.

Where Trout Access Gate fits

Access Gate is an appliance that puts compute in the data path, next to the industrial assets, which makes it the enforcement point for domains 2, 3, 4, 5, 6, 9, and 10 without requiring anything from the controllers themselves. It plugs into the existing LAN, discovers assets, and enforces identity-bound access, microsegmentation, network-layer MFA, and tamper-evident audit, with no agent on equipment, no rewiring, and no production downtime. It brokers multiple identity providers at once, corporate IdP for staff and independently MFA-anchored identity for vendors, and it runs on premise so the audit trail and the session data stay in your jurisdiction.

It does not solve every domain. Device posture on a controller (domain 7) is not obtainable from the network by any product, incident response (domain 11) is a process, and governance (domain 12) is an organizational commitment. The honest claim is that Access Gate makes the access-control and evidence domains provable, which is the majority of what a Zero Trust assessment actually asks for.

See Zero Trust access control for the product view and agentless Zero Trust for OT for the architecture.

Conclusion

Use this checklist as a quarterly assessment, not a one-time exercise. Score the twelve domains, take the three weakest, and make them the content of your next security sprint. The evidence rule keeps the exercise honest: if you cannot export the artifact in a day, the domain is not ready no matter what is installed.

The sequence that works in industrial environments is consistent. Inventory first, because you cannot write policy for assets you cannot name. Remote access second, because it is the most exploited path in. Then identity, then segmentation, then the evidence layer that turns all of it into something an assessor accepts. Deploy in monitor mode before you enforce, pilot on one cell before you scale, and never design a program that depends on downtime you will not be granted.

For more Zero Trust OT resources, architecture guides, and comparisons, visit the Zero Trust for OT Networks hub.