The Remote-Applicant Authenticity Read: Advance, Verify, or Reject

Before you spend interview time on a remote applicant, you have one judgement to make: is this a real, legitimately located person, or a synthetic, stolen, or proxied identity? This guide is for in-house recruiters, sourcers, talent leaders, and founders doing their own hiring. It gives you a scoring pass over public signals on GitHub, LinkedIn, and the open web, weighted by how often each signal lies, so you return a defensible Advance, Verify, or Reject before the first live interview and do not reject thin-but-honest engineers alongside the fakes.

Published guidance splits into two unhelpful piles. One is a vendor pitch for an identity-verification product. The other is a loose red-flag listicle that treats every anomaly as a nation-state operative. Neither tells you how to score the signals you can read yourself, and neither protects the real senior engineer with a quiet public footprint. This document assembles the scattered FBI, NYDFS, and multi-nation advisory indicators into a single pre-advance scoring pass with a three-way gate.

Why a scoring read beats a red-flag list

A red-flag list fails because it has no weights and no gate. The job is not to spot a flag; it is to decide whether this specific person is worth your interview slot, and to be able to defend that decision later. A list of twenty indicators with no sense of which ones mislead will reject real people and advance good fakes.

Two facts set the frame. First, most anomalies are ordinary fraud, not Pyongyang. In Pindrop's analysis of its own hiring pipeline, clear fraud signs appeared in 1 in 6 applicants, but only 1 in 343 linked to DPRK infrastructure or behavioral patterns. That makes nation-state cases roughly 57 times rarer than general fraud. A gate that reads every oddity as a state operation will over-reject honest candidates while feeling vigilant.

Second, the threat is real at scale and the stakes are high. One DPRK pod applied for 170,000 positions and landed 76 over a ten-month operation. CrowdStrike observed the FAMOUS CHOLLIMA group infiltrate over 320 companies in twelve months, a 220% year-over-year increase. GetReal Security's benchmark found 41% of surveyed enterprises had already onboarded a fraudulent candidate. The scheme funneled roughly $800 million to Pyongyang's weapons programs in 2024 alone. You cannot ignore this, and you cannot let it make you paranoid. The scoring read is the middle path.

The four signal groups the advisories agree on

The indicators recur across the 2022 State, Treasury, and FBI advisory, the November 2024 NYDFS industry letter, and the July 2026 eleven-nation joint alert. They sort cleanly into four groups: profile, location, document, and behavioral. Reading them as groups, not a flat list, is what lets you weight them.

The behavioral group is the most diagnostic and the least available before interview. Shipping a laptop to a different address than the stated residence, insisting on cryptocurrency or routing wages to a third party's account, and refusing direct deposit are strong tells, but they appear at offer and onboarding. Your pre-advance read leans on profile, location, and document signals, which are weaker and need corroboration. That asymmetry is the whole reason you need a gate rather than a verdict.

The signals you can read, and what each one proves

The strongest cheap signals are account age and contribution history, because provenance is hard to fake and polish is easy. A real developer typically has a contribution graph spread across months or years. A newly created account with no history, activity compressed into a short window, or contributions only to forked repositories is worth scrutiny.

But a green contribution graph is not a track record. Free public tools exist specifically to generate fake commits that fill the graph and give the impression of a productive developer. Worse, a commit author can be spoofed by forcing the author email to the target account. So the raw squares prove nothing. What proves something is a GPG-signed commit carrying a "Verified" badge, because that cryptographic signature is far harder to counterfeit than green squares or an author field.

Here is the discipline for each signal: say what it proves, and say what it looks like when it lies.

• GitHub account age and contribution spread. Proves sustained real activity. Lies as a dense graph manufactured by a filler tool, or a thin graph that actually belongs to a private, legitimate engineer.
• GPG-"Verified" signatures on commits. Proves cryptographic control of the identity. Rarely lies, which is why it carries the most weight; its absence is a prompt to Verify, not to Reject.
• Commit author email metadata. Proves which address made a commit, checkable because the commit SHA often includes it. Lies when forced, so cross-check it against an independent source like a personal domain.
• LinkedIn creation date and connection density. Proves the persona existed before the application and has real mutual ties. Lies when a persona is aged artificially or padded with low-density connections.
• Reverse-image search on the photo. Proves the face is not a reused stock or stolen image. Lies when operators generate a fresh synthetic face that returns no matches.
• Location consistency. Proves the stated geography matches behavior like commit timezone patterns. Lies for travelers and VPN users, so it never convicts alone.

Pool size as a plausibility prior

A rare skill claimed in a small market draws from a thin real pool, so a flood of such applicants outruns the people who actually exist. This is a quantitative prior you can set before reading any single signal. Refolk's index gives you the pool sizes.

In Refolk's index of professional profiles, there are only 96 Solidity engineers in Germany against 879 in the United States, roughly a 9.2x gap. The US React pool, at 5,646, is about 6.4x the US Solidity pool. The use is simple: a claimed rare-skill-in-small-market profile, like a German Solidity engineer, comes from a much thinner real population, so it warrants heavier corroboration before Advance. If you are seeing more inbound "German Solidity" applicants than that pool plausibly supports, the base rate itself is a flag, independent of any one resume.

Refolk lets you size that real pool and surface the corroboration in one query, so provenance checks start from a defensible baseline instead of a guess. When you want to see who genuinely matches a rare profile, ask for the people who carry the hard-to-fake signals directly.

The scoring pass and the three-way gate

Score the signals, then route to one of three verdicts: Advance to interview, Verify with enhanced steps, or Reject. The gate is Refolk's framework, not a cited standard; published sources supply the component logic, and this document assembles it into thresholds you can defend. The core rule, drawn from the advisories and the base rates, is that a verdict change requires two independent signals, never one.

