Is KBA still safe? Knowledge-based authentication risks explained

You are moving AI agents into production for the phone channel, and every agent needs to confirm who is calling before they touch an account or process a change. The default answer you inherited is security questions: personal history questions and last-four checks.

Security-question authentication has been failing for years. Now your team is preparing to embed security-question authentication into a system that runs at scale across many simultaneous calls and applies the same logic every time. The verification method you automate will become the standard control across every call, so the decision deserves a direct answer: Is KBA still safe?

What is knowledge-based authentication?

Knowledge-based authentication (KBA) is a method of verifying identity by asking a caller for information they are supposed to know. In practice, that means security questions (mother's maiden name, first pet, childhood street), account details (last four of a card or Social Security number), or transaction history the customer is expected to recall. The control rests on a single assumption: only the genuine customer knows the answer.

KBA comes in two forms:

• Static KBA uses answers that the customer sets up in advance and stores against the account.

• Dynamic KBA generates questions on the fly from public or credit-bureau data.

Both forms depend on the same premise, that the answers are private to the customer, and both are now tested by the same forces reshaping the phone channel. That premise is exactly what has broken down, which is where the failure mode begins.

Why security questions fail in caller verification

Knowledge-based authentication (KBA) verifies identity by asking the customer for information they are supposed to know, such as security questions or account details. KBA rests on one assumption: only the genuine customer knows the answer. That assumption no longer holds, which means KBA fails as a standalone control.

The National Institute of Standards and Technology (NIST) states that KBA is no longer an acceptable authenticator. The guidance cites two weaknesses: attackers can easily discover answers, and many questions have a small set of possible answers. KBA answers are no longer secret, so the control can no longer reliably verify identity.

Three forces have made KBA answers trivially available to anyone who wants them:

• Breach exposure: Years of large-scale data breaches have exposed personal details that KBA relies on. Attackers can buy or look up those details.

• Social engineering: Attackers harvest answers directly from customers through quizzes and games that ask for exactly the details KBA uses.

• Publicly findable data: Birthdates and family names sit in public records and social profiles, available to a fraudster with a search bar.

KBA now creates an inversion of the control's purpose. A genuine customer who set up security questions years ago forgets which answer they used or how they formatted it, and loses access. Fraudsters who looked up the answers in breached data read them off cleanly and passed. KBA fails the people it was built to protect more reliably than it stops the people it was built to catch. Every call that uses security questions as the gate carries that weakness into production. The operating rule is direct: stop treating security questions as sufficient wherever a caller can change the account state.

Fraud attempts in the phone channel are increasing

The contact center is now a primary fraud target, and fraud volume is rising faster than legacy controls can keep pace with. Caller verification is a current production risk for enterprise transformation teams. Four data points frame the scale of the problem:

• High-risk call share: In 2024, TransUnion identified 6% of calls into US call centers as high risk for fraud. At enterprise scale, even a 6% high-risk share sends repeated hostile attempts at the verification step.

• National fraud losses: FTC reporting documents the financial scale independently at the national level. Reported fraud losses reached about $16 billion in 2025, the highest on record and an increase of about 25% over the prior year.

• Contact center as a specific vector: Since January 2025, the Internet Crime Complaint Center has received more than 5,100 complaints involving support impersonation by financial institutions, with losses exceeding $262 million.

• AI-driven acceleration: Automated voice generation and scripted social engineering let a single fraudster run attempts at a volume no manual operation could match. More attackers are turning to AI-backed schemes precisely because they work.

AI-backed fraud matters most in the phone channel, where a single verification step gates account access and attackers time fraud to slip past human agents under pressure. An overloaded human agent under handle-time pressure is exactly the condition an attacker counts on: the moment when the pressure to move the call along outweighs the instinct to verify one more time. Automating the phone channel applies whatever verification logic you give it to every call at once.

Adaptive, risk-tiered verification turns that pressure into an operating rule: higher-risk intent triggers stronger verification before the caller reaches the account action. If KBA is failing and fraud volume is rising, the natural question is what to replace it with, and voice biometrics is usually the first answer on the table.

Why voice biometrics is just the first step

A common answer to KBA's failure is to swap in voice biometrics, and it is a reasonable first move. A social media quiz cannot expose a customer's voiceprint, thereby directly addressing KBA's core flaw. The technique also delivers real operational value: voice biometrics can cut authentication time to a matter of seconds and materially reduce fraudulent authentications compared with single-factor methods. As a control, it is a genuine step up, but only a step.

Voice biometrics now faces the same AI pressure weakening KBA. A leader migrating to voice biometrics today may be installing a control with a limited useful life against generative cloning, which is why it belongs in a layered program rather than as the sole gate.

Three exposures make voice biometrics insufficient as a standalone control:

• Deepfake vulnerability: AI voice cloning has advanced to the point where a synthetic voice can pass a voiceprint check. The control's central assumption, that attackers cannot fake a voice convincingly, is eroding in real time.

• Demographic accuracy variance: A peer-reviewed analysis found 18% variance across demographic cohorts. At enterprise scale, demographic accuracy variance becomes both a customer experience (CX) problem and a compliance exposure, as some customer groups face higher false-reject rates than others.

• Single-control design: Any lone control that gates account access becomes the entire attack surface. Once attackers defeat it, nothing behind it holds.

Voice biometrics still needs governance on when to trust it and when to require an additional factor. A durable authentication program verifies identity across controls. When one control weakens, policy can require another based on risk.

What compliance now requires from contact center authentication

Federal guidance has already resolved part of the KBA decision. Under NIST SP 800-63-4, effective August 1, 2025, KBA does not constitute an acceptable secret for digital authentication. High-risk call workflows that still rely on security questions need to be reviewed against assurance requirements.

Contact center teams need two plain-language measures. Identity Assurance Level (IAL) describes how confidently an organization establishes a person's real-world identity. Authentication Assurance Level (AAL) describes how confident a returning caller is that they are who they claim to be. Assurance levels scale with risk because not every call requires the same level of identity confidence.

Risk-tiered assurance maps directly onto the call workflows running through your contact center every day:

• Balance inquiry: Low assurance. A customer checking a balance poses limited risk if verification is light, so the required identity confidence is modest.

• Account or beneficiary change: Elevated assurance. Changing who controls or benefits from an account is a higher-stakes action and warrants stronger verification.

• High-risk request: Highest assurance. SIM swaps and wire transfers are where attackers concentrate, and these request types demand the strongest available identity confidence.

Risk-tiered authentication is straightforward to describe and hard to run, because it has to happen in real time inside a live call. The system must recognize what the caller is trying to do in the first seconds, then decide how hard to verify before any account action proceeds. Static Interactive Voice Response (IVR) authentication flows that apply a single blanket check to every caller cannot make dynamic, risk-tiered decisions. The verification decision has to respond to intent in real time and apply consistently across every call.

Governing authentication when an AI agent runs the call

When the agent conducting verification is an AI system running at scale, teams need a governed authentication policy with explicit rules for each call workflow. The AI-agent authentication policy must verify before any account action and select the appropriate assurance based on the caller's intent. If a call escalates mid-conversation, the same policy must carry cleanly into human handoff. A policy error can repeat across many simultaneous calls, so verification logic needs the same discipline as any production AI workflow.

Teams have to treat authentication as a lifecycle discipline. The same four phases that govern any production AI agent apply directly to the verification policy:

• Design and integrate: Build verification logic tied to call-workflow risk, so a balance inquiry and a wire transfer trigger different identity confidence from the first seconds.

• Test and iterate: Simulate fraud attempts and social-engineering scripts against the agent before production, unit-testing the authentication workflow the way you would any critical path.

• Deploy and scale: Apply consistent policy across multiple languages and call volume, so verification does not weaken on the thousandth simultaneous call.

• Monitor and improve: Monitor authentication outcomes and adapt as threats evolve, because the controls that hold today will be probed tomorrow.

For enterprises in mid-transition, the sequencing logic follows the same risk map. Retire KBA first on the highest-risk workflows, treat KBA as a legacy control that teams are retiring, and layer stronger verification where the stakes justify it. Teams must build contact center AI security into the agent before deployment.

Partnering with Parloa, Schwäbisch Hall put governed AI-agent authentication into practice. The deployment handled 500,000 calls over six months, achieved an authentication rate above 80%, reached 98% intent-recognition accuracy, and supported 16 live use cases. That deployment shows that an AI agent can verify identity at significant production volume, where governance becomes a production requirement.

Make knowledge-based authentication a governed decision

KBA is not a safe standalone control. Security questions and last-four checks can no longer carry the verification decision on their own, because the answers are exposed in breach data, harvested through social engineering, and findable in public records. KBA can still play a supporting role inside a layered policy, but it cannot be the gate that stands between a caller and an account change. The authentication policy should align with call-workflow risk, and knowledge-based authentication should no longer be the default control for high-risk journeys.

Parloa's AI Agent Management Platform treats verification as part of lifecycle management: Design and Integrate, Test and Iterate, Deploy and Scale, and Monitor and Improve. For regulated contact centers, teams can design, test, and continuously monitor authentication policy when it touches payment data or account changes inside a live call.

Book a demo to see how AI agents can run risk-based authentication at enterprise scale. Certifications and alignments backing the platform include ISO 27001:2022, ISO 17422:2020, SOC 2 Type I & II, PCI DSS, HIPAA, GDPR, and DORA. Legitimate customers get through faster, and fraudsters get stopped, instead of the reverse.

FAQs about knowledge-based authentication

Why does KBA fail legitimate customers more than fraudsters?

Genuine customers forget the answers they set years ago, while fraudsters look them up in breached data and public records. The control can lock out the real customer and admit the impostor.

Is voice biometrics a safe replacement for KBA?

It solves KBA's core flaw. Voice biometrics still needs supporting controls because AI voice cloning is defeating voice ID, and demographic accuracy variance creates fairness and compliance risk.

What does NIST SP 800-63-4 mean for contact centers?

Effective August 1, 2025, KBA is no longer an acceptable secret for digital authentication. Authentication strength must match the risk of each call workflow. One blanket control cannot cover every call workflow.

How should an AI agent handle caller authentication?

As a governed policy rather than a fixed script. Verification should be sequenced before any account action, tested against fraud attempts, and monitored continuously as threats evolve.