How should teams verify a high-risk request before trusting a caller?

How to verify a high-risk request before you trust the caller

High-risk requests should be treated as untrusted until the caller proves continuity across more than one signal. The practical test is not whether the message sounds plausible, but whether the request can be verified through an independent channel and against the caller’s normal authentication pattern before any approval or privileged action is taken.

That means teams should combine callback-style verification with contextual checks that are hard to fake in one interaction: known contact routes, prior session history, device continuity, and whether the current request matches the caller’s usual authentication context. If the request is unusual, urgent, or would create material exposure, step-up verification should be mandatory rather than optional.

For requests that move money, change access, release sensitive data, or override controls, the safest assumption is that the initial channel may be compromised. The stronger the consequence, the more the verification should rely on evidence the attacker is less likely to control at the same time as the message itself. A caller who can initiate the request but cannot reproduce their normal device, location, or second factor should not be trusted on the strength of the request alone.

Using device continuity and recent authentication context is especially useful because it tests whether the request fits the identity’s established behaviour. Teams should compare the claimed caller against the expected user, session, and device pattern, then challenge anything that breaks the pattern before acting on it.

What makes a request trustworthy enough to approve?

Trust should be earned from corroboration, not from confidence in tone, urgency, or familiarity. A trustworthy approval path usually combines at least two independent checks: a second channel that confirms the request, and a separate control that confirms the caller still controls the claimed identity at the moment of approval.

In practice, the most useful evidence is consistency. A request is stronger when the contact method is already known, the device has been seen before, the session history is normal, and the second factor is tied to the same identity that made the request. A request becomes weaker when any of those elements are new, missing, or unexpectedly different.

The aim is to avoid trusting a single point of contact. If the request arrived through email, chat, or a help desk ticket, verify it through a different route that is already established for that person or process. If the caller claims to be a privileged user, do not rely on the same conversation to validate both identity and intent.

When should teams escalate to step-up verification?

Escalation is warranted when the request is high impact, time sensitive, or abnormal for the caller’s pattern. A request that is outside normal hours, comes from a new device, originates from a new location, or follows a fresh authentication context should trigger additional checks before approval.

Step-up verification is also appropriate when the request would bypass a safeguard that normally slows or separates decision-making. If the action would change access, approve an exception, or expose a sensitive system, the caller should be asked to re-authenticate through a stronger path or confirm the request through a known independent contact method.

Where teams use phishing-resistant authentication, the value is not only in reducing impersonation, but in making the approval decision depend on an identity proof that is harder to replay across channels. NIST SP 800-63 Digital Identity Guidelines is useful here because it ties strong authentication and authenticator assurance to the quality of the verification step itself.

Risk and Threat Considerations

High-risk request verification fails when teams treat a familiar-looking message as proof of identity. Attackers often rely on urgency, social familiarity, or a compromised communication channel to push an approval before the target checks a second path. If the approval process does not challenge device, location, or session continuity, it becomes easier for a spoofed or compromised caller to succeed.

Failure mechanism: The attacker abuses trust in the initial request channel, then wins approval because the verifier does not independently confirm the caller through a separate route or compare the request to prior authentication behaviour.

Impact: The result can be unauthorized access, privilege change, payment fraud, data exposure, or an exception that bypasses normal controls and is difficult to unwind after the fact.

Practitioner Guidance

What to verify: Confirm that the approval comes through a known independent channel, not only through the channel where the request first appeared. For high-risk actions, verify both the request and the requester, not just the wording of the request.

Decision rule: If the device, location, or recent authentication context does not match the caller’s normal pattern, treat the request as untrusted until step-up verification succeeds. If the request is urgent and unusual at the same time, raise the bar further rather than lowering it.

What good looks like: The approver can explain why the request matches the caller’s normal behaviour, what independent evidence was checked, and which verification step would have blocked the request if the caller had been impersonated.

Practitioner takeaway: The safest approval path is the one that forces an attacker to satisfy two different verification stories at once, not one persuasive conversation.

Related resources from NHI Mgmt Group

• Why do organisations need to verify identity at every access request for high-risk digital services?
• What happens when merchants do not verify identity before high-risk online transactions?
• How should teams verify bearer access tokens before trusting a caller in their API?
• How should organisations verify B2B customers before extending credit or onboarding them in high-risk markets?