TL;DR: DHS’s Remote Identity Validation Rally tested commercial identity verification systems against deepfake, document fraud, and injection attacks, and Incode was one of only two vendors to meet multiple performance goals across those categories, according to Incode. The result reinforces that IDV governance now has to treat presentation attacks and stream injection as core control issues, not edge cases.
NHIMG editorial — based on content published by Incode: Incode invests in privacy-first architecture and acquires Identiq, including its discussion of the DHS Remote Identity Validation Rally
Questions worth separating out
Q: What fails when identity verification trusts the video stream too early?
A: When the capture layer is trusted before integrity checks, attackers can inject synthetic or replayed frames that look legitimate to the verification engine.
Q: Why do deepfake and document fraud controls need to be assessed together?
A: Attackers rarely rely on one broken control.
Q: How do security teams know if an IDV system is actually resilient?
A: Look for independent testing against realistic attack conditions, not just lab accuracy claims.
Practitioner guidance
- Stress-test the full proofing journey Validate face, document, and stream controls together in one workflow so attackers cannot combine a weak liveness check with a forged document or injected frame stream.
- Add capture-layer integrity checks Require device attestation, tamper-evident telemetry, and secure transport paths before accepting any verification outcome from live or recorded media.
- Map verification outcomes to downstream access decisions Tie IDV confidence levels to onboarding, step-up authentication, account recovery, and privilege grant rules so weak proofing cannot silently create trusted identities.
What's in the full analysis
Incode's full analysis covers the operational detail this post intentionally leaves for the source:
- The DHS evaluation framing and how RIVR was structured across liveness, document fraud, and injection testing.
- The vendor's explanation of which attack conditions differentiated stronger IDV performance from weaker approaches.
- The context behind why government-led testing matters for regulated deployment decisions.
- The article's view of how organisations should interpret third-party validation in their own risk programmes.
👉 Read Incode's analysis of the DHS Remote Identity Validation Rally →
Remote identity validation under attack: what do IDV teams do now?
Explore further
Identity verification is now an access-control dependency, not a front-door formality. When verification is used to decide onboarding, step-up checks, account recovery, or workforce access, weak assurance becomes an IAM problem as much as a fraud problem. The DHS rally shows that the real question is whether an IDV workflow can stand up to synthetic input under operational pressure. For practitioners, identity proofing must be governed as a control that influences trust decisions across the lifecycle.
A few things that frame the scale:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
A question worth separating out:
Q: Who should own accountability when IDV failures create access risk?
A: Accountability should sit with the team that decides how verification results affect trust, not only with the vendor or the fraud unit. If a weak proofing outcome can lead to onboarding, privilege, or account recovery, IAM, fraud, and compliance all share governance responsibility. Policy should define who accepts residual risk and who reviews exceptions.
👉 Read our full editorial: DHS identity validation rally raises the bar for fraud resistance