/

article

PAM for OT: Why “We Already Have It” Is the Most Expensive Sentence in Your Remote Access Budget

Ben Burke, President

Ben Burke, President

Aug 26, 2026

Aug 26, 2026

0 min read

min read

0 min read

min read

0 min read

min read

Article

Article

Key Takeaway: Extending enterprise PAM into OT plant floors usually means stacking a VPN, jump server, screen-sharing tool, and a parallel vendor-identity workflow around the PAM license you already pay for — costs and friction that never show up on the PAM renewal invoice but do show up in the OT budget. 

Every enterprise PAM vendor now says it covers OT. None of them changed what OT remote access actually needs: a workflow, not another identity system. 

I was on a panel recently with the security director at a Tier-1 automotive parts supplier: a dozen plants, and machine-builders plus contractors forced on-site most weeks. I asked how vendor remote access works today. 

“We’re covered,” he said. “We run an enterprise PAM platform company-wide. Vendors go through the same privileged access process as our own admins.” 

I asked how long that takes for a new vendor. He paused. “Onboarding into the vault, provisioning the account, getting the access request approved: call it two to three weeks, if nothing gets stuck in a queue.” 

“And once they’re in the vault,” I asked, “how do they actually reach the machine on the floor?” 

That’s where it got longer. VPN concentrator to get onto the network. A jump host to actually touch the HMI. A separate screen-sharing tool for the OEM’s support engineers, because the jump host didn’t support their software. “We already have PAM” turned out to mean PAM, plus four other things holding the rest of the path together. 

That conversation happens constantly, and it’s not because anyone’s doing anything wrong. It’s because the tool they already own was never the whole answer. It was one piece of a chain nobody designed end-to-end. 

Why “We Already Have It” Is the Natural Answer 

It’s a reasonable instinct. The tool’s already bought, already integrated with your identity provider, already has an owner and a budget line. Asking for something new means a fresh procurement cycle, a security review, and an uncomfortable question from finance: didn’t we already solve this? 

Here’s the problem: the PAM license was never the expensive part. What it costs to actually reach OT is. Extending PAM into the plant almost always means stacking a VPN, a jump server or two, a screen-sharing tool for vendor support, a file-transfer tool, and a parallel identity workflow for every contractor who isn’t already in your corporate directory, on top of the PAM you’re already paying for. Count it up and “we already have PAM” quietly becomes five or six systems, each with its own license, its own patching, its own person who has to know how it works. None of that shows up on the PAM renewal invoice. All of it shows up in your OT budget, your IT team’s ticket queue, and the three weeks a vendor waits before they can start a job. 

What “Extending PAM into OT” Actually Looks Like Across the Market 

This isn’t a knock on any of these products, they’re strong at what they were built for. It’s worth naming what “extending” actually means for each, because the pattern is similar three times over. 

  • BeyondTrust markets Privileged Remote Access as “purpose-built to secure OT environments,” with real investment behind it: Purdue Model alignment, protocol tunneling, case studies with industrial customers. But look at how it’s packaged: Privileged Remote Access sits inside BeyondTrust’s Pathfinder Platform alongside Password Safe (credential vaulting and rotation) and Endpoint Privilege Management, “united... under a single login.” It’s an OT access module riding on top of an enterprise identity suite, not an architecture-built OT-first SRA. 

  • CyberArk (acquired by Palo Alto Networks and relaunched in May 2026 as Idira, “built on CyberArk’s legacy”) extends privilege into OT through partner integrations, plus its own Vendor Privileged Access module. But identity and OT security are still two different product lines even under one parent company: Palo Alto’s Industrial OT Security offering predates the acquisition entirely, and Idira’s own FAQ says customers will gain cross-platform capabilities across the portfolio “over time,” not today. 

  • Zscaler routes privileged OT sessions through its global Zero Trust Exchange: clientless, browser-based, and explicitly marketed as an alternative to VDI. That’s a fine model for a quick RDP session. It’s the same ceiling we’ve written about before with browser-only access: fine until the job needs a full engineering workstation, a proprietary tool, or a device a browser session can’t reach. Different label, same limitation. 

Three different companies, three different architectures, and the same shape every time: an identity-first platform built for IT, with OT bolted on at the edge.  

The Industry’s Own Naming Gives It Away  

