Every Hire Is an Access Grant. HR Needs the Checkpoints IT Already Has.

Sixty-eight stolen identities. More than 300 US companies. Deel cites that case, attributed to the US Department of Justice, in its October 2026 launch of an identity fraud product: remote IT workers used those stolen identities to get hired, “in one scheme alone.”

The sentence Deel builds the product on is blunter: “Increasingly, bad actors don’t need to hack their way into a company because they can get hired.”

Security teams put years into the login page. The offer letter ends with a laptop, a corporate account, a VPN profile and a seat in the engineering channel. Most hiring workflows do not file that as an access request. It is one.

The fake candidate is cheap now

Deel’s launch post states that “AI can now fake a CV, a face, a voice, and a government ID in minutes.” Each of those four artifacts used to carry some cost to forge. The CV took effort to make plausible. The face had to show up on camera. The voice had to hold a conversation. The ID had to survive a document check.

When all four drop to minutes, the hiring funnel loses its implicit friction. The process did some identity verification by accident, so recruiting rarely had to treat it as a job. A person who sat through several video calls and mailed back a signed contract was probably the person on the paperwork.

We wrote earlier about what happens to the portfolio once AI makes it cheap. This piece goes one layer down. The question here is who the person is, before anyone asks whether they did the work.

Deel also points to a July 2026 joint advisory by the FBI and international partners about state-sponsored remote IT workers. We are relying on Deel’s summary of both the DOJ case and the FBI advisory. The pattern is clear enough to act on without the details.

A hire is a provisioning event

Consider what the identity team does when a service account is created. There is a request. Someone approves it. Credentials are issued with a scope. Activity is logged under that identity. When something unusual happens, an alert fires and a person looks at it. When the account is retired, the access goes with it.

Now consider a new employee. The request is the job application. The approval is the offer. The credentials arrive on the first day. From that point on, the identity stack treats the person as verified, because HR said so.

HR said so based on a CV, a few video calls and a document upload. If those inputs can be fabricated, the most privileged identity decision in the company rests on the weakest evidence in the stack.

The argument we made about identity becoming the perimeter for agent traffic applies to people too. Once you cannot trust the channel to tell you who is on the other end, identity has to be checked at the points where access changes hands.

Checkpoints across the lifecycle

Deel’s answer names the moments where it places identity checks:

• the application
• the live interview
• the offer, with ID and liveness verification
• a password reset
• a new device
• high-risk access

The list matters more than the vendor. Read it as an access engineer would. The first three points sit in recruiting. The last three sit with IT and Security. Read that way, a fraudster who passes the interview would face another check at the offer, and again at a password reset, a new device or a high-risk access request.

In many companies these moments run in separate tools owned by separate teams. Deel puts the count of systems at five. Recruiting owns the applicant tracking system. HR owns the offer and the background check. IT owns the password reset and device enrollment. Security owns privileged access. Each team checks its own step. In that setup, no single team owns the check that the person at step six is the person from step one.

The design choice in Deel’s launch is one candidate risk record that follows the person from application into employment. If the record works as described, a signal raised in the interview would still be visible when the same identity later asks for elevated access.

The audit committee question

The line in Deel’s post that should worry a CFO is this one: “When the audit committee asks what happened, the evidence is spread across five systems.”

The number five is Deel’s framing, and your company may have more or fewer. The structural problem holds either way. After an incident, someone has to reconstruct who this person was, what was checked, by whom, and when. If that answer lives in the applicant tracker, the background check vendor, the HRIS, the identity provider and the device management console, the reconstruction becomes a forensic project. Some of those systems may have purged the records under their own retention rules before anyone asks.

An auditor does not accept “we checked at each step.” They ask to see it. A single trail that links each checkpoint to the same identity, with the decision and the reviewer recorded, is what makes the answer showable.

Humans review the high-risk alerts

Deel says its “fraud experts review every high-risk alert and explain why it was flagged.” That detail separates a control from a score.

An automated flag on a candidate is an accusation. Rejecting someone on an unexplained model output can create its own legal and reputational exposure, and recruiters will learn to ignore a flag they cannot explain. A flag that arrives with a reason, reviewed by a named person, which is the standard we would hold it to, is something a hiring manager can act on and an auditor can trace.

A caveat belongs here. The source is a vendor launch post. It publishes no accuracy figures, no false-positive rate and no detection rate. We cannot tell you how well Deel’s checks work, and neither can the post. Evaluate any product in this category on its error rates under your own candidate population, and ask the vendor for them in writing.

Who owns the hire as an access decision

Recruiting is usually measured on time to fill. Security is usually measured on incidents. Neither is measured on whether the person hired is the person who applied. That question falls between the two teams, so it often goes unanswered.

Treating the hire as an access grant puts it on someone’s desk. The identity team already knows how to define checkpoints, log decisions and review exceptions. HR already knows the candidate. The work is to connect the two so that a hire inherits the same discipline as any other privileged account.

Do this now

Pick your last ten remote hires and try to answer four questions for each one, from records alone:

1. What identity evidence did we collect before the offer, and where is it stored?
2. Was a liveness or ID check done at the offer stage, and who reviewed the result?
3. When this person first reset a password or enrolled a new device, did any check compare that event to the identity we verified at hiring?
4. If this person turned out to be someone else, how many systems would we need to open to reconstruct the timeline?

If the answer to the fourth question is more than one, you have found the work. Name an owner for hiring as an access path, map your checkpoints against the six above, and decide where the single record lives. Then put a person on every high-risk alert, with the reason written down.

---

This analysis synthesizes Introducing Deel Security: A New Way to Detect and Prevent Identity Fraud (Deel, October 2026).

Victorino Group helps companies treat hiring as an access path, with identity checkpoints and one audit trail from application to production access. Let’s talk.