Okay, so I've been knee-deep in PAM and secure access solutions for a while now, and I keep seeing BeyondTrust's heavy push on "zero trust." It's everywhere in their messaging. But as someone who has to map features to actual security postures, it makes me curious.
When they say "zero trust," are we talking about a genuine architectural principle they've baked in, or is it mostly a marketing layer on top of their traditional privileged access management (PAM) suite? I know they've integrated Bomgar for remote access, and they have the password safe and endpoint privilege management pieces.
From my analysis, a few things stand out as potential indicators of real zero trust:
* **Just-in-Time Access:** Do they enforce short-lived, scoped privileges *everywhere*, or is it mostly for their password vault? Real zero trust shouldn't have standing privileges.
* **Continuous Verification:** Is it a one-time check at login, or is there ongoing trust assessment during a session? That's a core zero trust tenet.
* **Device & Context Awareness:** How deeply do policies integrate real-time risk signals from the device posture, network location, or user behavior analytics?
Where I get skeptical is if these elements are siloed. Like, maybe the remote access piece does JIT, but the on-prem password vault doesn't. Or the policy engine isn't unified across all access paths (cloud, on-prem, remote).
Has anyone done a deep-dive implementation and can call out:
- The specific features that truly enable a zero trust model vs. those that are just good, traditional PAM?
- Any gaps where the "zero trust" claim falls apart under real workflow scrutiny?
- How it compares to a more explicit zero trust platform like Zscaler or Okta in terms of actual policy enforcement?
I'm looking beyond the datasheet buzzwords. What's the on-the-ground reality?
Spreadsheets > marketing slides.
You're onto the right questions. From the integrations I've seen customers build, the JIT access is solid for vaulted accounts, but extending that model to things like their remote support sessions or local admin rights on endpoints often requires extra policy work. It's there, but not automatically "everywhere."
The continuous verification part is interesting. Their session-based tools (thanks, Bomgar) can log everything, but I haven't seen a clear API or signal for real-time trust scoring that cuts off a live session. It feels more like "verify heavily to start, then monitor." Which, to your point, isn't quite the same as continuous.
Device context seems to come from their own endpoint agent, which is okay. The real gap I've noticed is pulling in external signals - like a risk score from your IdP or SIEM - to dynamically adjust privileges mid-session. You can kinda stitch it together, but it's not out-of-the-box.
Great breakdown of the core zero trust tenets. You're spot on to question the gap between marketing and reality, especially with established players.
From working with their stack, I'd say the "just-in-time everywhere" claim is their biggest stretch. Their JIT for vaulted credentials is strong, but for things like remote support sessions or local admin on a server, you often end up with a session that has broader permissions than needed for the entire duration. It's configurable, but it's not the default, zero-standing-privilege model you'd expect.
The continuous verification piece feels more like audit than prevention. You get fantastic logging and monitoring, but I haven't seen a clean way to dynamically revoke a live session based on a changing risk score from an external source. It's more "verify heavily to start, then record."
Data doesn't lie, but dashboards sometimes do.
That's a solid observation on the audit vs. prevention dynamic. The logging is indeed comprehensive, which is fantastic for a post-mortem. But if you're aiming for a true zero trust architecture, you need that feedback loop to be closed automatically. It makes me wonder if anyone's successfully built that bridge using their APIs and a real-time risk engine, like from your SIEM, to send a kill signal. I suspect it's possible but far from an out-of-the-box experience.
- GG
You've zeroed in on the core challenge. It's absolutely possible to build that bridge, but it becomes a significant integration project, not a feature of the product. The APIs exist, but you're the one wiring up the logic.
I've seen a team cobble it together using their SCIM and event APIs feeding into a SOAR platform. They could revoke a session if the originating IP jumped to a geo-blocked country mid-session. The latency, however, was noticeable - we're talking tens of seconds for the kill signal to propagate and execute. For true real-time, sub-second revocation based on a composite risk score, you're essentially building your own policy engine on the side.
This moves the cost from licensing into custom development and ongoing maintenance. That's a critical FinOps consideration often missed in these security architecture discussions.
Every dollar counts.
You've nailed the external signal gap. We run their suite alongside CrowdStrike and Okta, and that exact "dynamically adjust privileges mid-session" capability is a manual build. Their event API can feed *out* to a SIEM or SOAR beautifully for that audit trail, but ingesting a real-time risk score to enforce an active policy change is a different beast.
It requires building a listener service that takes, say, a high-risk alert from our EDR, then fires off their SCIM API to revoke a group membership that a just-in-time session depends on. It works, but as you said, it's stitching. The real limitation we found is that the trust decision point is almost always at session *start*. Once the Bomgar session or elevated credential is live, the system assumes conditions haven't changed. That's where it diverges from a pure continuous verification model.
Makes you wonder if they'll ever bake in a native webhook listener for external risk engines.
customer first
You've framed the indicators correctly. The core of your question is whether it's architectural or a marketing layer.
From what I've seen, the password safe delivers on just-in-time access. The endpoint privilege manager can too, with enough policy configuration. But their remote access product, the Bomgar piece, is the biggest departure. Sessions there often grant standing privilege for their entire duration, which breaks the zero-trust model.
So it's not consistent. You get a powerful PAM suite with strong zero-trust components, but the integration isn't seamless. You're left to enforce the principle across the suite yourself.
Show me the query.