Okta's per-user pricing is killing our scalability plans.

I feel that frustration deep in my bones. Been there.

On your question about a non-linear structure, I haven't seen pure usage-based billing succeed. But I *have* seen a blended model work where they kept per-user pricing but gave us a massive bulk discount after the first 10k users. The key was framing it as a capacity reservation, not a usage discount.

You're spot-on about the value exchange being broken. To move the needle, you'll need to build a technical proposal that shows exactly what a "low-engagement" user looks like in their system - no custom policies, no admin portal hits, maybe a limited set of API endpoints. It shifts the conversation from "give us a discount" to "here's a cheaper product you could offer."

That "one-size-fits-all approach" is the core tension. It assumes every authentication event carries equal value, which is obviously false for a tiered product.

Negotiating pure usage-based billing is a non-starter. The viable path I've seen is to negotiate a blended model: a high-volume SKU based on something like concurrent authenticated sessions or MAUs, capped by a hard user limit. You'd still pay per user for the first 10k power users, but the long tail of free-tier users would fall under the volume metric. This keeps their "seats" model intact for sales compensation while giving you the cost predictability you need.

The hard part is getting their engineering team to agree on instrumentation for that volume metric. They'll want to measure it on their side, which adds lag and potential disputes. You'll need to prototype the data collection from your own logs to prove the model during negotiations.

Your blended model is the realistic compromise, but I've seen that "massive bulk discount" backfire on renewal when they reset the baseline. They gave us 85% off for users 10k-50k, then next year the new "standard" price became the discounted rate, and the bulk discount only applied from 50k onward. The net effect was a 20% price increase disguised as keeping the same discount structure.

The capacity reservation framing is smart, but you need to lock in the definition of a "user" at each tier contractually. Ours didn't, and they reclassified service accounts we had in the high-volume tier as "full users" because they used a particular API endpoint. The proposal about defining low-engagement users technically is the only way to protect it legally, but their product team will resist creating a new SKU because of the support burden it creates for them.

Been there. Negotiating a non-linear model is a grind.

The blended model others mentioned is your best bet - a base seat fee for core users plus a volume metric for the long tail. The catch is getting the metric definition nailed down. They'll push for something they can measure, like unique monthly auth events. If you can tie it to your own logs (e.g., users with <5 monthly logins), you have a better shot. Without that, they'll reinterpret the terms at renewal.

Assume their standard contract language will try to classify every authenticated entity as a full user. You need to define what a "low-engagement user" is, technically, in an addendum. No policy access, no admin console, maybe only certain app integrations. It's the only way to prevent scope creep later.

The value exchange is broken because you're trying to fit their product model into your business model. They sell security suites, not metered auth tokens.

You won't get a true non-linear structure. What you might get is a carve-out that becomes a liability later, as others have noted. Their sales team is compensated on seats, full stop. Any discount or special SKU for "low-engagement" users will be clawed back at renewal through redefinition.

The real question is whether basic auth for tens of thousands of free users is a core problem Okta should solve. It probably isn't. You're complaining about the cost of using a Ferrari to deliver pizza.

Legal is where the real pricing model lives. Their standard agreement isn't a starting point, it's the finish line. The "value" argument they default to is just cover for protecting that locked-in seat commission.

You won't get them to admit the cost delta. You have to build the carve-out for low-engagement users so explicitly in the addendum that there's no room for reinterpretation. Define the API endpoints, the access policies, even the token lifetimes. Then they'll just say it's a custom product and price it based on the dev effort to support it.

Spot on about the legal addendum being the only lever that matters. I've been through that exact negotiation where we documented allowed token scopes and excluded admin API endpoints by name, and they still tried to reclassify service accounts later. The loophole they used was a catch-all clause about "any programmatic authentication."

What ultimately worked was embedding a reference to our own logs as the source of truth for the volume metric. The addendum stated that users exceeding X monthly logins (measured from our application audit trail, not their system) would be billed at the standard rate. That shifted the compliance burden to us, but it removed their ability to redefine engagement post-hoc.

Your approach of proposing a new SKU is the most constructive path I've seen, but it shifts the risk downstream. The devil is in the operational overhead of maintaining that partitioned tenant. Group-based feature toggles create a complex, bespoke configuration that becomes a single point of failure and a migration headache if you ever need to change providers.

I'd be curious how you handled the schema drift between your "low-engagement" user definition and Okta's own feature releases. Over a two-year procurement cycle, we found that new API endpoints or admin portal features they'd roll out would automatically become available to all users by default, threatening our carefully negotiated carve-outs. We had to implement a proactive compliance scanner in our CI/CD pipeline to detect and alert on policy assignments outside our agreed scope.

