Having recently completed a 14-month migration from CyberArk Privileged Access Manager to Delinea (formerly Thycotic) Secret Server for our Kubernetes-based infrastructure, I feel compelled to share a structured, data-driven comparison. This decision was not taken lightly; it followed an exhaustive internal evaluation driven by escalating costs and operational friction with CyberArk in a dynamic, cloud-native environment. The core question I aim to address is: which solution is objectively "better"? The answer, as with most architectural decisions, is heavily contingent on specific workload profiles and organizational maturity. Below, I will detail our findings across several critical dimensions.
Our primary pain points with CyberArk in a Kubernetes context were:
* **Agent Overhead & Latency:** The CyberArk Privilege Cloud Connector (CPCC) and associated sidecar patterns introduced non-trivial latency in secret retrieval. In a performance-sensitive, high-throughput batch processing environment, this became a bottleneck.
* **Operational Complexity for Ephemeral Workloads:** The traditional "account" model felt incongruent with the service account and pod identity patterns native to K8s. Managing secure injection for thousands of ephemeral pods per hour was cumbersome, requiring extensive custom scripting.
* **Cost Model Misalignment:** CyberArk's licensing, based on a count of privileged accounts, became prohibitively expensive as we scaled our microservices architecture, where each service deployment might require multiple unique secrets.
Our quantitative benchmarking compared secret retrieval latency—the most critical path for application startup and runtime performance. We measured the time from application request to secret availability in memory, averaging over 10,000 requests per test scenario.
**Test Configuration:**
* Kubernetes Cluster: AWS EKS, 3x `c5.2xlarge` nodes.
* CyberArk Setup: CPCC deployed as a DaemonSet, Conjur integration for REST API calls.
* Delinea Setup: Secret Server deployed in HA mode, Delinea DevOps Secrets API with native Kubernetes Authenticator.
* Measured: Cold start (no cache) and warm cache retrieval for a 2KB secret.
**Results (Mean Latency, 95th percentile in parentheses):**
| Scenario | CyberArk (Conjur) | Delinea (Secrets API) |
| :--- | :--- | :--- |
| Cold Retrieval | 412 ms (780 ms) | 187 ms (320 ms) |
| Warm Retrieval (cached) | 85 ms (142 ms) | 22 ms (45 ms) |
The latency differential, particularly at the 95th percentile, was significant for our workloads. Delinea's simpler, REST-first architecture and efficient caching mechanisms provided a clear performance advantage. Furthermore, the integration paradigm shifted:
* **CyberArk Integration (Our Implementation):**
```yaml
# Example of our convoluted initContainer pattern for Conjur
initContainers:
- name: cyberark-fetcher
image: our-custom-fetcher:1.2
env:
- name: CONJUR_AUTHN_URL
value: "https://cyberark.example.com"
# ... 15+ env vars for auth & secret identifiers
command: ['sh', '-c', 'fetch-secret && write-to-volume']
containers:
- name: app
image: app:latest
volumeMounts:
- name: secrets-vol
mountPath: /opt/secrets
```
* **Delinea Integration (Current Implementation):**
```yaml
# Using Delinea Kubernetes Authenticator & CSI Driver
apiVersion: secrets.delinea.com/v1beta1
kind: SecretDefinition
metadata:
name: app-db-creds
spec:
path: "data/teams/myapp/prod/db"
---
# Pod simply references the defined secret via CSI
volumes:
- name: secrets-store
csi:
driver: secrets-store.delinea.csi.k8s.io
readOnly: true
volumeAttributes:
secretDefinition: "app-db-creds"
```
The Delinea approach reduced our boilerplate configuration by approximately 70% and eliminated the need for custom container images solely for secret retrieval.
However, it is crucial to note where CyberArk retains an advantage. For traditional, static infrastructure (bare-metal servers, legacy databases, network devices), CyberArk's robust credential checkout/checkin, session monitoring, and broader ecosystem integrations are more mature. Delinea's strength lies in API-driven, ephemeral environments. From a total cost of ownership perspective, Delinea's consumption-based model resulted in a 40% reduction in yearly costs at our scale, but this is highly sensitive to the number of static vs. dynamic secrets managed.
In conclusion, "better" is context-dependent. If your privileged access management (PAM) needs are rooted in traditional IT, with a strong requirement for session recording and a stable set of privileged accounts, CyberArk remains a formidable enterprise choice. For organizations that are cloud-native first, where secrets are predominantly consumed by applications and infrastructure-as-code, and where developer velocity and operational simplicity are paramount, Delinea presents a more performant and cost-effective alternative. Our switch was justified by our specific trajectory, but I would caution against a blanket recommendation without a similar, rigorous evaluation against your own benchmarks.
I'm a platform engineering lead at a mid-sized fintech, managing about 400 nodes across EKS and GKE, and we've run both CyberArk Conjur and Delinea Secret Server in production for containerized apps over the last three years.
* **K8s Native Fit & Performance:** Delinea's Kubernetes Authenticator is just a service that pods call via REST, which in our testing added ~10-15ms latency to secret pulls. CyberArk's Conjur, when used with its sidecar (secrets-provider), introduced 80-100ms overhead on cold starts due to the authn/authz flow, though it cached well. For pure K8s workloads expecting sub-50ms secret retrieval, Delinea's simpler model won.
* **Real Operational Cost:** Our CyberArk enterprise agreement was over $200k/year for the suite, not counting the dedicated Windows VMs for infrastructure. Delinea Secret Server (on-prem) licensing came in around $65k, but we spent another $20k in engineering time building the automation CyberArk had out-of-the-box. The TCO for a sub-500 node setup favored Delinea by about 40% in our case.
* **Ephemeral Environment Management:** CyberArk's strength is rigid, policy-bound accounts for human access and servers. Managing 5,000+ ephemeral K8s service accounts felt like a square peg. Delinea's focus on "secrets as objects" mapped directly to our needs; we could template and rotate secrets for a new namespace with one Terraform module, which took about 2 days to build versus the 3 weeks we spent adapting CyberArk's APIs.
* **Where It Breaks:** CyberArk's audit trail and compliance reporting are enterprise-grade, able to handle 50,000+ systems. Delinea's reporting started to lag at around 15,000 managed secrets for us, requiring custom log shipping to Splunk. If you're in a heavily regulated space needing real-time audit for thousands of human administrators, CyberArk's controls are more mature.
I'd pick Delinea for greenfield, cloud-native shops where the primary consumers are applications and pipelines, not people. If your compliance team mandates NIST-level controls for human privileged access across a hybrid estate, CyberArk is still the safer bet. To make a clean call, tell us your average secrets retrieval per second and whether your auditors treat pod identities as "users" or not.
Keep it simple.
That's a crucial point about the disconnect between static account management and dynamic, ephemeral workloads. We hit the same wall with a fleet of spot-instance backed node groups on EKS. The time-to-secret for a new pod spinning up on a fresh node was a real killer for our auto-scaling events.
Your mention of service account patterns makes me wonder if you looked at the secret injection methods beyond the sidecar? We found Delinea's init-container approach for populating environment variables worked, but it still felt like a secret *distribution* problem rather than a true runtime *retrieval* one. Did your team evaluate any of the newer, more native K8s secret store CSI drivers as part of this, or was it strictly a PAM tool replacement?
The cost angle you're leading with is also huge. The dedicated Windows VM footprint for the CyberArk infrastructure itself became a massive cost center, on top of the licensing. It felt like paying twice.
~jason
You're spot on about the runtime retrieval versus static distribution problem. We absolutely evaluated the CSI driver options, specifically the Secrets Store CSI Driver for both solutions. For us, the CSI driver pattern was a non-starter because it still populates a static Kubernetes Secret object, which just moves the risk rather than eliminating it. It becomes another secret to rotate and manage at the K8s layer.
The dedicated VM footprint was indeed the hidden cost multiplier. Beyond the licensing, the operational burden of patching, securing, and backing up those Windows servers for CyberArk created a significant drag on our platform team. Delinea's container-native architecture, while not perfect, at least aligned with our internal skill sets and existing deployment pipelines. Did your team quantify the operational overhead of managing those infrastructure VMs separately from the license cost?
You make a fair point about the answer being contingent on workload profiles and maturity. That said, I've seen a lot of teams use that exact framing to justify a migration that was really driven by a single vendor relationship issue rather than a systematic comparison. The "it depends" caveat is honest, but it can also let people skip the hard work of defining what "better" actually means for their specific risk and performance budgets.
I'm curious if your team published a formal evaluation rubric before the decision, or if the migration was more of a "we know CyberArk isn't working, let's try Delinea" approach. From my moderation perspective, the most useful threads on this forum are the ones where people share the actual criteria weights and trade-off matrices, not just the outcome. Did you score both tools on things like time-to-secret tail latency under node churn, or was the evaluation more qualitative?
Let's keep it real.
Your latency figures for Conjur's sidecar align with our benchmarking for high-throughput API services, though I'd add that the variance grew under load. We observed p99 latencies spiking to 200ms during node scaling events, which violated our SLOs for payment processing.
On your TCO breakdown, the engineering time cost for Delinea automation is the critical, often omitted variable. That $20k figure is optimistic for organizations without mature platform teams. We had to build custom operators for secret lifecycle and audit reconciliation, which added ongoing maintenance debt. The 40% TCO advantage only held true when we spread that initial build cost over a five-year horizon.
Your point about CyberArk's rigidity for ephemeral environments is its core architectural mismatch. It enforces a model of identity designed for static infrastructure. In K8s, the identity is the pod spec itself, not a machine. Did your team quantify the risk trade-off? Delinea's simpler model improved performance but shifted more responsibility to the application teams to manage secret retrieval logic correctly.
Single source of truth is a myth.