What are the best ways to forecast identity spend for spiky applications?

How to forecast identity spend when traffic does not stay flat

Forecasting works best when you model the traffic shape that actually drives authentication and directory load. A spiky app often has a small baseline, then sharp jumps from launches, campaigns, or seasonality, so the spend model should separate the steady component from the burst component instead of averaging them together. That gives finance a truer cost envelope and helps IAM teams avoid under-sizing controls.

For the identity layer, the right question is not only how many users exist, but how often they authenticate, how many tokens or sessions they generate, and whether peak periods change the mix of interactive, service, or delegated access. Those patterns matter because some identity costs scale with active usage, while others scale with configured capacity, licensing tier, or the need to absorb peak bursts without failure.

Which usage segments should you model separately?

The most useful segmentation is usually by demand pattern, not by business unit alone. Steady-state traffic forms the baseline, weekend or off-hours traffic often reveals idle inefficiency, and campaign or event traffic exposes the upper bound that determines short-term cost spikes. If a product has multiple regions or customer cohorts, keep those separate when they produce different authentication curves.

In practice, segmenting by MAU and aDAU only works if you keep the segments honest about behaviour. Two workloads with the same monthly user count can have very different identity spend if one has short-lived bursts and the other spreads the same volume across the month. Comparing those curves lets you estimate whether spend will rise linearly, step up at thresholds, or jump only during a narrow window.

For the most stable forecast, compare each segment against the controls that actually consume budget: directory calls, federation traffic, MFA challenges, token issuance, access reviews, and any premium identity tier required for resilience or automation. That lets you connect usage assumptions to cost drivers instead of assuming one flat per-user price.

How should finance and IAM teams turn peaks into a budget model?

The simplest reliable model is baseline plus burst capacity. Baseline covers normal authentication and lifecycle operations, while burst capacity covers launch windows, retries, and sudden concurrency increases. This approach is more accurate than annualising a single monthly average because identity services often fail or bill differently once peaks cross an internal threshold.

Historical curves are the best starting point, but they should be read as demand signals, not proof of future shape. A launch can change the peak-to-average ratio, and a seasonal campaign can move the busy period rather than just increase it. Forecasts should therefore include a best case, expected case, and stress case so that budget owners can see the cost spread before commitments are made.

Where identity pricing is tied to tiers or feature bundles, an identity provider buying model should be tested against the same traffic assumptions, because licensing and platform selection can change the forecast as much as raw usage. For a broader operating model view, an identity security programme helps align funding, ownership, and demand planning across teams. If non-human access is part of the workload mix, the NHI overview is a useful reference for understanding which access paths may scale differently from human sign-ins.

What tends to break the forecast in real deployments?

Forecasts usually fail when teams treat sign-ins as the only signal. Spiky applications often create hidden identity demand through retries, token refreshes, step-up authentication, delegated access, and service interactions that do not show up in a simple monthly login count. If those paths are omitted, the forecast understates both load and cost.

Another common failure is mixing populations that behave differently. Human users, customer accounts, service-to-service access, and admin activity may all share the same platform, but they rarely share the same volume pattern or cost sensitivity. If you merge them too early, peak exposure looks smaller than it really is, and the forecast misses the operational pressure during launch or incident recovery.

Finally, forecasts drift when the team does not revisit them after a major release, pricing change, or authentication policy change. A better model is one that is recalibrated after each spike, so that forecast accuracy improves over time instead of being reset every planning cycle.

Practitioner Guidance

What to prioritise: Start with the usage segments that create the largest cost variance, not the segments that are easiest to count. A forecast that misses the top one or two burst patterns is usually less useful than a simpler model that tracks them well.

What to verify: Check whether the forecast is anchored to observed peak concurrency and authentication frequency, not just average MAU. If the model cannot explain why cost rises during a launch week, it is probably too coarse to trust.

Decision rule: If a workload has recurring spikes, build the budget around the burst profile and treat the average as a secondary sanity check. If the spike is one-off, isolate it as an exception so it does not distort the baseline for the rest of the year.

Practitioner takeaway: The best identity spend forecasts are curve-based, not headcount-based, because cost follows how access is consumed under pressure, not just how many accounts exist.

Related resources from NHI Mgmt Group

• When does a machine identity become a compliance problem?
• Why is it important to integrate identity and data governance?
• How should security teams make NHI best practices usable across the business?
• When does secret exposure become a broader identity risk?