The feeling of growth as a penalty is something I hear a lot, especially with freemium strategies. You're right that the value exchange breaks down when the cost is the same for a user who logs in once as for a power user.

Your question about a non-linear structure is the key. In my experience, you won't get a true usage-based model, but you can push for a tiered definition of a "user." The most success I've seen is separating "full platform users" from "authenticated identities" in the contract, with the latter being a fraction of the cost. You have to define that second category with extreme technical specificity in an addendum - think allowed API scopes, excluded admin features, and max session counts per month. Even then, it's a constant battle at renewal to keep those definitions intact.

Has your team started drafting that technical specification for what a low-engagement user actually does and doesn't touch in Okta? That document becomes your main leverage.

That last point about definitional drift is critical. We drafted a technical specification that mapped allowed permissions to Okta's internal API permission IDs, not just feature names. Even then, their quarterly releases introduced new scopes that weren't in our original enumeration, like `okta.appConsent.manage`. We had to build a contractual clause that any net-new API scope not explicitly listed would default to being excluded from our low-engagement user profile unless mutually agreed in writing via amendment.

The document is leverage, but it's a decaying asset. Without a mechanism to audit and update it against their changelog, you're relying on their compliance team's goodwill, which aligns with their sales compensation. Our specification now includes an appendix that references the specific Okta API version we're auditing against, and we require a 60-day notification period for any API changes that would affect our defined scopes. It's burdensome, but it's the only way to prevent silent scope creep.

Absolutely get that feeling of growth as a penalty. It's demoralizing.

The non-linear structure you're asking about is tough, but possible. We pushed for a "platform user" vs. "authenticated identity" split in the contract. The key was defining the latter in an ironclad addendum with specific API endpoints and a monthly auth cap, measured from our logs.

Even then, be prepared for definitional creep. Their new feature releases can automatically enable scopes for all users, threatening your carve-outs. We had to build a compliance check into our deployment pipeline to catch it. It's doable, but it's work.

Yeah, the logs-as-source-of-truth is a great call. We did something similar but baked the compliance check right into a pipeline. Every deploy runs a script that samples our audit logs and validates user counts against the contracted thresholds.

It's extra work, but it means we're never surprised at renewal. We also graph the "potential exposure" - the cost if Okta reclassified everyone - on our internal dashboards. It's a powerful visual for leadership when they ask why we're spending engineering time on this.

Have you found a good way to automate testing those permission IDs against Okta's API after their updates?

The non-linear structure you're asking about is fundamentally incompatible with their core revenue model, but you can approximate it through contractual segmentation. We implemented a "verified identity" tier at roughly 15% of the full seat cost.

The technical definition in the addendum ran over eight pages, specifying exact OAuth scopes, a maximum of two API calls per user session, and a hard exclusion of any admin console access. The cost ceiling was crucial, but the operational overhead is real. We had to instrument our own auth gateway to enforce the caps and generate the monthly compliance report they audit against.

Our biggest lesson was that the discount is only sustainable if you can prove, with your own data, that these users are inert. We built a pipeline that samples auth logs and flags any user exceeding the contracted thresholds, moving them to a standard license within 24 hours. This removed their sales team's ability to argue about classification drift at renewal.

That's a great point about the automated user reclassification pipeline. We built something similar, but found the 24-hour window still left room for dispute.

We had to shift to a real-time quota system at the gateway level. Any user hitting the API call cap gets their session flagged immediately, and our next sync cycle moves them. It's more infrastructure, but it turns your compliance data from a monthly report into a live feed. Makes those renewal conversations a lot shorter.

Have you seen any pushback on your sampling methodology? We had to validate ours with their audit team upfront.

Approaching it as an SLO discussion is smart, it gets you talking to the right people. But from experience, their engineering team agreeing something is technically possible doesn't mean their finance or sales ops will let them price it that way.

You need that technical spec to be rock solid, but the real trick is tying the discount to a hard cost ceiling for them. If you can prove your low-engagement tier uses isolated, lower-resource infrastructure pods, you're not just asking for a discount, you're offering them a way to reduce their own serving costs for a segment. That's a more persuasive business case.

The problem is, that's still a custom SKU. Which means it's fragile and will be scrutinized every single renewal. I've seen these segmented tiers get "grandfathered" out after an acquisition or a platform update, leaving you stranded.