TL;DR: A KYC provider extended biometric authentication protection from mobile to web to counter crafted video injection, virtual camera bypass, DOM tampering, and reverse engineering, according to Jscrambler. The case shows that passwordless flows still depend on client-side integrity and anti-fraud controls, not just stronger verification logic.
At a glance
What this is: This is a web biometric authentication case study showing that extending passwordless verification to browsers also expands the fraud surface into client-side integrity risks.
Why it matters: It matters because identity verification teams cannot treat biometrics as a server-side trust decision alone; browser tampering, replay, and virtual camera abuse can undermine the control before identity proofing completes.
Context
Biometric authentication on the web is not just a verification problem. It is a client-side trust problem, because the browser and SDK can be manipulated before the biometric signal reaches the assurance layer.
For IAM and identity verification teams, the governance gap is clear: passwordless and biometric flows still need runtime integrity controls, anti-tampering protections, and fraud telemetry at the point of collection. When the same assurance model moves from mobile to web, the attack surface changes materially.
The article is about a London-based identity verification provider extending protections from mobile to web, which is a typical pattern for organisations that already understand biometric fraud on one channel and are now closing the gap on another.
Key questions
Q: What fails when web biometric authentication does not protect the browser runtime?
A: The assurance model fails because the biometric signal can be altered before verification completes. If DOM tampering, script patching, or injected media can change what the SDK sees, the backend is no longer evaluating a trustworthy live event. Identity teams should assume that browser integrity is part of the authentication control, not separate from it.
Q: Why do replay attacks create risk even when a biometric system can block fake photos or masks?
A: Replay attacks work because the system may still accept a real biometric captured earlier and injected later. If malware, a virtual camera, or browser pipeline hijacking can feed recorded imagery into the session, the biometric looks genuine. That means the core failure is not the face itself, but whether the claim was captured live and untouched.
Q: What do teams get wrong when they extend mobile biometric controls to the web?
A: They often assume the same assurance model will work without re-testing the browser execution path. Web environments add script manipulation, DOM tampering, and media injection risks that mobile SDK hardening may not cover. The result is a control that appears consistent but is not equally trustworthy across channels.
Q: Should organisations treat code integrity as part of identity assurance for passwordless login?
A: Yes, when the authentication decision depends on browser-side code to capture and validate the biometric signal. Code integrity protects the trustworthiness of the flow itself, which is essential when passwordless login is exposed to runtime manipulation. Without that layer, the identity decision can be based on altered evidence.
Technical breakdown
Why browser biometrics are vulnerable to client-side tampering
Web biometric authentication depends on trust in the browser session, JavaScript execution, and the SDK collecting the signal. If an attacker can alter DOM content, patch functions at runtime, or inject synthetic video before verification completes, the liveness result can still look legitimate to the server. That is why web biometrics are not only an identity proofing issue but also a client integrity issue. The control boundary sits partly in the browser, partly in the SDK, and partly in the risk engine that evaluates the session. When that boundary is weak, the attacker does not need to defeat the biometric itself, only the path that carries it.
Practical implication: protect the browser runtime, not only the biometric policy.
How replay and virtual camera abuse break liveness checks
Replay attacks reuse previously captured biometric video or imaging artefacts, while virtual camera bypass feeds fabricated media into the authentication flow. Both attacks exploit the assumption that the camera input is live and device-originated. Once the SDK accepts a synthetic stream, liveness verification can be satisfied by something the user never actually produced in real time. This is why mobile protections do not automatically transfer to web. The browser channel introduces different tooling, different hooks, and different opportunities for emulation. Effective defense therefore requires detection of manipulated input paths, not just stronger challenge prompts or more biometric policy logic.
Practical implication: detect media source abuse at the capture layer.
What code integrity adds to biometric and fraud controls
Code integrity helps ensure the JavaScript running in the browser has not been altered to weaken authentication or suppress security checks. In practice, that means monitoring for runtime modification, anti-debugging evasion, monkey patching, and DOM tampering that could change how the authentication flow behaves. This does not replace biometric assurance or fraud scoring; it protects the control plane that delivers them. For identity programmes, the important lesson is that credentialless or passwordless design still depends on trustworthy execution. If the runtime is compromised, the assurance decision is built on manipulated evidence.
Practical implication: treat runtime integrity as a prerequisite for reliable web authentication.
Threat narrative
Attacker objective: The attacker wants to defeat web biometric verification without possessing the real user’s live biometric signal.
- Entry occurs through the web authentication channel, where the attacker targets the browser-based biometric flow rather than the identity backend.
- Credential or signal abuse follows when crafted video injection or a virtual camera bypass feeds manipulated media into the liveness check.
- Impact is unauthorized account access or weakened assurance, because the system accepts a fraudulent biometric event as genuine.
Breaches seen in the wild
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
- SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Web biometrics create a client-side fraud control problem, not just an identity assurance problem. The browser becomes part of the trust boundary, which means DOM tampering, runtime patching, and input injection can all subvert the control before the backend sees a result. For identity programmes, that shifts the governance question from only "is the biometric strong?" to "is the path delivering the biometric trustworthy?" Practitioners should treat browser integrity as part of the biometric assurance model.
Passwordless does not mean control-free. Biometric verification removes passwords from the user experience, but it does not remove the need for anti-fraud controls, runtime monitoring, and signal validation. In fact, the absence of passwords can make teams overconfident about assurance unless the client environment is also protected. The named concept here is browser trust gap: the space between a strong identity check and an untrusted execution environment that can still falsify the evidence. Practitioners should close that gap with layered browser and SDK controls.
Cross-channel identity protection has to be designed, not assumed. Mobile SDK hardening does not automatically transfer to web, because the attack surfaces and bypass techniques differ. That means governance models for biometric identity need channel-specific control testing, not one unified assumption that the same policy works everywhere. For identity verification teams, this validates a channel-by-channel assurance view rather than a one-size-fits-all rollout.
Client-side fraud controls are becoming a core part of identity verification governance. As verification expands into web and browser-native journeys, fraud and IAM teams need to converge around runtime integrity, liveness protection, and telemetry from the authentication edge. That is where the practical control decisions now sit: in the execution environment, not only in the policy engine. Practitioners should align biometric governance with client-side anti-tampering requirements.
The article reinforces that privacy-preserving biometrics still need technical hardening. Storing no biometric data reduces one category of risk, but it does not protect against manipulation of the collection and verification flow itself. This is where identity assurance, fraud prevention, and application security intersect in a way many programmes still under-model. Practitioners should include client integrity in their biometric risk assessment.
From our research library:
- Gartner predicts that by 2026, 30% of enterprises will consider identity verification solutions unreliable in isolation because of AI-driven attacks.
What this signals
Browser trust gap: as biometric authentication moves from mobile to web, the security boundary shifts into the client runtime, where tampering and replay can distort the trust decision before it reaches identity systems.
Identity verification teams should stop thinking about biometrics as a single assurance control and start treating them as a chain of dependent controls across capture, execution, and fraud telemetry. That is where the failure modes now cluster.
For practitioners, the operational question is not whether biometrics are strong enough in theory, but whether the browser and SDK are trustworthy enough in practice to support them.
For practitioners
- Harden the browser execution path Use runtime integrity controls to detect DOM tampering, monkey patching, and script modification in web biometric flows.
- Test for replay and virtual camera bypass Run adversarial tests against biometric capture and liveness verification using crafted video, emulated devices, and synthetic media sources.
- Separate mobile and web assurance tests Validate biometric protections independently for each channel, because controls that work in mobile SDKs can fail in browser-based journeys.
- Align fraud telemetry with identity assurance Feed client-side anomalies, capture irregularities, and tamper signals into the same decision process that approves biometric login.
Key takeaways
- Web biometric authentication can be undermined by client-side manipulation even when the verification logic itself is sound.
- Replay attacks, virtual camera bypass, and DOM tampering show that assurance now depends on the browser runtime as much as on the biometric signal.
- Identity and fraud teams need separate assurance testing for mobile and web channels, with runtime integrity built into the authentication design.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V12 — Secure Communication | Web biometric flows depend on protecting the client-server trust path from tampering and interception. |
| V15 — Secure Coding and Architecture | Runtime tampering and DOM manipulation are application-layer integrity problems in the browser. | |
| Recommendation — Apply V12 controls to protect the authentication channel and verify integrity of biometric submission paths. Design the web authentication flow to resist script modification and client-side abuse. | ||
| NIST SP 800-63 | SP 800-63B — Authentication | Biometric authentication and passwordless flows fall under authentication assurance requirements. |
| Recommendation — Map biometric login assurance to SP 800-63B and validate the strength of the overall authenticator lifecycle. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centres on protecting the authentication mechanism and its supporting controls. |
| Recommendation — Use IA-5 to govern authenticator handling, validation, and protection across web login flows. | ||
| GDPR | Art.32 — Security of processing | The article explicitly notes privacy-preserving biometrics and no storage of biometric data. |
| Recommendation — Assess biometric collection and verification under Art.32 and secure the processing path against tampering. | ||
Key terms
- Web Biometric Authentication: A browser-based identity verification flow that uses biometric checks instead of passwords. The security question is not only whether the biometric is strong, but whether the client-side environment delivering the signal can be trusted end to end.
- Liveness Assurance: Liveness assurance is a biometric control that checks whether a presented face comes from a real, live person rather than a photograph, video, or other replayed image. It is used to reduce spoofing risk during online authentication and to help confirm that the user is physically present at the point of verification.
- Client-Side Integrity: Client-side integrity is the assurance that browser or app code has not been altered in ways that change security behaviour. In identity verification, it protects the trustworthiness of the capture, validation, and submission path before the server makes an authentication decision.
- Replay Attack: An attack where a previously valid signed message is captured and sent again later to trigger the same trusted action. Timestamping, nonces, and context binding are the main controls that reduce replay risk in HMAC-based systems.
Deepen your knowledge
NHI Mgmt Group's NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to the broader security programme.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org