Who is accountable when identity verification workflows rely on knowledge-based authentication?

Why This Matters for Security Teams

When identity verification relies on knowledge-based authentication, accountability sits with the security, identity, and control owners who approved it as a verification method, not with the end user who answered the questions. KBA is weak because it proves familiarity with exposed facts, not trustworthy identity. That makes it a governance problem, a risk acceptance problem, and often a policy failure. Controls should be evaluated against stronger identity assurance requirements in NIST SP 800-53 Rev 5 Security and Privacy Controls.

NHI Management Group research shows how often identity assurance fails in practice: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, according to the Ultimate Guide to NHIs. The same pattern applies to weak verification methods. If a workflow can be bypassed by data that is purchasable, searchable, or reused across breaches, the organisation has accepted avoidable impersonation risk. In practice, many security teams encounter that failure only after an account takeover, support fraud, or recovery abuse has already occurred, rather than through intentional assurance design.

How It Works in Practice

Accountability should be assigned to the control owner who selected KBA, the identity governance team that approved it, and the business owner who accepted the risk. In mature programmes, KBA is treated as a legacy fallback, not a primary verifier. The preferred path is stronger assurance: cryptographic credentials, device-bound authentication, or origin-bound signals that are harder to replay. That aligns better with current guidance in ISO/IEC 27001:2022 Information Security Management and identity proofing expectations in eIDAS 2.0, where assurance should be proportionate to the risk of impersonation.

Operationally, teams should document who owns each verification step, what evidence supports the method, and what triggers removal of KBA from the workflow. A practical control set usually includes:

• Replacing KBA with stronger authenticators for password reset, account recovery, and privileged step-up verification.
• Using risk-based checks that combine device, session, and origin signals instead of static challenge questions.
• Requiring approval from identity and security owners before KBA is used as an exception.
• Tracking whether support staff can override policy, and logging every such override for review.

For organisations handling sensitive access, this is not just an identity issue. It is a fraud-prevention and recovery-governance issue tied to the attack patterns documented in the 52 NHI Breaches Analysis and related compromise research. These controls tend to break down in outsourced help desks, high-volume consumer recovery flows, and legacy platforms where identity proofing cannot be re-engineered quickly because business pressure keeps exception paths alive.

Common Variations and Edge Cases

Tighter verification often increases friction and support cost, requiring organisations to balance assurance against recovery speed and user experience. That tradeoff is real, but it does not change accountability: the teams that continue using KBA must justify why stronger methods are not yet deployed, and they should define an end date for the exception. Current guidance suggests that if questions can be guessed, mined from public sources, or purchased from data brokers, KBA should be retired rather than hardened.

There are a few edge cases. Some low-risk workflows may tolerate limited KBA as a secondary signal, but only when paired with stronger controls and explicit review. Other environments, such as regulated financial services or customer onboarding, may need to align verification with AML and KYC obligations, where fraud and impersonation risks are materially higher. The practical lesson is that accountability stays with the control owner until the method is removed, and that owner must be able to show why KBA remained in scope. In NHI terms, the same governance failure appears when weak secrets handling is left in place because no single team owns remediation. That is why the Top 10 NHI Issues matter here: weak identity controls persist when responsibility is diffused instead of assigned.

Related resources from NHI Mgmt Group

• What breaks when contact-centre identity checks rely on knowledge-based verification?
• What breaks when knowledge-based verification is used as the main proofing method?
• Who should own identity verification when it sits inside authentication workflows?
• Why does knowledge-based authentication often fail in modern identity programmes?