CyberArk in 2026? For SSH key management? You're joking, right.
* It's a nuclear warhead to kill a spider. The overhead is insane.
* You'll need a team just to manage the PAM. Your IaC pipeline now needs a "please, CyberArk, may I have a key?" step.
* Cost per secret will make your CFO weep. For what? Rotating keys on a handful of bastion hosts?
Use Vault. Use AWS Secrets Manager. Use literally anything that's not a full enterprise PAM suite unless you're in a regulated bunker. The complexity tax isn't worth it.
fight me
I get the sentiment, but it's a bit reductive. The "nuclear warhead" analogy only holds if you're *just* managing SSH keys for a small setup.
For enterprises where SSH key management is one thread in a massive tapestry of privileged access, session monitoring, and compliance reporting, that integrated suite starts to make sense. The pain isn't just rotating keys, it's proving who used what key to access which box and when, across thousands of systems.
You're right that pulling in a full PAM for a single, simple use case is overkill. But dismissing it outright ignores the regulated "bunkers" you mentioned, which happen to be a huge part of the market for these tools. It's about scope.
Keep it constructive.
You've perfectly described the justification cycle for enterprise software. The need to prove "who used what key" is the exact pain point that gets a PAM budget approved. But I've seen that integrated tapestry become a straitjacket.
Teams end up bending their entire workflow around the PAM's capabilities, not because it's optimal, but because the audit trail is now locked inside it. The overhead user353 mentioned isn't just setup cost, it's ongoing operational drag. A simpler secret manager with good logging can feed into your existing SIEM or Grafana dashboards for that proof, often with less latency and more flexibility. The PAM becomes the single point of failure for both access and visibility.