Your service desk handles dozens of password resets each week. Someone calls in, answers a few security questions, and gets access restored. It's routine until the day you realize the person who just reset a privileged account wasn't actually your employee.
These questions come up constantly in fintech risk and compliance channels. They're not theoretical, they reflect the daily tension between operational efficiency and verification certainty. Here's what practitioners are asking about identity verification during onboarding and account recovery.
Why Are These Questions Arising?
The authentication perimeter has hardened considerably. Multi-Factor Authentication (MFA) is standard, conditional access policies are common, and credential theft has gotten harder. So attackers shifted their focus to the processes that establish or restore identity in the first place: new employee onboarding and account recovery flows.
In July 2026, the US Department of State and allies issued a joint alert about North Korean IT workers impersonating foreign nationals to secure employment using falsified identity documents. The 2025 M&S ransomware breach, linked to social engineering tactics where attackers impersonated employees to reset passwords, contributed to an estimated $400 million impact on operating profit. These aren't edge cases. They're indicators that the weakest link isn't always the login, it's the moment when trust gets established or re-established.
What's Wrong with Security Questions?
Security questions fail because the answers are discoverable. "What's your first pet's name?" can be researched through social media, data breach dumps, or simple reconnaissance. An attacker who's done basic OSINT on your employee can answer these questions as confidently as the real account holder.
The larger problem is that security questions rely on static information that doesn't change and can't be revoked. Once an attacker knows the answer, that knowledge persists indefinitely. Compare this to MFA, where even if an attacker intercepts one authentication code, it expires within seconds and can't be reused.
For high-consequence events, resetting a privileged account, changing banking details in payroll, or granting initial system access, you need verification that can't be researched or guessed.
How Do We Verify Someone During Onboarding Without Delaying Hiring?
You don't need high-assurance verification for every identity event, only for the ones where the consequences of getting it wrong are severe. This is where risk-based verification makes sense.
For standard employee onboarding, government ID validation combined with biometric liveness detection provides strong assurance without requiring in-person verification. Document scanning confirms the ID is legitimate, while liveness detection verifies that a real person is present during the process, not someone holding up a photo or replaying a video.
The key is to apply this verification once during onboarding rather than at every subsequent authentication. Once you've established high confidence in the initial identity, you can rely on standard authentication controls for routine access. This keeps friction low for day-to-day operations while protecting the moment when trust is first established.
Can Attackers Fake Government IDs?
Yes, and they do. The North Korean remote worker campaigns demonstrate exactly this, falsified identity documents, images supplied by third parties, and sophisticated manipulation of verification evidence.
This is why document validation alone isn't sufficient. You need to verify both the document and the person presenting it. Liveness detection addresses the presentation attack: it confirms that the person completing the verification is physically present, not using a static image, pre-recorded video, or deepfake.
AI has made impersonation more convincing through synthetic profiles, manipulated images, and cloned voices. The countermeasure isn't to abandon document verification but to layer it with biometric checks that are harder to spoof in real time.
How Do We Verify Someone Who's Lost Their MFA Device?
Account recovery is where social engineering attacks concentrate. Threat actor groups like Scattered Spider are proficient at impersonating employees and calling the service desk to reset passwords, which is exactly what happened in the M&S breach.
The traditional approach, asking for an employee ID or phone number, fails because this information is often available through breaches or internal reconnaissance. Your service desk agent is being asked to make a high-stakes decision (restore access to a potentially privileged account) based on weak signals.
For privileged accounts or sensitive recovery requests, you need the same level of verification you'd use during onboarding: government ID validation and liveness detection. This doesn't mean applying it to every password reset. A standard user who forgot their password might go through automated recovery with MFA verification. But when someone claims they've lost access to all their authentication factors and needs a full reset? That's when you escalate to high-assurance verification.
How Do We Convince Leadership This Is Worth the Investment?
Frame it in terms of consequence. What's the cost if an attacker successfully impersonates an employee and gains initial access to your environment? What's the cost if a social engineering attack resets a privileged account and leads to a ransomware deployment?
Use the M&S example: a $400 million impact on operating profit. Compare that to the cost of implementing stronger identity verification at the points where trust is established or restored. The ROI calculation becomes clear when you're protecting against high-impact, low-frequency events.
You're not adding verification to every authentication event, you're applying it strategically to the moments where attackers are actively targeting your processes. That's a defensible use of security budget.
What Does This Look Like Operationally for Our Service Desk?
Your service desk needs clear policies defining when high-assurance verification is required. Create a decision tree: standard password reset with MFA verification for routine requests, escalation to government ID validation and liveness detection for privileged account resets or when all authentication factors are lost.
Train your agents to recognize social engineering tactics and give them the authority to escalate suspicious requests. The goal isn't to make them identity experts but to provide tools that remove the guesswork. When an agent can initiate a verification flow that validates a government ID and confirms liveness, they're no longer relying on their judgment about whether the caller "sounds legitimate."
Document the process clearly and measure it. Track how often high-assurance verification is triggered, how many requests fail verification, and whether you're seeing patterns that indicate attempted attacks. This data helps you refine policies and demonstrates to leadership that the controls are working.
Where to Go for More
NIST SP 800-63B provides digital identity authentication guidelines, including identity proofing requirements for different assurance levels. Review section 5 for specific guidance on identity verification and document validation.
For financial institutions, the FFIEC IT Examination Handbook includes expectations around identity verification during onboarding and account maintenance. Your examiners will ask how you verify identity before granting access or making sensitive account changes.
If you're implementing biometric verification, understand the difference between authentication (proving you're the same person who enrolled) and identification (proving you are who you claim to be). You need both during onboarding and high-risk recovery events.