Watch the language the whole category uses. IT PAM extending outward calls itself “privileged remote access.” Cyolo, which builds OT-native access rather than extending an IT tool, still coined “secure remote privileged access” as its own category name. RPAM, PRA, SRPA: pick a vendor, and the name orbits the same word, privileged. The February 2026 Gartner® Market Guide for CPS Secure Remote Access makes the sharper point: it groups IT remote privileged access management products alongside VPNs and jump boxes as approaches that “lack the granularity and contextual knowledge needed for production or mission-critical environments,” and tells buyers not to extend IT-centric PAM into CPS without real validation first. That’s not a competitor’s marketing page saying that. That’s Gartner, telling its own clients the same thing (worth disclosing plainly: Dispel is also named a Representative Vendor in that same report, alongside everyone discussed here, so take the citation for what it is, not a trophy). 

Here’s what’s missing from every one of those names: operations. Workflow. Not one asks what an OT team actually asks every day: how fast can this vendor start, who signs off, what happens the moment a session looks wrong, does the line keep running. The whole category is still organized around who holds a credential, an identity question, not the question a plant manager is asking at 6am when a contractor is standing at the gate. That’s the reframe worth sitting with: OT secure access isn’t an identity problem. It’s a workflow problem: onboarding, approval, execution, and oversight, in that order, on a clock that matters. 

PAM Checks a Credential. Identity Verifies a Person. Neither Gets Anyone to the Machine. 

While we’re on the subject, it’s worth being precise about identity too, since we just shipped a real capability here and don’t want the argument to blur. In August we launched Dispel Identity: government ID verification and biometric matching, to the NIST IAL2 standard, confirming the account connecting is tied to a real, verified person, not just a credential someone happened to be holding. That gap was real everywhere, including in our own platform until Identity shipped, since every OT remote access tool verifies a credential and trusts whoever presents it. As AI makes it cheaper to fake the person behind an account, that gap only gets more dangerous. 

There’s a precise way to say what this does and doesn’t solve. AAL is authentication strength: was the right credential used. IAL is who the person actually is. PAM vaults, checks out, and rotates privileged credentials, and confirms the right one was used. PAM (and Dispel’s own Session Forensics) handles AAL; Dispel Identity adds IAL. Neither gets anyone to the device: a verified person still isn’t onboarded as a vendor, routed to a facility approver, or brokered to Line 3’s PLC. That’s why Identity sits inside the Dispel Zero Trust Engine as one layer among several, not a replacement for any: authenticate the credential (AAL), verify the person (IAL), broker them to the right asset (Secure Remote Access, the subject of this piece), score what the session does while it’s live (Intelligence). Four jobs, and PAM, wherever it comes from, was only ever built to do the first.  

What a Workflow-First Approach Changes 

This is where the Dispel Zero Trust Engine starts from a different place than any of the above: not identity first, workflow first: 

  • Hybrid domain support. A vendor arrives with their own SSO, their tenant, your corporate Entra ID, a local AD, whatever the plant already runs, instead of being provisioned into your identity system from scratch. 

  • Vendor self-onboarding. What took that automotive supplier two to three weeks through a vault-and-approval queue collapses to a self-service request that a facility owner approves in minutes, not an IT ticket that waits its turn. 

  • A risk score at the moment of approval, not after the fact. A combined, stoplight-simple signal, not a wall of log data to interpret after something’s already gone wrong. 

  • A shared-account model with individual attribution. Plants that run shared operator logins for good operational reasons don’t lose the audit trail: every action still traces to the person who took it. 

None of this replaces your PAM investment. It sits alongside it: PAM keeps governing enterprise IT credentials; the workflow layer governs how work actually gets done on the floor. 

The Question I'd Ask Before You Extend 

If you already have PAM, that's not the wrong call. PAM answers a real question. The problem is it's answering a different question than the one your plant is asking. 

"Who's allowed to hold this credential" and "how fast can this vendor safely start the job" are not the same problem. Stretching one tool to answer both is how a platform you already paid for ends up costing more than the one you didn't buy. Using an IT tool for an OT problem creates friction. That's the whole story, whether the tool is Idira, BeyondTrust, Zscaler, or the one you're already renewing this year. 

The right tool for OT access doesn't just solve the security problem. It reduces the budget for the four tools you stacked around PAM to make it reach the plant floor. It cuts the travel time your engineers and vendors are logging because remote access actually works the way operations needs it to. It eliminates the maintenance overhead of keeping a stitched-together stack current, patched, and compliant. And it removes the recurring cost of the workarounds your team has quietly built around the tools that were never quite right for the job. 

