Notifications
Clear all
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.
NHIMG editorial — based on content published by Trusona: Verifying people who don't have a Social Security number
Questions worth separating out
Q: How should identity teams verify users who do not have a Social Security number?
A: Use an identity proofing path that checks a government-issued document against the issuing authority, rather than asking for a US-only identifier.
Q: Why is using an SSN in account recovery a security risk?
A: Because an SSN is a durable identifier that users cannot change if it leaks, and attackers can reuse it for years.
Q: What breaks when a verification script assumes every user has the same national identifier?
A: The flow stops working for legitimate users who never had that identifier, including people outside the country, people in onboarding windows, and users who hold other official numbers instead.
Practitioner guidance
- Remove SSN as a default recovery question Strip the SSN field from identity verification scripts unless a specific regulatory use case truly requires it.
- Shift to issuing-authority verification Use government-issued document checks that query the issuer or authoritative record rather than relying on visual inspection or memorised data.
- Test the no-record and no-document paths Validate how the workflow behaves when the user has no SSN, no existing internal record, or no government-issued document.
What's in the full article
Trusona's full blog covers the operational detail this post intentionally leaves for the source:
- The specific first-contact verification workflow used for callers without an SSN
- The questions used to distinguish document inspection from issuing-authority validation
- Operational examples showing how the flow handles first-time users and mixed-country populations
- The implementation details behind data deletion, liveness avoidance, and real-time verification
👉 Read Trusona's blog on verifying users without a Social Security number →
No-SSN verification: what identity teams need to change now?
Explore further
14/09/2026 10:10 am
SSN-based verification is a design constraint masquerading as a control. Once an identity workflow depends on a US-only identifier, it has already failed the mixed-population test. The issue is not just coverage, but governance: the organisation is using a signal that many legitimate users cannot provide and attackers value precisely because it is hard to rotate. Identity teams should treat this as a verification architecture problem, not a user exception problem.
A question worth separating out:
Q: Should organisations keep document images or SSNs after verification?
A: Only if there is a clear legal or audit requirement. Otherwise, retaining SSNs, scans, or templates turns a one-time verification event into a permanent data protection problem. The safer model is to delete unnecessary artefacts after the check and preserve only the minimum operational evidence needed for traceability.
👉 Read our full editorial: Verifying users without an SSN exposes weak identity scripts
