How Do You Verify a Remote Hire's Identity When You've Never Met Them in Person?

September 6, 2026 ·Mairi Kutberg ·

workforce-identityremote-hiringcross-border-onboardingremote-onboardingemployment-verificationidentity-verificationkycadeseidaschip-anchored-identityglobal-digital-identity

You verify the passport chip — remotely, in ninety seconds, with cryptographic evidence signed by the state that issued the document. The engineering answer for a remote-hire identity check without an in-person meeting is chip-anchored NFC read plus biometric face-match against the chip photo, wrapped in an AdES record retained under a Long-Term Validity envelope. This post walks the pattern for full-time employment remote hires (distinct from gig workers and contractor-of-record engagements), the four questions the pattern actually answers, and where the picture is genuinely harder than the identity layer alone.

How Do You Verify a Remote Hire's Identity When You've Never Met Them in Person?

This is the fourth post in our workforce identity cluster, alongside the earlier procurement-side rubric on who offers trusted workforce identity services for distributed teams, the engineering-side walk-through of contractor-of-record identity integration pipelines, and the reusable-identity pattern for gig workers across many task activations. This post covers the fourth worker class in the workforce map — the full-time employment remote hire, typically on a direct employment contract with the hiring company (or a wholly-owned foreign subsidiary), where the identity-verification question sits alongside a set of harder cross-border employment questions the identity layer alone does not answer.

A Warsaw-headquartered engineering director asked us at a recent conversation how they should verify a Brazilian software engineer they were about to hire onto their Poland-based employment entity: they had never met the candidate in person, they were not going to fly them in for a two-day onboarding trip, and the compliance team had (reasonably) asked for a documented identity verification event before granting the new hire access to the production codebase and internal systems. The engineering director's default option was to book a video call with the compliance officer present and have the candidate hold up their passport to the camera — which the compliance officer had already pushed back on as not meeting the evidence bar. This post is how I would answer that question if I were writing the compliance memo for that hire.

What does "verifying a remote hire's identity" actually mean, and what does it exclude?

It means producing a cryptographically-anchored evidence artefact that the person applying for the job, signing the employment contract, and receiving payroll payments is the same real person whose passport chip was read at the identity-verification event. That is the identity layer. It is a bounded scope, and the boundary matters.

What it explicitly does not cover: whether the person has the right to work in the hiring jurisdiction (that is a work-authorisation check against national immigration databases, typically involving employer sponsorship, visa status, or bilateral labour agreements), whether the tax classification is correct (that is a payroll and tax question specific to each jurisdiction), whether the employment relationship itself is legally valid under the hiring jurisdiction (that is an employment-law question), and whether the payroll infrastructure can actually pay the person in their local currency in their local jurisdiction (that is an operational payroll question typically solved by an employer-of-record partner, a wholly-owned subsidiary, or a payroll provider with local presence). The identity layer is one of four load-bearing layers, and treating it as if it solved all four is the most common architectural mistake I see in remote-hire projects.

The other three layers — work-authorisation, tax classification, employment-relationship validity — are real problems that need real answers. The identity layer feeds into all three (a valid identity is a precondition for the other layers), but it does not close them. In our work with distributed engineering teams across the EU + third countries, the pattern that survives contact with legal review is: identity layer solved by chip-anchored proofing (fast, remote, cryptographically strong), and the other three layers handed off to a partner infrastructure (employer-of-record, local subsidiary, payroll provider) whose expertise those questions actually require.

Which four questions does chip-anchored remote identity verification actually answer?

Four specific questions, all answered by the same ninety-second flow.

Question one: Is this person real? The passport chip contains cryptographically-signed data (name, date of birth, nationality, photograph) that was signed by the issuing state's document-signing certificate. Reading the chip and verifying its signature against the ICAO Public Key Directory answers "is this a real passport issued to a real person by a real state" without needing to trust any commercial party in the middle. The state signed it; the state's public key is published; the verification is independent.

Question two: Is the person holding the passport the same person the passport was issued to? A biometric face-match between the chip's stored photograph and a live selfie captured during the verification flow answers this. Modern liveness-detection algorithms (FaceTec, NIST IBPC-tested vendors) defeat the deepfake and injection attack surface that pure document-scan-plus-selfie flows struggle against. The two-track combination — chip signature verification plus biometric face-match — meets NIST SP 800-63-4 Identity Assurance Level 2 evidence requirements globally.

Question three: Is the passport still valid, and has it been reported lost or stolen? The chip contains an expiry date that the verification flow reads directly. Cross-checking against the Interpol Stolen and Lost Travel Documents (SLTD) database answers the lost/stolen question for jurisdictions where that database is accessible to the verifying party. The combination gives a "yes, this document is currently valid and not on any known revocation list" answer at verification time.

