Caller verification fails when customers are sent to new websites

At a glance

What this is: This is an analysis of why out-of-band caller verification fails when it relies on a separate portal, and why anchoring verification to a known website materially changes the fraud model.

Why it matters: It matters because identity teams handling customer authentication, support-line access, and fraud workflows need verification patterns that resist redirection, impersonation, and social engineering rather than simply adding another step.

By the numbers:

• In 2025, the FTC reported about $16 billion in fraud losses, the highest total on record.
• Phone scams cost a median of around $1,500 per victim, making them more expensive per person than other channels.
• 442% between the first and second halves of, and second halves of 2024.

👉 Read Trusona's analysis of why separate caller verification portals fail

Context

Caller verification is meant to help a customer confirm that a person on the phone is genuine, but the model fails if the customer has to visit a new site the caller controls or introduces. In that design, the attacker does not need to defeat verification. They only need to redirect it, which turns the check into one more instruction in the scam.

For identity and fraud teams, this is a governance problem as much as a UX problem. A verification step that depends on a destination the customer does not already trust is weak against impersonation, redirection, and call-script manipulation, even when caller ID appears authentic.

The article frames this as a safer alternative to portal-based verification by anchoring the check to the customer’s own website or app. That starting position is typical of modern fraud paths, where trust cues are easy to imitate and the verification step itself becomes the attack surface.

Key questions

Q: How should security teams design caller verification so attackers cannot redirect it?

A: Anchor the check to a destination the customer already trusts, such as the organisation’s real website or app. Never ask the caller to supply the verification portal, because that gives the attacker control of the path. The control should confirm identity without creating a new place where a fake page can be inserted.

Q: Why do separate verification portals fail against phone scams?

A: They fail because the customer must trust the caller to route them correctly. Once the attacker controls the instructions, the verification step becomes another social-engineering task instead of an independent check. If the attacker can choose the destination, they can clone it, reuse codes, and make the process validate the scam.

Q: What do organisations get wrong about caller ID and sender trust?

A: They often treat a familiar caller name, number or email display name as proof of identity. In reality, those fields can be manipulated independently of the true source. The mistake is assuming the display layer is authoritative when the trust decision should depend on validated origin data.

Q: Who is accountable when a verification flow can be redirected by an impostor?

A: The organisation is accountable for designing a verification process that remains trustworthy under impersonation. Fraud teams, IAM leads, and customer operations should align on a control that does not rely on the caller to choose the path. If the process can be redirected, the design has failed before the scam completes.

Technical breakdown

Why separate verification portals fail

A separate verification portal creates a trust-transfer problem. The caller asks the customer to move to a destination the customer has not preloaded as trustworthy, so the customer must rely on the caller to supply the correct location. That collapses the security value of the second step, because an attacker can create a look-alike page and feed the victim the same code. Verification only works when the destination itself is pre-established and independently recognised.

Practical implication: do not let the caller choose the verification destination.

Verifier impersonation resistance and site binding

Verifier impersonation resistance means the check is bound to the real relying party, not to a generic web page that can be cloned. In practice, this is the same principle that makes phishing-resistant authentication stronger than one-time codes delivered through channels the attacker can intercept or redirect. If the user can be guided to any site that accepts the code, the control has no anchor and the attacker controls the path.

Practical implication: bind verification to a known domain or app path that customers already recognise.

Why caller ID authentication does not close the gap

STIR/SHAKEN can help authenticate a number, but it cannot prove the intent or legitimacy of the person speaking. That distinction matters because fraud uses a believable number as one cue among several, then adds a convincing story and timing pressure to drive the victim forward. Number attestation is useful metadata, not proof of identity, and it does not stop the social-engineering layer of the attack.

Practical implication: treat caller ID authentication as supporting evidence, not as the control that authorises action.

Threat narrative

Attacker objective: The attacker wants the victim to trust a fake verification flow enough to disclose credentials, approve actions, or transfer money.

1. Entry occurs when the attacker contacts the victim through a believable phone number and voice impersonation, often using real account details to establish credibility.
2. Escalation occurs when the attacker redirects the victim to a separate verification site or support flow that the attacker can control or imitate.
3. Impact occurs when the victim treats the redirected step as proof of legitimacy and follows instructions that enable account takeover or fraud loss.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Portal-based caller verification creates redirection risk, not verification strength. If the customer must move to a site the caller introduces, the caller controls the trust transition. That means the control is only as strong as the customer’s ability to detect a fake destination, which attackers routinely exploit. Practitioners should treat any verification model that depends on redirection as structurally weak.

