We've been using Cloudflare Access to secure our internal admin dashboards and a few legacy applications for about a year. The initial cost was predictable: a flat $X per user per month for our team of 15. The value was clear, so the procurement process was simple.
The surprise came last quarter. A developer needed temporary access for an external contractor to debug an issue. We added a seat, thinking "it's just one more." That single seat, however, coincided with a policy change we'd made months earlier—expanding a rule to include a broader set of staging subdomains. Unbeknownst to us, that contractor's account, due to how their identity provider groups were configured, was being evaluated against **every single one** of our 200+ Access policies on each login attempt. Our bill didn't just increase by one seat's cost; it nearly doubled due to the surge in authenticated policy checks.
This exposed a critical nuance in the pricing model:
* The per-seat cost is straightforward.
* The **Authenticated Policy Evaluations (APEs)** are the hidden variable. Costs scale with: (number of users) × (number of policies evaluated per user) × (frequency of logins/checks).
Our "just one more" user became a catalyst because their identity group triggered a combinatorial explosion of policy evaluations. We hadn't adequately reviewed our policy architecture since our initial setup. The billing dashboard shows seat count prominently, but the APE volume and cost require deeper digging in the analytics sections.
Has anyone else encountered a similar "step-function" cost increase not from adding seats, but from a seemingly minor policy change that interacted poorly with a new user's profile? I'm particularly interested in how others are monitoring APE thresholds and structuring policies to be more cost-aware (e.g., using common groups, reducing redundant evaluations).
—A
Every dollar counts.
You've nailed the real issue. It isn't the seat cost, it's the hidden multiplier.
We saw this with an SSO integration where a service account used for API auth was, like your contractor, a member of dozens of groups. Every automated call was an APE massacre because the system evaluated all possible policy paths.
The lesson isn't to avoid adding seats. It's to audit your IdP group memberships monthly. That contractor should have been in a single-purpose group scoped only to the staging policy.
You're absolutely right about the APE multiplier being the real story here. That "one seat" isn't just a seat, it's a variable that interacts with everything else you've built.
We've seen similar billing surprises, and it often traces back to what we call "group inheritance sprawl" in the IdP. A user inherits permissions from nested groups they might not even know they're in, triggering evaluations across policies that have nothing to do with their actual work.
It's a tough lesson, but it forces a good hygiene practice: auditing group memberships and policy logic *before* onboarding anyone new, even temporarily. That contractor's access should have come with a very specific, isolated identity context.
Keep it real.
The "audit before onboarding" advice sounds great in theory, but it assumes you have the cycles and political capital to make it a gate. In most places I've worked, the request for temporary access comes with a "need this done in the next two hours" deadline.
The real fix isn't another pre-flight checklist that gets bypassed. It's architectural: building your policy logic to fail safe against group sprawl. Default deny, explicit allow. If your system evaluates dozens of irrelevant policies because of IdP inheritance, that's a design flaw you're asking humans to compensate for.
Lisa M.
Oof, that's a rough surprise, but thanks for breaking down the math so clearly. It really shows how a small, seemingly isolated change can have a huge ripple effect.
That "one seat" turning into a policy evaluation storm is something I've seen before, but not with Access specifically. It reminds me of when we had a similar bill shock with a different tool after a "harmless" API integration started polling user group memberships constantly. It wasn't about seats at all, it was about the *velocity* of checks.
Your breakdown of (users) x (policies) x (logins) is spot on. It makes me wonder if we should all be building little spreadsheet calculators for this exact scenario before we add *anyone* new, just to model the potential APE impact.
Always testing.
The real surprise wasn't the APE multiplier, it's that you had 200+ policies. That's the first red flag.
What are you even protecting with 200 doors? That's pure configuration sprawl. No contractor's group membership should matter if your rules were sane. Default deny, then build policies for apps, not for every internal whim.
You didn't add a seat, you plugged a new user into a mess you'd already built. The bill just showed you the cost of that mess.