Our organization recently completed a 14-month migration from Thycotic (now Delinea) Secret Server to the BeyondTrust Password Safe platform, a move driven by a broader strategic consolidation under the BeyondTrust Privileged Access Management suite. While the long-term architectural alignment is sound, the transition process revealed significant operational and philosophical differences that were not apparent during the sales cycle. This post details the key friction points we encountered, which I would categorize as less about raw functionality and more about workflow, administrative overhead, and hidden cost drivers.
The primary learning is that BeyondTrust approaches privilege management with a more rigid, security-process-centric model compared to Thycotic's somewhat more developer-friendly and agile approach. This manifests in several critical areas:
* **The API and Automation Paradigm:** Thycotic's API is broadly RESTful and allows for extensive manipulation of secrets and configurations. BeyondTrust's API, while powerful, is more granular and requires a deeper understanding of its object model (e.g., Managed Systems, Accounts, Credentials). Scripts that automated secret rotation or deployment in Thycotic required a near-complete rewrite. The assumption that "PAM is PAM" from an automation standpoint is false.
* **Secret Templates vs. Password Rules:** Thycotic's secret template system allowed for highly customized fields and behaviors per secret type. BeyondTrust utilizes a global set of "Password Rules" and "Password Complexity" policies applied more broadly. We found the lack of per-secret-type granularity for complexity rules to be a regression, forcing us to standardize on a higher common denominator, which conflicted with legacy service account requirements.
* **Session Management and Just-In-Time Access:** This was a net positive but came with a cost. Integrating BeyondTrust's telemetry and policy engine for just-in-time elevation and session recording required significantly more upfront policy configuration than anticipated. The migration was not merely a data lift-and-shift; it was a re-implementation of access workflows. Project plans that allocated time for data migration but not for policy redesign were immediately off track.
* **Licensing and Cost Structure Scrutiny:** Be extremely precise in mapping your Thycotic license count and features to the BeyondTrust model. BeyondTrust's bundling of modules (Password Safe, Remote Support, Identity & Access Insights) can be advantageous, but the user/account/concurrent session definitions differ. We discovered that our legacy Thycotic usage of "heartbeat" accounts for monitoring tools suddenly consumed named user licenses in BeyondTrust's initial proposal. Negotiating the contract required a detailed audit of our actual credential types and access patterns to avoid 30%+ cost overruns.
From a procurement and vendor evaluation perspective, the key lesson is that migrations between established PAM platforms are integration projects, not simple data transfers. Our post-mortem identified the following critical to-dos for anyone considering a similar move:
* Conduct a full inventory of all automated processes, scripts, and integrations touching the legacy PAM *before* signing the new contract.
* Build a detailed mapping document that goes beyond field names (e.g., "username") to encompass behavioral parity (e.g., "auto-change behavior on checkout," "dependent secret linking").
* Insist on a paid, full-scale proof-of-concept using a representative sample of your most complex secret types and use cases, not just a sales demonstration. The POC must include your team executing your own automation via the API.
* Negotiate explicit contractual commitments for professional services support during the migration, with deliverables tied to the completion of specific migration milestones (e.g., "100% of automated rotation scripts operational").
The outcome is stable, and the platform is robust, but the path was far more resource-intensive than the initial business case projected. The core question for any team contemplating this shift is whether the benefits of suite consolidation and BeyondTrust's specific security model outweigh the significant transition costs and process re-engineering. In our case, the driver was enterprise-wide standardization, but for an organization focused solely on credential management, the value proposition requires much more careful analysis.
I'm a platform engineer at a mid-sized fintech that runs about 400 microservices on EKS, and I manage our PAM tooling for both human and machine secrets. We've been running BeyondTrust Password Safe in production for three years after evaluating Thycotic among others.
1. **API and Automation Overhead:** Thycotic's REST API treats a secret as a single manageable object. BeyondTrust's model requires you to orchestrate Managed Systems, Accounts, and then Credentials. A simple script to rotate 100 secrets went from ~50 lines with Thycotic's API to over 200 lines for BeyondTrust, as you have to fetch the system and account IDs first.
2. **Real Cost Driver - Connectors:** Thycotic's pricing felt more all-in for our scale. With BeyondTrust, the base license is just the start. Each "connector" for a different target type (e.g., a custom SSH box, a legacy database) can be a separate cost item. Our initial quote ballooned by about 30% once we mapped all our system types.
3. **Deployment and Configuration Rigidity:** BeyondTrust's security model is stricter, which is good for compliance but slows iteration. In Thycotic, we could delegate secret ownership to a dev team lead quickly. In BeyondTrust, that requires configuring a specific "Role" with exact permissions scoped to a "Managed System" group, which often meant a support ticket to get right. The initial policy setup took us 6 weeks versus the 2 we'd estimated.
4. **Where BeyondTrust Clearly Wins - Session Management:** If you need full remote session proxying/recording for compliance (like SOC2 or PCI), BeyondTrust is far ahead. Their integration between Password Safe and Privileged Remote Access is solid. Thycotic's session management felt like a bolted-on feature; in our tests, the BeyondTrust gateway held stable connections for 50+ concurrent RDP sessions where Thycotic choked at about 20.
I'd recommend BeyondTrust if your primary driver is rigid compliance and auditing for human access, especially with session recording. I'd recommend staying with Thycotic/Delinea if your use case is heavily skewed toward API-driven automation for DevOps and CI/CD pipelines. To make a clean call, tell us what percentage of your secret access is machine-vs-human and whether you have a hard compliance requirement for session recording.
Cloud cost nerd. No, I don't use Reserved Instances.
You're absolutely right about the API paradigm shift. We hit the same wall during our POC. That granular object model, while maybe more "correct" from a pure security data modeling perspective, creates massive friction for any real-world automation pipeline.
We wrote a whole internal adapter library just to map our existing Thycotic-centric scripts to the BeyondTrust system-account-credential hierarchy. The hidden time sink wasn't the migration itself, but rewriting all our CI/CD integrations and Terraform modules. It added about three months to our timeline.
Have you found their newer GraphQL API any better for these complex orchestration tasks, or is it the same model with a different query syntax?
security by default
Yep. That "process-centric model" is really just a euphemism for making simple scripts a three-act play. I've seen teams write more code for the PAM integration than the app it's securing.
The hidden cost isn't in the licenses, it's in the developer hours spent wrestling that granular object model. You trade agility for audit trails, which the security team loves right up until dev velocity tanks.
GraphQL just gives you a fancier way to fetch the same overly complicated schema, by the way. It's the same play, different costume.
Deploy with love