10 Questions to Ask an Identity Verification Vendor Before You Sign

Two cases from 2026 explain why most identity verification evaluations ask the wrong questions.

Alicia Flanagan worked as a nurse at two Arkansas facilities using the real, valid, in-good-standing license of a nurse in Virginia. In June, Carleen Noreus pleaded guilty to selling roughly 2,600 fraudulent nursing diplomas through two South Florida schools — part of Operation Nightingale, which produced more than 7,300 fake diplomas in total. Many purchasers passed the NCLEX and obtained genuine state licenses.

Flanagan was the wrong person with a real credential. The Nightingale purchasers were the right people with fake credentials. No single control catches both, and a vendor evaluation that doesn't start there will produce a confident answer to a question you didn't need answered.

Here are the ten questions worth asking instead. Several of them are uncomfortable for vendors. That's the point.

1. Which failure mode does this actually address?

Ask directly: does this product verify that a person is who they claim to be, or that a credential is legitimate?

A vendor who answers "both" without distinguishing them is either selling a bundle or hasn't thought about it. Identity verification confirms the person. Primary source verification confirms the license. Education verification confirms the schooling. They are separate controls with separate failure modes, and you need to know which ones you're buying and which ones remain your problem.

Follow up with: would this have caught Operation Nightingale? The honest answer for any pure identity product is no — those individuals were exactly who they said they were. A vendor who claims otherwise is telling you something you can check.

2. Do you detect injection attacks, or only presentation attacks?

This is the single most technically revealing question on the list, and most buyers don't know to ask it.

A presentation attack shows fake imagery to the camera — a printed photo, a screen, a mask. Presentation Attack Detection catches this by looking for artifacts in the captured scene.

An injection attack bypasses the camera entirely, feeding a deepfake directly into the verification software's data stream. Because no real scene is ever captured, the camera-based signals that PAD depends on simply aren't there. Injection defeats presentation-attack detection by design, not by being better at fooling it.

Reporting suggests injection attacks have become substantially more common than presentation attacks. If a vendor's liveness answer only describes PAD, they are defending the door while the wall is open.

Ask whether they have been independently tested for injection resilience — CEN/TS 18099 covers this as a distinct test scope, with ISO/IEC 25456 in development.

3. When you say "NIST," which document and which level?

"NIST-certified" appears in a lot of identity marketing and means very little on its own. NIST publishes several things that get conflated:

• SP 800-63A-4, finalized August 2025, covers identity proofing and enrollment — including, notably, a section on digital injection prevention and forged media detection, treated as a requirement distinct from PAD.
• Identity Assurance Levels (IAL1, IAL2, IAL3) describe the rigor of the proofing process. IAL2 is not a deepfake-detection certification, and a vendor citing "NIST Level 2" in a sentence about deepfakes is blurring two different things.
• FRVT / FATE evaluations measure algorithm performance and are ongoing, not a pass/fail badge.

Ask which document, which version, which level, and whether the assessment was independent or self-declared. A vendor who can answer that precisely is a vendor who reads the standards.

4. What happens when verification fails — and is that an adverse action?

This is where general-purpose identity vendors reveal whether they understand employment.

A failed verification is not the same as a fraud finding. Poor lighting, a damaged document, an old ID, a disability affecting the capture flow — legitimate candidates fail identity checks for mundane reasons. What your process does next matters legally and practically.

Ask: what's the remediation path? Is there a manual review queue, and who staffs it? What does the candidate see? And critically — does your product treat a verification failure as a screening decision? If a failed check contributes to a decision not to hire, you may be in territory governed by the FCRA and by state fair-chance rules, with notice and dispute obligations attached.

Most KYC vendors have never had to think about this. Vendors built for hiring have.

This is general information, not legal advice. Confirm your obligations with counsel.

5. Where does biometric data live, for how long, and under whose consent?

Biometric data carries specific statutory exposure that general PII does not.

