When does MAU billing become a poor fit for identity infrastructure?

Why This Matters for Security Teams

MAU billing works best when identity activity is steady and easy to predict. It becomes a poor fit when authentication demand is bursty, tied to campaigns, or driven by short-lived operational events, because the monthly bill starts to reflect peak presence instead of real service consumption. That distorts chargeback, makes forecasting noisy, and can hide whether IAM cost is actually growing or merely spiking.

This matters most in environments where identity is part of a broader control plane. If service accounts, workforce identities, and non-human identities all touch the same platform, cost pressure can push teams toward under-provisioning or delayed governance work. NHI Management Group has shown how often organisations still struggle with visibility and privilege sprawl in Ultimate Guide to NHIs, which is exactly why usage-based billing can become politically harder to defend than technically to operate. NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls also reinforces that governance should track actual control outcomes, not just monthly account counts.

In practice, many security teams discover the billing problem only after a seasonal launch, incident response surge, or partner onboarding wave has already made the invoice hard to explain.

How It Works in Practice

The key question is whether identities are measured by average use or by peak monthly presence. MAU pricing is usually defensible when users return regularly, sessions are spread across the month, and the number of active identities is a reasonable proxy for platform load. It is a weaker fit when access is event-driven, because a single login during a month can count the same as a power user who authenticates daily.

That is why MAU often misaligns with infrastructure identity, especially where automation, temporary access, and delegated administration dominate. For example, a platform that issues access for maintenance windows, incident response, or developer sandboxes may have low day-to-day activity but sharp spikes when work happens. In those scenarios, the invoice can overstate operational demand while underrepresenting how much identity governance is actually required. NHI research from Top 10 NHI Issues shows why this matters: identity sprawl and excessive privileges are already common, so pricing that rewards high account counts can become detached from risk and control effort. For control baselines, teams should tie billing analysis back to NIST SP 800-53 Rev 5 Security and Privacy Controls and verify whether the measured unit actually matches the security unit being governed.

• Use MAU when login frequency is relatively stable across the month.
• Avoid MAU when one-off events drive most identity activity.
• Compare billing units against actual control-plane workload, not just account counts.
• For NHI-heavy environments, assess whether access creation, rotation, and revocation are the true cost drivers.

These controls tend to break down when identity usage is dominated by rare but high-volume operational events because monthly active counts flatten distinct workload patterns into one billing signal.

Common Variations and Edge Cases

Tighter billing alignment often improves fairness, but it also increases metering complexity, requiring organisations to balance forecasting accuracy against operational overhead. That tradeoff becomes more visible in hybrid environments where workforce users, partners, and NHIs are billed differently, or where a platform vendor defines “active” in a way that does not match internal reporting.

There is no universal standard for this yet. Some teams move toward per-authentication, per-seat, or tiered capacity models when MAU becomes too volatile, while others keep MAU but build internal smoothing rules for chargeback and budget planning. The right answer depends on whether the identity platform is being bought as a human-user service or as shared infrastructure for machines, workflows, and agents. If the environment includes large numbers of dormant accounts, short-lived tokens, or third-party access, the billing model may also mask security work that never shows up in monthly averages. NHIMG’s 52 NHI Breaches Analysis is a reminder that identity failures are rarely uniform; they cluster around exposure, privilege, and delayed revocation, not around a neat monthly usage curve.

Best practice is evolving toward billing models that distinguish steady-state identity traffic from burst-driven access, especially where IAM is also serving governance and machine identity use cases.

Related resources from NHI Mgmt Group

• When does a machine identity become a compliance problem?
• When does secret exposure become a broader identity risk?
• When does legacy PAM become a poor fit for modern infrastructure?
• When does vault-based PAM become a poor fit for modern infrastructure?