Caller Authentication in Contact Centres: Replacing Security Questions with Stronger Phone Verification

Most contact centres still decide who is on the line from a caller ID that can be spoofed and answers to questions that fraudsters can research, buy or socially engineer. Caller authentication is the set of checks a business runs before an agent or an IVR discloses account data, changes contact details or moves money for a customer on the phone. This guide covers customer facing phone verification: in-app push verification, OTP to a registered device, the risk signals in the calling number, voice biometrics, and the step-up rules that tie them together. It is written for fraud, CIAM and contact centre leads who want to replace knowledge-based authentication (KBA) without wrecking handle times. Workforce help desk resets are covered separately in the Account Recovery and Help Desk Security Guide.

Key takeaways

• Caller ID is a signal, never an authenticator. The calling number (ANI or CLI) can be spoofed, ported or SIM swapped, so use it to choose a risk path, not to skip verification.
• Retire knowledge questions as a pass or fail gate. NIST SP 800-63A-4 says knowledge-based verification SHALL NOT be used for identity verification, and the 2021 FFIEC guidance warns against relying solely on knowledge-based questions.
• Verify through a channel the customer already controls. An in-app push that carries a code or number match, or an OTP to a device bound before the call, is far harder to socially engineer than a date of birth.
• Tie verification strength to what the call will do. A balance enquiry, a change of phone number and a payment to a new payee need different assurance; contact detail changes are the classic account takeover step.
• Agents need a process that cannot be talked around. Scripts, system enforced step-up and a no-override rule matter as much as the technology, because the attacker's real target is the agent's goodwill.

Why phone channels attract account takeover

The phone channel is where a fraudster can apply pressure in real time. An agent is measured on handle time and customer satisfaction, the caller can claim urgency or distress, and many processes let the agent use judgement when a customer "cannot remember" an answer. The 2021 FFIEC interagency guidance notes that threat actors have deceived customer call centre and IT help desk representatives into resetting passwords, and recommends enhanced authentication for credential resets, such as a one-time passcode to a pre-established device or a call-back to a pre-established phone number.

The typical attack sequence has three steps: gather personal data (breached records, social media, phishing), call and pass knowledge checks, then change the phone number or email on the account so that every later OTP and alert goes to the attacker. ATT&CK tracks voice based social engineering as T1566.004 Spearphishing Voice for initial access and T1598.004 for reconnaissance, and the mobile matrix lists T1451 SIM Card Swap. See the Vishing and Smishing Guide for the customer facing awareness side.

Caller ID, ANI spoofing and network signals

Automatic Number Identification (ANI) and the presented Calling Line Identity (CLI) tell the contact centre which number the network says placed the call. They are useful for routing and pre-fetching the customer record, and they are a weak identity claim. Spoofing, number porting and SIM swap all let someone else present the customer's number.

• STIR/SHAKEN in the US: the FCC describes STIR/SHAKEN as a framework in which originating carriers sign a call's caller ID and downstream carriers validate the signature. It helps unmask spoofed calls, but a valid signature is a statement about the originating carrier, not proof that the customer is the person speaking. See the STIR/SHAKEN Caller ID Guide.
• UK CLI rules: Ofcom's statement of 15 November 2022 changed General Condition C6 so that providers, where technically feasible, identify and block calls with invalid or non-dialable CLI and calls from abroad that spoof UK numbers. The rules took effect on 15 May 2023. They reduce crude spoofing; they do not authenticate your customer.
• Carrier and device signals: recent SIM change, recent port, line type (mobile, fixed, VoIP) and whether the call came through the expected carrier are all useful risk inputs. NIST SP 800-63B-4 says verifiers SHOULD consider risk indicators such as device swap, SIM change and number porting before using the phone network to deliver an out-of-band secret. See the SIM Swap Fraud Guide.

Design rule: a matching ANI may route the call to a faster path that still requires a possession check. A mismatched, withheld or high-risk ANI should route to the strongest path, and an ANI on an internal hotlist (numbers seen in prior fraud) should alert the fraud team.

Verification methods compared

The table compares the methods most contact centres choose between. Strength assumes the factor was bound to the account through a trusted process before the call; a factor registered during the same call proves nothing.

See the Authenticator Apps and OTP Guide for factor details.

In-app caller verification

