Right-to-Work and I-9 Document Fraud: The Tampered PDF Your Compliance Check Misses

A new hire emails over their work-authorization paperwork before the start date. In the US, that’s a permanent resident card and a supporting document for the I-9. In the UK, it’s a screenshot or PDF of a Home Office share-code result, or a sponsor letter confirming the candidate’s visa. The name matches the offer. The dates are in range. The document looks exactly like every genuine one your team has processed. Your onboarding coordinator files it and clears the candidate to start.

Every step of that review was done correctly. And the document could still have been edited.

The reason is that the right-to-work (RTW) and I-9 verification process is built to check whether the document is plausible and consistent — the right name, a valid-looking expiry date, the correct document type for the person’s status. It was never designed to check whether the PDF file itself was altered after the issuing authority produced it. Those are two different questions. A candidate who opens a real share-code printout or a real sponsor letter, changes one expiry date or one name, and re-saves it defeats the second question completely — while passing the first without trouble.

This is the shape of most right-to-work document fraud and fake I-9 document cases in practice: not a forgery built from nothing, but a real document edited in one field. This article walks through how employers and background-verification (BGV) operators actually verify work authorization today, exactly where that process breaks on a well-edited PDF, and the structural forensic layer that closes the gap. It is written for HR compliance, BGV operations, and sponsor-licence holders — not developers, though there is a short integration section at the end.

One thing to be clear about up front, because this sits right next to a category HTPBE? is not in: HTPBE? does not confirm a person’s identity and does not confirm their eligibility to work. It does not replace E-Verify, the Home Office online right-to-work check, or any identity-document validation service. Those checks answer “is this person who they say they are, and are they allowed to work?” HTPBE? answers a single, narrow, different question: was this PDF file edited after it was created? It is additive to your existing process, not a substitute for any part of it.

The Stakes: Civil and Criminal Liability Land on the Employer

Work-authorization fraud is one of the few compliance areas where accepting a forged document exposes the employer, not just the fraudster, to penalties.

In the United States, employers must complete Form I-9 for every employee and examine documents that establish identity and employment authorization. Knowingly accepting fraudulent documents, or failing to properly verify, carries civil fines into the thousands of dollars per violation, and a pattern of knowing violations can escalate to criminal exposure — against a backdrop of steadily rising US Immigration and Customs Enforcement audit activity.

In the United Kingdom, the regime is sharper still. An employer who hires someone without a valid right to work and cannot show a statutory excuse faces a civil penalty the Home Office raised to up to £60,000 per illegal worker in 2024 — triple the previous maximum. For sponsor-licence holders, the consequence isn’t only the fine: a compliance failure can mean licence suspension or revocation, severing the right to sponsor any overseas worker and collapsing a hiring pipeline overnight. And the statutory excuse depends on having carried out the prescribed check correctly. If a candidate hands over an edited document and the operator processes it at face value, that excuse can be undermined precisely because the underlying file was not what it appeared to be. The liability attaches to the organisation that accepted the paperwork.

How Employers Verify Work Authorization Today

Work-authorization verification is a layered process, and a competent one catches a great deal. Here is what the controls actually do — and they do their jobs well.

United States: I-9 and E-Verify

For the I-9, the employer examines the documents the employee presents from the Lists of Acceptable Documents — a List A document that proves both identity and authorization (a permanent resident card, an Employment Authorization Document), or a List B identity document paired with a List C authorization document — confirming each reasonably appears genuine and relates to the person. Many employers then run the data through E-Verify, which checks it against Social Security Administration and Department of Homeland Security records. When E-Verify runs, it is the right control — keep it. But under the remote alternative procedure available to qualified E-Verify employers, documents may be examined over video with copies transmitted in advance. That is where edited PDFs enter the workflow: the reviewer is looking at a transmitted file, not a physical card.

United Kingdom: Share Codes and Sponsor Compliance

For candidates with a digital immigration status, the prescribed check is online: the candidate generates a share code, the employer enters it with the candidate’s date of birth on the Home Office service, and the official result displays straight from government records. Done live, this check is robust — the data comes from the Home Office, not from a candidate-supplied file. Where an online check isn’t possible, the employer examines documents from the prescribed lists manually and retains a clear copy. Licensed sponsors carry ongoing duties on top of this: tracking visa expiry and retaining right-to-work evidence — sponsor letters, Certificate of Sponsorship records, share-code printouts, passport and BRP copies — as PDFs in a compliance folder, ready to produce if the Home Office audits.

