Average Activity Days

The spread component of an application usage score. It measures how many distinct days activity occurs, which helps separate concentrated bursts from steady use across time. This is useful because the same number of actions can represent very different usage patterns depending on whether they happen in one day or across many.

Expanded Definition

Average Activity Days describes the spread of usage across time, not just total volume. A value is higher when the same application or identity shows activity on more distinct calendar days, and lower when actions are concentrated into short bursts. That distinction matters because two entities can produce the same count of events while reflecting very different operating patterns.

In security and identity analytics, this term is often used alongside related activity measures such as total actions, active span, and frequency. It helps separate a steadily used account from one that appears dormant except for periodic spikes. For NHIs, that boundary is especially useful because service accounts, API keys, and workload identities often have predictable schedules. A change in day-level spread can indicate automation drift, a new integration, or a lifecycle issue rather than normal human-like variance.

Definitions are usually consistent at a conceptual level, but implementations vary in the window used, how partial days are counted, and whether weekends or maintenance windows are treated specially. Those details can change the score without changing the underlying behaviour.

Examples and Use Cases

Average Activity Days shows up anywhere practitioners need to understand whether usage is routine or bursty.

• A CI/CD service account that runs every weekday will score differently from one that only appears during release weekends.
• An API token used across many distinct days can suggest stable integration traffic, while the same request count compressed into one day may reflect a one-off job or replayed automation.
• A workload identity that suddenly starts appearing on more days than usual may indicate a new dependency, a broader rollout, or an access pattern change that should be reviewed.
• A dormant NHI that becomes active on scattered days after a long quiet period may warrant investigation because the pattern no longer matches its historical use.

The main trade-off is sensitivity versus context. Short observation windows can make ordinary usage look erratic, while long windows can smooth away meaningful shifts. For that reason, the metric is most useful when read with surrounding lifecycle data rather than in isolation.

Security Implications

When Average Activity Days is misread, teams can miss the difference between a steady production identity and a bursty or anomalous one. That creates blind spots in detection, especially for machine identities that are assumed to behave consistently. A sudden increase in the number of active days can signal wider exposure, new integrations, or a compromise that is being used intermittently to avoid obvious spikes.

Low visibility compounds the problem. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, which means activity spread is often being interpreted with incomplete inventory and ownership data. In practice, a metric like this is most useful when it is tied to a known identity, a known business function, and an expected operating rhythm.

Common failure modes include treating high spread as automatically healthy, or treating irregular spread as automatically malicious. Either mistake can lead to missed offboarding issues, stale credentials that remain usable, or activity that is never reconciled against expected job schedules.

Domain and Governance Relevance

Average Activity Days matters most in NHI governance because machine identities are usually evaluated by behaviour over time, not by a single login event. For service accounts, tokens, and workload identities, the day-level spread can help distinguish planned automation from accidental reuse, fragmented ownership, or an access path that has expanded beyond its original purpose.

That makes the metric useful for lifecycle review, attestation, and anomaly detection. A stable identity with a narrow, predictable pattern is easier to govern than one whose activity footprint keeps widening without a documented change. In an NHI program, this kind of signal supports better decisions about rotation timing, offboarding readiness, and whether a credential still matches its intended workload.

It also fits the broader assurance problem described in Ultimate Guide to NHIs, where operational control depends on seeing how identities are used, not just whether they exist.

Related resources from NHI Mgmt Group

• How should security teams monitor AI agent activity without disrupting developers?
• How can SOC teams use identity context to improve response to agent activity?
• What is the difference between activity metrics and risk metrics in IAM?
• How can organisations tell legitimate automation from compromised service account activity?