A candidate applies, interviews well over video, passes screening, accepts the offer, and starts on a Monday. Equipment is shipped. An account is provisioned. A manager adds them to the team channel.

The candidate does not exist.

Nothing in the security stack fires, and nothing should have. There was no intrusion. No perimeter was crossed, no credential was stolen, no control was bypassed. The organization was asked for access through the front door by someone following the published process, and it said yes, because that is what the process is for.

We run this scenario as a paid engagement against enterprise organizations, alongside the payroll change and the offboarding gap that sit next to it. This is the failure mode that makes HR the highest-consequence social engineering surface in most organizations, and it is not the one their awareness program is built to prevent.

Ranking Departments on Failure Rate Answers the Wrong Question

Most department-level reporting compares click rates and stops there. That tells you how many people engaged. It tells you nothing about what happened afterward, and those two things move independently.

We score departments on two separate axes. Depth is how far the attack got, set by the deepest outcome any single person reached. Spread is how much of the population went with them. A department can be high on one and low on the other, and the combination is the finding.

Depth and spread are OSES™ components. Spread is measured across tested participants within each department, not across a client base. Depth is set by the deepest single observed outcome, so it is an event rather than a rate. See the note on reading this table below.

Read the table carefully and it says something counterintuitive. IT has the highest spread of any department we have tested. More of IT engaged and acted than any other group, including HR. On a conventional click-rate ranking, IT is your worst department.

IT still comes last on this table, because nothing that happened in IT produced a consequence. The attacks landed, people acted, and then the failures stopped moving. That is a genuinely good result and it deserves to be read as one.

HR sits at the top for the opposite reason. Its spread is not remarkable. What is remarkable is where its failures went.

Every Warning Sign in Your Training Is a Job Requirement in HR

Open any awareness curriculum and you will find a list of indicators. Unexpected contact from someone you do not know. Attachments from strangers. Links to external sites. Urgency around a personal or financial matter. Requests that arrive outside normal channels.

Now read that list as a recruiter's job description.

• Unsolicited contact from people you have never met is the pipeline. It is the definition of inbound sourcing.
• Attachments from strangers are resumes, and opening them is the work.
• External links are portfolios, profiles, and work samples.
• Urgency about a payroll or benefits problem is the most ordinary inbound a people team receives.
• Requests through unusual channels are how candidates and employees actually reach HR, because they do not know the org chart and are not supposed to.

This is not a training gap. It is an incompatibility. You cannot teach a recruiter to be suspicious of unsolicited inbound without asking them to stop recruiting, and you cannot teach an HR generalist to distrust an employee with an urgent personal problem without asking them to stop doing the job people hired them for.

Every other department can be told to slow down when something feels unusual, because unusual is genuinely unusual for them. For HR, the attack profile and the workflow profile are the same profile. Indicator-based training has nothing to work with.

HR Is an Issuance Point, Not a Target

Here is the structural reason HR outranks everything else, and it has nothing to do with how often people there click.

Every other department is somewhere an attacker tries to get to. HR is where access is created.

The hiring path is also not the only irreversible transaction HR owns. Direct deposit changes move money out of the organization on the strength of an email, a form, and a name. Payroll data requests hand over the personal and tax information of the entire workforce in a single file. Offboarding failures leave access alive after a person leaves.

None of these is classified as a security transaction by most organizations, and all of them are one human action with an outcome you cannot undo on Monday. That is the definition of the transactions that need a verification step. HR owns several of them and is usually not in the room when the security team writes them.

What the Data Says, and What It Does Not

Two honest notes about the table above, because the argument does not need them hidden.

HR and IT fail at close to the same rate. Their action rates land within a fraction of a point of each other, and the IT spread is higher. If the question were which department engages with attacks most often, the answer would be IT, not HR. Anyone who wants to read the table that way is reading it correctly. The separation is entirely in what happened next. The failures in IT did not produce consequences. HR's did, and the path was the hiring process.

HR's depth comes from an observed event, not from a rate. One synthetic candidate progressed through screening. That is an event we watched happen, and it is the reason the department carries a Critical band. It is not a frequency estimate, and we are not claiming a percentage of hires are synthetic.

We report it as an event on purpose. A single person moving money, or a single fake identity being onboarded, is an organizational failure regardless of how many people were tested alongside them. Sample size governs rates. It does not govern whether something happened.

So the claim is narrow and specific: this path works, we have seen it work, and there is currently no control watching it.

