Notifications
Clear all
Topic starter
11/07/2026 8:32 pm
TL;DR: Deepfake hiring fraud is pushing identity attacks into hiring, onboarding, and help desk workflows, where attackers can use synthetic faces, cloned voices, and fake personas to bypass credential-only IAM controls, according to Incode. The underlying problem is that many programmes still assume the person behind the device is already trusted, which no longer holds.
NHIMG editorial — based on content published by Incode: Deepfake Hiring Fraud on the Security You Should Know podcast
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
Questions worth separating out
Q: How should security teams handle deepfake risk in hiring and onboarding workflows?
A: Security teams should treat hiring and onboarding as identity proofing points, not just HR workflow steps.
Q: Why do MFA reset processes attract identity attackers?
A: MFA reset processes attract attackers because they often sit outside the strongest authentication path while still being able to change account state.
Q: What do organisations get wrong about identity verification and privacy?
A: A common mistake is treating security, privacy, and fairness as separate problems.
Practitioner guidance
- Map high-risk proofing moments Identify where hiring, onboarding, password reset, MFA recovery, and service desk escalation rely on subjective trust or a single signal.
- Harden help desk recovery workflows Require stronger identity assurance before any reset that can change authentication state.
- Build appeal and exception handling into verification Create a clear process for candidates or employees who are blocked by automated verification, including manual review, identity re-verification, and a time-bounded resolution path.
What's in the full article
Incode's full article covers the operational detail this post intentionally leaves for the source:
- Specific examples of where to place verification in hiring and workforce journeys.
- Discussion of appeal paths for legitimate users who are blocked by automated checks.
- Details on how facial data, consent, and model training are handled in privacy-sensitive environments.
- How the verification workflow integrates with help desk, HR, and identity systems.
👉 Read Incode's discussion of deepfake hiring fraud and identity verification →
Deepfake hiring fraud and MFA reset abuse: are controls keeping up?
Explore further
11/07/2026 9:01 pm
Credential verification is no longer enough when the attack target is the human layer. The article shows that passwords, devices, and even normal IAM workflows can all be satisfied without proving the actual person behind the interaction. That shifts the control problem from authentication alone to identity assurance at the moments where fraud turns into access. Practitioners should treat proofing as a core part of access governance, not as an optional fraud add-on.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who should own identity proofing controls in the enterprise?
A: Identity proofing should be owned jointly by IAM, security operations, and the business process owner for the workflow being protected. If the control sits only with the help desk or only with HR, it will fail at the point where one team can override the other without consistent governance.
👉 Read our full editorial: Deepfake hiring fraud exposes the limits of credential-only IAM
