I’ve been reviewing our security posture and the upcoming SOC 2 audit requirements, and the topic of Privileged Access Management (PAM) has come up—again. The security team is pushing hard for a full CyberArk implementation, citing it as the "industry standard." However, I'm looking at our actual infrastructure and team size, and the proposal feels like using a sledgehammer to crack a nut.
We're a data engineering team of 12 people managing about 50 service accounts across Snowflake, AWS, Kafka, and various ETL tools (Airflow, dbt). Our "privileged access" is largely:
* SSH keys for a handful of EC2 instances (mostly bastion hosts).
* Database credentials for admin-level Snowflake roles (ACCOUNTADMIN, SECURITYADMIN).
* IAM keys for a few break-glass AWS accounts.
* Service account passwords for legacy on-prem applications.
The CyberArk sales cycle and the projected architecture overview they provided were... substantial. It involves:
* A vault cluster (obviously).
* The Privilege Cloud portal or on-prem CPM/PVWA components.
* Integration nodes for our various targets (AWS, Snowflake, SSH servers).
* The inevitable "just-in-time" access workflows they're now pushing.
My immediate concerns are complexity and friction. For a team our size, the overhead seems immense. I'm picturing our CI/CD pipelines that currently use HashiCorp Vault for dynamic secrets, now having to call out to a CyberArk Central Credential Provider (CCP) and handle their specific APIs. Or our on-call engineer needing to access a bastion host at 3 AM and having to go through a request-and-approve workflow in a portal first.
So my question is for teams of a similar scale: **Are you actually using CyberArk in production, and does it work without crippling productivity?** I'm specifically interested in:
* **Actual daily usage patterns:** Do your engineers *use* it directly, or is it a back-end system managed solely by security?
* **Integration reality:** How have you integrated it with AWS Secrets Manager, HashiCorp Vault, or CI/CD pipelines (Jenkins, GitLab)? Is the `cybr` CLI robust enough for automation?
* **Cost vs. benefit:** For under 15 engineers and ~100 privileged accounts, does the security uplift justify the licensing cost and maintenance burden compared to, say, a well-configured Vault instance with OIDC and temporary credentials?
The security argument is clear, but I need to understand the operational tax. If the outcome is that engineers start keeping static credentials in personal 1Password vaults to bypass the system, then we've made things worse, not better.
I’d appreciate blunt, data-driven experiences. Marketing gloss and "industry best practice" talking points are not helpful here.
—davidr
—davidr
I had the exact same reaction when our security team brought up CyberArk. The scale just didn't make sense for our team, which is about your size.
What did you end up looking at as alternatives? I've been researching options like HashiCorp Vault or even AWS Secrets Manager with some custom tooling for rotation, but it's hard to gauge what actually works for a smaller setup without the overhead.
The "projected architecture overview" they sent you is a classic. Ours had so many boxes and lines it looked like a subway map.
Yeah, the scale mismatch is real. For your stack, especially with heavy AWS and Snowflake usage, I'd look at native services first. AWS Secrets Manager can handle the IAM keys and rotate them automatically. For Snowflake, you can integrate Secrets Manager with a little Lambda glue to push new credentials.
The big win for CyberArk is the session management and recording for those SSH bastion hosts. If that's a hard audit requirement, then you're stuck. But if it's just about credential storage and rotation, you're building a Rube Goldberg machine.