Security questions and knowledge-based authentication (KBA) still guard password resets, MFA recovery and call centre verification in many organisations, even though the answers are guessable, researchable and frequently forgotten by the real user. Standards bodies have moved against them, identity vendors now recommend against them, and Microsoft has announced the retirement of security questions in Entra self-service password reset. This guide covers what has changed and why, the official positions and dates, how to find every place KBA is still used (including help desks and customer contact centres), and how to replace it without locking people out. It is written for IAM engineers, CIAM owners and contact centre security leads. It goes deeper than the Account Recovery and Help Desk Security Guide, which covers recovery design as a whole.
Key takeaways
- KBA is no longer an accepted factor. NIST SP 800-63B-4 forbids prompting for KBA or security questions, and SP 800-63A-4 forbids knowledge-based verification for identity verification.
- Vendors are retiring it. Microsoft has announced that security questions will be retired for Entra SSPR in March 2027, and Okta recommends against security questions in any authentication flow.
- The weakness is structural, not configurable. Answers are low entropy, often public or purchasable, and Google's own study found many users could not recall them, so tuning question lists does not fix it.
- Call centres are the hidden estate. "Mother's maiden name" and "date of birth" checks spoken to an agent are KBA too, and they are where social engineering crews operate.
- Retire in phases, not by switch. Inventory, register a stronger alternative for every user, demote KBA to a secondary check, then remove it and purge stored answers.
What is changing and why
KBA asks the user to prove identity with something they know that is not a password: a preset question ("name of your first pet"), a user-written question, or, in call centres and identity proofing, "out of wallet" facts such as a previous address or loan amount (knowledge-based verification, KBV). It was popular because it costs nothing to deploy and needs no device. That is also the problem.
Why security questions fail
| Weakness | What happens in practice | Evidence |
|---|---|---|
| Low entropy | Common answers (popular pet names, cities, colours) can be guessed in a handful of attempts across many accounts | Google's WWW 2015 study (Bonneau et al.) found security far lower than user-chosen passwords |
| Public and breached data | Schools, birthplaces, family names and previous addresses are on social media, people-search sites and in breach dumps | The MGM help desk call relied on an employee identity found on LinkedIn |
| Fake answers | Users who invent answers to resist guessing often pick predictable fakes and then forget them | 37% of users in the Google study admitted fake answers, which reduced security overall |
| Poor recall | The genuine user fails, calls support and lands in a weaker manual path | About 40% of English-speaking US users in the Google study could not recall their answers; SMS reset codes succeeded over 80% of the time |
| Shared secrets | Answers are stored by the service and spoken to agents, so insiders and contact centre staff can harvest them | In the Coinbase insider breach, bribed support agents copied customer records, including transaction history, later used to impersonate the company |
| Not a second factor | Password plus security question is two things the user knows, not MFA | OWASP Choosing and Using Security Questions Cheat Sheet |
Account recovery is a form of authentication. If a phishing-resistant sign-in can be bypassed by answering "Where were you born?", the account's real strength is the strength of that answer.
Official timeline and current status
Status checked on 8 November 2026 against the sources listed in Standards and references. Vendor dates can move: treat them as announced, and recheck before you plan cut-over.
| Body or product | Position | Status as published |
|---|---|---|
| NIST SP 800-63B-4, section 3.1.1.2 | Verifiers and CSPs SHALL NOT prompt subscribers to use KBA or security questions when choosing passwords, and SHALL NOT permit stored password hints. Recovery follows section 4.2 (saved recovery codes, issued recovery codes and other defined methods) | Final, July 2025; supersedes SP 800-63B (2020) |
| NIST SP 800-63A-4, section 2.5.1 | KBV or knowledge-based authentication SHALL NOT be used for identity verification. Section 3.2 allows KBV only as part of a CSP's fraud management programme | Final, 2025 (SP 800-63-4 suite) |
| OWASP ASVS 5.0.0, V6.4.2 | Verify that password hints or knowledge-based authentication ("secret questions") are not present (Level 1) | Current release |
| Microsoft Entra ID SSPR | Security questions are not a sign-in method, cannot be used by administrator accounts, and "will be retired for Self-Service Password Reset (SSPR) in March 2027", as announced on Microsoft Learn (page updated 18 February 2026) | Announced deprecation; users must move to methods in the Authentication methods policy |
| Okta Identity Engine | Security question authenticator still available for MFA, SSO and recovery, but "Okta recommends against using security questions in any authentication flow"; it cannot be an additional authenticator where Okta FastPass is enabled | Available, not recommended |
The practical reading: there is no standard that permits KBA as an authenticator or as identity proofing evidence for new designs, and the largest workforce identity platform has a dated removal. For a deeper look at the proofing side, see the NIST SP 800-63A-4 Identity Proofing (IAL) Guide.
Who and what is affected
- Workforce SSPR: Entra tenants with security questions enabled in SSPR, and any on-premises password reset portal that uses question sets. Users whose only registered SSPR methods are security questions (or questions plus an office phone) will be unable to self-reset after removal.
- Workforce MFA: identity providers where a security question is enabled as an MFA or recovery authenticator, often left over from early rollouts.
- Customer accounts: CIAM and home-grown login stacks that ask a question before sending a reset link, or that use questions as "step-up" for payment or address changes. See the Customer IAM (CIAM) Guide.
- Contact centres and help desks: scripted verification that asks for date of birth, postcode, account number, last transaction or a "memorable word". This is KBA delivered by a person, and it is the route used in help desk impersonation attacks such as the MGM Resorts breach.
- Identity proofing and onboarding: credit-bureau style KBV quizzes at account opening, which SP 800-63A-4 no longer accepts as verification evidence.
- Legacy applications: line-of-business and vendor portals with their own question tables, frequently storing answers in plain text or reversible form.
- Administrators: privileged accounts are the highest-value target. Entra already blocks security questions for administrator SSPR; check every other system for the same rule.
Finding affected systems and identities
Most organisations underestimate the estate because KBA hides in scripts and application tables rather than in the identity provider. Build the inventory from four directions.
- Identity provider configuration: in Entra, review SSPR authentication methods and the Authentication methods policy. In Okta, check whether the Security Question authenticator is active and in which authenticator enrolment and global session policies it appears.
- Registration data: in Entra, go to Entra ID, Authentication methods, Activity (Authentication Policy Administrator role, Entra ID P1 or P2). "Users registered by authentication method" lists everyone registered for security questions, and "User registration details" shows each user's "Methods registered". Filter for users whose only methods are security questions; they are your lockout risk. Data can lag by up to 36 hours and excludes disabled and soft-deleted users.
- Usage data: the Usage tab's "Password resets by authentication method" and the registration and reset events list (Method used: Security questions) show how often questions actually complete a reset. Low use makes a fast removal safer; high use tells you where to campaign first.
- Applications and databases: search code and schemas for tables or fields named like security_question, secret_answer, memorable_word or kba; search front-end templates for "forgot password" flows that render a question. Record whether answers are hashed, encrypted or plain.
- Contact centre scripts: collect the verification scripts for every queue (service desk, customer service, outsourced partners, collections). Mark each question as "knowledge" (anything the caller can say) versus "possession" (a push approval, a one-time code to a registered device, a call-back to a number on file).
| Inventory field | Why it matters |
|---|---|
| System and flow (SSPR, MFA, step-up, agent script, proofing) | Decides the replacement method |
| Population and count of users relying on KBA alone | Lockout risk and campaign size |
| Privileged users in scope | Remove first, no exceptions |
| Answer storage (plain, encrypted, hashed) | Breach exposure and purge plan |
| Owner and vendor deadline | Accountability and timeline |
Migration options
Replace the question with something the user has or is, matched to the flow. NIST SP 800-63B-4 encourages every subscriber to keep at least two separate means of authentication, which is the single most effective way to reduce recovery volume. See the MFA backup codes and recovery codes guide and the Passkey account recovery guide.
| Flow | Replace KBA with | Trade-offs |
|---|---|---|
| Workforce SSPR | Authenticator app push or passkey, plus a second registered method; Temporary Access Pass or help desk issued one-time credential for users with nothing registered | Requires a registration campaign before removal; users without a phone need hardware keys |
| Customer password reset | Passkey sign-in (removes most resets), verified email or SMS one-time code plus risk signals, saved recovery codes for high-value accounts | SMS and email are hijackable; add cooling-off periods for payout and contact changes |
| Customer step-up | Passkey or app-based confirmation of the specific action | Needs app or passkey adoption; keep an assisted route |
| Help desk caller verification | Push or passkey challenge to a registered device, call-back to the number in the HR system, manager confirmation over a known channel, live video against an ID document for privileged resets | Longer calls; agents need scripts and authority to end and call back |
| Contact centre (customers) | In-app "verify this call" prompt, one-time code to the registered device, or voice and device risk signals as a supporting check | Customers without the app need a slower but stronger path, such as a posted code |
| Identity proofing | Document plus biometric comparison or other SP 800-63A-4 verification evidence; KBV kept, if at all, as a fraud signal | Cost per check; accessibility needs an assisted channel |
Choosing for small and large organisations
- Small organisations on Entra or Okta can usually switch SSPR to authenticator app plus a second method, run one registration campaign and remove questions in a quarter. The help desk script change is the bigger job.
- Large organisations with outsourced service desks, several CIAM stacks and regulated customer populations should run the retirement as a programme with a named owner per flow, and fund an assisted channel for people who cannot use a smartphone.
- Interim fallback: if questions cannot be removed yet, follow the OWASP cheat sheet: never the sole mechanism, hash answers like passwords, normalise case, count wrong answers towards lockout, and require re-authentication to change answers. Microsoft likewise recommends pairing questions with another method so they are used only when the phone is unavailable.
Testing and rollback
- Register first, remove later. Enable the replacement methods and enforce registration (Entra registration campaign or "require users to register when signing in") while security questions remain enabled. Track the count of KBA-only users to zero or to a known exception list.
- Pilot ring: remove questions for IT staff and one business unit. Microsoft's own example shows that removing a method can leave users without enough registered methods to reset, so watch reset failures and help desk calls for two weeks.
- Privileged users next: confirm administrators have no question-based path anywhere (IdP, PAM vault, cloud consoles, legacy apps).
- Broad removal: remove by group, with help desk staffing increased for the first week and a published self-help page.
- Contact centre change: deploy new scripts queue by queue, with call recording reviewed for script adherence.
- Rollback: keep the configuration change reversible for a defined window (re-enable the method for a group), but do not restore questions for privileged users. Once the window closes, purge stored answers from directories and application databases and record the deletion.
Test the new path adversarially: ask your red team or a social engineering provider to call the help desk as a named employee using only public information, and to attempt a customer reset with breached data. The Vishing and Help Desk Social Engineering Awareness Guide covers agent training.
Risks of doing nothing
- Forced lockouts: Entra users who rely on questions will fail SSPR once enforcement begins in March 2027, and the calls will land on the help desk, the channel attackers prefer.
- Takeover through recovery: attackers bypass strong sign-in by targeting the reset path. Scattered Spider actors convinced help desk staff to reset passwords and MFA tokens, according to CISA advisory AA23-320A; the Storm-2949 attack began with an attacker starting a self-service reset and posing as IT support to get the user to approve the MFA prompts.
- Audit findings: assessors testing against ASVS 5.0 (V6.4.2) or NIST SP 800-63-4 will record KBA as a failed requirement.
- Breach liability: stored answers are personal data reused across services; a database of plain-text answers is a credential breach for other sites too.
- Insider harvesting: any secret an agent hears can be sold, which is why possession-based caller verification matters more than script secrecy.
Detection and measurement
Monitor the reset path as closely as sign-in.
- Signals to log: password resets and MFA resets by method and by agent; new authenticator registrations shortly after a reset; failed security question attempts; recovery contact changes; privileged role use within an hour of a reset.
- Metrics: number of users whose only recovery method is KBA (target zero); percentage of resets completed with a possession-based method; help desk resets per 1,000 users per month; percentage of help desk resets verified by device challenge or call-back; mean time from reset to new strong authenticator registration; number of systems still storing answers.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01, PR.AA-02, PR.AA-03; DE.CM-03 | Credential management, proofing bound to context, authentication, monitoring personnel activity |
| NIST SP 800-53 Rev. 5 | IA-2, IA-5, IA-11, IA-12 | Authentication, authenticator management including recovery, re-authentication, identity proofing |
| OWASP ASVS 5.0.0 | V6.4.2, V6.4.3, V6.4.4, V7.4.3, V7.5.1 | No secret questions; resets that do not bypass MFA; re-proofing on lost factor; terminate sessions after factor change; re-authenticate before changing recovery data |
| ISO/IEC 27001:2022 | Annex A 5.17 Authentication information | Allocation and management of authentication information |
| MITRE ATT&CK v20 | T1684.001 Impersonation; T1598.004 Spearphishing Voice; T1078 Valid Accounts; T1110 Brute Force | Help desk impersonation, voice phishing for answers, use of recovered accounts, guessing answers |
Where identity fits beyond people
KBA has no place in machine identity, but the same anti-pattern appears when service account passwords are reset by a help desk ticket that only quotes the account name. Re-issuance of a non-human credential should require an owner request and approval, as described in the NHI Ownership Guide.
Practitioner checklist
- Inventory every flow that uses security questions, memorable words or spoken personal facts, including outsourced contact centres.
- Remove KBA for all privileged and administrator accounts immediately, in every system.
- In Entra, report users registered for security questions and those with no other method, and plan for the March 2027 SSPR retirement.
- Run a registration campaign so every user has at least two strong methods before removal.
- Rewrite help desk scripts around device challenge, call-back to a number on file and manager confirmation.
- Pilot the removal, monitor reset failures and help desk volume, then remove by group.
- Purge stored answers after the rollback window and record the deletion.
- Where removal must wait, apply OWASP interim controls: never sole factor, hashed answers, lockout counting.
- Alert on resets followed by new device registration or privileged activity.
- Test the new process with a social engineering exercise using public information only.
Standards and references
- NIST: SP 800-63B-4 Authentication and Authenticator Management
- NIST: SP 800-63A-4 Identity Proofing and Enrollment
- OWASP: Application Security Verification Standard 5.0
- OWASP: Choosing and Using Security Questions Cheat Sheet
- Microsoft Learn: Security questions in Microsoft Entra ID
- Microsoft Learn: Authentication methods activity
- Okta: Configure the Security Question authenticator
- Google Research: Secrets, Lies, and Account Recovery
Related NHI Mgmt Group resources: Account Recovery and Help Desk Security Guide · Help Desk Social Engineering Incident Playbook · Passkey Rollout Guide · SIM Swap Fraud Guide · Scattered Spider Threat Actor Profile