What should organisations use instead of caller-directed verification pages?

Use a Trusted Destination, Not a Caller-Controlled Page

The safer pattern is to send the person to a website or app they already trust and can open on their own, then complete the check there with a one-time code or similar proof tied to that interaction. That preserves user control of the destination and keeps the verification step inside an independently trusted channel rather than inside the caller’s flow.

This matters because caller-directed pages can be engineered to look legitimate while quietly proving nothing about the caller. The page itself becomes part of the social-engineering path, so the person is no longer verifying the caller, they are verifying whatever the caller chose to show them.

Why Caller-Controlled Verification Fails

Caller-directed verification pages are weak because the attacker controls the route into the check. If the caller can dictate the URL, app, or prompt, they can steer the person to a lookalike page, prefill context, or use the page to reinforce urgency. The control fails at the point where trust is being outsourced to the very party being checked.

A better design keeps the confirmation step separate from the conversation. The person should independently open a saved bookmark, trusted mobile app, or known customer portal, then confirm a call-specific code, transaction detail, or callback instruction that the caller cannot change.

In practice, the strongest versions also bind the proof to a specific event, such as a recent support case, login attempt, or service request. That makes the check useful as an anti-impersonation control, not just a second screen that repeats what the caller already said.

What Good Looks Like in Practice

Good implementations minimise the number of trust decisions the caller can influence. The trusted destination should be established before the call starts, reachable through a known path, and able to display a short-lived code or case reference that the caller cannot predict or rewrite. NIST AI Risk Management Framework is not the right lens for the page itself, but the design principle is the same: keep the trust decision under the verifier’s control, not the requestor’s.

For digital identity flows, the best supporting pattern is a phishing-resistant, user-initiated verification step. NIST SP 800-63 Digital Identity Guidelines reinforces the value of stronger authenticators and user-initiated verification, while OWASP ASVS gives a practical control lens for authentication and access checks that must not be subverted by an attacker-controlled endpoint.

For organisations with customer portals or support journeys, the control should be simple enough that staff can explain it consistently: the customer opens the app or site they already know, enters the code received through the channel they trust, and the organisation verifies the interaction from its own system of record.

Practitioner Guidance

What to prioritise: Replace any workflow that relies on a link, QR code, or page provided by the caller with a verifier-owned destination that the user navigates to independently. If the current process allows the caller to choose the page, the control is already too weak to trust.

What to verify: Check that the code or proof is short-lived, bound to the specific interaction, and validated only after the user reaches the trusted site or app through a known path. If the same proof can be reused, forwarded, or validated on a page the caller supplied, it is not a reliable check.

Common mistake: Treating any “verification page” as equivalent to verification. A page only adds value when the verifier controls the destination and the proof is specific enough to resist replay, pretexting, and lookalike-site abuse.

Practitioner takeaway: The core rule is destination control, if the caller chooses where the verification happens, the trust test has already been lost.

Related resources from NHI Mgmt Group

• Should organisations use NFC verification instead of OCR document checks?
• When should organisations use domain intelligence instead of relying only on email verification?
• When should organisations use stronger liveness checks instead of lighter verification in digital identity journeys?
• How should organisations decide when to use face verification instead of face recognition for online identity checks?