Provenance is the first input, not metadata. Because a profile with a decade of consistent history is far harder to counterfeit than one resume PDF, an outbound-sourced profile should clear on thinner evidence than an identical inbound one. Fraud rides the inbound flood; Pindrop's fake applicants came through a job posting. So the same thin GitHub footprint reads very differently depending on whether you went looking for this person or they came to you.

Here is how the inputs map to verdicts.

• Advance. Outbound-sourced, or inbound with GPG-signed commits plus a consistent multi-year history that cross-corroborates on an independent source. No corroborated location or document flag. Pool size plausible for the claimed skill and market.
• Verify. Any single location or identity mismatch, a thin or absent GitHub history on an inbound candidate, a photo that returns no reverse-image matches, or a rare-skill-in-small-market claim without strong provenance. One flag, not two. The candidate is not rejected; they move to enhanced verification.
• Reject. Two or more corroborated flags, especially across groups. The clearest Reject cluster is behavioral and corroborated: an alternate-address laptop shipment, crypto-only or third-party payroll, and a proxy interviewer appearing together. A forged document matched to a manipulated video feed is the same tier.

The procedure, start to verdict

Run the steps in order. The first six take under an hour and produce a written Advance, Verify, or Reject. Steps seven and eight only fire when the gate routes a candidate to Verify or forward to offer.

On ordering, sources disagree about exactly when IP is formally captured. One line of guidance puts a location check before the offer; others place formal ID and right-to-work inside onboarding. The defensible position is that verification precedes the offer, because every downstream control depends on knowing who and where the candidate is. Require government-ID verification and a location check before contract generation, not after. For US right-to-work, the employee completes Form I-9 Section 1 on or before the first day, and the employer completes Section 2 within three business days of the start date. Running background checks before onboarding is finalized avoids compliance, financial, and legal risk.

How this read goes wrong

The failure modes below are where honest practitioners both over-reject real people and advance good fakes. Each one names the false positive and the check that corrects it. This is the most valuable part of the standard, so give it weight.

Camera-on treated as proof of personhood

A smooth live video "confirms" a real person. It does not. Operatives run a deepfake model live and route output through a virtual-camera driver the platform treats as a normal webcam, producing a result indistinguishable from a normal call to a manager not probing for artifacts. Eleven governments jointly named this specifically because "turn your camera on" is no longer a reliable identity check. The correction: demand spontaneous unscripted physical actions, and pair any video read with a second signal.

Green contribution graph treated as track record

A dense graph reads as years of real work. Free tools fill the graph on demand, and author fields spoof trivially. The correction: open the commits for GPG-"Verified" signatures and inspect author email metadata against an independent source. Count signatures, not squares.

Polished LinkedIn treated as legitimacy

A strong profile with relevant experience and natural speech is exactly what a sophisticated persona presents. The correction: corroborate against creation date, connection density, and an independent source. Operations at this level deploy fully constructed identities, histories, and public credentials designed to withstand due diligence, so single-source consistency proves nothing.

Thin profile auto-rejected

A real senior engineer with a sparse public footprint gets scored as synthetic. This is the error that destroys your pipeline quietly. The correction: outbound-sourced long-history profiles are harder to fake than inbound resumes, so weight provenance before you penalize thinness.

Single location mismatch treated as conviction

A legitimate traveler or VPN user is flagged as proxied. The correction: require a second corroborating signal. Lip-sync drift plus a location mismatch convicts; either one alone does not.

Machine-translation errors over-weighted

A genuine non-native speaker gets flagged, while fluent LLM-polished text clears a fake. The correction: treat language as a weak signal, never decisive. Workers now use translation tools and LLMs to produce convincing profiles, so phrasing cuts both ways.

Verification deferred to onboarding

An offer gets drafted for the wrong jurisdiction and payroll goes live before identity is confirmed. The correction: ID and location before contract generation, with I-9 Section 2 inside three business days. The Knoot facilitation case ran to out-of-pocket losses exceeding $500,000 for auditing and remediation; the deferral is expensive.

A copy-ready verdict record

Write the verdict down. A defensible read is one you can reconstruct months later. Use this skeleton for each candidate so the gate is reproducible across your team.

Candidate:
Channel: inbound / outbound-sourced
GitHub account age:
Signed commits present: yes / no / none found
Author email corroborates independent source: yes / no
LinkedIn creation + connection density:
Reverse-image result: match / no match / stolen
Employer linkage confirmed: yes / no
Location vs behavior signal: consistent / discrepant
Rare-skill-in-small-market: yes / no (pool size: )
Flags corroborated (count across groups):
VERDICT: Advance / Verify / Reject
Signals cited:
Enhanced Verify steps run (if any):

Final checks before you call it

Before you lock a verdict, run this list. If any item fails, the correct default is Verify, not Reject, unless you have a second corroborating flag.

Keeping the read current

The signals move, so the framework has to be re-checked rather than frozen. The one control everyone used to trust, live video, is already defeated, and the next broken control is coming. Re-check three things on a schedule.

First, re-read the primary advisories when they update. The NYDFS industry letter, the FBI IC3 alert, and the multi-nation joint alert carry the indicator lists; treat the mechanism, not any single named tell, as the durable part. Second, re-pull your base rates from your own pipeline. The 1-in-6 and 1-in-343 figures are Pindrop's; your mix will differ, and Gartner's projection that one in four candidate profiles globally could be fake by 2028 means the prior is rising. Watch your own Verify-to-Reject ratio and recalibrate thresholds if real candidates start landing in Verify. Third, re-size your real pools. A query against Refolk's index tells you how many genuine engineers with a given skill and location exist, so a flood that outruns that number is a flag before you read a single resume. The read stays defensible only as long as its weights match the world you are hiring in.