Notifications
Clear all
Topic starter
22/06/2026 5:02 pm
TL;DR: Step-up is increasingly framed as a policy-selected chain of phishing-resistant checks for sensitive actions, not another prompt layer, according to Scramble ID. The governance question is no longer whether step-up exists, but whether it is bound to intent, measurable, and resilient enough to defend high-blast-radius actions, while SMS or voice OTP remains unsuitable for high-risk policies because replay, relay, SIM-swap, and carrier social engineering remain practical bypass paths.
NHIMG editorial — based on content published by Scramble ID: XFactor Step-Up Status (June 2026)
Questions worth separating out
Q: How should security teams implement step-up for high-risk actions?
A: Start by tying step-up to a short list of sensitive actions such as payout changes, recovery updates, and privileged configuration changes.
Q: Why do OTP-based step-up flows fail for sensitive access?
A: OTP-based flows fail because the secret can be relayed, replayed, or socially engineered in real time.
Q: What do identity teams get wrong about step-up authentication?
A: Teams often treat step-up as extra friction at login instead of a governance control for specific transactions.
Practitioner guidance
- Map step-up to protected actions, not login states Identify the small set of actions that change money movement, recovery paths, delegated trust, or privileged configuration, then require chained assurance only there.
- Remove OTP from high-risk policy paths Replace SMS, voice, and email OTP with phishing-resistant proofs for actions that would cause irreversible impact if abused.
- Make every approval auditable as a signed artefact Store the correlation identifier, protected action, factor chain, outcome, and timeout result so audit and incident teams can verify what happened without reconstructing the flow from logs alone.
What's in the full article
Scramble ID's full product post covers the operational detail this post intentionally leaves for the source:
- Factor-by-factor policy examples for WebAuthn, hardware keys, signed QR, and device re-checks
- Copy templates for protected actions, failure states, and cross-device approval flows
- Rollout guidance for the top 2 to 3 high-risk actions and the metrics to tune after launch
- Accessibility and localisation checks for timeouts, code entry, and voice alternatives
👉 Read Scramble ID's design preview for policy-selected phishing-resistant step-up chains →
Phishing-resistant step-up chains: are your controls keeping up?
Explore further
22/06/2026 5:15 pm
Step-up is becoming a transaction-control problem, not an authentication problem. The article’s design shows that the decisive boundary is the sensitive action, not the initial sign-in event. Once teams move from login to payout changes, recovery resets, or admin configuration changes, the control must prove intent at the moment of risk. That is why step-up belongs in the same governance conversation as PAM and high-risk workflow approvals, not only MFA rollout. Practitioners should treat this as a control-placement decision, not a factor-choice exercise.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, which shows how quickly assurance claims diverge from operational behaviour.
A question worth separating out:
Q: How can organisations measure whether step-up is working?
A: Measure step-up rate by action, pass and fail rates, time to complete, timeout frequency, and abandon rate. If the control is working, it should reduce abuse on high-risk actions without creating broad user workarounds or excessive helpdesk escalation.
👉 Read our full editorial: Step-up status shows why phishing-resistant checks must be chained
