How can organisations measure whether step-up is working?

Why This Matters for Security Teams

Step-up is only useful if it changes attacker outcomes without turning high-risk actions into a frustration factory for legitimate users. Security teams often focus on whether the prompt appears, but the real question is whether the control actually blocks risky behaviour, preserves completion on approved actions, and stays narrowly targeted. That means measuring both security effect and user friction at the same time, not treating them as separate dashboards.

This is especially important in NHI and privileged access workflows, where poor step-up design can push teams toward blanket exemptions or static allowlists. NHI Management Group notes in the Ultimate Guide to NHIs that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why step-up has to be measured against real abuse scenarios, not just login events. The measurement baseline should align with the NIST Cybersecurity Framework 2.0, especially where access control and continuous improvement are tied together.

In practice, many security teams discover step-up failures only after users develop workarounds or attackers find low-friction paths around the control, rather than through intentional measurement.

How It Works in Practice

A workable measurement model starts by tying step-up events to specific actions, not to a generic authentication count. High-risk actions should have their own baseline metrics so teams can see whether the control is reducing abuse where it matters most. Typical signals include step-up rate by action, pass and fail rate, median time to complete, timeout frequency, retry rate, and abandon rate. Security teams should also track whether the action was completed after step-up, whether the attempt was denied, and whether the same identity immediately retried through another path.

Current guidance suggests comparing these numbers across risk tiers. For example, a privileged API key rotation may tolerate a slightly longer step-up than a routine read operation, but a spike in abandon rate may signal that the challenge is too slow, poorly timed, or misaligned with the real workflow. This is where step-up should be measured alongside control outcomes, not just authentication ergonomics. The NIST CSF guidance on risk management supports this kind of operational evidence, and the broader NHI lifecycle guidance in Ultimate Guide to NHIs is useful for understanding how access decisions fit into secrets governance, rotation, and offboarding.

• Track step-up by action type, identity type, and risk score.
• Compare pass, fail, timeout, and abandon rates before and after policy changes.
• Measure time to complete against business-critical workflows, not against a single global average.
• Look for helpdesk spikes, repeated retries, and policy bypass attempts after rollout.
• Validate whether high-risk abuse drops without a matching rise in false blocks.

The best signal is not that more users complete step-up, but that fewer risky actions succeed without approval while legitimate users continue to finish the task. These controls tend to break down when the same policy is applied to every action and every identity, because the challenge becomes either too broad for users or too weak for attackers.

Common Variations and Edge Cases

Tighter step-up often increases user friction and support overhead, requiring organisations to balance stronger assurance against workflow disruption. That tradeoff is especially visible in service-heavy environments, where step-up may be rare but extremely costly when it interrupts automation or time-sensitive operations.

There is no universal standard for this yet, so teams should treat some metrics as directional rather than absolute. For example, a low pass rate may indicate a strong control, or it may mean the challenge is poorly designed. A high abandon rate may point to user fatigue, but it can also signal that the policy is correctly stopping risky behaviour. The right interpretation depends on whether the control is protecting human accounts, privileged admins, service accounts, or API-driven workflows.

One useful way to reduce ambiguity is to separate outcome metrics from friction metrics. Outcome metrics answer whether abuse dropped. Friction metrics answer whether the legitimate path became too expensive. In NHI-heavy environments, where secrets and non-human identities already carry elevated operational risk, that distinction matters. The Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0 both support the broader principle: controls should be monitored for effectiveness, not merely deployed.

Step-up measurement becomes least reliable when organisations exempt too many “trusted” paths, because the control appears healthy on paper while attackers simply move to the easier route.

Related resources from NHI Mgmt Group

• How should organisations measure whether identity governance is actually working?
• How should organisations measure whether ASPM is working?
• How can organisations measure whether technique-level detection is working?
• What should organisations measure to know whether browser security is working?