Step-up status shows why phishing-resistant checks must be chained

At a glance

What this is: This is a design note on chaining phishing-resistant step-up checks before sensitive actions, with the key finding that OTP-based factors remain unsuitable for high-risk policies.

Why it matters: It matters because IAM, PAM, and NHI programmes need assurance controls that bind approval to intent, survive phishing, and produce audit evidence for high-blast-radius changes.

Context

Step-up in this context means escalating assurance before a sensitive action, not adding another login prompt. The governance gap is that many programmes still treat every challenge as equivalent even though the attack surface changes sharply once users can reset passwords, change payout destinations, enroll new devices, or alter federation settings.

Scramble ID's design note argues for chaining phishing-resistant checks that are bound to the initiating session and action. That shifts the control objective from generic authentication strength to verifiable intent, measurable outcomes, and auditability across web, desktop, IVR, and machine-to-machine flows.

The model is relevant to IAM, PAM, and non-human identity governance because the same step-up logic increasingly gates privileged workforce actions, customer changes, and custodian-approved token minting. The starting position described here is a design pattern under development, not a shipping control.

Key questions

Q: What breaks when step-up is implemented as a generic prompt instead of an action-bound check?

A: A generic prompt proves only that a challenge was answered, not that the answer was tied to a specific sensitive action. That leaves room for relay, replay, and approval fatigue to satisfy policy without genuine intent. High-risk identity governance needs proof that the approval is bound to the exact request, session, and relying application.

Q: Why do SMS or voice OTPs remain unsuitable for high-risk identity policies?

A: They remain unsuitable because they are readable, relayable, and often socially engineered through SIM swap, carrier compromise, or adversary-in-the-middle phishing. For sensitive actions, the control must prove possession through non-reusable cryptographic evidence rather than a secret that a user can copy or recite.

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.

Q: How should identity teams design step-up for workforce and machine-to-machine flows?

A: Use the same governance principle across both: only allow the protected action after a signed, session-bound proof is returned. Workforce flows may use WebAuthn or hardware keys, while machine-to-machine flows may use a human custodian approving a short-lived scoped token. The control objective is the same even when the channel differs.

Technical breakdown

Why step-up must bind to intent

A step-up flow only changes the risk equation when it is tied to the protected action, the active session, and the verification event. That is what distinguishes policy-selected assurance from a generic prompt. In practical terms, the system has to prove that the person or custodian approved this specific change in this specific context, rather than merely proving that some factor was satisfied. Public-key proof, origin binding, and session binding matter because they create a verifiable link between request and approval. Without that link, an attacker who can relay or replay the challenge can still satisfy the control while bypassing its intended meaning.

Practical implication: bind step-up to the exact action and session so the approval cannot be reused elsewhere.

Why reusable secrets weaken high-risk step-up

Reusable secrets such as OTPs are weak for high-risk actions because they can be copied, relayed, or coerced. The article's core argument is that a factor is only phishing-resistant when it does not depend on something a user can read aloud or forward. That is why WebAuthn with user verification, hardware security keys, and signed cross-device codes are preferred for sensitive actions. They shift the trust anchor away from a human-readable secret and toward cryptographic proof that is harder to intercept in real time. This is a control-design issue, not just a user-experience preference.

Practical implication: reserve OTP-style factors for low-risk use cases and require cryptographic proof for sensitive actions.

How signed step-up results support audit and enforcement

The design returns a signed result artifact that the application can verify before allowing the protected action. That matters because the application, not the identity prompt, is where business risk is actually released. A signed result gives the relying surface a way to enforce allow or deny decisions, record correlation, and prove which chain ran. This is especially important in IVR, helpdesk, and machine-to-machine scenarios where the approving party and the protected action may be separated by channel. The architecture makes step-up a control outcome, not just an interaction record.

Practical implication: treat the signed result as the enforcement object and log it with the protected action.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Mailchimp breach 2022: Attackers socially engineered Mailchimp staff, used a support tool to export 102 customer lists and exposed customer API keys for phishing.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Phishing-resistant step-up is an intent-control problem, not a prompt-management problem. The article's strongest insight is that high-risk actions need an approval chain that is cryptographically tied to the action being protected. That is materially different from asking users to satisfy a factor more often. For identity governance, the unit of control shifts from authentication event to action-specific proof, which is the right mental model for privileged workforce flows, customer changes, and custodian-approved machine actions.

