Knowing your first school is not the same as being you
Why biographical security questions are weak evidence, how NIST frames the issue and what a usable account-recovery process should establish instead.
Your first school, the street where you grew up and a relative’s name can feel like intimate facts. They may also appear in family conversations, old social posts, public records or information shared with other organizations.
A person who knows those facts knows something about you. That is not the same as being you, controlling your account or having permission to reset it.
This distinction is easy to lose in customer support. A familiar detail makes a conversation feel personal, and a correct answer can look like a completed identity check. Knowledge about a person is not automatically a reliable authenticator for that person.
The issue is especially important when the reward for answering is a new password, a changed recovery number or access to sensitive records.
Why the question feels stronger than it is
A fact can feel private without remaining secret.
An answer can be easy for its owner and others to recall.
The same biographical fact may be requested by many services.
People do not usually choose their childhood history as a security credential. The information exists before the account and is shared for reasons unrelated to authentication.
That creates an awkward design tradeoff. A question with an obvious, stable answer is convenient, but others may know it. A question with an ambiguous answer can frustrate the legitimate user without reliably excluding an impersonator.
The interface can hide that weakness by presenting several questions and a formal verification screen. More fields do not necessarily produce stronger evidence if every answer comes from the same discoverable biography.
What NIST guidance says—and what it does not
The NIST SP 800-63B digital identity guidance does not treat knowledge-based questions as acceptable secrets for digital authentication. The NIST digital identity FAQ provides related explanations about the guidance and its scope.
This is an important standards reference, not a claim that every organization worldwide is legally prohibited from asking any personal question. Applicable requirements depend on the organization, jurisdiction and service.
The broader design conclusion is that security questions should not be casually treated as equivalent to possession of a strong authenticator. The rest of this article applies that distinction to everyday recovery and support decisions.
Information, identity and authority are different
| Question | What it can establish | What it cannot establish by itself |
|---|---|---|
| “Do you know this person’s school?” | Knowledge of a biographical fact | Control of the person’s account |
| “Can you receive a message at this verified route?” | Access to that route at that moment | Every possible right to change the account |
| “Can you authenticate with an enrolled method?” | Evidence associated with that method | Whether the requested action is appropriate |
| “Are you authorized to make this specific change?” | The action-level decision, with suitable evidence | A shortcut around the need to establish identity |
The table is an editorial model, not a replacement for a formal identity standard. It helps explain why a support call can contain accurate information and still lack adequate authorization.
The same distinction appears in helpdesk identity-reset decisions. A plausible story about losing a phone does not determine which evidence should replace the missing authenticator.
Familiarity can become a social shortcut
Support staff are trained to make interactions efficient and humane. A caller who knows account details and speaks confidently can seem easier to help than someone who struggles to remember an answer.
Unfortunately, confidence and familiarity are not reliable substitutes for the approved verification process. A legitimate customer may be anxious, have language difficulties or have forgotten an old answer. An unauthorized caller may have prepared accurate information.
A good process should accommodate the first person without automatically trusting the second. That requires a defined recovery path rather than an employee inventing more biographical questions until the conversation feels convincing.
The organization should also avoid making staff responsible for guessing character. The relevant task is to evaluate evidence and authority, not whether the caller sounds like a good person.
If a service still requires security questions
Some users cannot choose the authentication design of an existing service. If security questions are mandatory, review the provider’s guidance and available stronger recovery options.
Where the service permits it, a unique, non-biographical answer stored securely can avoid reusing a widely known personal fact. Treat that answer as another secret: do not reuse it across accounts or rely on memory if the stored wording must match.
This advice concerns optional security-answer fields, not official identity records. Do not falsify legal identity information, regulated account information or documents. If a field’s purpose is unclear, ask the provider before entering invented data.
A password manager can help store required recovery information, but protect the manager itself and plan for access if the primary device is lost. Replacing one fragile dependency with another is not a complete recovery design.
Do not make privacy depend on never sharing your life
People should be able to talk about their childhood, celebrate relatives and participate in communities without assuming that every biographical fact is an account password.
Reducing unnecessary public exposure can be sensible, but it does not repair an authentication system that relies on facts other people naturally know. Family members, classmates and previous service providers may already possess them.
The stronger response is to separate biography from authentication wherever the service allows it. Use suitable enrolled authenticators and recovery methods rather than trying to keep a whole life history secret forever.
This also makes the advice less blaming. If an account recovery process accepted a discoverable answer, the problem is not adequately explained by saying the user once posted a school photograph.
Recovery is part of the security model
Strong sign-in methods can be undermined by a weak fallback. If losing an authenticator leads to a phone call where public facts are enough to replace it, the account’s practical protection includes that recovery path.
Organizations should examine recovery with the same seriousness as ordinary login. Define evidence requirements, escalation, notification and limits on sensitive changes during recovery.
Consider what happens when several things are unavailable at once: the phone is lost, the email account is locked and the employee is traveling. Real users need a workable process for these situations.
Our article on phishing-resistant MFA and its limits explains why a strong authentication method is valuable but does not automatically secure every surrounding workflow.
A better support conversation
The support agent can explain which approved verification route is available and why a particular change cannot be completed through the current conversation. Clear next steps reduce the temptation to improvise.
Avoid asking for more sensitive information than the process needs. Collecting extra personal facts can create a privacy burden while adding little assurance.
If the caller cannot complete the normal method, move to a documented recovery or escalation procedure. Record what evidence was accepted and what remains unresolved. Do not turn a supervisor’s sympathy into an undocumented exception.
Managers should support agents who maintain the boundary while providing respectful service. A policy that disappears whenever a customer becomes angry is not a dependable recovery control.
If someone knows a supposedly secret answer
Knowledge of the answer does not prove that the account has been accessed. It does mean the answer should not be assumed private.
Where possible, replace exposed recovery answers with unique values and strengthen the available authentication and recovery methods through the service’s official settings. Review related accounts if the same answer was reused.
If you see unauthorized account changes, contact the provider through a trusted route and follow its recovery instructions. Do not rely only on changing the answer if sessions, recovery addresses or other access may also have changed.
Keep a record of relevant alerts and timing. Avoid sharing the answer itself in public discussions about the incident. The goal is to reduce exposure while establishing what actually happened.
How to review a legacy process
Start by identifying every place where biographical questions influence access: account creation, password reset, telephone support, employee onboarding and vendor administration.
For each use, ask what action a correct answer enables. A low-consequence personalization question and a question that authorizes a new recovery phone number are not equivalent.
Then identify a feasible migration path. Remove unnecessary questions, support stronger methods, explain changes clearly and provide accessible recovery options. A redesign that locks out legitimate users can generate pressure for informal bypasses.
Test the process with people who have forgotten old answers or changed circumstances. The aim is stronger evidence with a usable fallback, not a more elaborate memory exam.
The principle worth keeping
Account owners should also check recovery arrangements after major changes such as leaving a job, replacing a phone or closing an old email address. A strong primary login does little to clarify an obsolete fallback that nobody can use reliably. Review the provider’s supported options while access still works, and store recovery material according to its instructions rather than waiting for a lockout to discover the missing dependency.
The safest system is not the one that asks the most intimate questions. It is the one that knows what evidence each question provides, what it does not provide, and how a real user can recover access without turning public history into a master key.
Found a factual error or a source that has changed?
Send a correction →
