They fail because knowledge-based questions are easy to assemble from breached or publicly available data, especially when fraudsters are already impersonating the bank. Cryptographic caller verification is more resilient because the customer must prove identity with a bound authenticator before the agent can act.
Why This Matters for Security Teams
Contact centre authentication fails when banks rely on static knowledge-based checks to defend a dynamic fraud channel. Attackers can assemble answers from breached data, social media, and prior incidents, then social-engineer the agent while the real customer is on the line. That creates a false sense of assurance, especially when the workflow treats a spoken answer as equivalent to cryptographic proof.
For banking teams, the issue is not just customer inconvenience. Weak caller verification becomes an account takeover path, a payment redirection risk, and a compliance problem when agents are authorised to change high-value account attributes. The NIST Cybersecurity Framework 2.0 reinforces that identity proofing and access decisions need stronger, risk-based controls than secret questions. NHIMG research on the DeepSeek breach also shows how quickly exposed secrets and sensitive data can be operationalised by attackers once they are available.
In practice, many security teams encounter customer identity failures only after a fraud loss or complaint investigation has already exposed the weakness.
How It Works in Practice
The most reliable approach is to move from knowledge-based authentication to cryptographic caller verification and step-up controls. Instead of asking a customer to recite data that may already be public, the bank verifies a bound authenticator such as an in-app device key, push approval, or another possession-based signal before the agent can act. This shifts the trust decision from human memory to a verifiable identity assertion.
Current guidance suggests treating the contact centre as a high-risk channel, not a low-friction exception path. Agent workflows should be tied to risk scoring, policy-as-code, and event-driven approvals so that high-impact actions like password resets, beneficiary changes, or card reissues require stronger proof than routine inquiries. The NIST Cybersecurity Framework 2.0 supports this shift by emphasising identity assurance, access control, and continuous risk management. For organisations building stronger non-human and machine-mediated identity controls, NHIMG’s DeepSeek breach coverage is a useful reminder that exposed secrets are routinely converted into operational access.
- Use a bound authenticator that is linked to the customer device or account, not a knowledge question.
- Require step-up verification before any action that changes money movement or account recovery settings.
- Log the verification method, agent action, and risk score for audit and dispute resolution.
- Design fallback flows for locked-out users, but keep them distinct from normal servicing.
Where this breaks down is in legacy contact centres that cannot support real-time verification against a mobile app, hardware token, or policy engine because the process remains dependent on manual scripts and fragmented customer records.
Common Variations and Edge Cases
Tighter verification often increases call handling time and customer friction, so organisations have to balance fraud resistance against abandonment risk and accessibility. That tradeoff is real, especially for older customers, vulnerable users, and cross-border banking journeys where the preferred authenticator is not always available.
Best practice is evolving around exception handling. There is no universal standard for this yet, but banks are increasingly using layered checks: device binding for routine servicing, risk-based step-up for sensitive requests, and human review for edge cases. The DeepSeek breach illustrates why fallback paths must also be protected, because attackers frequently target the weakest alternative path rather than the strongest primary one. That is also why current guidance treats secrets and recovery data as high-value assets rather than ordinary customer metadata.
For teams aligning controls to broader identity governance, the NIST Cybersecurity Framework 2.0 provides a practical anchor for access decisions, monitoring, and recovery planning. In practice, call-centre authentication fails when the fallback flow is easier to exploit than the main one.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Identity verification before agent action is core access control. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Static secrets and weak verification patterns are a non-human identity risk. |
| NIST AI RMF | Risk-based, context-aware decisions fit AI-assisted fraud and verification. |
Require stronger caller proof before any privileged account change or recovery action.
Related resources from NHI Mgmt Group
- Why do voice and contact-centre identity flows need separate controls?
- How should security teams replace knowledge-based authentication in contact centres?
- Why do voice and contact-centre workflows need a different identity pattern from normal SSO?
- Why is it crucial to adopt new authentication methods in MCP usage?
