By Carolyn Crandall, Chief Marketing Officer, Xona Systems
Carolyn brings more than 30 years of cybersecurity strategy and product marketing experience to OT and ICS secure remote access. She has authored research and analysis on session visibility for industrial cybersecurity, identity-based access for critical infrastructure, and third-party vendor access governance, and has led marketing for cybersecurity companies across deception, identity, and OT security categories.
Identity-based access for OT and ICS is a security model that grants access according to verified identity, explicit policy, and session-level control rather than broad network connectivity. Instead of extending VPN or jump-server access into critical environments, it limits each user to the specific systems, tasks, and time windows they are authorized to use.
In brief: Identity-based access for OT and ICS replaces broad VPN-style connectivity with verified, policy-based access to specific systems, improving security, vendor control, and auditability.
That shift matters because remote access is now part of normal industrial operations. Vendors, engineers, operators, and support teams all need access to critical systems, yet many environments still rely on methods built for convenience rather than accountability. The result is often too much standing access, too little visibility, and more operational risk than organizations realize.
In OT and ICS, the value is practical. Identity-based access reduces lateral movement risk, improves vendor access control, and creates the evidence needed for investigations, compliance, and safer day-to-day remote operations.
In brief: Identity-based access for OT and ICS replaces broad VPN-style connectivity with verified, policy-based access to specific systems, improving security, vendor control, and auditability.
Many organizations are trying to modernize access control in OT without changing the basic structure of how access is granted. That creates a gap. Identity may be verified at the front door, but once a user is connected through a VPN or jump host, the organization often loses precision over what that user can reach, how long access should last, and what actually happens during the session.
In OT environments, that gap is more serious because the systems were not built for modern IAM assumptions. Legacy systems may not support native identity integration. Vendors may rely on shared accounts or persistent remote access paths. Operations teams are also cautious, for good reason, about introducing controls that could affect uptime or maintenance workflows.
Common failure points include shared or generic credentials, unmanaged vendor and contractor access, limited session visibility, manual access reviews, and access models that grant more reach than the task requires. In practice, that leaves security teams with weak accountability and operations teams with too much hidden risk.
How Xona addresses this
The practical requirement is not just stronger authentication. It is tighter control over the access path itself. Xona helps close that gap by enforcing identity-based access at the session level, so users are connected only to the systems they are approved to use, for the time they are approved to use them.
That changes the operating model in a meaningful way. Instead of extending broad network trust, Xona enables tightly scoped access with clear accountability, stronger oversight, and less residual exposure, especially for vendors and contractors supporting critical systems.
Identity-based access is one of the clearest ways to put Zero Trust into practice. It replaces implicit trust based on network location with explicit trust based on verified identity, policy, and session context. Access is granted because a user has been validated and authorized for a specific task, not because they have landed on the right segment of the network.
That matters for resilience as much as for security. When access is tightly scoped and attributable, organizations reduce lateral movement risk, improve auditability, and gain better control during incident response and recovery. For OT and ICS, that means a cleaner connection between cyber controls and operational outcomes like uptime, maintenance continuity, contractor management, and compliance readiness.
A strong identity-based model also supports more disciplined vendor workflows. Instead of relying on standing access or shared accounts, organizations can move to time-bound, role-based access that is easier to approve, review, revoke, and investigate.
In OT, strong identity-based access does not stop at authentication. It controls the session itself. Xona supports that model through browser-based secure sessions, MFA, time-based access control, and real-time monitoring and recording, all without exposing internal networks directly to the user.
That helps organizations move closer to Zero Trust without forcing a fragile OT environment into a generic IT pattern. The point is not abstract architecture purity. The point is stronger governance and resilience without making remote operations brittle or slow.
VPNs and jump servers were not designed for modern industrial cybersecurity or compliance requirements. They often create broad network access, rely on shared or privileged accounts, and provide limited session visibility.
That problem becomes more serious in OT environments, where proprietary protocols, fragile systems, vendor dependencies, and uptime constraints make broad remote connectivity especially risky. These tools are not just old. They solve the wrong problem. They provide connectivity first and precision second.
In OT, the better order is the reverse. Access should be limited to the specific system, user, and task involved, with clear policy enforcement and full session accountability.
How Xona addresses this
Xona is built around a more controlled model. Rather than extending direct network access to the user, Xona brokers access to the specific system or resource the user is authorized to reach.
That architecture reduces exposure, improves accountability, and gives organizations better evidence for audit, investigation, and vendor governance without creating unnecessary operational drag.
A modern OT/ICS remote access approach should begin with identity-bound, time-bound access. Every session should be attributable to an individual user, a specific purpose, and a defined window of approval. Shared accounts and persistent access undermine both auditability and operational control from the start. If identity is weak, session visibility becomes less valuable because the organization cannot reliably tie activity to a person or an authorized workflow.
The architecture should also mediate access rather than exposing internal networks broadly. In OT/ICS, remote users should not receive open-ended connectivity to industrial systems simply because they need to perform support or maintenance tasks. A modern model places control at the access layer so session monitoring, recording, and policy enforcement can be applied consistently across protocols, users, and environments. This is especially important for vendors and contractors, who often represent the highest-risk remote sessions while receiving the least session-level oversight.
Organizations should also expect more than video capture. Useful session recording should support replay, search, user attribution, and correlation with surrounding identity and governance events. Teams should be able to answer practical questions without manual reconstruction: who requested access, who approved it, what systems were reached, what happened during the session, and whether that evidence can be retrieved quickly in response to an incident or audit.
Operational fit matters as much as security control. If the solution is too fragile, too hard to manage, or too disruptive to industrial workflows, coverage gaps will persist. OT/ICS environments need a model that improves control without requiring invasive endpoint changes or constant administrative overhead.
How Xona addresses this
Xona combines identity-based remote access, session monitoring, recording, and governance in a model designed for OT/ICS rather than adapted from general-purpose IT remote access.
Its protocol-aware, access-layer approach helps organizations apply session visibility consistently without depending on agents on managed and unmanaged endpoints.
Xona also supports searchable and exportable session evidence, which makes recordings more useful for investigation, governance, and audit than static or isolated capture methods.
In OT/ICS, session visibility and recording is not only a security control. It is also an operational safeguard. When something goes wrong during a maintenance window, a vendor intervention, or a patching cycle, the absence of session evidence forces teams to reconstruct events from memory and partial logs. That slows root-cause analysis, increases finger-pointing, and can extend outages from hours into days.
A modern approach improves reliability by preserving a timestamped record of what was done, by whom, and in what sequence. That matters when multiple engineers touch a critical system, when a vendor introduces a change that affects performance, or when a production issue emerges after a routine session that appeared harmless at the time. With session recordings, teams gain a precise operational history rather than a patchwork of assumptions.
Safety and access control also improve because controlled sessions reduce ambiguity around privileges and actions. When access is time-bound, supervised, and reviewable, organizations are in a stronger position to support third-party maintenance without granting broad, persistent exposure. That creates a better balance between operational continuity and security governance, especially in critical environments where remote access must exist but cannot be trusted blindly.
When something goes wrong on the asset side after a remote session, the absence of session evidence is what makes the post-incident review hard. A failed maintenance task, an unintended state change, a misconfigured PLC, a setpoint drift discovered hours after the technician disconnected: each of these turns into a forensic exercise built on memory, partial network logs, vendor recollection, and ticket commentary. The recovery clock keeps running while the investigation argues about what actually happened.
Session recordings collapse that exercise. The replayable record shows which user authenticated, which asset they reached, which commands they sent, and the screen state at each step. Root-cause analysis becomes a five-minute replay rather than a two-day reconstruction. Recovery accelerates because the team can isolate the actual change rather than testing hypotheses against partial evidence. Inter-party disputes between vendor, operator, and compliance compress because the evidence is the same artifact for everyone in the conversation. Regulatory posture improves because the audit trail is producible on demand rather than reconstructed under deadline pressure.
Real-time supervision is one of the operational features OT/ICS teams care about most and one of the least-marketed capabilities in the secure-remote-access category. A senior engineer or operations lead can observe a vendor's live session as it happens, intervene if needed by sending an in-session message, pausing the session, or taking control, and never has to physically visit the asset or schedule on-site supervision time. The supervisor sees what the technician sees in the same moment, with the session record building underneath the live view.
The operational benefits land in the places that actually move the cost-of-operations needle. Decisions get made faster because the supervisor is already watching when the question arises rather than getting paged in afterward. Truck rolls drop because supervision no longer requires physical presence at the site. Inter-time-zone supervision gaps close because supervisors in any location can attend any session. Commissioning windows, vendor maintenance cycles, and contractor onboarding all benefit from this directly: the senior person whose oversight makes the work safer can be present without being physically present.
How Xona addresses this
Xona's real-time session monitoring supports active oversight during remote access rather than limiting visibility to after-the-fact review.
Its ability to record and review full session activity helps reduce ambiguity during outage investigation, maintenance review, and vendor accountability questions.
Xona's controlled access model is especially relevant where organizations need to support remote operations without accepting the open-ended exposure of VPN-based access.
CISOs and architects sign the contract. Plant operators, engineering leads, and field technicians live with the result. The operational pain that drives most VPN replacement projects is not abstract. It is logged in the trouble-ticket queue.
The recurring complaints are familiar to anyone who has run an OT remote access program. The VPN drops during a commissioning window, and the technician on the line loses an hour of work. The jump-server queue fills up during a planned maintenance day, and three vendors wait their turn to push a patch they had already scheduled. A new contractor's VPN client install takes a help-desk round trip the morning a turnaround starts. A site engineer trying to reach a relay at 3:00 AM gives up after the second prompt for a hardware token because the token was at the office. None of these are security failures in isolation. Together they erode trust in the access model that is supposed to keep operations moving.
Identity-based access through a browser-based gateway changes the day-to-day experience in concrete ways. There is no client to install on a contractor laptop, so onboarding a new vendor takes a single Xona policy configuration rather than a help-desk install ticket. Sessions hold across network blips with Session Hold, so a technician working over a flaky cellular link does not lose progress and does not have to call the SOC to re-establish the path. There is no shared jump-server queue, because each user gets a directly-brokered session into the asset they are approved to reach. Deployment is engineered for plant tempo: 20 minutes per site for the gateway stand-up, not a week of network re-architecture.
Operations teams notice that the new model puts fewer items on their plate, not more. The CISO gets per-user attribution and audit-ready evidence. The plant gets a remote access path that does not become its own outage source. That alignment is what makes identity-based access durable in OT, where any control that operations teams resist tends to get worked around within a quarter.
A modern secure remote access model should do more than confirm who a user is. It should control how access is granted, how long it lasts, what systems it reaches, and what evidence is created during the session. In OT and ICS, that means moving beyond broad network access toward identity-based, task-specific connectivity.
At a minimum, the approach should include:
This is where many legacy approaches fall short. VPNs and jump servers can authenticate users, but they still tend to grant broad reach once connected. That leaves organizations trying to govern precise operational risk with blunt access tools.
How Xona addresses this
Xona is aligned to this modern model through identity-based access, time-bound permissions, secure browser-based sessions, session recording for audit and forensics, and support for high-performance access to critical industrial systems.
The practical advantage is twofold. Security teams gain stronger enforcement and evidence. Operations teams gain a remote access model that is easier to govern without making maintenance, support, or vendor access harder than it needs to be.
In industrial environments, access control is not only a cyber issue. It is also a reliability and safety issue. Weak access design can expose fragile systems to unnecessary risk, complicate maintenance activity, and make it much harder to reconstruct what happened after an incident or outage.
Identity-based access improves this by narrowing the connection path between the user and the critical system. Instead of granting broad access to a network segment, it limits access to a defined system, role, or task. That reduces the blast radius of every session and improves accountability across internal and external users alike.
This matters in OT because remote access must coexist with uptime requirements, separation of duties, contractor workflows, and compliance expectations. The right model supports remote work without introducing hidden instability or governance gaps.
Phase 1 discovery typically surfaces a bigger access surface than expected. When operators run their first identity-based access deployment phase, the discovery exercise typically uncovers more than 20 vendor, contractor, and engineer access paths that were not on the original inventory. The pattern is consistent across our customer deployments: shared credentials get reused across teams, vendor remote-access tunnels get stood up around procurement cycles, and emergency access paths created during incidents stay in place long after the incident closes. The number is not the headline. The headline is that the access surface in a typical operator environment is meaningfully larger than the system-of-record reflects, and identity-based access requires that surface to be enumerated before it can be governed.
When operators share an HMI account and reach it through a VPN, the audit record stops at the VPN connection log. The post-incident question, "who actually executed that command at 02:14?", becomes a recollection exercise. Per-session attribution at the gateway changes the answer surface. Each session is bound to a verified user, scoped to a specific asset, and captured as a replayable record.
| Dimension | Shared HMI Credentials with VPN | Credential injection at gateway with per-session attribution |
| Who logged in | Unknown beyond shared account label | Per-user, tied to verified identity |
| What they did during the session | Not captured beyond connection logs | Captured as full session recording |
| When | VPN connection timestamp only | Session start, key actions, session end timestamps |
| Audit evidence available | Connection log only | User identity, session scope, recording, replay |
| Post-incident attribution time | Hours to days, often inconclusive | Minutes; replay the recording |
| NERC CIP-007 R5.3 audit defensibility | TFE filing required, evidence thin | TFE filing supported by gateway session evidence |
| Vendor offboarding effort | Rotate shared credential and notify everyone | Revoke per-vendor access at gateway, no shared rotation |
The data points behind the table are reproducible. AltaGas attests audit-prep time fell from six months to three weeks after moving to gateway-mediated access. The protocol-isolation property is verifiable in a Wireshark packet capture: industrial protocol frames terminate at Purdue Level 3.5 and never traverse the user-side interface.
NERC CIP-007 R5.3 requires entities to identify each individual with access to shared accounts. For OT field assets that cannot hold per-user credentials natively, R5.3 contemplates a Technical Feasibility Exception (TFE) supported by compensating evidence. The audit question is not whether the asset itself authenticates each user. It is whether the entity can produce per-user attribution by other means.
Auditors typically request four evidence fields: per-user identity tied to the session, session scope (which asset, which actions allowed), timestamps spanning session start through session end, and a session recording or equivalent activity log. When those fields exist and are producible on request, the compensating-control argument becomes defensible.
Xona produces that evidence at the access path rather than at the asset. Each session is authenticated against the entity's identity provider, scoped to a specific asset and task, time-bound, and recorded. The shared HMI account on the asset side stays operationally intact. The per-user attribution lives at the gateway. That is the structure auditors evaluate when they assess R5.3 compensating controls for assets that cannot natively meet R5.3 on their own.
How Xona addresses this
Xona's value here is not just that it restricts access. It helps organizations operationalize safer access through controlled, monitored, and time-bound sessions, replayable session records for investigations, and stronger evidence for audits.
That balance matters. Controls that are too loose create risk. Controls that are too brittle get bypassed. Xona is strongest where organizations need both stronger governance and a remote access model that works in real operating conditions.
The shared-credential forensics nightmare. Picture a control room where five operators share a single HMI account on a critical pump-station console. An incident occurs at 02:14 on a Saturday. A setpoint was changed; a downstream alarm fired; the line went into a controlled shutdown. The post-incident review starts on Monday morning. The network-layer logs show the HMI was reached through the site VPN. The application log shows the operator account in use. The Active Directory log shows three of the five operators were logged into the corporate domain at the time. None of those three logs answers the question that matters: which person executed the change. Forensic attribution becomes a recollection exercise, supplemented by phone records, badge swipes, and shift hand-off notes.
Per-user authorization at the gateway plus session recording turns that nightmare into a 5-minute replay. The session record shows which verified user authenticated, which asset they were scoped to, which keystrokes they sent, and the screen state at the moment of the change. Attribution is no longer reconstructed from circumstantial evidence. It is read from the session recording. The shared HMI account on the asset side stays operationally intact, and the accountability moves up to the access path where it belongs.
e activity rather than govern access directly. Detection tools can help identify suspicious behavior. They do not determine whether the session should exist in the first place, how narrowly it should be scoped, or what controls should apply throughout the connection.
Most OT buyers know their vertical before they know their primary compliance framework. The decision tree below routes a vertical to the framework that owns the relevant identity, session, and audit controls. Use it to find the right entry point into the framework table that follows.
This mapping is a starting point, not a regulatory determination. Consult your registered entity, regulator, or compliance team for framework applicability to your specific assets, asset class, and jurisdiction.
Architects building secure remote access RFPs for OT and ICS evaluate four broad approaches. The comparison below anchors each approach against the criteria that matter most when the asset side is a Purdue Level 1-3 industrial environment rather than an IT data center.
| Approach | Deployment | OT-protocol Path | Audit Evidence | Suitability for OT |
| IT-PAM with VPN | IT-PAM agents plus VPN concentrators; integration with directory and ticketing typically takes weeks | VPN tunnel terminates inside OT zone, so industrial protocol frames such as Modbus TCP, DNP3, and OPC UA traverse the user-side network on the way to the asset | Privileged credential vaulting and session recordings for managed sessions; coverage gaps for non-PAM-managed remote paths | Strong fit for IT privilege governance; less aligned to OT protocol containment, which is the property reproducible in a Wireshark capture for protocol-terminating gateways |
| VDI-in-zone | VDI farm provisioned inside the OT zone; user reaches a virtual desktop that already lives next to the asset | Industrial protocols stay zone-internal between VDI host and asset; user-to-VDI traffic is display-protocol only | Display-protocol session capture is supported by most VDI platforms; per-asset attribution depends on what the inside-zone account model is | Operationally heavy: VDI farm cost, OS patch cadence, and licensing; protocol containment depends on disciplined zone hygiene |
| Protocol-terminating gateway (Xona) | Browser-based gateway, no client install, deployment time engineered for plant tempo at 20 minutes per site | OT protocol terminates at Purdue Level 3.5; industrial frames never traverse the user-side interface, a property reproducible in a Wireshark packet capture | Per-user authentication, session scope, timestamps, and replayable session recording produced at the access path | Aligned to OT protocol containment, vendor governance, and NERC CIP-007 R5.3 compensating-control structure; AltaGas customer-attestation: audit prep dropped from six months to three weeks |
| Jump-server bastion | Hardened jump host inside the OT DMZ; typically combined with VPN access for the user-to-jump path | Industrial protocols traverse the jump host into the asset; the bastion is typically multi-user with shared OS-level accounts | OS audit logs and SSH session captures where configured; shared bastion accounts complicate per-user attribution | Familiar legacy pattern; the shared-account audit surface is the same one R5.3 contemplates, which is why TFE filings and compensating evidence are common |
The category labels in the rows above match Gartner's Cyber-Physical Systems Secure Remote Access (CPS SRA) Market Guide, which is the industry-recognized taxonomy buyers use when scoping vendors. Session evidence typically supports the audit-prep compression named in the AltaGas attestation, and operationally typically requires the protocol containment named in the Wireshark POC. Both claims are reproducible against published artifacts rather than vendor narrative.
How this fits into the broader architecture
Xona fits in as a control layer between identity, policy, and the critical systems being accessed. It complements identity providers and MFA by enforcing access decisions at the point of connection, and it complements SIEM and compliance tooling by generating session-level evidence for review and reporting.
That makes it easier to connect identity governance with operational access control. Instead of treating OT access as an exception, organizations can bring it into a more consistent model that supports Zero Trust principles, audit readiness, and safer day-to-day operations.
A Technical Feasibility Exception (TFE) is the regulatory exception path NERC CIP entities use when a registered cyber asset cannot meet a CIP requirement through native means. Shared-account assets such as legacy HMIs, jump-host bastion accounts, and vendor service accounts are common TFE candidates because the asset itself cannot bind activity to an individual identity.
Auditors evaluating a TFE typically look for the same four evidence fields named in the R5.3 discussion above: per-user identity, session scope, timestamps, and a session recording. The TFE filing names the technical limitation; the compensating-control evidence proves that entity-level attribution is preserved despite the limitation. When those evidence fields are routinely produced at the access path, the TFE filing rests on something durable rather than something narrative.
Xona's role in the TFE structure is to produce that evidence at the session level: identity at authentication, scope at policy, timestamps across session lifecycle, and a replayable record from start to finish. The gateway is not the regulator and Xona does not certify TFE acceptability. Consult your registered entity or regulator on TFE acceptability for your specific assets.