Verifier impersonation resistance is the right control concept for customer-facing identity checks. NIST SP 800-63B already distinguishes checks that can survive look-alike destinations from those that cannot. That framing matters because the problem is not just phishing, it is whether the relying party remains the anchor for the interaction. Teams should design verification so the user independently reaches the trusted domain before any code is accepted.

Caller ID authentication solves numbering, not identity. STIR/SHAKEN can tell you the number was attested, but not whether the speaker is an employee, a fraudster, or an outsourced impostor. That distinction matters for support desks and customer operations alike, because the attacker needs only enough legitimacy to keep the script moving. Practitioners should separate transport-layer trust from human identity trust.

Redirectable verification is a governance failure, not a tooling failure. If the organisation permits a check that can be re-routed by the caller, the process has already accepted the attacker’s terms. The named concept here is the verification redirection gap, where the security step becomes part of the scam path. Identity teams should classify this as a control-design issue across fraud, IAM, and support operations.

From our research:

• 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, according to The State of Secrets in AppSec.
• For a broader breach lens, The 52 NHI breaches Report shows how weak trust boundaries repeatedly turn identity controls into attack paths.

What this signals

Verification redirection gap: Teams that let the caller choose the destination are not adding a second factor, they are extending the attack surface. The safer pattern is to require the user to independently reach a known domain before any code or approval is accepted, because the trust anchor must exist before the conversation starts.

Fraud and identity teams should align on a single trust model across support channels, customer flows, and account recovery. The control objective is not to prove that a call sounds right, but to prevent the caller from steering the user into a fake trust boundary. That makes customer verification a governance issue, not just a fraud workflow issue.

The broader signal is that verification steps increasingly need to resist human manipulation as much as technical interception. As adversaries combine spoofed caller ID, leaked account context, and scripted persuasion, programme owners should treat redirection resistance as a baseline requirement and test it against the same rigor as authentication controls.

For practitioners

• Anchor verification to a known customer destination Require customers to complete caller checks only in a domain, mobile app, or authenticated session they already use, not in a caller-supplied portal.
• Remove caller-controlled routing from the verification flow Do not let agents, IVR prompts, or SMS instructions tell users where to go for confirmation. The customer should navigate independently to the trusted channel.
• Separate number attestation from identity approval Treat caller ID authentication as supporting evidence only. Require a second trust signal that cannot be satisfied by a spoofed call or cloned voice.
• Test support scripts for redirection abuse Red-team the call flow by simulating impostors who direct users to fake verification pages. Use the results to remove any step that can be captured by the attacker’s script.

Key takeaways

• Caller verification fails when the attacker can control where the customer goes to validate the call, because the verification step becomes part of the scam.
• A trusted number or convincing voice proves nothing on its own, so identity teams need verification anchored to a destination the user already recognises.
• The practical fix is not more friction, but a trust anchor that cannot be redirected by the caller or cloned by an impostor.

Key terms

• Verifier-impersonation resistance: A property of an authenticator that resists an attacker pretending to be the legitimate service during the login ceremony. It matters because the authenticator verifies the real origin before signing, which blocks the relay pattern used by adversary-in-the-middle phishing.
• Trust anchor: A trust anchor is the root authority that signs federation metadata and establishes the policies other participants inherit. In practice, it controls who can join, what cryptographic rules apply, and how trust is delegated across an ecosystem. The security posture of the whole federation depends heavily on this layer.
• Caller ID attestation: A network-level signal that helps confirm a phone number was authenticated, but not who is speaking or whether the request is legitimate. It can reduce ambiguity about the originating number, yet it does not stop voice impersonation or social engineering.
• Verification redirection: A failure mode where an attacker steers the victim away from the legitimate verification channel and into a fake one. The redirection itself becomes the attack, because the customer is no longer validating against a trusted destination.

What's in the full article

Trusona's full blog covers the operational detail this post intentionally leaves for the source:

• How the verification flow binds the customer to the organisation’s own website rather than a caller-supplied portal.
• Why single-use, time-limited Verify Codes change the fraud model compared with static codes or SMS passcodes.
• How the call workflow is designed so the caller never supplies the destination for the verification step.
• Which trust cues remain useful when caller ID, voice, and account knowledge are all easy to fake.

👉 Trusona's full post explains the verification model, the redirection weakness, and the control logic behind site-bound checks.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.