Each of these is a real, valuable control, and the live share-code check in particular is excellent because it pulls from the source rather than trusting a supplied file. The problem is not that these checks are weak. The problem is what happens when a file is processed in place of the live source.

The One Thing the Process Doesn’t Check

Read those controls again and notice the common thread. They verify whether the document’s content is plausible and matches the person: right name, valid-looking expiry, correct document type, data that corresponds to a real record. These are content questions. None of them ask the other question: “Was this PDF edited after the issuing authority produced it?”

That is the gap a careful fraudster exploits. Consider the most common way work-authorization documents are faked — not forged from nothing, but edited from a real one:

1. The candidate obtains a genuine document as a PDF — their own expired share-code printout, a real sponsor letter issued to someone else, a permanent resident card scan, a visa grant letter.
2. They open it in a desktop or online PDF editor.
3. They change one field — push an expiry date forward, swap the name, alter a visa category, change a Certificate of Sponsorship number.
4. They re-save the file and send it to the employer.

The result is a document built on a real template, with the real layout, the real fonts, the real official styling — and a candidate who had every chance to make the edited field look correct. The expiry date is now in the future. The name now matches the offer. On screen, the edited field is indistinguishable from an original one, because the editor renders it in the same font at the same position. A visual review has nothing to catch.

Where does this slip through the otherwise-strong checks? Precisely at the moments when a file stands in for the live source:

• A US reviewer examining transmitted document copies under the remote procedure is looking at a PDF, not a card.
• A UK employer who relies on a candidate-supplied share-code printout rather than running the code live on the Home Office service is trusting a file, not the government record. (Running the code live is the safer path — and exactly why a tampered printout is the fraudster’s workaround for candidates who can’t pass the live check.)
• A sponsor compliance folder full of retained PDFs has, by definition, no live source behind it — it’s the file or nothing when the auditor asks.
• A BGV operator processing thousands of documents at scale receives PDFs by email and upload, far downstream from any original.

In every one of these cases, the decision rests on an uploaded or emailed PDF, and the integrity of that PDF goes unchecked. The content review confirms the data is plausible; nothing confirms the file wasn’t altered to make it so.

What E-Verify and the Online Check Solve — and What They Don’t

When E-Verify runs against DHS and SSA records, or a UK employer runs a share code live against the Home Office service, the data is validated against the authority directly — there is no supplied file to edit, so there is nothing for a PDF editor to defeat. For the candidates and moments those checks cover, they are the gold standard. HTPBE? does not replace them, and you should keep every one of them.

But those checks have a coverage and timing boundary, and document fraud concentrates exactly at that boundary:

• Documents that aren’t run live. A share-code printout examined as a PDF, rather than entered live on the Home Office service, is a file — and a file can be edited. The same is true of any supporting document transmitted as a copy.
• Document types with no online equivalent. Sponsor letters, internal Certificate of Sponsorship records, visa grant letters, and many supporting documents have no real-time validation service behind them. They exist only as PDFs.
• Retained compliance evidence. A sponsor’s audit folder is a collection of files captured at hire time. Nothing re-validates them later; their integrity is assumed.
• High-volume BGV intake. Background-verification operators handle work-authorization documents in bulk, mostly as uploaded PDFs, where a manual live check on every single file isn’t feasible.

In each of these cases, an organisation is back to a human relying on a PDF — the exact scenario where content checks and even excellent live-lookup services can’t see an edit, because no file passed through them. Identity and eligibility services don’t fill this gap either: they confirm who the person is and whether they may work, not whether a particular submitted PDF was altered. That uploaded-file case is precisely where a structural layer earns its place. It is additive — it catches what the live checks sidestep and what the human reviewer can’t see.

The Missing Layer: Structural File Forensics

A PDF is not a flat picture. It is a structured file that carries an internal record of how it was built and saved — when it was created, what software produced it, whether it holds a digital signature, and how many times it was written to disk. When someone opens an authority’s original PDF and saves an edit, that act leaves traces in the file’s structure, no matter how convincing the visible field looks.

Structural forensics reads that internal record and returns a verdict. It never asks whether an expiry date is plausible or whether a name belongs to a real person — that’s the job of E-Verify, the Home Office check, and your reviewer. It asks whether the file’s own construction is consistent with a clean, single-pass document from an issuing system, or whether it bears the marks of having been opened and re-saved in an editing tool after the fact.

HTPBE? is a self-serve API that performs exactly this analysis. You send it a PDF; it returns one of three verdicts plus a list of named markers describing what it found. To be unambiguous: it is not an identity or eligibility vendor, and was never meant to be one. It does not tell you the candidate is who they claim or that they may legally work. It answers only: was this file altered after it was created?