Neither Team Can Fix This Alone

Security cannot fix it because security does not own the workflow. The hiring process belongs to HR, runs in HR's systems, is measured on HR's metrics, and is optimized for speed to offer. A security team that shows up with a verification requirement and no relationship gets treated as friction in someone else's funnel, correctly.

HR cannot fix it because HR does not know the attack. Nobody in recruiting has been shown what a synthetic candidate looks like, and there is no reason they should have been. Identity verification has never been their job. They screen for fit and qualification, not for existence.

So the work is joint by necessity, not by goodwill. Three transactions, each with an owner on both sides.

The relationship matters as much as the procedures. HR is the department most likely to receive an attack that looks exactly like work, which makes them the group most worth talking to and the group least often invited. Bring them the scenarios, not the policy. A recruiter who has been shown a convincing synthetic candidate becomes an ally in ten minutes. A recruiter who receives a new mandatory step in a policy email becomes an obstacle for a year.

For HR, Put Technical Controls Underneath the Human Ones

Everywhere else we argue that the procedure is the control. In HR we go further, because the transaction is identity itself, and a person is the wrong instrument for verifying identity at all.

• Technical identity verification before provisioning. Document verification, liveness checking, and validation against authoritative sources. Not a recruiter's judgment about whether a video call looked normal.
• Background screening that confirms existence, not only history. Most screening validates the record of a person. Confirm that the record belongs to the individual in the interview.
• Synthetic media detection on the interview channel. If candidate interviews happen over video, the channel itself needs a control on it.
• A hard gate between offer acceptance and account creation. Every technical check above is worthless if provisioning can proceed before it clears.

This is not a reversal of the argument. The case against detection was never a case against detection as such. It was against locating detection in human perception, which does not improve, does not scale, leaves no record, and cannot be audited. Machine detection has the opposite properties on all four counts. It versions, it runs on every candidate rather than the ones someone thought to scrutinize, it logs, and you can test whether it works.

Put detection where it can be measured. Put verification where a person can execute it. Those are different layers and they are not in competition.

One caveat, and it is not a small one. A detection product is a claim, and claims should be tested rather than trusted at purchase. We have tested deepfake detection tooling and found a synthetic artifact that passed a current production version. After disclosure the vendor shipped an update, and a separate artifact we had not disclosed was caught by it. That is a healthy outcome and it is also the point: the control moved because it was tested. Both sides of this are shipping new models continuously, so a detection capability verified at procurement and never revisited is a control with an unknown current state.

Test the technical controls, the screening process, and the detection capability together, against the actual hiring workflow rather than in isolation. A liveness check that a recruiter can skip when the candidate says their camera is broken is not a control. It is a setting.

What to Measure

If your HR reporting is a click rate, you are measuring the one axis that does not separate these departments. These are the questions worth answering instead.

The fifth question is the one almost nobody can answer today, and it is the one that separates a working control from a control with a hole in it. We cover that distinction in detail in our breakdown of why a click rate cannot grade a procedure.

What We Would Do First

Six steps. Every one of them needs somebody from both teams in the room, and none of them requires a purchase.

1. Map where access is created. Walk the path from offer acceptance to provisioned account and write down every point where a human decision grants something. Most security teams have never seen this diagram.
2. Write the verification step for hiring. One sentence. It has to name the channel, and the channel cannot be one the candidate supplied.
3. Do the same for direct deposit changes. This is the fastest win on the list and the one with immediate financial consequence.
4. Check that running each step leaves a record. If it does not, fix that before training anybody, because a step you cannot see is a step you cannot reinforce.
5. Show the recruiting team a real synthetic candidate. Not a slide about deepfakes. A convincing one, with the artifacts. Ten minutes of that will do more than a year of modules.
6. Find out what your identity verification actually verifies. Ask whether it confirms a record exists or confirms the person in the interview matches it, and whether anyone can proceed without it.

The Hire That Was Never an Intrusion

Go back to the candidate who started on Monday.

No control failed. The email gateway had nothing to block, the endpoint agent had nothing to flag, the identity platform had nothing to challenge, and the SOC had nothing to investigate. Every system behaved exactly as designed, because the organization was not attacked. It was asked, and it agreed.

That is why HR ranks where it does. Not because its people are less careful than anyone else's, and not because they click more, because they do not. It ranks there because it is the one department where a social engineering success does not look like a breach. It looks like a hire.

The department that cannot be trained out of it is the one that needs the procedure most.

Frequently Asked Questions