Why do contact centres need stronger caller verification than STIR/SHAKEN?

STIR/SHAKEN authenticates the calling number, not the person speaking. A real phone number can still be used by the wrong individual, so it is useful as a network signal but not as identity proof. Contact centres need a separate possession-based control to verify the account holder.

Why This Matters for Security Teams

STIR/SHAKEN is valuable, but it answers a narrow question: whether the calling number was authenticated somewhere in the telecom path. Contact centres need a stronger control because fraudsters can still exploit compromised numbers, social engineering, call forwarding, and reused caller IDs to reach high-risk workflows. The real risk is not caller presentation alone, but whether the person on the line is entitled to act on the account.

That distinction matters most when agents are authorised to reset passwords, change payout details, or bypass normal digital authentication. Current guidance suggests treating caller ID authentication as one input, not an identity proof. The Ultimate Guide to NHIs shows that identity failures often begin where trust is assumed too early, especially when credentials or access paths are reused without enough verification. NIST’s NIST Cybersecurity Framework 2.0 reinforces that identity assurance must match the transaction risk, not just the channel.

In practice, many security teams encounter phone-based account takeover only after a high-value request has already been completed, rather than through intentional verification design.

How It Works in Practice

Strong caller verification in a contact centre uses layered evidence, not a single signal. The first layer may still include STIR/SHAKEN, but only as telecom attestation. The second layer should verify possession of a separate factor or trusted device, and the third should use contextual checks that reflect the specific action being requested. Best practice is evolving toward risk-based authentication, where a low-risk inquiry may need light verification while a payout change or SIM swap should trigger stricter checks.

Typical controls include:

• Out-of-band confirmation through a registered mobile app, push approval, or secure callback.
• Knowledge- or account-based checks that are not easily mined from public data.
• Step-up verification for sensitive actions, with a tighter approval path for recovery and fund-transfer workflows.
• Fraud scoring that combines caller history, device reputation, location anomalies, and prior account behaviour.
• Agent scripting that forces a pause before high-impact changes are accepted.

The Ultimate Guide to NHIs is especially relevant because it highlights how quickly identity abuse becomes operational damage when access paths are broad and poorly governed. For identity assurance design, the key takeaway from NIST CSF 2.0 is to align verification strength with business impact and threat exposure, not with call volume or convenience. In environments that support privileged service requests, the strongest model is possession plus context plus policy, evaluated before the action is executed.

These controls tend to break down when legacy telephony, outsourced agents, and fragmented customer records make it impossible to bind one verified identity to one trusted recovery path.

Common Variations and Edge Cases

Tighter caller verification often increases handling time and customer friction, so organisations have to balance fraud reduction against abandonment rates and service costs. There is no universal standard for this yet, which means the right design depends on the sensitivity of the account action and the threat profile of the contact centre.

Some edge cases need different treatment:

• High-risk industries may require mandatory out-of-band verification for any credential reset or beneficiary change.
• Low-risk support queues may use STIR/SHAKEN only as a fraud signal, then rely on step-up verification only when anomalies appear.
• Customers without smartphones or stable access to digital channels need non-app fallback methods that are still harder to forge than caller ID alone.
• Third-party call handling creates extra uncertainty because the verified caller number may not belong to the actual account holder.

Industry consensus is clear on one point: caller ID authentication is not enough for account assurance. What remains unsettled is the exact mix of friction, automation, and agent discretion that delivers acceptable security without breaking the customer experience. Contact centres that rely on number trust alone tend to absorb the loss later, after the recovery workflow has already been abused.

Related resources from NHI Mgmt Group

• When should operators prioritise stronger verification over lower onboarding friction?
• How do teams decide when to apply stronger identity verification?
• How should security teams replace knowledge-based authentication in contact centres?
• What breaks when contact-centre identity checks rely on knowledge-based verification?