Question four: Does the verification event itself have long-term evidential value? The identity verification produces an Advanced Electronic Signature under eIDAS Article 26 as its evidence artefact — retained under a Long-Term Validity envelope (PAdES-LTA, XAdES-A, or CAdES-LTA depending on the record format) so that three years later, when the hire's employment is being audited or the payroll is being reviewed, the evidence of the original identity verification is still independently verifiable. This is the difference between "we verified them" (an assertion) and "here is the cryptographic evidence of the verification" (an artefact).

Getting all four in a single ninety-second flow is what makes remote hiring actually work at scale, without either flying every candidate in or accepting a document-scan-plus-selfie evidence tier that will not survive a serious compliance review.

Why does chip-anchored verification work remotely without a supervised human reviewer?

Because the trust anchor is the issuing state's digital signature on the passport chip, not the verifier's ability to see the document with human eyes.

A traditional in-person identity check has the trust anchor in the checker's judgement — the human at the counter looks at the document, checks the security features (hologram, microprinting, UV features), compares the photo to the person, and forms an opinion. This works, but it does not scale, it does not travel across time zones, and the trust anchor is unreliable across checkers of different training and different attention levels on different days.

A chip-anchored remote check has the trust anchor in the state's cryptographic signature on the chip data. The verifying software reads the chip, verifies the signature against the ICAO trust list, confirms that the chip has not been cloned (via ICAO Chip Authentication mechanisms), and binds the read to physical presence (via PACE — Password Authenticated Connection Establishment). No human judgement is involved in the crypto layer. The biometric face-match then does what the in-person checker did with the photo — with the important difference that the algorithm is testing against a known-good reference (the chip's signed photograph) rather than a printed image that could itself be forged.

For jurisdictions whose passports are pre-NFC or where the candidate presents a non-ICAO national ID document, the fallback pattern is document authenticity verification (security-feature checks, MRZ consistency, anti-tamper signals) combined with biometric face-match against the document photo. Both paths — chip-anchored and document-plus-liveness — produce an evidence record at NIST SP 800-63-4 IAL2 equivalent. The chip-anchored path covers the 179 ICAO 9303 countries; the document-plus-face-match path covers every remaining country. Combined, the two paths cover any candidate the hiring team could realistically be considering.

Where does the picture get harder than identity alone?

Three places, all worth naming honestly so the hiring team knows to budget for them separately.

