What should organisations use instead of liveness tests when they need to confirm an employee remotely?

Why liveness tests are the wrong tool for remote employee confirmation

Liveness testing is designed to resist presentation attacks in biometric or identity proofing workflows, but it is a poor substitute for confirming a known employee during a remote support interaction. The real problem is not whether a face is live on camera, but whether the person on the call can be tied back to authoritative employee records, current device context, and an interaction path the organisation can trust. That distinction matters because a convincing live video can still be a fraud attempt, while a legitimate employee may fail a strict liveness flow for entirely non-security reasons. For a broader treatment of machine identity risk where trust and verification become operationally central, NHI Management Group recommends the OWASP Non-Human Identity Top 10 as a complementary lens, though it is not the primary frame for this question. In practice, many security teams discover the weakness in liveness-based confirmation only after a helpdesk process has already been used as the easiest way to bypass stronger identity checks.

What layered remote verification should combine

The better approach is to treat remote confirmation as an evidence problem, not a single-signal test. One strong signal rarely answers the question on its own, especially when the requester already knows basic personal details or can spoof one channel. Organisations should combine authoritative identity evidence, contextual device evidence, and, where risk is higher, a separate interaction path that proves the employee can control an already trusted channel.

In practice, that means matching the request against data the organisation already trusts, such as HR or identity records, then checking whether the request comes from a device, network, or location that is plausible for the employee. If the request involves account recovery, reset, payment, or privilege changes, the workflow should require a second channel that is independent of the helpdesk conversation. Carrier-held attributes and SIM swap checks can help when mobile identity is part of the assurance model, but they should support the decision rather than replace it. A remote verifier should be asking whether the evidence set is consistent, not whether a webcam image looks authentic.

• Use authoritative records to validate name, role, employment status, and other known data points.
• Check whether the device and session context match the employee’s normal pattern.
• Use an out-of-band challenge for high-risk actions so the interaction is not self-contained.
• Escalate when the presented evidence is incomplete, stale, or easy to obtain from public or internal sources.

This guidance breaks down when the organisation lacks reliable source records, when remote workers routinely change devices and networks, or when the support process is so urgent that operators start accepting partial evidence.

Where remote confirmation breaks down and what to do when risk rises

Tighter remote verification increases friction, so organisations have to balance speed against assurance. That tradeoff is especially visible in service desk resets, payroll changes, travel-related access issues, and executive support, where staff often push for whatever path is fastest. The common failure is to treat one high-friction check as proof of identity, then allow the rest of the workflow to become permissive. Guidance on SIM swap or device evidence should be applied carefully here because those signals can support confidence without proving personhood.

There is also a genuine consensus gap in the industry: some teams still overvalue biometric-style assurance for remote support, while others overcorrect and rely only on static knowledge questions or chat-based confirmation. Neither approach is robust on its own. The stronger pattern is layered assurance with clear escalation thresholds, especially when the requested action changes privileges, contact details, or recovery pathways. Organisations should be most cautious where the request would let an attacker capture the employee’s future access rather than merely complete a one-off transaction.

When the evidence is ambiguous, the right response is not to force a binary pass or fail from a weak signal. It is to slow the process, add another trust path, or route the case to a higher-assurance workflow.

Risk and Threat Considerations

Remote employee confirmation is attractive to attackers because helpdesk and support workflows often sit between public identity data and privileged account changes. If the organisation treats liveness as a substitute for evidence-based verification, it can create a path for social engineering, account takeover, or fraudulent recovery actions.

Failure mechanism: the attacker combines stolen personal data, caller impersonation, or compromised phone access with a support process that lacks independent verification. Weak workflows can be abused when the operator trusts a live interaction more than authoritative records or a second channel.

Impact: the organisation may reset credentials, update recovery factors, or grant access to the wrong person, which can expose email, payroll, HR data, and downstream systems that rely on the employee account.

Practitioner Guidance

What to prioritise: build the workflow around evidence quality, not around whether the person can perform live on camera. The key decision is whether the support action can be justified from trusted records and a separate proof path, especially when the request changes recovery settings or privilege.

Decision rule: if the request can lead to account recovery, contact-detail changes, or access restoration, require an independent second channel and treat the interaction as higher risk until the evidence set is complete. If the request is low impact and the employee’s context is already well established, a lighter check may be acceptable.

What good looks like: operators can explain why they trusted the request, what evidence was checked, and what escalation path was used when the evidence was incomplete. The most reliable programmes also retain a clear audit trail showing which signals were accepted and which were insufficient.

Practitioner takeaway: remote confirmation should be designed as a controlled trust decision, not a one-off human judgment about appearance or liveliness.

Related resources from NHI Mgmt Group

• When should organisations use webhooks instead of direct provisioning for access requests?
• Should organisations use SSH certificates instead of long-lived keys?
• When should organisations use self-signed TLS client authentication instead of CA-signed mTLS?
• When should organisations block an AI agent instead of letting teams use it?