CIAM Pricing Models: MAU, MTU, and the Cost Traps That Bite at Renewal

Key takeaways

• Per-MAU pricing is the dominant CIAM model. The trap is the long-tail user — inactive accounts that still count, B2B trial users who never convert, bot signups.
• MTU (Monthly Tracked Users) varies wildly in definition. Read the contract; the difference between 'authenticated MAU' and 'tracked MAU' can be 5-10× at the same headline price.
• Feature-tier pricing — SSO/MFA/SCIM gated behind enterprise plans — is the SaaS pricing pattern auditors call 'the SSO tax'. Increasingly contested; some vendors are unbundling.
• Renewal pricing is the recurring buyer surprise. Negotiate caps at initial purchase; standard CIAM vendor escalator is 5-15% annual.
• TCO modeling should include the price you'll pay at 3× current scale, not just current — pricing curves are usually convex, not linear.

The pricing models, and what each hides

The dominant models and their typical structures:

Model	What you pay for	Typical range (per unit)	Where it hides cost
Per-MAU	Each user who authenticated this month	$0.01-$0.10/MAU at scale	Definition of "active"; inactive accounts that still count
Per-MTU	Each user the platform tracks, regardless of authentication	$0.005-$0.05/MTU	Definition of "tracked"; can be 5-10× larger than MAU
Platform-bundle	Flat monthly fee for a feature set	$500-$50K/month per tier	Feature gating — SSO, SCIM, MFA, custom domains gated to higher tiers
Per-feature add-on	Base price plus per-feature pricing	Varies wildly	Per-MAU charges that stack across enabled features
Hybrid	Combinations of the above	n/a	Combines the failure modes of multiple models

The per-MAU trap

Per-MAU pricing looks attractive on the pricing page — "$0.02 per active user!" — and most CIAM vendors lead with it. The complications:

What counts as "active" varies. Some vendors count a user who authenticated at least once in the month (the strict definition). Some count any user with an active session token. Some count any user record marked active in the system, regardless of authentication. The difference can be 3-10× billed users at the same usage level.

Long-tail inactive users still count. A user who created an account two years ago and hasn't logged in since may still appear as "active" depending on the vendor's definition. B2B trial users who never convert, abandoned signup flows, bot signups — all can pad the MAU count.

Bursty traffic patterns get priced at peak. Some vendors bill on monthly MAU but reset on a fixed calendar; a marketing event that spikes signups in one month bills against that month's high water mark for the next year.

Multi-tenant counting. A user with accounts in multiple B2B Organizations may count as multiple users on the customer's bill. Always confirm whether the per-MAU count is unique-user or per-Organization-user.

The procurement counter: get the active-user definition in writing in the contract. Ask the vendor to produce historical MAU counts based on their definition for a sample customer of similar scale. Compare to your expected user behavior model.

The MTU misnomer

MTU (Monthly Tracked Users) is used by some vendors as a deliberately broader unit. The pitch is sometimes framed as predictable pricing — "we count every user we touch, you know exactly what you'll be billed for". The reality is usually that MTU produces a larger billable unit at the same nominal per-unit price.

The contract language to watch:

• "Tracked user": defined by the vendor; can mean any user record they process.
• "Monthly active": typically the stricter definition, usually requires authentication.
• "Identity": vendor-specific term; varies widely.
• "User record" or "stored user": broadest definition; includes everyone in the database.

A vendor quoting $0.005 per MTU may end up materially more expensive than a competitor at $0.02 per MAU if the MTU count is 5× the MAU count at the same usage level. The pricing-page comparison misleads; the contract comparison is what matters.

The SSO tax

The pattern where enterprise SSO (SAML, OIDC) is gated behind a higher pricing tier than the base plan. Several CIAM vendors structure it this way:

• Base / Pro tier: passwords, social login, basic MFA, limited customization.
• Enterprise tier: SAML/OIDC SSO, SCIM, advanced MFA, custom domains, dedicated tenants, audit log export.

The tier delta is often 3-10× the base per-MAU price. The community-maintained sso.tax site documents the pattern across SaaS broadly; CIAM vendors are over-represented because they're built around the gate.

The argument against the SSO tax: SSO and SCIM are security features that benefit the customer's compliance posture; gating them behind enterprise pricing penalizes the customers who most need them and creates an adverse-selection dynamic where mid-market customers can't afford the secure tier.

The argument for: enterprise customers expect enterprise-grade support, SLAs, dedicated tenancy, and operational guarantees; the SSO/SCIM bundle is a packaging shorthand for the enterprise feature set, not a deliberate security paywall.