Before you extend what you have, add up what it would take to reach OT without the extra tools, the travel, and the maintenance. It's a cheaper question to ask than to avoid. 

CPS Secure Remote Access is rated High-Benefit in the new Gartner® Hype Cycle™ for CPS Security, 2026. Read the Report 

Frequently Asked Questions 

What is PAM for OT, and how is it different from IT PAM? 

PAM (Privileged Access Management) was built to govern credentials for IT systems: servers, databases, SaaS. Extending it into OT means bridging that identity-first architecture out to the plant floor, typically through jump hosts, VPNs, or partner integrations, since OT access is less about who holds a credential and more about onboarding, approval, and execution on operational timelines. 

Can I use my existing PAM tool (like CyberArk/Idira or BeyondTrust) for OT remote access? 

You can extend most enterprise PAM platforms toward OT, and vendors including BeyondTrust, CyberArk (now Idira, under Palo Alto Networks), and Zscaler all market ways to do it. In practice this usually adds a VPN, jump server, screen-sharing tool, and a parallel vendor-identity workflow around the PAM license you already have, which is where the hidden cost shows up. 

What is secure remote privileged access (SRPA)? 

SRPA is newer vendor language, used by OT-focused access vendors like Cyolo, for governing privileged sessions into operational technology. Whether it's called PAM, RPAM, PRA, or SRPA, the naming still centers on identity and privilege rather than the onboarding, approval, and execution workflow an OT team actually runs. 

Is OT secure remote access (SRA) different from PAM? 

Yes. PAM governs who holds a privileged credential. OT SRA governs how work actually happens on the plant floor: vendor self-onboarding, facility-level approval, session oversight, and execution, without requiring every vendor to be provisioned into a corporate identity system first. 

Does verifying identity replace the need for OT secure remote access? 

No. Identity verification (like Dispel Identity) confirms that a real, verified person is behind an account; it answers who. It doesn't onboard a vendor, route an approval, broker a session to a specific device, or provide oversight while the work happens. That's still the job of OT secure remote access. 

Ready to Simplify OT Secure Remote Access?

See how Dispel helps industrial teams standardize connectivity and protect critical environments—without added complexity.

Key Takeaway: Extending enterprise PAM into OT plant floors usually means stacking a VPN, jump server, screen-sharing tool, and a parallel vendor-identity workflow around the PAM license you already pay for — costs and friction that never show up on the PAM renewal invoice but do show up in the OT budget. 

Every enterprise PAM vendor now says it covers OT. None of them changed what OT remote access actually needs: a workflow, not another identity system. 

I was on a panel recently with the security director at a Tier-1 automotive parts supplier: a dozen plants, and machine-builders plus contractors forced on-site most weeks. I asked how vendor remote access works today. 

“We’re covered,” he said. “We run an enterprise PAM platform company-wide. Vendors go through the same privileged access process as our own admins.” 

I asked how long that takes for a new vendor. He paused. “Onboarding into the vault, provisioning the account, getting the access request approved: call it two to three weeks, if nothing gets stuck in a queue.” 

“And once they’re in the vault,” I asked, “how do they actually reach the machine on the floor?” 

That’s where it got longer. VPN concentrator to get onto the network. A jump host to actually touch the HMI. A separate screen-sharing tool for the OEM’s support engineers, because the jump host didn’t support their software. “We already have PAM” turned out to mean PAM, plus four other things holding the rest of the path together. 

That conversation happens constantly, and it’s not because anyone’s doing anything wrong. It’s because the tool they already own was never the whole answer. It was one piece of a chain nobody designed end-to-end. 

Why “We Already Have It” Is the Natural Answer 

It’s a reasonable instinct. The tool’s already bought, already integrated with your identity provider, already has an owner and a budget line. Asking for something new means a fresh procurement cycle, a security review, and an uncomfortable question from finance: didn’t we already solve this? 

Here’s the problem: the PAM license was never the expensive part. What it costs to actually reach OT is. Extending PAM into the plant almost always means stacking a VPN, a jump server or two, a screen-sharing tool for vendor support, a file-transfer tool, and a parallel identity workflow for every contractor who isn’t already in your corporate directory, on top of the PAM you’re already paying for. Count it up and “we already have PAM” quietly becomes five or six systems, each with its own license, its own patching, its own person who has to know how it works. None of that shows up on the PAM renewal invoice. All of it shows up in your OT budget, your IT team’s ticket queue, and the three weeks a vendor waits before they can start a job. 

