Hey everyone, I’ve been testing Banyan Security for about three months now, mostly for managing access to our dev and staging environments.
I love the zero-trust model in theory, and the just-in-time (JIT) access approvals seemed like a great way to tighten security. But I'm running into a side effect I didn't expect: **it feels like it's generating more support tickets, not fewer.**
Before, we had static roles with maybe overly-broad access. Now, with JIT, every time someone needs a resource for a one-off task—even a teammate who just needs to check something—it requires a request/approval cycle. If the designated approver is busy or out, the requester just opens a ticket with our team to "expedite" it.
Has anyone else seen this? I'm trying to figure out if it's:
* A configuration issue on our end (are our policies too restrictive?)
* A workflow problem (should we have more delegated approvers?)
* Just an inevitable growing pain when moving from "always on" to "just-in-time" access.
It's adding friction to quick collaborations, which feels counter to the productivity gains we wanted. Curious if others have balanced this better, or if you just accept the ticket influx as the cost of better security.
Yeah, we hit this exact friction early on. The ticket spike is real, especially when people are used to having standing access.
For us, the key was defining clear "low-risk" access patterns and automating approvals for those. For example, we set up a policy where access to non-production database read replicas gets auto-approved for anyone in the app's developer group, but only for 2 hours and it logs the query. It cut down maybe 60% of the approval tickets.
Also, make sure you have at least two delegated approvers per service/resource, preferably in different time zones if you're distributed. The "approver is OOO" bottleneck creates tickets instantly.
It's a balance, but you can tune the policies to match your actual risk levels. Not everything needs a manual human approval.
Yep, that's the classic pain point. The initial JIT setup often mirrors your old static RBAC matrix, just with more steps.
You asked if it's a config, workflow, or growing pain. It's usually all three. The first policy pass rarely matches actual day-to-day usage patterns. You need to map out those "quick collaboration" flows and create safe harbors for them, like user561 mentioned.
What's the actual ROI if your team is now a ticket-clearing house? Track the most common request types for a week; that's your list for policy automation. Start with read-only access to staging resources for engineers in the same project group.
Ask me about hidden egress costs.