Should contact centres keep any fallback after KBA is retired?

Why a fallback can exist after KBA, but not replace the control objective

KBA retirement does not mean every fallback disappears, it means the fallback can no longer behave like an alternate fast lane. A defensible fallback should change the workflow enough to make abuse costly: slower handling, separate approval, stronger identity proofing, and a clear audit trail. The point is to preserve recovery without preserving the original weakness.

A good fallback is a containment mechanism, not a duplicate of the primary process. If it can complete the same transaction with the same urgency and same operator discretion, it has effectively inherited the role of KBA and will attract both routine use and attacker interest.

In contact-centre terms, that usually means the fallback should be usable only for a narrow set of cases, with explicit reason codes and supervisor review. The more often staff can reach the same outcome by bypassing the normal route, the less likely the fallback is to remain exceptional in practice.

What makes a fallback safe enough to keep

Keep the fallback only when it is clearly worse for the caller and better for control. That trade-off is intentional: the fallback should be slower, more observable, and more selective than the retired KBA path. If the process is meant to protect high-value accounts, the fallback should also raise the bar for access to the account, not just add an extra question.

Look for three properties together: independence, friction, and reviewability. Independence means the fallback should not rely on the same knowledge, phone number, or agent judgement that made KBA weak. Friction means it should add delay or extra verification steps. Reviewability means another person or a later control can test whether the fallback was used correctly.

That design aligns with the general control logic in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially access control, authentication, and auditability. It also fits the identity guidance in NIST SP 800-63 Digital Identity Guidelines, where stronger assurance should come from better proofing and authenticators, not from convenient exceptions.

How contact-centre teams should think about bypass pressure

The main operational failure is not that a fallback exists, it is that people start preferring it because it is easier than the primary control path. Once a fallback is available for speed, empathy, or customer retention, it tends to get widened, then normalised, then treated as mandatory service logic. That is how a temporary recovery measure becomes the new weak link.

Fallbacks are also attractive because they often sit at the intersection of user frustration and agent discretion. That makes them a good target for social engineering, impersonation, and repeated probing. A weaker route can be discovered simply by asking for it often enough, so the control should assume active abuse pressure rather than rare legitimate use.

For that reason, contact centres should treat any fallback as part of a controlled recovery design, not as an operations convenience. A useful reference point is NIST Cybersecurity Framework 2.0, because the relevant issue is governance of recovery and resilience, not just authentication mechanics.

Risk and Threat Considerations

Fallbacks after KBA retirement create a classic bypass risk: if the backup route is easier to use than the primary control, attackers will shift attention to it. The danger is not only account takeover, but also process drift, where frontline staff learn that the exception path is faster and safer than the intended path.

Failure mechanism: A fallback that preserves the same speed, same outcome, and same agent discretion as the retired KBA path becomes a de facto replacement control, which can be abused through impersonation, persistence by repeated attempts, or overreliance on agent judgement.

Impact: The organisation loses the security benefit of retiring KBA while keeping its attack surface, and it may also weaken audit quality because exception handling becomes too common to review meaningfully.

Practitioner Guidance

What to verify: Confirm that the fallback cannot complete the same request with the same urgency as the primary route. If it can, the design is already too permissive, even if the intent is good.

Decision rule: If the fallback is needed for business continuity, make it narrowly scoped, supervisor-approved, and recorded in a way that can be sampled later for misuse. If you cannot explain why it is slower and harder than the main path, do not keep it.

Common mistake: Teams often preserve customer convenience by allowing the fallback to behave like a normal support flow. That choice is usually incompatible with retiring KBA, because it replaces a known weak control with an equally convenient exception.

Practitioner takeaway: The right fallback is one that helps recover service while reducing attacker advantage, so any retained path should be harder to use, easier to inspect, and clearly less attractive than the control it replaces.

Related resources from NHI Mgmt Group

• When does an NHI become too risky to keep as-is?
• Why do retired APIs keep creating security risk after decommissioning?
• What breaks when movers keep inherited access after a role change?
• How do teams keep fallback links from weakening access controls?