What “Extending PAM into OT” Actually Looks Like Across the Market 

This isn’t a knock on any of these products, they’re strong at what they were built for. It’s worth naming what “extending” actually means for each, because the pattern is similar three times over. 

  • BeyondTrust markets Privileged Remote Access as “purpose-built to secure OT environments,” with real investment behind it: Purdue Model alignment, protocol tunneling, case studies with industrial customers. But look at how it’s packaged: Privileged Remote Access sits inside BeyondTrust’s Pathfinder Platform alongside Password Safe (credential vaulting and rotation) and Endpoint Privilege Management, “united... under a single login.” It’s an OT access module riding on top of an enterprise identity suite, not an architecture-built OT-first SRA. 

  • CyberArk (acquired by Palo Alto Networks and relaunched in May 2026 as Idira, “built on CyberArk’s legacy”) extends privilege into OT through partner integrations, plus its own Vendor Privileged Access module. But identity and OT security are still two different product lines even under one parent company: Palo Alto’s Industrial OT Security offering predates the acquisition entirely, and Idira’s own FAQ says customers will gain cross-platform capabilities across the portfolio “over time,” not today. 

  • Zscaler routes privileged OT sessions through its global Zero Trust Exchange: clientless, browser-based, and explicitly marketed as an alternative to VDI. That’s a fine model for a quick RDP session. It’s the same ceiling we’ve written about before with browser-only access: fine until the job needs a full engineering workstation, a proprietary tool, or a device a browser session can’t reach. Different label, same limitation. 

Three different companies, three different architectures, and the same shape every time: an identity-first platform built for IT, with OT bolted on at the edge.  

The Industry’s Own Naming Gives It Away  

Watch the language the whole category uses. IT PAM extending outward calls itself “privileged remote access.” Cyolo, which builds OT-native access rather than extending an IT tool, still coined “secure remote privileged access” as its own category name. RPAM, PRA, SRPA: pick a vendor, and the name orbits the same word, privileged. The February 2026 Gartner® Market Guide for CPS Secure Remote Access makes the sharper point: it groups IT remote privileged access management products alongside VPNs and jump boxes as approaches that “lack the granularity and contextual knowledge needed for production or mission-critical environments,” and tells buyers not to extend IT-centric PAM into CPS without real validation first. That’s not a competitor’s marketing page saying that. That’s Gartner, telling its own clients the same thing (worth disclosing plainly: Dispel is also named a Representative Vendor in that same report, alongside everyone discussed here, so take the citation for what it is, not a trophy). 

Here’s what’s missing from every one of those names: operations. Workflow. Not one asks what an OT team actually asks every day: how fast can this vendor start, who signs off, what happens the moment a session looks wrong, does the line keep running. The whole category is still organized around who holds a credential, an identity question, not the question a plant manager is asking at 6am when a contractor is standing at the gate. That’s the reframe worth sitting with: OT secure access isn’t an identity problem. It’s a workflow problem: onboarding, approval, execution, and oversight, in that order, on a clock that matters. 

PAM Checks a Credential. Identity Verifies a Person. Neither Gets Anyone to the Machine. 

While we’re on the subject, it’s worth being precise about identity too, since we just shipped a real capability here and don’t want the argument to blur. In August we launched Dispel Identity: government ID verification and biometric matching, to the NIST IAL2 standard, confirming the account connecting is tied to a real, verified person, not just a credential someone happened to be holding. That gap was real everywhere, including in our own platform until Identity shipped, since every OT remote access tool verifies a credential and trusts whoever presents it. As AI makes it cheaper to fake the person behind an account, that gap only gets more dangerous. 

There’s a precise way to say what this does and doesn’t solve. AAL is authentication strength: was the right credential used. IAL is who the person actually is. PAM vaults, checks out, and rotates privileged credentials, and confirms the right one was used. PAM (and Dispel’s own Session Forensics) handles AAL; Dispel Identity adds IAL. Neither gets anyone to the device: a verified person still isn’t onboarded as a vendor, routed to a facility approver, or brokered to Line 3’s PLC. That’s why Identity sits inside the Dispel Zero Trust Engine as one layer among several, not a replacement for any: authenticate the credential (AAL), verify the person (IAL), broker them to the right asset (Secure Remote Access, the subject of this piece), score what the session does while it’s live (Intelligence). Four jobs, and PAM, wherever it comes from, was only ever built to do the first.  

