Hey team! 👋 I've been hearing more chatter about teams using Delinea (formerly Thycotic) for just-in-time privilege elevation. The big promise is reducing those "I need admin rights" or "can someone run this script for me?" tickets that clog up our service desks.
In our last retro, we flagged ticket fatigue as a major pain point. If Delinea can let approved users temporarily elevate their own privileges for specific tasks, that sounds like a win for both IT and dev teams. But does it actually work that way in practice?
I'm curious if anyone here has rolled it out and measured the impact. Specifically:
* What was your baseline ticket volume for privilege-related requests before implementation?
* Did you see a measurable drop after enabling self-service elevation?
* What were the unexpected hurdles? (e.g., training, defining safe policies, user hesitation)
* Did it just shift the work from tickets to policy management, or was it a net gain?
Sharing some real numbers or even anecdotal workflow changes would be super helpful. I'm trying to build a case for my own team! 🌻 fiona
null
That's a really good question, and I've been wondering about the same thing. We're in the early stages of evaluating a PAM tool, and Delinea is on the list, so I don't have our own numbers yet. But I can share what I've dug up from talking to a couple of peers.
One person at a mid-sized SaaS company said their ticket drop was significant, but not immediate. They tracked privilege elevation tickets for three months before rollout as a baseline, and saw about a 60% reduction in the first quarter after implementation. The caveat, they stressed, is that it took a solid month of training and communication to get adoption - at first, people just kept filing tickets out of habit.
> Did it just shift the work from tickets to policy management?
From what I've gathered, it does shift some work. You're now defining and maintaining those "safe" policies for elevation, which is a different kind of lift. But their team considered it a net gain because the policy work is planned and proactive, while the tickets were a constant, reactive interruption. I'd be really curious to know how others balanced granularity vs. simplicity when setting those policies - it seems like you could easily overcomplicate it.
The 60% reduction figure is plausible, but I've seen it hinge entirely on the granularity you mentioned. Your peer is right, the work shifts. It shifts from ticket triage to data modeling, frankly.
If you define policies at the role level (e.g., "All Developers"), you'll get a fast drop in tickets but a dangerously broad blast radius. The real reduction comes from modeling policies against specific, sanctioned commands or binaries. For example, a policy that allows elevation only for `dnc.exe` with specific parameters to restart a service. That's where you stop tickets for good, because you've encoded the solution into the policy.
The counterpoint is that building that model is a significant upfront data engineering effort. You need to audit what those privilege tickets were actually for, cluster them, and then codify the exceptions. If you skip that and just hand out "admin for 15 minutes," you're not reducing risk, you're just automating the problem. Did your peer mention if their 60% drop correlated with a reduction in security incidents, or just ticket volume? That's the data point that matters.
—davidr
That's exactly what we're hoping for with ticket fatigue too. I haven't used Delinea, but I'm curious about one part of your question.
> Did it just shift the work from tickets to policy management?
If defining "safe policies" is a huge upfront effort, does that mean you need a dedicated person to manage it? Like, does IT now need a full-time policy admin instead of handling tickets? That trade-off worries me a bit.
60%? That's a nice round number from one company. I'd want to see their actual ticket categorization and how they defined a "privilege-related request" for their baseline. Was it a single Jira label, or did they have to manually review hundreds of ticket descriptions? That prep work alone can skew the before-and-after picture.
And yeah, the work shifts. But calling policy management "planned and proactive" is a bit optimistic for the first year. It's more like reactive archaeology: you build policies only after enough people try to elevate for a new, unexpected thing and fail. You're just trading ticket noise for policy exception noise.