Notifications
Clear all
Topic starter
25/08/2026 6:10 pm
TL;DR: Caller verification breaks when customers are sent to a separate website they do not already trust, because attackers can redirect that step and turn the check into another part of the scam, according to Trusona's analysis. The real control is verifier impersonation resistance anchored to a destination the user already knows, not a portal the caller can steer.
NHIMG editorial — based on content published by Trusona: If you have to visit a new website to verify the call, it isn’t verification
By the numbers:
- 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.
Questions worth separating out
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.
Q: Why do separate verification portals fail against phone scams?
A: They fail because the customer must trust the caller to route them correctly.
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.
Practitioner guidance
- 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.
- Separate number attestation from identity approval Treat caller ID authentication as supporting evidence only.
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.
👉 Read Trusona's analysis of why separate caller verification portals fail →
Caller verification portals: are your controls actually resistent to redirection?
Explore further
25/08/2026 6:11 pm
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.
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, according to The State of Secrets in AppSec.
A question worth separating out:
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.
👉 Read our full editorial: Caller verification fails when customers are sent to new websites
