IAM should not be the only control at onboarding. Teams should verify the person, not just the document or submitted credentials, by pairing biometric liveness checks with government-issued ID validation during hiring or contractor intake. That closes a major gap where deepfakes and stolen identities can create a legitimate-looking account that later receives normal access like any other employee.
Why This Matters at Onboarding
Synthetic employees are dangerous because they do not arrive as an obvious account threat; they arrive as a trusted intake decision. If IAM only checks that a form is complete, a document is attached, or a credential can be issued, the directory becomes the first place where a fabricated person turns into an operational identity. That matters because directory entry usually unlocks downstream provisioning, joiner workflows, and access approvals that assume the identity is already real.
The practical risk is not limited to fraud at the hiring stage. A synthetic employee can inherit normal lifecycle treatment, appear in HR-linked systems, and gain a long-lived identity record that is difficult to unwind cleanly once other systems begin trusting it. This is why onboarding controls need to verify human presence and document authenticity before directory creation, not after access has already been granted. NHI management research consistently shows that identity gaps become much harder to correct once they are embedded in routine operations, and that is especially true when the identity was never genuine to begin with.
In practice, many security teams discover the problem only after a fraudulent account has already been treated as an ordinary employee by downstream systems.
How to Keep a Fake Identity Out of the Directory
The control point is earlier than most IAM teams assume. The directory should not be the place where identity truth is established; it should receive only identities that have already passed a stronger intake decision. That means the onboarding workflow needs a decision gate that verifies the person, validates the government-issued ID, and checks for live presence with a biometric liveness step before any directory object is created.
That gate works best when it is treated as a separate trust decision, not as a formality inside HR onboarding. The intake workflow should distinguish between document authenticity, person authenticity, and employment eligibility. A scanned ID alone can be forged or stolen, and a video interview alone can be deepfaked. A strong process combines multiple independent signals so that one manipulated input does not create a directory record.
- Require live identity proofing before account creation, not after first login.
- Separate document validation from presence validation so one control cannot substitute for the other.
- Bind the onboarding approval to a traceable decision owner, especially for contractors and remote hires.
- Block automatic directory provisioning until the verification result is explicit and recorded.
Teams also need to think about where the control breaks down operationally. If verification is outsourced, the IAM team still owns the trust boundary and must define what evidence is acceptable, how exceptions are approved, and when manual review is mandatory. The most reliable model is to fail closed: if the verification signal is incomplete, the identity does not enter the directory yet. That is a better failure mode than creating a record and hoping access review will catch the problem later. Current guidance suggests this boundary is especially important where onboarding is remote, high volume, or partially automated, because those are the conditions that make social engineering and synthetic identity abuse easier to scale.
These controls tend to break down when onboarding is optimized for speed without a hard approval gate, because directory provisioning then becomes a rubber stamp rather than a trust decision.
Common Failure Patterns and Edge Cases
Tighter onboarding verification often adds friction, so organisations have to balance user experience against the cost of admitting a fake identity. The trade-off is real: stronger proofing can slow hiring, but weak proofing creates long-lived directory exposure that is far more expensive to unwind. Best practice is evolving, and there is no universal standard for the exact combination of checks, but there is broad agreement that a single static document check is not enough.
Special cases deserve explicit handling. Contractors, seasonal workers, acquisitions, and remote international hires often have more exceptions, more third-party intermediaries, and weaker face-to-face assurance. Those are the environments where synthetic identities are most likely to slip through because teams are tempted to relax verification in order to keep operations moving. The right response is not to eliminate exceptions, but to route them through stronger review and tighter approval thresholds.
If the onboarding path cannot support live proofing, treat that as a higher-risk intake condition rather than a normal workflow variant. Directory creation is a trust event, and any exception that bypasses identity proofing should be measurable, reviewable, and rare. NHIMG research on non-human identity security shows how often identity hygiene breaks down once shortcuts become routine, and the same operational pattern applies when a fake employee is allowed into the directory through convenience alone.
Risk and Threat Considerations
The material risk is identity fraud at the trust boundary. Once a synthetic employee is created in the directory, the organisation has converted an unverified person into a legitimate internal identity that can be provisioned, monitored, and escalated like any other worker. That creates exposure across access governance, payroll, auditability, and downstream system trust.
Failure mechanism: Attackers or fraud actors exploit weak onboarding by using stolen credentials, forged documents, or deepfake presence to satisfy a shallow verification step. If the directory accepts that record, the organisation loses its first and best chance to stop the impersonation before privilege assignment begins.
Impact: The result can be unauthorized access, fraudulent employment records, difficult-to-reverse provisioning, and a contaminated identity lifecycle that survives long after the original onboarding error.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 5 — Account Management | Controls account creation and onboarding approvals for directory entry. |
| Recommendation — Gate account creation on verified identity proofing and approved onboarding evidence. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control | Applies to establishing trusted identities before access is granted. |
| Recommendation — Require verified identity assurance before provisioning any directory account. | ||
| NIST SP 800-63 | IAL2 — Identity Assurance Level 2 | Covers stronger identity proofing for remote or higher-risk onboarding. |
| Recommendation — Apply higher identity-assurance proofing when onboarding cannot be trusted at face value. | ||
| NIST Zero Trust (SP 800-207) | PL-1 — Trust Algorithm and Policy Enforcement | Supports enforcing trust decisions before granting internal system access. |
| Recommendation — Enforce policy decisions before directory issuance rather than after access begins. | ||
| NIST AI RMF | MAP — Measure and Manage | Supports measuring onboarding identity risk and control effectiveness over time. |
| Recommendation — Measure onboarding exceptions and identity-proofing failures as managed AI-era trust risk. | ||
Practitioner Guidance
What to prioritise: Put the strongest verification requirement in front of directory creation, not in front of first access. If an identity has not passed live proofing and document validation, it should remain outside the directory until the evidence is complete.
What to verify: Check that onboarding exceptions are rare, approved, and auditable. Verify that manual review exists for edge cases such as contractors, remote hires, and delegated recruiting workflows, because those are the conditions where synthetic identities are most likely to enter through process drift.
Decision rule: If the onboarding signal is only documentary, treat the case as unverified. If the person cannot be matched to a live verification step, do not create the directory record and do not rely on later access review to fix the problem.
Practitioner takeaway: The key judgement is to treat directory creation as the outcome of identity proofing, not the start of it; once a fake employee is in the directory, every downstream control becomes more expensive and less reliable.
