Deepfake-resistant remote onboarding
A liveness result alone does not make onboarding deepfake-resistant. Defensible remote proofing layers evidence validation, applicant-to-evidence verification, injection and replay controls, device/session protections, operational review and monitoring.
ENISA documents photo, video replay, mask and deepfake attacks against remote proofing. Current guidance increasingly distinguishes presentation attacks at the sensor from digitally injected or modified media.
For: fraud, security, identity-product and procurement teams. This is independent information, not legal, compliance or security advice.
Threats to model
- Presentation: a photo, screen, replay or mask is shown to the camera.
- Injection: manipulated media bypasses the intended capture path.
- Evidence fraud: forged, altered, stolen or fraudulently obtained documents.
- Synthetic identity: real and invented attributes are combined.
- Process bypass: weak recovery, manual review or duplicate enrolment defeats strong capture.
Layered controls
- Validate documentary or digital evidence and authoritative attributes.
- Confirm ownership through face comparison, chip interaction, account control or attended review appropriate to risk.
- Protect capture with PAD, injection detection, signed SDK signals and replay/session binding.
- Apply device, velocity, duplicate and behavioural controls.
- Escalate anomalies to trained review with auditable reasons.
- Monitor post-onboarding behaviour and recovery events.
Evidence to request
- Attack classes included in testing and those excluded.
- Product, SDK, platform and configuration covered.
- False-accept and false-reject results at deployed thresholds.
- Testing recency and independence.
- Controls for rooted/emulated devices, virtual cameras and API submission.
- Incident response when an attack bypass is discovered.
Do not create an exclusion trap
Stronger controls can increase failure for legitimate users with older devices, disabilities, poor connectivity or unsupported documents. Provide accessible alternatives and measure rejection by meaningful user segments without collecting unnecessary data.
Evidence and limits
MyID separates enacted rules, official implementation material, testing and vendor claims. A source can establish what its publisher says; it does not prove that every product, deployment or interpretation works as claimed. Where Irish implementation remains unsettled, this page says so.
Sources checked 22 August 2026. Re-check the linked primary material before making a consequential decision.
Next useful pages
Follow the Irish evidence
Get the business briefing when Irish wallet, verification and age-assurance evidence changes.
Join the business briefing