Hey everyone, I've been deep in a multi-cloud SASE/SSE deployment for the last six months, and I keep hitting a major snag that I'm curious if others are experiencing.
We're using one of the major SASE platforms (trying to avoid naming names, but it's one of the big three). The architecture itself is solid—we've got Cloud SWG, CASB, ZTNA, and FWaaS all stitched together, and for our full-time employees, the per-user, per-month pricing is predictable. The problem explodes when we factor in non-human and transient human identities.
**Here's our real-world breakdown:**
* **500 full-time employees:** Easy. 500 licenses.
* **50-150 contractors/month:** They need full, secure access to specific projects for 3-12 months. They're "users," but they come and go. Do we buy licenses in bulk and leave them idle? Pay exorbitant short-term fees?
* **Service accounts & bots:** Our CI/CD pipelines (Jenkins, GitHub Actions runners), monitoring daemons, and backup services need to reach external APIs (like GitHub, cloud provider APIs). Under a strict per-user model, each of these needs a "user" license just to get out through the ZTNA gateway. We have over 200 of these non-human identities.
Suddenly, our "per-user" bill wants to be for 850+ "users," most of which aren't people. The cost/benefit gets completely distorted. We're effectively paying a premium security tax for our automation.
I tried to model the cost of creating a separate, less-secure egress path for automation, but that violates the whole "single pane of glass" and consistent security posture promise of SASE. It feels like a step backwards.
```yaml
# Example: Our GitHub Actions runner needs to tag a release.
# It must authenticate via our ZTNA to reach the GitHub API.
# Under a strict model, this service account = one licensed user.
- name: Create Release
uses: actions/create-release@v1
env:
ZTNA_GATEWAY: ${{ secrets.ZTNA_HOST }}
SERVICE_ACCOUNT_TOKEN: ${{ secrets.SVC_BOT_TOKEN }} # This identity needs a license??
```
**My question to the community:** How are you handling this? Are vendors offering sensible models for non-human identities (like a service-tier license at 10% of the cost)? Have you split your architecture—using SASE for humans and a traditional firewall/VPN for service egress? Or bitten the bullet and licensed everything?
I'm particularly interested in any GitOps or CI/CD pipeline integrations where you've solved this cleanly. The pricing model seems stuck in a pre-automation, pre-bot era.
— francesc
— francesc
Totally get your point about contractors, we ran into that too. Had to onboard a whole dev team for a 6-month project and the licensing headache was real. Ended up buying a block of licenses just for them, but then had to track when people rolled off to reassign them. It felt like an extra admin job.
And the service account thing is huge, isn't it? We had a similar shock when we realized our automated deployment tools needed their own "seats" just to reach out to the internet. Makes you wonder if there's a better model for these non-human workflows. How did you end up handling those 200+ bot identities? Did the vendor have any workaround?
Oh, the contractor license shuffle is so real. We ended up creating a whole separate OU and license pool just for them, but like you said, tracking the offboarding became a part-time job. We actually built a tiny integration between our HR system (for contractors) and the vendor's API to auto-reassign those seats, but it was a pain to set up.
For the non-human identities, that was our big "aha" moment. We pushed back hard on the vendor. After a lot of haggling, they offered a special "service account" SKU that was about 60% of the cost of a full user seat. It's still not perfect, but it at least acknowledged that a CI/CD pipeline doesn't need the full CASB or SWG features. Might be worth asking your account rep if they have something like that tucked away? The worst they can say is no.
Measure twice, automate once.
You've just described the exact moment where the shiny vendor slide deck meets the ugly reality of how work actually gets done. Everyone nods along to the per-user pricing in the sales call because they're only picturing Bob in accounting. Nobody is picturing the 200 service identities that are essentially treated as second-class citizens.
The "special SKU" workaround mentioned later is just a band-aid on a fundamentally broken model. It's the vendor admitting their pricing is misaligned without actually fixing it. You're still left playing license bingo, tracking contractor end dates and trying to figure out if your logging daemon needs the "service account" SKU or if it can sneak by on a shared "non-human, non-interactive, only-on-Tuesdays" plan they'll invent next year.
This is why I always push for a capacity-based model during procurement, even if it costs more upfront. A model based on throughput or sessions scales with actual use, not with your headcount fluctuations. When the vendor pushes back, I ask them to explain exactly how many licenses a bash script running in cron should consume. The silence is telling.
monoliths are not evil
You're right about the band-aid. That special SKU is just a pricing concession, not an architectural fix. It creates a new shadow tier you have to manage forever.
I've seen this play out with data pipeline tools, too. Per-seat licensing for something like a workflow orchestrator is madness when 90% of the "users" are service accounts for ETL jobs. The vendor's answer is always "use a service account license," but then you're just doing the same license shuffle, but now with two different SKUs in your procurement system.
Your capacity-based model push is the only sane path. When they can't answer the "bash script in cron" question, it proves the model is fiction.
garbage in, garbage out