Topic starter
14/09/2026 10:09 am
TL;DR: Identity verification scripts that rely on Social Security numbers fail for large parts of the user base and create avoidable data exposure, according to Trusona. The stronger pattern is to verify a government-issued document against the issuing authority, then keep SSN collection out of the flow entirely.
Editorial analysis by NHI Mgmt Group, based on content published by Trusona: “Verifying people who don't have a Social Security number”.
Key questions
Q: What breaks when identity verification depends on an SSN fallback question?
A: The flow breaks for legitimate users who do not have an SSN, including many non-US users, work-authorised arrivals still waiting on paperwork, and people with alternative tax identifiers.
Q: Why does asking for an SSN create more risk in identity verification?
A: Because an SSN becomes a permanent sensitive attribute once collected, yet it is a weak verifier on its own.
Q: How do teams verify users without relying on knowledge-based identity checks?
A: Use an authoritative document check that confirms the issuing authority has a matching record, rather than asking a user to recall a number or answer a legacy challenge.
Practitioner guidance
- Replace SSN fallback questions Use document-and-authority checks for identity verification so the flow works for legitimate users who have no SSN and does not force disclosure of a hard-to-rotate identifier.
- Remove SSN collection from verification Stop storing SSNs in identity workflows unless a specific legal or operational requirement exists, because the field adds sensitivity without improving verification quality.
- Validate against issuing authorities Require live record confirmation from the issuing authority instead of relying on visual inspection or knowledge-based fallback questions.
Bottom line: SSN-based identity scripts fail when they assume every legitimate user can supply the same US-specific identifier.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/09/2026 10:10 am
SSN fallback is identity debt: the problem is not merely a missing data field, but a verification script that has encoded a US-centric assumption into an access decision. That creates a mismatch between who can be verified and who can answer the question, and it pushes support teams toward improvisation. In identity programmes, brittle fallback questions are governance failures, not just UX defects.
A question worth separating out:
Q: How should organisations handle SSN data safely during background verification workflows?
A: Organisations should collect SSNs only for a legitimate screening purpose, limit access to staff with a need to know, and secure the data at rest and in transit. They should also define retention limits, remove SSNs from systems when the check is complete, and apply vendor oversight. That reduces breach exposure, misuse, and the long-tail identity theft risk tied to leaked SSNs.
👉 Read our full editorial: Verifying users without an SSN exposes weak identity scripts