The Binding Problem in Remote Hiring
The hiring identity verification process was originally designed to answer two narrow questions: has this person committed a crime, and are they legally permitted to work here? The I-9 form reflects that purpose precisely. Its core function is establishing the income tax relationship between employer and worker. Criminal background checks became common later, and neither was designed with multi-system hiring pipelines in mind… because multi-system hiring pipelines did not exist yet. When hiring was conducted in physical offices, identity verification was largely a compliance step. Remote hiring for remote roles introduced a different kind of risk, and the problem expanded further once AI tools made impersonation easier.
What exists now is a hiring workflow that typically spans six or more independent systems: an ATS, a background check vendor, a skills assessment platform, a video interview tool, an HRIS, and an IdP. Each operates within its own trust scope, each satisfying its own specification. No system in that chain is responsible for what happens at the handoffs between them. That gap is not a configuration problem; it is architectural. Without a specific tool, it becomes a human problem, but not one that any Talent Acquisition team can realistically solve through manual checks.
Why this matters now
The rapid increase in impersonation fraud made the "is-this-candidate-who-they-claim-to-be" question consequential, and then the DPRK IT worker campaigns made this visible at scale. As covered in our breakdown of how these schemes operate, the person on the video call, the person doing the work, and the person receiving payment may be three different individuals. So while each step in the hiring pipeline passed independently, with each system completing its assigned check, no one confirmed that the same individual remained present throughout the entire process.
Isn't this what the frameworks were built for?
The frameworks most organizations reference when thinking about identity assurance (NIST SP 800-63, FATF guidance, FINTRAC) were designed for a different problem. NIST SP 800-63 separates identity proofing from authentication, and scopes assurance levels to individual relying parties operating within defined sessions or transactions. FATF and FINTRAC define identity, address verification, and monitoring obligations within regulated institutional contexts. These frameworks are coherent and well-constructed for what they were built to do: one institution verifying one subject, once.
Hiring pipelines involve multiple originating and relying parties in sequence: from ATS to Skills Assessment platform, through video interviewing to the background check platform, through onboarding and finally to the HRIS. No standard defines how assurance established by one carries forward to the next. The modularity that makes each system independently auditable is precisely what prevents the pipeline from producing a unified subject assertion.
Where the pipeline breaks
The practical consequence is this: each system handoff represents a trust boundary where prior assertions are accepted by convention, not by validation. A skills assessment has no mechanism to confirm the test-taker is the same subject which the background vendor evaluated. The HRIS provisions access on workflow completion, inheriting every prior assertion without re-validating any of them. The result is a compliant audit trail attached to an unconfirmed subject.
Companies naturally think of their Identity Platform as the system that contains their employees. That framing is accurate for post-hire access management. It also means candidates fall entirely outside the identity team's domain until after they are hired, leaving the rest of the organization vulnerable precisely when the impersonation risk is highest. In practice, the only binding assertion that connects a candidate across the full pipeline is typically their name. In each step in the hiring flow, someone claims to be a specific person, and the pipeline trusts that claim. In an in-person interview, establishing that claim demands a physical ID check at the front desk. But on a video call, it costs nothing. Your pipeline runs on raw trust.
"Amateurs hack systems, professionals hack people." - Bruce Schneier
The location solution
True location, when applied correctly, addresses this problem in a specific way. In most hiring stacks, location is captured as a plain form field rather than a standardized assurance claim with an associated trust level. A self-reported address is not the same category of claim as a verified location. And location has traditionally been a weak assurance signal, since a laptop farm can effectively show a device in any jurisdiction. Where location becomes meaningful is when it's fused with proof of physical presence: confirming that the candidate was physically present with the device converts a weak assertion into a much stronger one. That fusion only became practical last year, with the commercial availability of optical distance bounding technologies for ordinary smartphones.
The gap no framework closes
There is no widely adopted regulatory framework governing employment workflows that defines a cross-system subject-continuity requirement. That absence doesn't mean the requirement doesn't exist, but that organizations are currently responsible for meeting it without external guidance. Component-level compliance does not produce pipeline-level assurance. A pipeline of individually compliant tools does not produce a unified hiring assurance.
What to do about it
The immediate question for any organization running a hiring pipeline for remote workers is whether any system in that pipeline produces a cross-system subject-continuity assertion; the practical steps follow from that audit. Map every system and identify each trust boundary explicitly. Classify each control as identity-verifying, location-verifying, or skills-verifying. Identify which controls, if any, bind those claims to a single confirmed subject across the full sequence. And then ask each system vendor directly: does your output include a subject-binding assertion, or a point-in-time artifact evaluation? If no system produces a continuity assertion that persists across the pipeline, treat it as an architectural gap requiring a structural fix, not a vendor configuration issue. The hiring decision ultimately depends on whether the pipeline as a whole produces the subject-binding assertion that the decision rests on.
Sources
Want to see Polyguard in action?
Experience real-time identity verification for your communication security.