Work-authorisation and immigration status is a jurisdiction-specific check that identity does not answer. A verified Brazilian identity does not tell the Poland-based hiring company whether the Brazilian engineer has the right to work for a Polish employer while resident in Brazil. That answer depends on national immigration law, bilateral labour agreements, whether the employment is being performed on Polish soil or on Brazilian soil (which changes the applicable regime), whether a work visa or residence permit is required, and whether the employer needs to sponsor. Identity verification is a precondition for the work-authorisation check (you can't authorise an unverified person), but it does not perform the check itself. In practice, this is typically handled by immigration counsel, an employer-of-record partner with local presence, or an internal legal function with jurisdiction-specific expertise.

Tax classification and payroll infrastructure is a separate architectural investment. Hiring a Brazilian engineer as a full-time employee of the Polish entity raises questions about where the tax liability sits, whether the Polish entity needs to register with Brazilian tax authorities, whether social contributions are due in one or both jurisdictions, and whether the payroll provider can actually pay the person in BRL to a Brazilian bank account. Employer-of-record providers (Deel, Remote.com, Rippling and comparable) exist to solve this specific layer — they employ the person on the hiring company's behalf in the correct jurisdiction, handle local tax and payroll, and abstract the complexity from the hiring company. The identity verification IdentiGate produces feeds into the EOR's onboarding flow (the EOR needs to know the identity is verified before it can execute the local employment contract), but the EOR relationship is a separate procurement decision. The contractor-of-record post in this cluster walks the identity-side integration pattern with EOR/CoR platforms in engineering detail.

Employment-law validity of the relationship is a jurisdictional question that changes over time. Whether the person you are hiring can legally be your employee under the applicable employment law depends on the hiring jurisdiction, the worker's residence jurisdiction, the nature of the work, and increasingly on evolving regulatory frameworks. The EU Platform Work Directive (Directive (EU) 2024/2831) with Member State transposition due by 2 December 2026 is one example of how the classification landscape is moving. The identity-verification architecture should be classification-neutral — same evidence quality regardless of whether the person ends up being classified as an employee or a contractor — because the classification answer can change on regulatory grounds without changing the underlying person.

Where does IdentiGate fit — the honest scope

The identity-verification product produces the ninety-second chip-anchored + biometric face-match evidence record described above, at NIST IAL2 evidence quality, across the full 179 ICAO 9303 country footprint plus document + face-match for the rest. The signatures product produces the AdES record under eIDAS Article 26 that binds the verified identity to the onboarding attestation, and the evidence layer wraps it in a Long-Term Validity envelope that survives well past the hire's tenure. This is the identity layer of the four — the one we own end-to-end.

The other three layers — work-authorisation, tax and payroll classification, employment-law relationship validity — we do not ship. Distributed hiring teams that engage us in 2026 typically pair the IdentiGate identity primitive with an employer-of-record partner (for tax and payroll infrastructure) and an immigration counsel or in-house legal function (for work-authorisation and employment-relationship validity). The pattern that works cleanly is: IdentiGate for identity + AdES evidence; EOR partner for legal-entity abstraction + payroll; internal or external counsel for immigration and employment-law questions. Splitting the responsibilities at the boundary where each vendor's expertise actually lives gives the hiring team a stronger overall posture than trying to source everything from a single vendor whose depth in any one layer is diluted.

The push-back on "verify by video call"

Where I would push back on the video-call-with-passport pattern that most compliance teams default to for remote hires is on the assumption that a video call meets the evidence bar. It does not, for three separate reasons.

First, the video-call frame is subject to the same deepfake attack surface as any other video-based identity check — an attacker can inject a manipulated video feed that shows a plausible-looking document held up to a plausible-looking person, and the compliance officer on the other end of the call has no way to know. The chip-anchored verification is not vulnerable to this because the chip signature verification happens against a physical chip the attacker cannot forge without state-level document-issuance capability.

Second, the evidence artefact of a video call is a compliance officer's memo saying "I verified the candidate on [date] via video call and the passport matched their appearance". This is not an evidence artefact in the cryptographic sense — it is a claim by the compliance officer. Three years later, when the audit asks for proof of the original verification, the memo is not the same class of evidence as a signed AdES record with a chip cryptogram.

Third, the operational cost of video calls at scale is real. A compliance team running twenty remote hires per month across five jurisdictions ends up with a full-time-equivalent's worth of video-call time booked just for identity verification. The chip-anchored remote flow completes in ninety seconds, unattended, with the compliance team only reviewing the produced evidence record rather than staffing the verification itself.

The video-call pattern was a reasonable default in 2020 when remote hiring was new and the chip-anchored infrastructure was not yet production-ready across enough countries. That has changed. In 2026, the chip-anchored path is the default for teams whose remote-hire cadence is above a small handful per year and whose compliance posture will be reviewed by anyone who understands what evidence quality actually means.

Sources

Primary — identity assurance and document standards

Primary — eIDAS and evidence framework

Primary — platform work and cross-border employment

Directive (EU) 2024/2831 — Platform Work Directive

About the author

Mairi Kutberg is a co-founder of IdentiGate OÜ, a European identity-verification and digital-signature company building on top of chip-anchored identity proofing (ICAO 9303 passport NFC), Advanced Electronic Signatures under eIDAS Article 26, and Advanced Electronic Seals. She works with distributed engineering teams, cross-border hiring functions, and remote-employment operators on the boundary between the identity-verification layer and the wider cross-border employment infrastructure that identity feeds into.

The words we use in digital identity are load-bearing. Use the wrong one and the listener walks confidently down the wrong road — and in identity, security, and compliance, most of our everyday words send people the wrong way. This is the eleven-point vocabulary repair kit for anyone building identity infrastructure: data vs information, trust vs proof, authentication vs identity, permission vs authority, compliance vs evidence, disclosure vs predicate. If our language keeps reaching for words that can't be measured, are we building resilience — or performing security?

Multi-party document signing takes one of two shapes — sequential (party A signs, then B, then C, each signature depending on the previous one) or parallel (all parties sign the same document independently, with an aggregator collecting and combining the signatures). Both are supported cleanly by the eIDAS AdES formats (PAdES, XAdES, CAdES) but the cryptographic semantics, the timestamp coordination, and the LTV envelope requirements differ meaningfully between them. This post walks the two patterns, when to use each, and what tends to break when the pattern is chosen wrong for the workflow.

You do not — you verify once, chip-anchored, and reuse the record across every subsequent task engagement with a lightweight activation step (biometric touch, PIN, or device unlock) that binds each task to the same verified person. The engineering pattern is reusable identity anchored at first-verify and retained under an AdES evidence envelope that survives well beyond any single task lifetime. This post walks the pattern, the three architectural properties that make it survive a compliance review, and where the picture is genuinely harder than the marketing suggests.