Presentation attacks try to fool the system directly with an image, mask, screen replay, or video shown to the camera. Injection attacks bypass the camera path altogether by replacing the live feed with synthetic or prerecorded media. Both aim to impersonate a real person, but the technical control point and detection approach are different.
How presentation attacks differ from injection attacks
Presentation attacks are physical spoofing attempts at the capture point, so the defender is trying to tell whether the person, face, or voice presented to the sensor is genuine. Injection attacks are a pipeline compromise, so the defender is trying to prove that the media reaching the decision engine actually came through the intended live camera or microphone path. That difference changes both the control point and the evidence you need.
In practice, presentation attacks and injection attacks can produce similar outputs, such as a fake face match or a fraudulent voice verification, but they fail different trust assumptions. A presentation attack abuses the sensor’s view of the world. An injection attack abuses the transport or software path that carries that view into the system. That means a solution aimed only at liveness may miss a virtual camera, while a solution aimed only at device integrity may miss a high quality printed or replayed presentation.
The distinction matters because the same fraud workflow can combine both. For example, an attacker may use a replayed selfie for one checkpoint and then inject a prerecorded video stream into another, especially when remote onboarding depends on browser media permissions or a third-party capture SDK. The right response is not to treat every deepfake as the same problem, but to identify where the control boundary failed: sensor, browser, app, device, or backend verification.
Why the control strategy changes with the attack path
Presentation attacks are usually addressed with presentation attack detection, liveness checks, challenge-response prompts, and quality controls that look for reflections, motion inconsistencies, audio artifacts, or display replays. Those controls are designed to test whether the observed signal is a live human interaction. Injection attacks require a different defensive lens because the live signal may never reach the verifier at all. You then need checks for virtual cameras, rooted or compromised devices, API tampering, media pipeline integrity, and browser or app instrumentation.
The practical takeaway is that a strong anti-deepfake workflow needs layered assurance, not a single proof. A biometric or video check can be useful, but it should be paired with device and session validation, step-up verification for high-risk actions, and an explicit trust decision about the capture channel. The more valuable the action being approved, the less acceptable it is to rely on the media stream alone.
For readers building identity verification flows, the strongest reference point is Biometric Authentication and Verification Guide, which separates liveness and presentation attack detection from camera injection and virtual camera abuse. For onboarding and account-opening controls, Identity Proofing and KYC Guide is the better fit because it connects deepfake and injection risks to assurance levels and synthetic identity fraud.
What defenders should look for in deepfake fraud investigations
When investigators see a failure, they should ask whether the weak point was the physical presentation, the capture pipeline, or the downstream approval process. A presentation attack often leaves clues at the image or audio level, such as screen glare, compression patterns, mismatch between lip motion and voice, or poor challenge-response behavior. An injection attack more often leaves software and device clues, such as inconsistent device fingerprints, impossible media timestamps, browser extension interference, virtual camera traces, or gaps between what the user claims to have done and what telemetry records.
That distinction also changes escalation. If the fraud involved a presentation attack, the remediation focus is usually on stronger liveness and better human verification of higher-value events. If the fraud involved injection, the response should also include application hardening, endpoint review, and trust revocation for the affected device or session. In remote identity workflows, both can be present in the same case, so investigators should preserve capture logs, session metadata, and device evidence before they assume the fraud was only a face or voice problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Deepfake fraud in verification flows depends on proving the claimant's identity. |
| Recommendation — Harden authentication checks so replayed or injected media cannot satisfy approval. | ||
| NIST SP 800-63 | IAL2 — Identity Proofing Requirements | Deepfake fraud often targets remote identity proofing and onboarding assurance. |
| Recommendation — Require stronger identity-proofing evidence when presentation or injection risks are present. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Fraud cases often hinge on weakening the assurance around the session or authenticator lifecycle. |
| Recommendation — Protect authenticator and session handling so spoofed media cannot bypass verification. | ||
| OWASP ASVS | V6 — Authentication | The page compares two attack types that target authentication and verification controls. |
| Recommendation — Test authentication flows for replay, spoofing, and media-path abuse. | ||
Practitioner Guidance
What to prioritise: Treat the capture path as a security boundary. If the verifier cannot prove that it is receiving a live signal from the intended device and channel, liveness alone is not enough.
What to verify: Confirm whether the fraud evidence points to sensor spoofing or media injection. The difference should show up in telemetry, device posture, and how the media entered the workflow.
What good looks like: High-risk checks require layered controls, including presentation attack detection, device integrity checks, and step-up verification before a payment, reset, or onboarding approval is finalised.
Common mistake: Teams often overfit to the visible deepfake and underinvest in the transport path. That leaves virtual camera abuse, browser tampering, and app-level feed replacement open even when liveness scoring is strong.
Practitioner takeaway: The key decision is not whether the media looks fake, but whether the system can trust how that media arrived.
Related resources from NHI Mgmt Group
- What is the difference between deepfake impersonation and synthetic identity fraud in AI-enabled attacks?
- What is the difference between presentation attacks and digital injection attacks in biometric verification?
- What is the difference between prompt injection and traditional injection attacks?
- What is the difference between overlay attacks and activity injection on Android?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