For customers who use your mobile app, in-app verification is the best replacement for KBA. The app session already carries strong authentication (device binding, a passkey or biometric unlock), so the phone call can inherit that assurance.

Two patterns

• Inbound verify: the agent or IVR triggers a push to the customer's registered app. The push shows the request in plain words ("Contact centre verification for a call now in progress") and either displays a code the customer reads back, or asks the customer to enter a number shown on the agent screen. NIST SP 800-63B-4 says approve-only push is no longer considered acceptable because of authentication fatigue, so carry a secret across channels. The same publication sets a 10 minute limit for out-of-band authentication and says verifiers SHOULD cap the number of push notifications.
• App-initiated call: the customer taps "Call us" inside the app. The app requests a short-lived, single-use token, the IVR receives it through the telephony platform (for example as call data attached to the session), and the agent desktop shows "Verified in app" with the time and device. No questions are asked.

Implementation details that matter

• Bind to the call: the token or code must be tied to a specific call ID and expire within minutes, so it cannot be harvested and reused.
• Explain the request in the push: include "Only approve if you are on the phone with us now and you started the call." This turns the push into a fraud warning when a criminal triggers it.
• Handle denial as a signal: a declined push or a "this was not me" tap should flag the call to fraud operations and lock high-risk actions on the account.
• Keep a fallback: not every customer has the app. Design a strong non-app path (OTP with SIM change checks, or a call-back) rather than falling back to KBA.

One-time passcodes over SMS and voice

SMS and voice OTP remain the most widely reachable possession check. NIST SP 800-63B-4 keeps PSTN out-of-band delivery as a "restricted" authenticator: verifiers SHALL offer an alternative authenticator type to all subscribers, and changing the pre-registered phone number is treated as binding a new authenticator. For identity proofing, SP 800-63A-4 sets confirmation codes of at least six decimal digits, valid for 10 minutes when sent by SMS or voice.

• Check before you send: query SIM change, port and line status signals from your provider or carrier before the OTP goes out. A swap in the last few days should route the caller to a stronger method.
• Never let the agent read or type the code on the customer's behalf: the customer enters it in the IVR or reads it to the agent who enters it into the system, which then compares it. The agent must never see the expected code.
• Throttle: SP 800-63B-4 requires verifiers to limit consecutive failed attempts to no more than 100 and says generating a new secret does not reset the count. Contact centres usually set far lower limits per call and per account.
• Word the message as a warning: "Your code to verify a call with us is 482913. Our staff will never call you and ask for this code." This disrupts the reverse pattern where a fraudster calls the customer pretending to be the bank.

Voice biometrics and synthetic voice

Voice biometrics compare the caller's voice with an enrolled voiceprint, either passively during conversation or with an active pass phrase. They cut handle time, but generative voice cloning has changed the risk calculation. NIST SP 800-63B-4 states that "Biometric comparison based on voice SHALL NOT be used" in its biometric requirements, and allows biometrics only as part of multi-factor authentication with a physical authenticator. That publication governs US federal systems, but it is the clearest public benchmark for what a standards body now considers safe.

• Use voice as a risk score: a strong voice match can lower the risk tier for low-value enquiries; a poor match or a liveness or synthetic voice alert should raise it.
• Never authorise high-risk actions on voice alone: contact detail changes, payee creation and credential resets need a possession factor.
• Consent and privacy: voiceprints used to recognise a specific caller are biometric data, and the ICO states that biometric data used for unique identification is special category data under GDPR Article 9, and some US states regulate biometric collection. See the Illinois BIPA and Biometric Privacy Guide.
• Watch for AI voice agents calling in: automated voice bots can now handle full conversations. See the Voice AI Agent Security and Fraud Guide and the Deepfake-Resistant Identity Verification Guide.

Replacing knowledge-based authentication

NIST SP 800-63A-4, Section 2.5.1, states that knowledge-based verification or knowledge-based authentication SHALL NOT be used for identity verification, while allowing KBV as part of a fraud management programme. The FFIEC guidance says reliable verification methods generally do not depend solely on knowledge-based questions. The practical answer is to demote KBA rather than delete it overnight.

