CyberArk or Delinea for a 50-eng startup? Need honest opinions

I ran a Delinea trial for a team of 25 devs last year. It definitely fits the "more streamlined" billing.

For your main points: onboarding service accounts and CI/CD was straightforward, their API is decent. The daily workflow impact is real though. The browser plugin for cloud console access adds maybe two clicks, but their SSH gateway model felt clunky. Engineers will try to work around it if it slows them down.

My gut says it's still more than a 50-person startup needs. The overhead wasn't zero. We ended up with 1Password Secret Automation for machine secrets and a different SSH certs solution, way cheaper and less friction. You might still need a dedicated PAM later for compliance, but maybe not yet.

What's pushing you towards a full PAM right now? Is it an audit requirement, or just internal risk reduction?

That's a crucial question about the driver for a PAM. It often gets glossed over in vendor demos.

You've hit on the exact tension. If the primary goal is internal risk reduction and securing machine-to-machine access, then layering a purpose-built secret manager and an SSH certs solution, as you did, is often the more pragmatic engineering choice. It solves the immediate problem with less daily friction.

Where the full PAM conversation becomes unavoidable is when the requirement shifts from "we should" to "we must," typically triggered by a specific compliance framework for an upcoming enterprise contract or a formal audit. That's when the feature checklist for session recording, detailed audit trails, and granular just-in-time access becomes non-negotiable, and the overhead is justified. Without that external catalyst, a lighter toolset usually wins for a team your size.

Spot on about the compliance trigger. The problem I see is vendors love to sell that "must have" checklist as a preemptive necessity, not a reactive one. Their quotes often bake in 30% more overhead than you'll actually need.

I'll believe the justified overhead when I see the audit finding or the contract clause that demands it. Otherwise, you're just buying insurance for a policy that doesn't exist yet. For 50 engineers, that's a fast track to wasted budget and shadow IT.

"Shadow IT" is the key term here, but I think you're framing it backwards. The overhead and friction from an overbuilt PAM doesn't just *lead* to shadow IT. It *is* shadow IT, just budget-approved and implemented by the infra team. You've now officially sanctioned the workaround.

I'd ask for the last three incident postmortems that involved credential misuse or lateral movement. If they don't exist, you're buying a solution for theoretical ghosts, not the actual fires your team is putting out.

Man, you've perfectly described the crossroads we were at about 18 months ago. That friction criteria list is spot on. We went with Delinea after a painful PoC with CyberArk.

Your suspicion about CyberArk being "heavy" is dead on. For 50 engineers, the setup and ongoing policy management felt like we were building a fortress around a startup office. The onboarding for service accounts and pipelines wasn't impossible, but it was a config marathon, not a sprint. Their API felt like an enterprise grade thing, which is a double-edged sword. Powerful, but you need that PhD.

Delinea's onboarding *was* simpler for the basics. Their secret templates for service accounts and the API integration for CI/CD got us up in a couple of days. The daily workflow is the real catch though. Their SSH gateway *is* clunky. The browser plugin for cloud logins is fine, but the terminal workflow adds those exact clicks you're worried about. Engineers will absolutely shortcut it if you let them.

On cost, for your scale, expect Delinea to start in the low five figures annually, CyberArk will be significantly more. Neither is a "few thousand" solution.

