Breaking Down Know-Your-Customer Deepfake Attacks

Where Hardening Fits in the Deepfake Attack Surface 

A face isn’t proof of a person anymore. That’s the uncomfortable truth banks are learning as AI-generated faces and documents start slipping past Know-Your-Customer (KYC) checks that were built for a world before generative AI. 

Cameras show up at a handful of specific moments in a banking app’s identity flow, not just once at signup. The most obvious is account opening: a new customer photographs a government ID and then takes a “selfie” or a short live video so the app can match the face on the document to the face in front of the lens and confirm a live person is present (liveness detection). Many banks also trigger a camera check as part of step-up authentication: a large wire transfer, a password reset, adding a new payee can prompt a re-verification. Some institutions use periodic re-verification checks every 1-2 years or whenever risk signals spike. In each case, the camera isn’t the only thing standing guard; it’s typically paired with device checks, one-time passcodes, or behavioral signals, which is why deepfake attacks are often paired with identity theft, malware, phishing, and other techniques to get past the layers of security controls in place. 

It is tempting to treat “deepfake fraud” as one problem with one fix. But it isn’t a single point of failure. A KYC verification travels through a multi-stage pipeline, starting from the physical scene in front of the lens, through the device, the app runtime, the on-device decision model, the network, the server-side decision, and finally the ongoing session. An attacker only needs one weak stage; a defender needs to secure all of them. 

No single security control covers that whole pipeline, and multiple security vendors or components built in-house are needed to cover the attack surface. This post walks the pipeline end to end, focuses on the three stages an application hardening and RASP product like Arxan Security genuinely mitigates (stages 2, 3, and 5), and gives an honest account of who covers the rest.  

KYC deepfake attack surface: seven pipeline stages, each with its own attack and control.

Stage 1 — The Physical / Presentation Layer: Is the Face Even Real? 

Before the device or the app is ever in play, the attack is on the lens itself: photos, screens, and masks. Presentation Attack Detection (PAD) engines, evaluated under ISO/IEC 30107-3, catch it using sensor analysis. That’s the identity vendor’s responsibility who use techniques like texture, depth, reflection analysis, and proprietary approaches to make sure what is shown to the camera is real. 

Stage 2 — The Device / Capture Layer: Is the Camera Even Real? 

This stage addresses the question most people never think about: whether the “camera” feeding the identity check is a camera at all. On a rooted or jailbroken device, or inside an emulator, an attacker can replace the camera component and inject a pre-rendered deepfake video directly into the camera API. The software receives frames that look perfectly captured but contain anything the threat actor wants. This is the injection attack, and it is a step to get AI deepfakes into the application. 

This is squarely RASP territory: root and jailbreak detection, emulator detection, and camera API hooking detection during the application runtime. MASVS-Resilience-1 requires the app to validate the integrity of the platform and covers this aspect of protection from deepfake camera attacks.  

Stage 3 — The Runtime Layer: Is the App Still the App? 

Suppose the device is genuine. The next question is whether the application code performing the verification has been tampered with. Threat actors hook or patch the identity software using instrumentation frameworks like Frida or Xposed. They can also repackage the app with the liveness check disabled, so that the verification function simply returns “pass” no matter what the camera sees. 

This is the standard anti-tamper use case, and it is Arxan Security’s wheelhouse where we are the original and the best: obfuscation to make the identity software hard to find, instrumentation and hooking detection to limit the hacking tools available, and integrity checks that detect patched binaries at runtime. MASVS-Resilience-2, 3, and 4 map directly onto these controls: anti-static-analysis, anti-dynamic-analysis, and anti-tampering. 

Stage 4 — The Client-Side Decision Layer: Did the On-Device Model Get Fooled? 

When a synthetic video is good enough to convince an untampered on-device model, only a better model helps. Passive liveness and on-device deepfake detection is the identity vendor’s capability — the same vendors as Stage 1, just a different discipline. 

Stage 5 — The Transport Layer: Did This Result Actually Come From the App? 

Even with a clean device and an untampered app, the verification result still has to travel to the backend. Threat actors target this stage with man-in-the-middle interception, replay attacks, and direct API abuse. Techniques such as capturing a legitimate “verified” response and replaying it, or skipping the app entirely and talking to the KYC API with forged results. 

The standard controls are well known: end-to-end encryption, client app attestation, certificate pinning, and a secure API design. Arxan Security has certificate pinning and whitebox cryptography that can be used for secure end-to-end encryption,  attestation, and protocols like Mutual TLS (mTLS). In typical MitM threat assessment, the MiTM focuses on intercepting communication exclusively. For client applications like banking apps, the threat actors control the hardware, software, and communication layers. The Arxan whitebox cryptography takes these a step further and protects the transport layer by protecting the key that exists in the application binary and memory. Layering whitebox cryptography with end-to-end encryption and attestation protocols prevents threat actors from breaking through the transport layer. More details on MitM controls are here: https://digital.ai/catalyst-blog/when-the-attacker-is-the-client-defending-against-mitm-attacks/  

Stage 6 — The Server-Side Decision Layer: Did the Backend Catch What the Device Missed? 

Like the client-side decision layer, some or all the model to process camera images can be handled on the server side. The client vs server architecture will vary by identity vendor, platform, and application software. Server-side re-verification, signal analysis, and the business’s own decisioning and orchestration logic catch what the client-side model missed.  

Stage 7 — The Behavioral / Session Layer: Does the Rest of the Session Still Look Like the Customer? 

Threat actors often have a pattern of their behavior that can vary from typical users. Continuous risk scoring, device fingerprinting, and behavioral biometrics live with fraud/risk platforms or an in-house risk engine, not with the identity vendor or the RASP layer. 

Why the Boundary Matters 

Secure software comes from defense in depth. This applies to layering different security features like obfuscation and integrity verification with secure application development and infrastructure behind it. Being clear about who owns which stage is how the defense actually holds. A best-in-class Presentation Attack Detection (PAD) and liveness vendor is wasted if the binary running its SDK can be patched to always return “pass.” Equally, a strong RASP layer cannot detect a well-crafted deepfake presented to an untampered app. 

The pipeline only holds together if each stage’s owner is genuinely covering their stage. In our experience, fraud usually avoids the strongest controls and instead walks through the gaps left in the security layers.  

The Takeaway 

Arxan Security’s application hardening and RASP capabilities mitigate three of the seven stages of the KYC deepfake attack surface, and they are the three stages an identity vendor cannot cover on its own. At the device/capture layer, root, jailbreak, emulator, and camera-API hooking detection stop an attacker from injecting a deepfake before a single frame ever reaches the identity SDK. At the runtime layer — our original wheelhouse, where we remain the benchmark — obfuscation, instrumentation, hooking detection, and binary integrity checks stop attackers from simply patching the liveness check to always return “pass.” At the transport layer, certificate pinning and whitebox cryptography make sure the “verified” result reaching the backend is the one the app actually produced, not a replayed or forged result. Each of these controls maps directly to MASVS–Resilience 1 through 4, giving customers an auditable standard behind the claim. Skip any one of them and a strong identity vendor’s result can be faked, tampered with, or intercepted before it ever reaches the backend. The identity vendor, the server-side decisioning stack, and the fraud/risk platform own the other four stages, while Arxan Security is what keeps their results trustworthy end to end.