Because MAU counts any user who authenticates during the month as a full monthly unit, even if they only appear on one day. That means a short spike can be charged as if it defined the whole period. The result is a bill that follows monthly presence more closely than runtime load.
Why MAU pricing can overstate identity usage
MAU pricing turns identity consumption into a calendar-counting problem. A user who authenticates once during the month is usually counted as a full monthly active user, even if that person only touched the system briefly. That means the bill reflects monthly presence, not session length, transaction volume, or runtime load.
Why a short spike can look like sustained demand
The pricing model does not care whether activity was concentrated in one day or spread across thirty. If a campaign, onboarding wave, contractor cohort, or seasonal access burst causes many distinct users to authenticate, the cost can rise sharply even when overall usage hours remain modest. The pricing signal is therefore sensitive to breadth of access, not depth of use.
That makes MAU useful for vendors because it tracks how many unique identities must be supported and billed, but it can feel counterintuitive to buyers who expect cost to move with infrastructure consumption. A light-touch account that logs in once and a heavily used account that logs in every day may both count the same for billing if they are each active in the month.
Where the mismatch shows up in budgeting and forecasting
MAU-based billing can make identity spend appear volatile even when the underlying workload is stable. Small changes in population, such as adding temporary staff or giving more people direct access instead of shared access paths, can move the invoice more than the actual business activity they support. In practice, that means finance teams need to model user-count growth separately from system load growth.
It also means the metric is a poor proxy for peak concurrency or security exposure. A monthly active user may have authenticated for a single report download, a one-off approval, or a brief support interaction, yet still be priced as a full month. If you only watch runtime telemetry, the bill can look inflated because billing is counting identity events across the month, not CPU minutes or storage bytes.
Risk and Threat Considerations
MAU pricing can create planning risk when organisations assume identity cost scales linearly with actual system usage. A short-lived access surge can push the invoice up for the whole month, and that makes onboarding campaigns, audits, or seasonal access changes more expensive than the activity profile suggests.
Failure mechanism: Billing counts unique authenticating identities over a month, so a temporary increase in distinct users is priced like persistent demand even when access was brief.
Impact: Forecasts can understate spend, teams may delay access expansion for budget reasons, and cost reviews may misread normal identity growth as inefficient platform use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | MAU billing is driven by user authentication events and active user populations. |
| IA-5 — Authenticator Management | Monthly active user counts are triggered by authenticators being used during the month. | |
| Recommendation — Track authenticated-user counts separately from runtime usage to forecast identity spend accurately. Review authenticator-driven activation patterns when estimating monthly identity charges. | ||
| CIS Controls v8 | CIS-5 — Account Management | Monthly identity billing is affected by how many accounts are active and used. |
| Recommendation — Reconcile active-account inventory against billed MAU populations before budgeting. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems are inventoried | MAU pricing needs an accurate inventory of active identities and users for cost control. |
| Recommendation — Maintain an inventory of active users so MAU growth can be explained and planned. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access decisions determine which identities can authenticate and therefore affect MAU cost. |
| Recommendation — Limit unnecessary access paths that inflate the count of monthly authenticating users. | ||
Practitioner Guidance
What to measure: Track MAU alongside session frequency, median days active per user, and the ratio of transient users to steady users. That gives you the difference between one-time access and recurring demand, which is the real driver of cost surprises.
Decision rule: If the main growth comes from short-duration users, treat the bill as a population-management problem, not a usage-efficiency problem. If the main growth comes from a smaller set of users authenticating more often, MAU pricing is probably not the root issue.
Practitioner takeaway: The important judgement is to separate identity breadth from system intensity, because MAU prices the number of distinct authenticating users, not how much they actually consume.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org