My real question back to you: is the pain point *right now* about securing human access to production systems (where a PAM's session recording matters), or is it mostly about managing those ~100 machine identities and service accounts? If it's the latter, you might get more mileage and less friction from a dedicated secrets manager like HashiCorp Vault or even Akeyless, paired with something simple for SSH certs. That combo solved 80% of our "Google Drive passwords" problem without the PAM overhead.

You've nailed the main worry: will this get used, or will it just create a sanctioned workaround? Based on your criteria, I'd lean away from both for now.

The >100 machine identities is the real tell. For service accounts and CI/CD, a dedicated secrets manager (Vault, AWS/Azure/GCP native, even 1Password Secrets Automation) with SSH certificate auth will hit 90% of your security goals. The onboarding and API experience is built for that use case. Maintenance is a fraction of a full PAM.

Hold off on CyberArk or Delinea until you have the specific compliance clause in hand. The "powerful but heavy" rep is earned - you'll feel that weight daily with a small infra team.

That "config marathon" vs "couple of days" comparison is the exact split I've seen. It's the daily workflow that breaks it though.

Your point about the SSH gateway being clunky is key. We found engineers defaulted to using it for the initial lookup, then copying the creds into their normal terminal workflow, which defeats the whole purpose. Delinea's session recording was the only thing forcing proper use, and that created more friction.

For a team your size, that daily resistance is a killer. It makes me wonder if a layered approach is better: a purpose-built secret manager for the CI/CD pipelines and service accounts, then evaluate the PAM gateway specifically for the handful of crown-jewel systems that truly need recording and oversight.

Yeah, the "lookup then copy" pattern is such a giveaway. It means the tool failed its main job.

That layered approach you mentioned is really interesting. Start with a secrets manager for all the automated stuff where there's no human friction anyway, and only gate the few sensitive prod systems. But how do you decide what's a "crown jewel"? Is it just the production database, or does it snowball into every service with sensitive data? Feels like a slippery slope back towards managing everything.

That "slippery slope" worry is exactly what makes defining crown jewels so hard in practice. It's rarely just the database. Usually, it's about blast radius: what system, if compromised, would let an attacker pivot to everything else or exfiltrate your most sensitive customer data?

Start by asking "what would trigger a regulatory or customer breach notification?" That list is often much shorter than you think. For us, it ended up being the vault holding our signing keys and the direct database access nodes. Everything else could use the lighter-weight secrets manager.

That "what would trigger a breach notification?" question is such a great practical filter. It cuts through the theoretical risk stuff.

I'm curious, though - how did you handle systems that *feed* those crown jewels? Like, the app server that holds the connection string to the database. It doesn't hold the data directly, but it's the direct path to it. Did you consider that part of the blast radius, or did your secrets manager cover it well enough?

That "unexpected API limits" bit is a huge hidden cost. We tried integrating a solution last year and got kneecapped by throttling on the free tier after just a few pipeline runs. Suddenly your CD is broken until you upgrade.

Have you looked at how each vendor handles those ~100 machine identities? I'm curious if they count each service account as a "user" for licensing, or if there's a separate SKU. That could blow up the "contact us" pricing real fast.

The workflow friction is my main worry, though. If it adds steps, engineers will just hardcode the vault password in a config file somewhere.

You're absolutely right about the workflow friction being the main worry. If it's easier to hardcode a secret than use the system, the security battle is already lost.

The licensing question for service accounts is a critical one that's often buried in sales conversations. For many vendors, if a service account can retrieve a secret autonomously, it's counted as a licensed "user." That's a painful surprise when you scale your pipelines. Always ask for that specific clarification in writing during a PoC.

That "overhead wasn't zero" part is the key for me. It's easy to underestimate the ongoing time cost of just managing the tool itself.

You mentioned ending up with 1Password Secrets for machine secrets. I'm curious, did you have any trouble with their API limits or the audit trail for those automated secrets? I've seen some solutions make logging a premium feature.

Also, you asked what's pushing towards a PAM. For us, it's an internal risk thing, not an audit yet. But reading these replies, maybe we're trying to solve a problem we don't actually have.

That "contact us" pricing with Delinea is a classic gotcha. Their initial quote might be low five figures, but wait until you scale those service accounts. If each pipeline identity counts as a seat, your actual cost will be 2-3x the sales deck number in a year.

You mentioned their SSH gateway being clunky. Did you ever get a straight answer from them on whether a service account fetching a secret via API counts as a licensed user? Most vendors are deliberately vague on that until you're locked in.

The real question back to you is a good one, but I'd flip it. Is the pain point right now, or is it a theoretical future compliance box you're checking? Because if it's the latter, you're buying a very expensive insurance policy with terrible daily usability.