What's the best way to start a PoC? Should we focus on servers or people first?

I'm Hannah, a platform engineering manager at a mid-size fintech, and we've been running CyberArk Privileged Access Manager in production for about two years to secure both our AWS service accounts and team access to PostgreSQL clusters.

**Entry Point Comparison for a CyberArk PoC**

1. **Time to First Win:** Starting with human user sessions for DevOps (SSH/RDP) delivers visible wins in 2-3 weeks. You can demonstrate session recording and just-in-time access for a handful of power users quickly. Starting with application server credentials for pipelines often takes 4-6 weeks for the first integrated service, due to SDK integration and credential rotation testing.
2. **Team & Executive Buy-In:** The "people-first" approach directly impacts daily workflows, making the security benefits tangible for engineers and their managers. This builds advocacy. The "servers-first" approach is invisible to most teams initially, which can make it harder to justify expanding the PoC later.
3. **Implementation & Scope Control:** Onboarding human users is primarily a process and policy change within a controlled group. Starting with service accounts is a technical integration project; you risk scope creep into CI/CD pipelines and deployment patterns, which can stall a PoC.
4. **Foundational Data Load:** Vaulting static database and service account passwords first creates your system-of-record for non-human credentials, which is a prerequisite for any secrets rotation project. However, this foundational work often has less immediate perceived value during a pilot.

**My Recommendation**

I'd recommend starting with the **people side** - onboarding your DevOps and DBA teams for their SSH and database client access. In our case, securing human access first created the internal champions we needed to fund and tackle the more complex, backend work of vaulting all our pipeline secrets. If the choice isn't clear, tell us: 1) Is there a major audit finding pressuring one area over the other, and 2) do you have a dedicated app team ready to modify their services for credential retrieval?

Oh, I feel this so much. That "people vs. servers" starting point debate is a classic for a reason, and your data pipeline angle is super relevant. You're right on the edge of both worlds.

I'd gently push back on the idea of starting with human users just for quick wins. In your case, where those pipeline service accounts are your biggest, hairiest pain point, starting there can force a *much* more rigorous PoC. Integrating with your actual automation (think CI/CD jobs, ETL tasks) tests the hard parts early, credential rotation, SDK resilience, API reliability. If you can get that working smoothly for one pipeline, you've proven the system under real stress. The human user onboarding often rides on top of that same infrastructure anyway.

That said, if you do go the people-first route, tie it directly back to your pipeline problem. Onboard the DevOps engineers who *own* those problematic service accounts first. Let them experience the session management, then immediately task them with helping you convert one of their own automated accounts. It builds buy-in through shared pain and purpose, not just by showing them a shiny recording of their SSH session.

You're right to go after the biggest pain point first. Starting with the pipeline accounts actually tests if the system works for real work, not just a demo. Quick wins with human users are fine, but they're basically just logging in, not proving the tech handles automated credential rotation under load.

The "people first" advice is usually from vendors who want an easy sale. If you can't make your service accounts work, the whole project is useless anyway. Prove the hard part first.

I agree in spirit, but framing it as "vendors want an easy sale" is a bit too cynical. A people-first start can still be valid if you need to build internal confidence and social proof. The risk is that if you *only* demo the easy part, you're setting unrealistic expectations.

You're dead right about proving the tech under real stress, though. Service accounts and pipelines don't give you wiggle room - either the integration works flawlessly or it breaks production. If I had to choose one path to determine a true go/no-go, that's the one. It just requires everyone to understand the initial timeline will be longer and messier.

That's a great instinct, to go after the biggest pain point. It cuts right to the heart of whether the tool will work for your actual needs.

In my rollout, we actually split the difference and it worked wonders. We started with one critical, high-visibility pipeline service account (the "server" side) as our primary PoC goal. Simultaneously, we onboarded a single, trusted DevOps engineer for SSH access (the "people" side). This gave us two parallel feedback loops: proving the tech could handle automated rotation under real load, while also giving that engineer a firsthand view of the end-user experience. Their feedback on the interface and workflow was invaluable for planning broader team onboarding later.

The lesson was that you don't have to pick just one. Starting with a focused, representative slice of *both* worlds can give you a much more complete picture of operational viability and user adoption hurdles. You get to test the hard technical integration and build a small, internal champion at the same time.

"Splitting the difference" sounds reasonable in theory, but you're essentially doubling the initial scope and muddling your success criteria. Now you have two separate deliverables to manage, each with its own failure modes.