The three verdicts

• intact — no evidence of post-creation modification, and the file looks like a genuine single-pass document from an institutional system. The structural layer found nothing to flag.
• modified — the file carries forensic evidence that it was changed after it was first generated. This is the case that matters most: a document that should be a clean export but instead shows the fingerprints of an editing session.
• inconclusive — the file was produced by consumer software, an online editor, or a scanner, so there is no institutional baseline to check integrity against. This is not a pass. It is a routing signal, and in work-authorization checks it is often the most useful verdict of all (more on that below).

What it actually catches — in plain terms

Without turning this into a how-to for forgers, here is the kind of structural evidence the analysis surfaces, described as outcomes rather than recipes:

• Editing-tool fingerprints. Documents issued by government and institutional systems are produced server-side. When a file instead carries the signature of a consumer PDF editor or an online conversion service, that origin is inconsistent with a genuine issuing pipeline. The marker HTPBE_EDITING_TOOL_FINGERPRINT flags this.
• Disagreeing internal timestamps. A clean export’s creation and modification timestamps line up. When they contradict each other — the file claims one creation date but was last written days later — that gap is recorded structurally even though it’s invisible on the page. HTPBE_DATES_DISAGREE covers this.
• Multiple revision layers. Each time a PDF is edited and saved, the change is appended as a new layer on top of the original. A document that should have been generated in a single pass but instead shows several stacked write sessions reveals that it was modified after creation. The marker is HTPBE_MULTIPLE_REVISION_LAYERS.
• Producer identity that’s been overwritten or spoofed. Some tools try to hide their involvement by rewriting the file’s stated generator. When that identity has been blanked or forged, the analysis flags it (HTPBE_IDENTITY_OVERWRITTEN, HTPBE_PRODUCER_IDENTITY_FORGED).
• Tampering around a digital signature. Where a document is digitally signed — some official letters and certificates are — the analysis detects content changed after signing (HTPBE_POST_SIGNATURE_EDIT) or a signature stripped off entirely (HTPBE_SIGNATURE_REMOVED). These are among the most conclusive signals there are.

None of these depend on the visible field being implausible. A perfectly formatted, perfectly believable forged expiry date still sits inside a file that was edited — and the edit is what gets caught.

Want to see it on a real document? You can drop a PDF into the free check on this site and get a verdict in a few seconds — no account needed. It’s the same engine the API runs, and it’s a fast way to check a single suspicious share-code printout or sponsor letter before you decide whether to add it to your onboarding.

What inconclusive Means for Work-Authorization Documents

The inconclusive verdict is the one people most often misread, so it’s worth being precise.

inconclusive means the file was created in software that anyone can use to build a document from scratch — Word, an online editor, a scanner. Because there’s no institutional baseline, the structural layer can’t say whether the content was tampered with. It’s telling you, honestly, “I can’t verify integrity here.”

The power of that verdict comes from context — specifically, what the document claims to be.

A Home Office share-code result printout, an official visa grant letter, a permanent resident card scan from a government system: these have an institutional origin. A genuine one should look like an institutional export. So if a candidate hands you a document claiming to be an official government-issued result, and the analysis returns inconclusive because the file was actually built in a word processor or run through an online editor, the verdict is doing real work: a real official document would not look like that. That mismatch is a reason to escalate — and, ideally, to go run the share code live yourself rather than trust the printout at all.

The same inconclusive verdict on a document that’s supposed to be a simple internal letter — something an HR team might legitimately produce in Word — is routine, and you’d treat it as such. The verdict is identical; the action depends on whether the claimed source is supposed to produce institutional files. Used this way, inconclusive isn’t a dead end. It’s a fork in your workflow — and frequently a prompt to fall back to the authoritative live check.

Honest Limits — What This Layer Cannot Catch

Structural forensics is a powerful additional control, not a fraud oracle. Two scenarios sit outside its reach, and a serious compliance team should know them.

Documents fabricated entirely from scratch in the right kind of software. If a fraudster doesn’t edit a real document but instead builds a fake from zero using a tool that produces institutional-looking output, there is no “original” to compare against and no editing event to detect. The file may look clean structurally because, structurally, it is a clean single-pass file — it just contains invented data. This is exactly why the structural layer complements rather than replaces source verification: running the share code live on the Home Office service, running E-Verify, and confirming details with the issuing authority remain the right controls for fabricated-from-scratch fraud. The structural layer’s strength is the far more common case — editing a real document.