Reusable secrets collapse under adversary-in-the-middle pressure. OTPs remain readable, relayable, and socially engineerable, so they do not reliably prove possession under attack. The article's rejection of SMS, voice, and WhatsApp OTP for high-risk policies is a governance statement about trust boundaries, not just a transport preference. Programmes that still allow those factors for sensitive actions are accepting a control that can be satisfied without the actor truly controlling the session.

Action-bound step-up is a named governance pattern: session-bound assurance. The article describes a control that binds origin, session, and action into a signed verification result. That pattern is more useful than generic phishing-resistant MFA language because it tells architects what actually has to be tied together. Practitioners should treat session-bound assurance as the design objective when the cost of a mistaken allow decision is high.

Measurability is part of the control, not a reporting afterthought. The article's emphasis on rates, pass or fail, abandon, and median time shows that assurance controls become governable only when they can be measured. That matters because identity teams cannot improve what they cannot instrument. The practical implication is to design step-up as an auditable control with operational KPIs, not as an invisible policy layer.

Channel-aware step-up extends identity governance beyond the browser. The same assurance logic has to work in web, desktop, IVR, people verification, and machine-to-machine contexts. That broad applicability matters because modern identity programmes increasingly span human and non-human workflows. The control model should therefore be written around protected actions and trust evidence, not around a single front-end channel.

From our research library:

• The IBM/Ponemon 2025 Cost of a Data Breach Report found that phishing-initiated breaches cost an average of $4.8M each.

What this signals

Session-bound assurance: Identity teams should stop treating step-up as a universal challenge layer and start designing it as proof tied to the action, the session, and the application that is about to release risk. That design choice is what separates a meaningful gate from a user prompt that an attacker can route around.

The next governance question is where to draw the line between low-risk convenience and high-risk enforcement. If the action can change money movement, federation trust, or device enrollment, the approval flow should be cryptographically bound and auditable before the action is released.

For practitioners

• Define high-risk action lists Start with the two or three actions that carry the largest blast radius, such as payout destination changes, password resets, device enrollment, or federation key changes. Map each action to a distinct step-up chain rather than a universal policy.
• Replace reusable secrets for sensitive gates Remove SMS, voice, and email OTP from policies that protect privileged or financially material actions. Use phishing-resistant checks that rely on public-key proof, user verification, and session binding instead.
• Bind the challenge to the protected action Make the user interface show the exact action being approved, the application or domain requesting it, and the expiry of the request. Do not allow a generic approve-anywhere prompt to satisfy a high-risk policy.
• Instrument step-up outcomes end to end Log chain invocation, pass or fail, timeout, abandon rate, and median completion time with a correlation ID so the enforcement point and the audit trail stay aligned.

Key takeaways

• High-risk step-up works only when the verification is tied to the protected action and not treated as a generic challenge.
• SMS, voice, and other reusable-secret factors remain weak for sensitive policies because they can be relayed, replayed, or socially engineered.
• The control becomes governable when teams measure pass rates, failures, abandonment, and completion time at the action level.

Key terms

• Phishing-resistant step-up: A step-up control that requires additional proof before a sensitive action is allowed, using methods that cannot be easily relayed or reused by an attacker. In practice, it binds assurance to the session and action so the result can be verified and audited.
• Session Binding: A control that ties an authenticated session to the device, connection, or risk context that created it. When applied well, it makes stolen cookies harder to reuse from an untrusted endpoint or a different network context.
• Signed result artifact: A signed result artifact is a verifiable record that a step-up chain completed successfully for a defined action. It gives the application an enforcement object, not just a UI event, and supports audit, correlation, and allow-or-deny decisions.
• High-blast-radius action: A high-blast-radius action is a change that can quickly expand the impact of compromise, such as password resets, payout changes, device enrollment, or federation key updates. These actions need stronger proof because a mistaken allow decision can create immediate downstream risk.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.