What do organisations get wrong about knowledge-based verification for support requests?

Why Organisations Overestimate Knowledge-Based Verification

Knowledge-based verification fails when teams confuse familiarity with identity. Support agents often ask for pet names, prior addresses, manager names, or other details that are easy to recover from breaches, social media, or public records. That creates a false sense of assurance while giving attackers a low-friction path to impersonate legitimate users. NIST’s NIST Cybersecurity Framework 2.0 emphasizes stronger, risk-based control selection rather than relying on weak challenge questions as a default gate.

The mistake is usually operational, not theoretical. KBA survives because it is cheap, familiar, and easy to script into a help desk workflow. But it does not scale to modern attack conditions, where adversaries can combine breached data, phishing, and social engineering in minutes. NHIMG’s Ultimate Guide to NHIs shows how commonly attackers benefit from weak identity hygiene elsewhere in the enterprise, including the fact that 79% of organisations have experienced secrets leaks and 77% of those incidents caused tangible damage. In practice, many security teams discover the weakness of KBA only after a support agent has already reset access for the wrong person.

How Support Verification Should Work Instead

Better verification starts by treating the help desk as a risk decision point, not a memory test. The question is not “does the caller know static facts,” but “is there enough evidence to justify this request right now?” That usually means combining multiple signals: authenticated portal access, verified callback to a known number, device or session continuity, ticket context, step-up approval for high-risk actions, and clear separation between low-risk and privileged requests.

For sensitive actions such as password resets, MFA rebinds, bank detail changes, or recovery of admin access, current guidance suggests using stronger identity assurance aligned to the request’s impact. NIST’s framework direction supports proportionate controls, while NHIMG’s Ultimate Guide to NHIs is useful for understanding how credential exposure and weak control design compound over time. In practice, organisations should define:

• Which support actions are never eligible for KBA alone
• What evidence is required for identity proofing versus account recovery
• When to require manager approval or out-of-band confirmation
• How to log, review, and challenge unusual support requests

In mature environments, the strongest pattern is to minimise discretionary judgment and force the workflow through policy. That reduces pressure on individual agents, closes informal exceptions, and makes replay attacks less effective. These controls tend to break down in distributed support centres with inconsistent scripts, weak ticketing discipline, and no authoritative user registry because verification becomes fragmented across tools and people.

Where the Practical Edge Cases Appear

Tighter verification often increases customer friction and support handling time, requiring organisations to balance recovery speed against fraud resistance. That tradeoff is real, especially for retail, healthcare, and global service desks where urgent access restoration matters. The goal is not to eliminate all inconvenience, but to reserve lighter checks for low-risk cases and apply stronger proof only when the blast radius justifies it.

There is no universal standard for KBA replacement yet, but best practice is evolving toward layered assurance and documented exception handling. Static questions may still have limited value as one weak signal among many, but they should not be treated as identity proof for privileged actions. The safer pattern is to pair policy-based verification with auditability and clear escalation paths, using the NIST Cybersecurity Framework 2.0 for governance alignment and NHIMG’s Ultimate Guide to NHIs for broader identity risk context.

Edge cases appear when support teams serve contractors, consumers with sparse records, or regions where identity data is fragmented across systems. In those environments, organisations should prefer consistent recovery workflows over improvisation, because improvised verification is exactly where attackers exploit human trust.

Related resources from NHI Mgmt Group

• What do security teams get wrong about identity verification for support requests?
• What do organisations get wrong when comparing seat-based pricing with consumption-based pricing?
• What do organisations get wrong about questionnaire-based vendor risk management?
• What do organisations get wrong about identity verification during account recovery?