What a Workflow-First Approach Changes 

This is where the Dispel Zero Trust Engine starts from a different place than any of the above: not identity first, workflow first: 

  • Hybrid domain support. A vendor arrives with their own SSO, their tenant, your corporate Entra ID, a local AD, whatever the plant already runs, instead of being provisioned into your identity system from scratch. 

  • Vendor self-onboarding. What took that automotive supplier two to three weeks through a vault-and-approval queue collapses to a self-service request that a facility owner approves in minutes, not an IT ticket that waits its turn. 

  • A risk score at the moment of approval, not after the fact. A combined, stoplight-simple signal, not a wall of log data to interpret after something’s already gone wrong. 

  • A shared-account model with individual attribution. Plants that run shared operator logins for good operational reasons don’t lose the audit trail: every action still traces to the person who took it. 

None of this replaces your PAM investment. It sits alongside it: PAM keeps governing enterprise IT credentials; the workflow layer governs how work actually gets done on the floor. 

The Question I'd Ask Before You Extend 

If you already have PAM, that's not the wrong call. PAM answers a real question. The problem is it's answering a different question than the one your plant is asking. 

"Who's allowed to hold this credential" and "how fast can this vendor safely start the job" are not the same problem. Stretching one tool to answer both is how a platform you already paid for ends up costing more than the one you didn't buy. Using an IT tool for an OT problem creates friction. That's the whole story, whether the tool is Idira, BeyondTrust, Zscaler, or the one you're already renewing this year. 

The right tool for OT access doesn't just solve the security problem. It reduces the budget for the four tools you stacked around PAM to make it reach the plant floor. It cuts the travel time your engineers and vendors are logging because remote access actually works the way operations needs it to. It eliminates the maintenance overhead of keeping a stitched-together stack current, patched, and compliant. And it removes the recurring cost of the workarounds your team has quietly built around the tools that were never quite right for the job. 

Before you extend what you have, add up what it would take to reach OT without the extra tools, the travel, and the maintenance. It's a cheaper question to ask than to avoid. 

CPS Secure Remote Access is rated High-Benefit in the new Gartner® Hype Cycle™ for CPS Security, 2026. Read the Report 

Frequently Asked Questions 

What is PAM for OT, and how is it different from IT PAM? 

PAM (Privileged Access Management) was built to govern credentials for IT systems: servers, databases, SaaS. Extending it into OT means bridging that identity-first architecture out to the plant floor, typically through jump hosts, VPNs, or partner integrations, since OT access is less about who holds a credential and more about onboarding, approval, and execution on operational timelines. 

Can I use my existing PAM tool (like CyberArk/Idira or BeyondTrust) for OT remote access? 

You can extend most enterprise PAM platforms toward OT, and vendors including BeyondTrust, CyberArk (now Idira, under Palo Alto Networks), and Zscaler all market ways to do it. In practice this usually adds a VPN, jump server, screen-sharing tool, and a parallel vendor-identity workflow around the PAM license you already have, which is where the hidden cost shows up. 

What is secure remote privileged access (SRPA)? 

SRPA is newer vendor language, used by OT-focused access vendors like Cyolo, for governing privileged sessions into operational technology. Whether it's called PAM, RPAM, PRA, or SRPA, the naming still centers on identity and privilege rather than the onboarding, approval, and execution workflow an OT team actually runs. 

Is OT secure remote access (SRA) different from PAM? 

Yes. PAM governs who holds a privileged credential. OT SRA governs how work actually happens on the plant floor: vendor self-onboarding, facility-level approval, session oversight, and execution, without requiring every vendor to be provisioned into a corporate identity system first. 

Does verifying identity replace the need for OT secure remote access? 

No. Identity verification (like Dispel Identity) confirms that a real, verified person is behind an account; it answers who. It doesn't onboard a vendor, route an approval, broker a session to a specific device, or provide oversight while the work happens. That's still the job of OT secure remote access. 

Ready to Simplify OT Secure Remote Access?

See how Dispel helps industrial teams standardize connectivity and protect critical environments—without added complexity.