The biggest risk is that the "people side" succeeds quickly and the "server side" lags, leading management to declare victory based on the wrong metric. They'll see the slick session recording for one engineer and assume the hard part is done, when your pipeline integration is still bleeding. This creates pressure to buy before you've proven the system handles your actual pain point.

Pick one lane. If the pipeline service account is truly the biggest pain, prove that works in isolation. Adding a human user into the mix distracts from the core technical risk.

Your data pipeline instinct is right, but I think you're looking for confidence in your choice. The "biggest pain point" principle is solid, but the fear of missing out on quick wins is real.

Here's what I'd propose: define two distinct success criteria for your PoC, one technical and one social. Your primary goal is to prove the service account integration works end-to-end under real conditions. That's your technical pass/fail. Your secondary, "nice-to-have" win, is to generate one piece of compelling evidence for broader buy-in. That could be as simple as a short demo video showing session recording for a single, pre-existing service account you've already onboarded - you don't need to onboard a new human user to get that.

This keeps you focused on the hard tech problem while still capturing a tangible win you can show around. It's not about splitting scope, it's about being smart about what you document and share.

> define two distinct success criteria for your PoC, one technical and one social

This is the key insight. Everyone arguing about "which one first" is missing the governance angle. The technical pass/fail for the service account is non-negotiable. But the "social" win is what you use to disarm the inevitable "why can't I just use my old SSH key?" objections later.

Just make damn sure the social win doesn't become the *primary* success metric in the status report. That's how you get stuck with a shiny toy that can't handle a real pipeline.

Your point about vendors pushing "people first" for an easier sale has merit, but I think it overlooks the technical sales cycle for enterprise security tools. A vendor's SE team knows that if the service account integration fails under load, the deal collapses regardless of any user session demo. They might lead with the quick win to secure budget and stakeholder attention, but they're fully aware the technical proof for automation is the real gate.

The risk isn't vendor cynicism; it's internal misalignment. If the security team champions the "people first" win to leadership without clear caveats, it creates political momentum that can override the later, more critical technical validation. The pipeline test becomes a checkbox instead of the cornerstone.

Oh gosh, reading this thread as a newbie is making my head spin a bit. But this part from your post really hit me:

>I'm used to tackling the biggest pain point first. For us, that's probably the automated service accounts...

That just sounds like the right instinct? If your pipeline accounts are a mess now, proving the PAM fixes that feels like the win you need. I'd be scared to start with people stuff and then find out the hard part doesn't actually work later.

Maybe a silly question, but can you do a tiny version of the pipeline fix first, like just one account? That way you're still focused on the big pain, but it's not a huge project.

Your instinct is right on the money. Starting with a single, high-impact pipeline service account is the perfect PoC entry point. It's a real workload that forces you to solve the tough integration and rotation problems.

I'd just add one tactical suggestion: make sure your test pipeline has solid observability. Add extra logging and metrics around the credential fetch and connection steps. When (not if) something goes weird during the PoC, that telemetry will be the difference between a day of debugging and a week of finger-pointing between your team and the vendor.

It proves the tech *and* gives you concrete data on performance and reliability for your cost/benefit analysis later.

Your instinct is right. People who push the "quicker visibility" path are often the ones who won't have to clean up the mess later when the automation piece fails under load.

Starting with human users first just proves the vendor can build a nice UI for session management. That's the easy part. It tells you nothing about whether the platform can handle the real, messy work of programmatic credential rotation without breaking your pipelines. That's the actual risk you're trying to mitigate.

Focus on the single worst service account you've got. If it can't handle that, all the flashy session recordings in the world are worthless.

Your instinct is correct. I've seen three CyberArk rollouts fail because they started with the shiny "people side" demo. Management saw the session recordings, signed the check, and we spent the next two years trying to duct tape the automation layer that never really worked.

The painful truth is, if you can't handle automated rotation for a service account under real pipeline load, you don't have a PAM solution. You have a gloriated session recorder. Start with your worst, most critical pipeline service account. Make the PoC pass/fail on that alone. If it works, you've proven the hard part. Anything after that is just configuration.

And ignore anyone who says you need the "social win" first. That's a political problem, not a technical one. Solve the tech risk, then use the proven automation story to force the social change.

Three rollouts failing the same way is a strong signal.

The "forced social change" part is key. A successful automation proof creates its own political gravity. When you can show the platform *already* rotating credentials for a critical pipeline, the "but my ssh key" arguments sound trivial. The hard tech proof re-frames the entire conversation.

Just make sure your "worst, most critical" account isn't so critical that a PoC hiccup causes a production incident. Pick the second-worst.