Illinois, Texas and Washington have standalone biometric statutes. Illinois BIPA is the one that generates litigation: it requires advance written informed consent stating the purpose and retention period, a publicly available retention and destruction policy, and it carries a private right of action with statutory damages — reported at $1,000 for negligent and $5,000 for intentional violations. In April 2026 the Seventh Circuit held that the per-person damage accrual amendment applies retroactively to cases pending as of August 2024. Roughly twenty additional states treat biometric data as sensitive data under broader consumer privacy laws.

Ask the vendor: is the biometric template stored or discarded after matching? Where? For how long? Who obtains consent — you or them? What does the consent language say, and will your counsel see it before a single candidate is enrolled?

"We're SOC 2 compliant" is not an answer to any of these questions.

6. What evidence do I get for an audit?

You will eventually need to demonstrate, to an auditor, a regulator, an accrediting body or opposing counsel, that a specific person was verified on a specific date by a specific method.

Ask what the audit record contains, how long it's retained, whether you can export it, and what happens to it if you leave. A verification you can't evidence later is a control you can't prove you ran.

7. What is your completion rate, and what happens to candidates who can't finish?

Vendors quote accuracy. Accuracy on completed verifications tells you nothing about the candidates who abandoned partway.

Ask for the completion rate on a comparable population, and ask what happens to people who can't complete: candidates without a smartphone, without a current government ID, with limited connectivity, with a disability affecting the capture flow, or who simply decline on privacy grounds. In high-volume or shift-based hiring, an identity step that quietly loses ten percent of applicants is an expensive control regardless of how accurate the other ninety percent were.

Ask specifically about accessibility and about the alternative path for candidates who can't use the primary flow.

8. What is your demographic performance?

Face matching algorithms do not perform identically across demographic groups, and NIST's evaluations have documented differentials for years.

In an employment context this is not a technical footnote. A verification step that fails more often for one group than another, and that contributes to hiring outcomes, is a disparate impact question. Ask for demographic performance data. Ask whether it's independently measured. Ask what the vendor does when a differential is found.

A vendor who has never been asked this will say so in how they answer.

9. Where in the workflow does it run, and what does a failure cost me?

Identity verified after you've ordered primary source verification, education verification, background screening and a drug panel means you've paid for all of it on a candidate who may not exist.

Verified at application, the same control becomes a filter. Ask where the vendor's customers typically place it, what integration that requires, and how much of your existing process has to change. A product that only works if you rebuild your workflow around it has a cost that won't appear on the quote.

10. Is the verification reusable — and who owns it?

Ask what happens to a verification after it's delivered.

If it expires on completion, you pay again at every re-screen, every renewal, every new placement. If it's portable — a credential the individual holds and can present again — the same check becomes an asset that accelerates every subsequent process. In contingent and high-turnover environments, this is often the largest cost variable in the entire evaluation, and it's the one most rarely raised in a demo.

Then ask who owns it. If the credential belongs to the vendor rather than to the person, portability is a marketing word.

How we answer these

It would be poor form to publish this list and dodge it.

Failure mode: vID addresses identity — binding a real person to a government-issued document with biometric verification and liveness detection. It would not have caught Operation Nightingale. Those individuals were who they claimed to be. We do not verify licenses or education; Nursys, the state boards and the issuing institutions do that, and you need those controls alongside ours.

Workflow position: vID runs at the start of the process, before screening is ordered, and it does not require a background check — it can operate as a standalone identity step inside a credentialing process you already have.

Reusability: The Wallet seals a completed verification into a portable credential the individual carries and can present again — which is the specific reason we built it, and the answer to question ten.

Everything else on this list — injection testing scope, retention specifics, completion and demographic performance, audit export, consent language — deserves a direct conversation with our team and documentation rather than a paragraph in a blog post. If you're evaluating us, ask all ten. If a vendor won't answer them in writing, that is itself an answer.