Why do deepfakes create a new identity security problem even when passwordless is deployed?

Why This Matters for Security Teams

Deepfakes change identity security because they can convincingly imitate a person at the exact moment a workflow depends on human judgment. Passwordless authentication removes a major class of secret theft, but it does not verify whether a caller, approver, or recruiter is being socially engineered by synthetic audio or video. That gap matters most when the request is urgent, exceptional, or outside normal process.

This is why identity teams must think beyond login assurance and into the trust decisions around it. NHI governance already shows how often identity failures are about visibility, privilege, and process, not just credentials. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a reminder that the attack surface often expands where trust is too broad, not where authentication is weak. NIST’s NIST Cybersecurity Framework 2.0 also reinforces the need to manage identity risk as an ongoing governance problem, not a one-time login event.

In practice, many security teams encounter deepfake-driven abuse only after a help desk reset, payment approval, or account recovery has already been completed under false pretenses.

How It Works in Practice

Deepfakes exploit the fact that many organisations still rely on voice, face, or familiar mannerisms as informal proof of identity. A synthetic executive voice can pressure a help desk into bypassing normal checks. A fabricated video can make a recruiter accept a fraudulent candidate interaction. A cloned manager can authorise a change that should have been independently reviewed. Passwordless helps because stolen passwords, push fatigue, and phished OTPs become less effective, but the workflow still has human decision points that can be manipulated.

The practical response is to harden the trust layer around identity events. Security teams should require separate verification paths for high-risk actions, especially resets, approvals, bank changes, and vendor access. That usually means call-back procedures, policy-based step-up checks, independent approval channels, and strong evidence that is not voice or video alone. For machine-to-machine workflows, the same principle applies through workload identity and short-lived secrets, not long-lived credentials. The Top 10 NHI Issues and the 52 NHI Breaches Analysis both show that identity risk tends to concentrate where credentials, approvals, and visibility are weak.

• Use a second channel for high-risk requests, such as manager callback or ticket verification.
• Treat audio and video as untrusted evidence unless corroborated by process data.
• Limit help desk authority with RBAC, PAM, and JIT access for recovery actions.
• Log and review identity events that change trust state, not just successful logins.

Best practice is evolving, but current guidance suggests that organisations should map these controls to NIST Cybersecurity Framework 2.0 outcomes for identification, access control, and governance. These controls tend to break down in high-pressure service desks and outsourced support environments because speed targets encourage exceptions.

Common Variations and Edge Cases

Tighter identity verification often increases friction, training burden, and support latency, requiring organisations to balance fraud resistance against operational speed. That tradeoff is especially visible in customer support, executive assistance, and incident response, where delayed approvals can have real business impact.

There is no universal standard for this yet, but current guidance suggests different thresholds by use case. A low-risk directory update should not require the same workflow as a wire transfer or privileged account recovery. For high-impact actions, organisations should combine identity proofing, contextual approval, and exception logging rather than trusting a single voice or face. The Cisco DevHub NHI breach and JetBrains GitHub plugin token exposure illustrate the wider lesson: identity failures often cascade when trust in one layer is assumed to protect all others. For emerging agentic workflows, NIST Cybersecurity Framework 2.0 and Ultimate Guide to NHIs - What are Non-Human Identities both support the same principle: authenticate the actor, but also verify the action.

The hardest edge case is when a deepfake is combined with insider knowledge, because familiarity can make an obviously synthetic interaction feel operationally plausible.

Related resources from NHI Mgmt Group

• When does static testing create a false sense of security?
• Why do passwords still create so much identity risk in modern environments?
• Why do non-human identities create more risk than many human accounts?
• Why do AI agents create new risk in non-human identity management?