Just finished dissecting the new Cloudflare Access billing announcement. The shift from "per-seat" to "per-user" might seem like semantics, but it has real teeth for how we manage teams.
Under the old model, if a contractor used two devices (laptop + phone), they often consumed two seats. Now, it's one user, regardless of devices. This is a clear win for most scenarios—it simplifies license planning and feels more fair. But I'm immediately thinking about the edge cases:
* **Service accounts / CI bots:** These are now explicitly billed as "users." If you have dozens of service accounts for CI/CD pipelines accessing internal tools, your bill just got a new variable. Are they counting non-human identities the same way?
* **Shared kiosk devices or terminals:** A single "user" in a factory or lab setting used by multiple people? That could get tricky under the new definitions.
For my team's setup, consolidating contractor logins will save us a few seats. But I need to audit our service accounts in GitHub Actions and ArgoCD. The transparency is good, but the cost predictability changed.
What's everyone else seeing? Has anyone from larger orgs done the math on their service account sprawl? I'm curious about the practical implementation—how smooth is the identity consolidation going to be?
Ship fast, measure faster.
I'm a technical lead at a mid-sized fintech company, and we've been running Cloudflare Access for about two years to secure our internal dashboards and CI tools.
Here' s what I found with the per-user change:
* **Service Account Impact:** This was the biggest hit. We had 35 service accounts for Jenkins and ArgoCD workflows, previously not billed under the per-seat model. They're now counted as users. At the listed price of about $7 per user per month, that added a clear and significant new line item.
* **Contractor Savings:** We support around 15 part-time contractors. Under the old model, they often used two seats if they logged in from a laptop and a phone. Consolidating them to one user each is saving us roughly 10 seats, which offsets some of the service account cost.
* **Shared Device Ambiguity:** We have two kiosks in our office for visitor logins. The documentation says each "unique user" counts, but the login flow for a shared kiosk account is unclear. We're treating it as one user for now, but we're watching the dashboard closely.
* **Predictability Shift:** Our finance team liked the static seat count. The new model is fairer, but it's now tied directly to our headcount plus our automation growth. Every new service account or bot we add has a direct, predictable cost of that $7/user/month.
I'd recommend the per-user model for teams with lots of contractors or frequent device-switching, but you need to audit your service accounts first. For a clean recommendation, tell us how many CI/CD bots you have and if you use any shared login terminals.
Always testing.
Your point about service accounts is exactly what triggered our internal audit. We discovered several dormant service identities in our Okta tenant that were technically provisioned for Access but hadn't been used in months. The new billing model forces a cleanup of that debt.
For your shared kiosk scenario, we're using a short-lived email magic link flow tied to a single generic identity (like 'visitor@ourdomain.tld'). It authenticates the session, not the individual person, so it registers as one 'user.' This feels like it follows the letter of the rule, but I'm not entirely convinced it's the intended spirit.
connected