The 2026 movement: several vendors (Tailscale, Cal.com, some developer-focused CIAM platforms) have explicitly unbundled SSO from enterprise tiers. The major CIAM platforms mostly haven't, though the pricing structures continue to evolve. For a buyer, the practical implication is to identify which features you need over a 3-year horizon and confirm they're included at your projected MAU tier — not just the current tier.

The renewal escalator

The recurring CIAM cost surprise at year 2 and 3:

• Base growth: customer MAU has grown, so the bill is higher at the same per-MAU rate.
• Annual escalator: most CIAM contracts include 5-15% annual price increases on the per-unit rate or the platform fee. CPI-linked is sometimes available; uncapped escalators are common in standard contracts.
• Plan-tier creep: the customer needs a feature locked to a higher tier (often SSO/SCIM at the moment they sign their first enterprise customer), and migrating up tiers can multiply the bill.

The compounding can be material. A customer signing at $50K/year with a 10% escalator at 30% YoY growth ends year 3 at: $50K × 1.3³ × 1.1² = $130K. Plus any tier migration along the way.

The procurement counter, three negotiations:

1. Cap the escalator — 5% annual maximum, ideally CPI-linked. Standard for serious contracts; vendors will agree if pushed.
2. Lock the per-unit price at scale — get the per-MAU rate at 3× current scale in writing. Many vendors negotiate volume discounts for committed growth; structure them in upfront.
3. Lock the feature tier — confirm which features stay in your plan tier through 3 years of growth. If you're projecting SSO/SCIM needs, lock the enterprise tier price now rather than facing a step-function at year 2.

The scale curve

CIAM pricing curves are convex — per-unit costs decrease with volume, but slower than linearly. The trap: the price quoted at your current scale doesn't reflect what you'll pay if you 3× or 10× from there.

Typical curve shapes:

• 0-10K MAU: free or close to free at most vendors. Generous starter tiers; pricing barely moves.
• 10K-100K MAU: per-MAU pricing kicks in, typically $0.03-$0.10 per MAU. This is where most B2B SaaS lives and where pricing is most competitive.
• 100K-1M MAU: per-MAU drops to $0.01-$0.03; volume discounting starts mattering. Custom enterprise contracts displace pricing-page rates.
• 1M-10M+ MAU: heavily negotiated; per-MAU can drop to $0.001-$0.01 but the absolute bill is in the millions per year regardless. Many at-scale customers move to self-hosted CIAM (Keycloak, FusionAuth, Authentik) or partial self-hosting to escape the per-MAU model.

The right TCO model includes the bill at 1×, 3×, and 10× current scale. Vendors will sometimes resist quoting at hypothetical scale; insist or model conservatively from public pricing.

When open-source CIAM tilts the math

The build-vs-buy question covered fully in Build vs Buy CIAM. The cost-model summary:

• Below ~500K MAU: managed CIAM is usually cheaper all-in. License cost dominates the small infrastructure cost; engineering time to operate is meaningful overhead at low scale.
• 500K-2M MAU: the math tips depending on use case. Managed pricing at this scale can run $250K-$1M/year; self-hosted Keycloak or FusionAuth on enterprise infrastructure plus 1-2 FTE typically runs $300-600K/year. Toss-up; non-cost factors (operational risk, time-to-feature) often decide.
• 2M+ MAU: self-hosted is usually cheaper, sometimes dramatically. Managed pricing scales convex but not flat; self-hosted scales mostly with infrastructure, which is cheaper per-unit at scale.

The wrinkle: self-hosted CIAM ships fewer of the enterprise-feature primitives. Per-Organization B2B SSO with self-service IdP setup, advanced abuse defense, SCIM Directory Sync with all the major IdPs — these are managed-platform strengths. At very large scale the per-MAU savings may justify building or augmenting the self-hosted deployment; at sub-1M MAU the engineering cost typically doesn't.

Implementation guidance

1. Read the contract definition of MAU/MTU. Headline rates mislead; contract definitions decide the bill.
2. Cap the renewal escalator at 5-10% annual in the initial contract. Standard for serious negotiations.
3. Get pricing at 3× current scale in writing. Vendors will provide if pushed; this is the cost you'll actually face at year 2 or 3.
4. Identify features needed over 3 years and lock them in. Don't get caught by the tier-creep pattern when you need SSO/SCIM for a future enterprise customer.
5. Build the TCO model with realistic growth. Build vs Buy CIAM and the TCO calculator handle the framework; this guide's numbers fill in the cost-trap line items.
6. For high-scale or compliance-driven deployments, consider self-hosted as a serious alternative — the math tilts past ~1M MAU, especially with SOC 2 / HIPAA / FedRAMP requirements where dedicated tenancy adds cost in managed.
7. Track MAU on the customer side, not just the vendor's reported number. Disagreements at renewal are common; having your own counts makes the negotiation factual.