TL;DR: Knowledge-based authentication can add a lightweight check to identity verification, but static questions are guessable, dynamic questions depend on external data quality, and both are vulnerable to breach exposure and social engineering, according to 1Kosmos. For IAM teams, KBA should be treated as a fallback signal, not a durable trust anchor, in modern authentication programmes.
NHIMG editorial — based on content published by 1Kosmos: knowledge-based authentication and its role in identity verification
Questions worth separating out
Q: When should organisations stop using knowledge-based authentication for account recovery?
A: Organisations should stop using KBA for account recovery when the answers can be inferred from public data, breach dumps, or customer support scripts.
Q: Why does knowledge-based authentication often fail in modern identity programmes?
A: KBA fails because it assumes private knowledge stays private.
Q: How can security teams evaluate whether KBA is still acceptable in their environment?
A: Security teams should test whether each KBA question can be answered from open sources, whether the answer can change over time, and whether the process creates an easier bypass than the main login path.
Practitioner guidance
- Remove KBA from high-value recovery paths Reserve knowledge questions for low-risk friction only, and replace them in privileged or sensitive journeys with stronger recovery methods such as device binding, help-desk verification, or identity proofing.
- Map where KBA still exists in the identity journey Inventory onboarding, password reset, account recovery, and step-up authentication flows to identify every place where challenge questions are still used as a trust decision.
- Test KBA answers against public-source exposure Review sample questions for answerability from social media, breach data, and open web records, then retire any question set that can be reconstructed without private knowledge.
What's in the full article
1Kosmos's full article covers the operational detail this post intentionally leaves for the source:
- Examples of static and dynamic KBA question sets used in real identity flows
- A practical comparison of KBA alternatives such as OTPs, device authentication, and biometrics
- 1Kosmos's identity-based authentication and identity proofing capabilities in more implementation detail
- How the platform integrates with existing infrastructure through APIs and SDKs
👉 Read 1Kosmos's analysis of knowledge-based authentication and identity verification →
KBA and MFA: where identity checks still fall short?
Explore further
KBA is a brittle identity control because it treats personal knowledge as if it were a stable secret. That assumption was always weak in consumer-facing identity, and it fails further once attackers can mine public data, breach dumps, and social profiles. The result is a control that looks familiar to users but offers far less assurance than its place in many recovery flows suggests. Practitioners should treat KBA as a legacy fallback, not as a trust anchor.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why weak identity controls often persist unnoticed across recovery and authentication flows.
A question worth separating out:
Q: What is the difference between KBA and stronger identity verification methods?
A: KBA relies on remembered information, while stronger methods rely on possession, biometrics, or device-bound verification. The difference matters because knowledge can be guessed or researched, but a possession or inherence factor usually requires a separate attack path and gives the programme a higher assurance signal.
👉 Read our full editorial: Knowledge-based authentication is a weak identity fallback