1. Inventory every phone journey: list each IVR menu and agent task, what data it discloses and what it can change.
2. Assign a risk tier to each task: for example Tier 1 (general information, no account data), Tier 2 (balance, recent transactions), Tier 3 (contact detail change, card replacement to a new address, credential reset, new payee, large transfer).
3. Set the minimum verification per tier: Tier 2 needs one possession factor; Tier 3 needs a possession factor that is not the channel being changed, plus a notification to the existing contact details.
4. Keep KBA as a negative signal: wrong answers raise risk; right answers never lower it below the possession requirement.
5. Build the system enforced flow: the agent desktop unlocks fields only after the required verification result arrives from the platform, not from an agent tick box.
6. Pilot with one queue: run the new flow in shadow mode (record what the decision would have been) for two to four weeks, compare against fraud outcomes, then switch on enforcement queue by queue.
7. Plan rollback: keep the old flow available behind a feature flag for a short period, but with KBA alone blocked from Tier 3 actions even in rollback.

Step-up rules and agent controls

• No discretionary override: remove buttons that let agents bypass verification. Replace them with a warm transfer to a fraud specialist who also cannot bypass, but can apply alternative proofing.
• Scripts for pressure: give agents approved phrases for urgency, distress and "I am the account holder's son" calls. Delegated access should be set up formally; see Delegated and Proxy Access in CIAM.
• Training: run regular call simulations based on real fraud recordings. A written policy model is in the Help Desk Identity Verification Policy Template.

Where identity fits

Caller authentication is a customer identity (CIAM) problem, not a telephony one. The verification result should come from the same identity platform that authenticates web and app sessions, so that factor binding, recovery rules and risk signals are consistent across channels. Agents should also be treated as privileged users: an agent desktop that can change a customer's phone number is an account takeover tool if the agent's own account is compromised, so require phishing-resistant MFA for agents and least privilege per queue. See the Customer IAM (CIAM) Guide.

Detection and measurement

• Log every verification decision: call ID, ANI, risk signals checked, method used, result, agent ID and the action that followed. Feed it to the fraud platform and SIEM.
• Correlate across channels: a contact detail change by phone followed by a login from a new device and a new payee within hours is a high-confidence takeover pattern.
• Alert on agent behaviour: one agent processing unusual volumes of contact changes or failed verifications may be targeted or complicit.

Framework mapping

Common failure patterns

• ANI match skips verification: an IVR that authenticates on calling number plus a PIN lets a spoofer with a guessed or phished PIN straight in.
• Change of number in the same call: verifying with an OTP and then letting the caller change the number that OTP went to, without notification or delay, hands over the account.
• Agent overrides: "the customer was upset and could not remember" exceptions are where most social engineering succeeds.
• Approve-only push: a simple "Approve" prompt is easily tapped by a customer who is being coached by a fraudster on another line.
• OTP visible to agents: if the expected code appears on the agent screen, an insider or a compromised agent account can complete verification.
• Voiceprint as a sole gate: treating a voice match as full authentication ignores synthetic voice risk.

Practitioner checklist

• Map every phone journey to a risk tier and a minimum verification method.
• Treat ANI and CLI only as risk inputs and route high-risk numbers to the strongest path.
• Deploy in-app verification with a code or number match, bound to the call ID and expiring within minutes.
• Check SIM change and porting signals before sending any SMS or voice OTP.
• Demote knowledge questions to a negative fraud signal and block them from Tier 3 actions.
• Require a possession factor on the existing channel, plus notification, before changing contact details.
• Remove agent overrides and route exceptions to a fraud team with alternative proofing.
• Use voice biometrics only as a passive risk score, with consent and a retention policy.
• Log every verification decision and correlate phone changes with later digital activity.
• Protect agent accounts with phishing-resistant MFA and least privilege.

Standards and references

• NIST: SP 800-63B-4 Authentication and Authenticator Management
• NIST: SP 800-63A-4 Identity Proofing and Enrollment
• FFIEC (via Federal Reserve): Authentication and Access to Financial Institution Services and Systems
• Ofcom: Statement on improving the accuracy of Calling Line Identification data
• FCC: Combating Spoofed Robocalls with Caller ID Authentication
• MITRE ATT&CK: T1566.004 Spearphishing Voice
• MITRE ATT&CK Mobile: T1451 SIM Card Swap

Related NHI Mgmt Group resources: Account Recovery and Help Desk Security Guide · Contact Centre Fraud Prevention · SIM Swap Fraud Guide · STIR/SHAKEN Caller ID Guide · Customer IAM (CIAM) Guide