How should security teams stop fake workers from getting hired in the first place?

Security teams should require identity proofing that binds the applicant to verified documents, liveness checks, and a trusted enrollment record before any account is created. Hiring workflows need the same scrutiny as privileged access workflows, because a fraudulent employee can become a trusted insider if onboarding is treated as administrative rather than security-critical.

Why This Matters for Security Teams

Fake-worker hiring is not a simple HR fraud problem. It is an identity assurance problem that can end with a trusted account, payroll access, internal systems access, and eventually privileged reach across SaaS, source code, or support tooling. If an attacker can become a “legitimate” employee at onboarding, every downstream control inherits that false trust. Guidance from the NIST Cybersecurity Framework 2.0 and NHIMG’s Ultimate Guide to NHIs both point to the same operational reality: identity proofing belongs at the front door, not after account creation.

Teams often mistake a clean background check, a completed form, or a video interview for sufficient assurance. Those signals help, but they do not prove that the person presenting documents is the same person who will use the account later, nor that the identity evidence was not stolen, fabricated, or rented. The core control objective is to bind the applicant, the verified documents, and the enrollment record before any access is issued. In practice, many security teams encounter fake-worker fraud only after payroll diversion, data access, or lateral movement has already occurred, rather than through intentional prevention.

How It Works in Practice

Effective prevention combines identity proofing, enrollment integrity, and access gating. Before an account is created, the hiring process should verify government-issued documents, apply liveness checks, and capture a trusted enrollment record that can be audited later. The account creation step should depend on the proofing outcome, not the other way around. This is similar in spirit to the identity assurance discipline in NIST guidance, but the practical challenge is higher because the organization is trusting a human to enter a production environment that can later be used for finance, code, customer data, or internal tooling.

Security teams should require evidence that the person who was proofed is the person who shows up for day-one onboarding. That means restricting remote onboarding shortcuts, controlling who can override exceptions, and forcing any mismatch into manual review. Where risk is elevated, use stronger verification for high-impact roles and separate the proofing step from the employment approval step so no single approver can bypass both. The same rigor should extend to contractor and vendor onboarding, especially where third-party access is involved.

• Bind proofing to a trusted enrollment event, not just an HR record.
• Require liveness and document verification before identity creation.
• Delay account issuance until proofing is complete and approved.
• Log proofing evidence, reviewer actions, and exception approvals for later audit.
• Use step-up review for remote hires, high-risk regions, and privileged roles.

NHIMG research shows why this matters: only 5.7% of organisations have full visibility into their service accounts, and 96% store secrets outside secrets managers in vulnerable places, which means a single fraudulent hire can quickly become an internal pivot point once a real account exists. That risk is amplified when onboarding is treated as administration rather than security-critical. These controls tend to break down when hiring is fully outsourced across multiple systems because proofing evidence, approval authority, and account creation become disconnected.

Common Variations and Edge Cases

Tighter identity proofing often increases onboarding friction, so organisations have to balance fraud reduction against hiring speed and candidate experience. That tradeoff is real, and current guidance suggests risk-based proofing rather than one universal workflow for every role. For example, a low-risk desk role may not need the same verification depth as a finance administrator, a developer with repository access, or a support agent with customer data visibility.

There is no universal standard for this yet, but best practice is evolving toward layered checks: stronger verification for remote hires, extra scrutiny for name or document mismatches, and manual review whenever the applicant appears in a high-risk geography, changes devices mid-process, or requests fast-track access. Security teams should also coordinate closely with HR and legal so the process remains defensible and privacy-aware. NHIMG’s Ultimate Guide to NHIs is useful here because the same lifecycle discipline used for NHI onboarding applies to human identity enrollment: prove before you provision, and revoke any trust that cannot be validated. Where fraud teams rely only on post-hire monitoring, the organisation has already accepted the wrong identity into the environment.

Related resources from NHI Mgmt Group

• How should security teams decide where data observability is needed first?
• What should IAM and security teams review first when endpoint insider risk rises?
• How should security teams stop hiring fraud from turning into access abuse?
• How should security teams prioritise NHI remediation in cloud environments?