Legitimately consumer-generated documents. Some genuine letters really are produced in Word or exported through generic print drivers. For those, inconclusive is the correct and expected verdict, and reading it as guilt would generate false positives. The signal only carries weight when the claimed source has an institutional baseline to deviate from.

And to restate the boundary that matters most here: HTPBE? checks the file, not the person. It does not establish identity or the right to work, and it is not a statutory check on its own. A modified verdict tells you a file was altered and should be escalated and re-sourced; an intact verdict tells you the file wasn’t altered — not that the candidate is authorized to work. Your E-Verify run and your live Home Office check remain the controls that answer eligibility. The structural layer slots alongside them, catching the altered-PDF case they can’t see.

Wiring It Into Your Onboarding or BGV Workflow

For teams that decide the structural layer belongs in their workflow, integration is deliberately small. The pattern is three steps.

1. Analyze the uploaded document. When a candidate uploads or emails a work-authorization PDF, send its URL to the analyze endpoint. There is no numeric risk score to interpret — you get a verdict and named markers.

curl -X POST https://api.htpbe.tech/v1/analyze \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://your-storage.example.com/onboarding/candidate-7821-rtw.pdf"}'

The response is just the check ID:

{ "id": "506a6b1b-1360-48a2-b389-abb346f85d04" }

2. Fetch the verdict. Retrieve the result by ID. The response is a flat object — the fields your policy cares about are status, modification_markers, and modification_confidence.

curl https://api.htpbe.tech/v1/result/506a6b1b-1360-48a2-b389-abb346f85d04 \
  -H "Authorization: Bearer YOUR_API_KEY"

{
  "status": "modified",
  "modification_markers": ["HTPBE_EDITING_TOOL_FINGERPRINT", "HTPBE_DATES_DISAGREE"],
  "modification_confidence": "certain"
}

A Python version for a typical onboarding service:

import os
import requests

API = "https://api.htpbe.tech/v1"
KEY = os.environ["HTPBE_API_KEY"]
HEADERS = {"Authorization": f"Bearer {KEY}", "Content-Type": "application/json"}

def screen_document(pdf_url: str) -> dict:
    submit = requests.post(f"{API}/analyze", headers=HEADERS, json={"url": pdf_url})
    submit.raise_for_status()
    check_id = submit.json()["id"]

    result = requests.get(f"{API}/result/{check_id}", headers=HEADERS)
    result.raise_for_status()
    data = result.json()

    return {
        "status": data["status"],                       # intact | modified | inconclusive
        "markers": data["modification_markers"],         # e.g. ["HTPBE_DATES_DISAGREE"]
        "confidence": data["modification_confidence"],   # certain | high | none
        "check_id": check_id,                            # store for your audit trail
    }

3. Route on the verdict. Wire the three outcomes into your existing review queue rather than auto-deciding on any single marker:

• modified → route to manual review, request a fresh document direct from the candidate, and re-run the authoritative check (run the share code live, run E-Verify). For the most conclusive markers — a post-signature edit on a signed letter — treat the finding as conclusive: decline to accept that file and require a fresh issuer-delivered copy before proceeding, rather than making the verdict the sole basis for an automatic decision about the person.
• inconclusive → branch on the claimed source. A consumer-software origin on a document claimed to be an official government result is worth escalating and re-sourcing live; the same verdict on a plain internal letter is routine.
• intact → no structural evidence of alteration; proceed with your normal identity and eligibility checks, which remain the controls that confirm the person can work.

Store the check ID against the candidate record. If a hiring decision or a sponsor audit is ever questioned, you can retrieve the forensic result from your check history. It shows exactly which structural signals fired — useful both for demonstrating diligence and for defending a statutory-excuse position.

Who Should Add This Layer

If you run HR compliance, onboarding, or BGV operations — or you hold a sponsor licence and keep a folder of retained right-to-work evidence — this is the gap in your stack worth closing. Your team already runs E-Verify or the Home Office check well, and those controls already confirm identity and eligibility. What they cannot see, by design, is whether a particular uploaded PDF was edited after the authority issued it. That blind spot is exactly where a careful candidate operates, and exactly what a structural layer covers — without ever pretending to be an identity or eligibility check.

For a deeper look at how this works as a workflow, see the right-to-work document fraud detection use case and the broader immigration document fraud detection hub. When you’re ready to put a verdict behind your onboarding intake, the self-serve API is documented end-to-end with test keys you can wire up before you spend a credit — create an account and screen your first document in minutes.