A locked-out employee calls the helpdesk. The agent asks for a name, an employee ID, maybe the answer to a security question set up two years ago. The caller answers correctly, the agent resets their MFA, and just like that, the attacker is in the door. Nothing about that exchange confirmed who was actually on the line, only that someone knew a few facts, and attackers can research those facts as thoroughly as any real employee knows them.
Key takeaways
- Knowledge-based authentication (KBA), security questions, employee ID, confirms what someone knows, not who they are, creating an identity gap attackers exploit.
- Attackers now use generative AI to strengthen the social engineering itself, sharper pretexts, cloned voices, faster research, which is what gives them initial access in the first place.
- Biometric privacy statutes like BIPA regulate stored biometric identifiers specifically, not identity verification generally, which is why what gets stored matters more than whether verification happens.
- Identity verification prevents helpdesk social engineering, but most systems solve it by storing biometrics for every user.
- The Self-service and Helpdesk modules verify identity without storing biometric data.
Why Knowledge-Based Checks Fail at the Helpdesk
According to Verizon's 2026 Data Breach Investigations Report, social engineering was the third most common breach pattern, representing about one in six breaches. The report also found attackers increasingly turning to voice and other mobile-centric techniques, using generative AI not to invent some new attack vector, but to make the existing one, impersonating a real employee, harder to catch: a cloned voice, a more convincing pretext, research pulled together in minutes instead of hours. That shift is what makes KBA fail: it can only catch someone guessing, not someone who has done the research, or an AI system doing it for them.
The obvious fix, verify people more rigorously by collecting more identity data, runs into a second constraint: GDPR Article 9 and biometric privacy laws like Illinois's Biometric Information Privacy Act specifically regulate biometric identifiers used to recognize a person, treating that category of data as elevated risk regardless of how well it's secured. Security teams are caught between the two: verify more rigorously, but hold onto less identity data, not trade one for the other.
How Most Tools Try to Solve This Today
Faced with that tension, most self-service password reset and helpdesk verification tools stay with knowledge-based questions, easy to defeat once an attacker has done any homework. Others check a government photo ID against a live selfie and store the result, ID images, selfies, and the biometric templates generated from them. A biometric template is the mathematical representation of a person's facial features extracted from a scan for matching purposes, distinct from the photo itself, and it's typically stored indefinitely in a vendor database. That solves the impersonation problem, but creates a different one: that template database is exactly the kind of stored biometric identifier that statutes like BIPA are written to regulate. It's the same recurring trade-off covered in Self-Service Account Recovery Is Broken, just showing up here on the compliance side instead of the operational one.
How the Self-Service and Helpdesk Modules Resolve It
Nametag verifies the real human behind an account recovery or helpdesk request without generating a biometric template database in the first place. The comparison runs in real time and no template is retained afterward. Customers who wish to keep verification data in their own infrastructure can do so through Enterprise Data Custody, which stores things in the customer's own AWS S3 or Azure Blob Storage rather than Nametag's.
For an employee, account recovery means verifying identity with a live selfie and a government-issued photo ID, then resetting a password or clearing an MFA factor directly, without ever looping in the helpdesk. Returning users re-verify with just a selfie in as little as 3 seconds. Because it integrates with identity and access management (IAM) providers like Microsoft Entra ID, Cisco Duo, and OneLogin, this works within the systems already in place, giving security teams full auditability along the way.
For a support agent, helpdesk verification removes the guesswork entirely. Instead of judging whether a caller's answers sound convincing, the agent sends a verification request and gets back a clear Pass or Fail result in real time. On success, the agent can perform high-risk actions, a password or MFA reset, with confidence. Nametag's Helpdesk module embeds directly into IT service management (ITSM) workflows, including ServiceNow and Zendesk, so agents can verify identity without leaving the tools they already use. When an employee appeals a rejection, it doesn't fall to the agent to decide; Nametag's Managed Resolutions feature routes it to in-house identity and fraud experts, who resolve it into a definitive pass or fail.
Security and Compliance Impact
Not generating a biometric template removes an entire category of sensitive data from the equation: there's no template database to breach, subpoena, or misuse, the specific repository a stored-biometric vendor carries regardless of how well they secure it. Verification data, the ID and selfie, is still retained under your policy and still needs standard access controls, that part doesn't disappear. But the template itself, the piece of data biometric privacy laws are specifically written to address, is never generated in the first place. Separately, and just as concretely: most recovery happens without a ticket at all, which means fewer requests reaching the helpdesk queue, and the ones that do reach an agent come with a binary result to act on instead of a transcript of answers to judge.
Frequently Asked Questions
Does this mean no data is collected?
No. A government-issued ID and a live selfie are still used to verify identity. No biometric template is generated or retained. Verification data are retained under the customer's retention policy, or in the customer's own storage through Enterprise Data Custody.
How is this different from encrypting stored biometric data?
Encryption protects a template database at rest, but the database, and the template itself, still exists and can be breached, subpoenaed, or misused. When no template is generated, that database doesn't exist either.
What happens if an employee appeals a rejected verification?
The case routes through Nametag's Managed Resolutions feature to in-house identity and fraud experts, who resolve it into a definitive pass or fail rather than leaving the helpdesk agent to make a judgment call.