How should security teams replace knowledge-based authentication in contact centres?

Why This Matters for Security Teams

Contact centres are a high-pressure environment where agents need fast access, callers need quick resolution, and attackers look for the weakest path. Knowledge-based authentication fails because memorised facts are easy to harvest, infer, or socially engineer, and they do not prove the caller controls a real identity at the moment of the request. NIST’s NIST Cybersecurity Framework 2.0 pushes teams toward stronger, risk-based controls, which is the right direction here.

For NHI Management Group, this is part of a broader identity lesson: controls that depend on static knowledge or stale entitlements do not hold up when the threat actor can research the target before calling. The same identity flaws that create weak secrets hygiene in machine environments also appear in human-facing workflows, where recovery questions become reusable bypasses instead of proof. The Ultimate Guide to NHIs shows how often organisations struggle with visibility, rotation, and revocation, and the pattern is similar here: the weakest identity proof tends to survive long after it should have been retired. In practice, many security teams encounter account takeovers only after a caller has already used the support process as the attack path.

How It Works in Practice

The replacement for KBA is not a single tool. It is a verification stack that ties the request to a stronger identity signal, then makes recovery deliberately controlled. In mature designs, the caller proves possession of a device, a cryptographic credential, or a federated identity assertion instead of answering questions that can be guessed from public data or prior breaches. That proof should be evaluated at runtime, not assumed from a preapproved profile.

Current guidance suggests combining multiple elements:

• Phishing-resistant authentication such as passkeys or device-bound cryptographic proof for user re-verification.
• Federated identity checks for known customers, employees, or partners where the upstream identity provider can assert trust.
• Step-up verification for higher-risk actions such as password reset, payout changes, or contact-detail updates.
• Recovery workflows that are short-lived, logged, and approved through policy, not informal agent discretion.
• Fraud and risk signals such as location, call history, device reputation, and transaction context.

Teams should also govern exceptions. A lost device, a business continuity event, or an accessibility accommodation may require alternate paths, but those paths should be explicit, time-bounded, and reviewed. Best practice is evolving toward policy-as-code and real-time decisioning rather than fixed scripts, because the right answer depends on the caller, the request, and the risk level at that moment. The controls work best when identity proof, case management, and audit logging are integrated, as described in the Ultimate Guide to NHIs, and when the control model aligns with modern identity assurance thinking in the NIST Cybersecurity Framework 2.0. These controls tend to break down when legacy telephony systems cannot consume modern identity signals because the fallback process reintroduces manual trust.

Common Variations and Edge Cases

Tighter verification often increases call handling time and friction, so organisations have to balance fraud reduction against customer experience and accessibility. That tradeoff matters because a perfect control that blocks legitimate users will be bypassed in practice, especially in contact centres under pressure.

There is no universal standard for every recovery scenario yet. Some environments can move almost entirely to digital self-service plus authenticated callback, while others need agent-assisted recovery for vulnerable customers, regulated services, or multilingual support. In those cases, the key is not to preserve KBA, but to ensure the alternate path has stronger evidence than the original one. For example, a customer who cannot use a passkey may need a recorded in-app approval, a known-device challenge, or supervised identity proofing that is documented and monitored.

Organisations should also be careful with overreliance on “security questions” hidden inside broader workflows. If a support desk can override policy based on verbal confirmation, the attacker only needs persistence and social engineering. The safer pattern is to define explicit recovery tiers, minimise data exposed to agents, and make every exception visible to audit. The same principle applies in NHI governance: strong identity systems fail when exception handling becomes the real policy.

Related resources from NHI Mgmt Group

• How should security teams authenticate AI agents in enterprise environments?
• How should security teams implement Client ID Metadata Documents?
• How should security teams phase out password-based authentication without disrupting operations?
• How should security teams use context-based authentication in high-risk environments?