How do organisations know whether platform adoption is healthy after onboarding a new team?

Why This Matters for Security Teams

Platform adoption is not proven by a successful rollout alone. Security teams need evidence that the new team is actually using the platform in the workflows it was meant to support, because unused access becomes stale access, and stale access is where risk accumulates. NHI Mgmt Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is a useful reminder that activity measurement is often weaker than provisioning control.

Healthy adoption is visible in recurring logins, meaningful session activity, and a spread of use across the intended user base. That is different from counting accounts created or licenses assigned. In practice, teams often discover too late that one sponsor or power user drove the onboarding, while the rest of the group never embedded the platform into daily work. The result is poor return on investment, lingering access for inactive users, and a false sense that onboarding was successful. Best practice is to compare onboarding numbers against recent activity and investigate gaps by team, role, and location. In practice, many security teams encounter low adoption only after access reviews or renewal cycles reveal it, rather than through intentional monitoring.

How It Works in Practice

Healthy adoption tracking starts with a simple control question: who was onboarded, who has actually used the platform, and how recently? Teams should measure activity over a defined window, then compare it with onboarding cohorts to identify dead accounts, one-time users, and teams that never moved beyond pilot behaviour. For identity-rich platforms, the same discipline used for NHI lifecycle control applies here: visibility, recency, and purpose matter more than raw account counts. NHI Mgmt Group’s Ultimate Guide to NHIs is useful background because the same visibility gap that affects service accounts also affects platform adoption metrics.

In practice, security and platform teams should look at:

• Login frequency by intended user group, not just by tenant or department.
• Time since last activity for each onboarded account.
• Activity concentration, where adoption is limited to a small number of champions.
• Workflow depth, meaning whether users are doing only basic access or using core functions.
• Exceptions such as service accounts, test users, and disabled teams that can skew counts.

This same evidence-based approach aligns with broader identity and resilience guidance. The FATF Recommendations are not an adoption framework, but they reinforce the operational value of traceability, accountability, and monitored use. Current guidance suggests pairing access logs with business context so inactive users are not mistaken for seasonal or project-based exceptions. These controls tend to break down when the platform lacks reliable audit data, because no one can distinguish low adoption from missing telemetry.

Common Variations and Edge Cases

Tighter adoption monitoring often increases operational overhead, requiring organisations to balance visibility against noise and review burden. That tradeoff is real, especially when new teams include contractors, shift workers, or regional groups with uneven usage patterns. The goal is not to force identical usage across every person, but to identify whether the platform has become part of the intended operating model.

There is no universal standard for what counts as “healthy” adoption. Best practice is evolving, but current guidance suggests setting thresholds by team type: for example, a support function may need near-daily activity, while a project team may only need periodic use during delivery windows. Adoption can also look artificially weak when users rely on a few delegated operators, shared workspaces, or downstream automation instead of direct logins. That is why activity should be interpreted alongside workflow design, not in isolation.

Security teams should be cautious when interpreting temporary spikes. Training weeks, migration periods, and go-live support often inflate usage and then fall back. A platform is usually healthy when activity persists after the launch window closes, when inactive accounts are reviewed, and when team-by-team gaps shrink over time. The practical test is whether access, usage, and business process alignment move together. If they do not, the platform is present but not embedded, and adoption remains superficial.

Related resources from NHI Mgmt Group

• How do organisations know whether a new IAM platform is actually reducing risk?
• How can organisations know whether their detections still work after platform changes?
• How do organisations know whether their infrastructure access controls are actually reducing risk?
• How do organisations know whether an IAM platform is covering the right apps?