Look for early-life behaviour that does not match the role, such as access patterns, system requests, or authentication habits that are inconsistent with the team’s normal working model. The key signal is not a single event, but a cluster of actions that look legitimate in isolation and unusual in context.
What a synthetic hire looks like in early-life behaviour
The first clue is usually drift between the stated role and the way the person or account behaves in the first days or weeks. A synthetic hire often appears “productive” in a narrow sense, but the activity pattern is wrong for the job: requests land too quickly, access is pursued in an odd sequence, and authentication or system-use habits do not match the team’s normal operating model.
That mismatch matters because onboarding controls are designed to make the early employment or account lifecycle observable and bounded. When the profile is fabricated, the controls may still complete, but the resulting behaviour often looks efficient, generic, or oddly consistent across tasks that should vary by role, manager, or team rhythm.
Common signals include a flurry of onboarding-adjacent requests that do not fit the role, such as asking for unusual system combinations, seeking broad access before task context is established, or pushing for exceptions that bypass standard approval paths. The issue is not that any one request proves fraud, but that the sequence does not resemble how a genuine new hire normally ramps up.
Behavioural clues that are most useful to review
Focus on clusters, not isolated events. A legitimate new hire may ask for help or show uncertainty; a synthetic hire is more suspicious when the person’s actions are internally coherent but operationally strange, for example when they know exactly which systems to target, request the right credentials too early, or move between tools with a confidence that outpaces their apparent tenure.
Authentication habits are another useful clue. Repeated logins from unexpected locations, unusual device changes, rapid switching between accounts, or login timing that does not fit the declared work pattern can indicate that the onboarding identity is being used as a cover for another operator or workflow. Those patterns become more meaningful when they line up with access requests that are broader than the role requires.
Watch for role-performance mismatch as well. A synthetic hire may display either over-precision, such as immediately knowing internal terminology and escalation paths, or under-specificity, such as avoiding normal team artefacts like project discussions, manager check-ins, or local context. The more the behaviour looks “legitimate in isolation” but abnormal when viewed as a whole, the stronger the signal.
How onboarding controls fail when the hire is synthetic
Synthetic hires usually slip through when onboarding is treated as a paperwork check instead of a lifecycle control. If identity proofing, manager validation, access approval, and early activity review are disconnected, a fake profile can be provisioned with enough legitimacy to start using systems before anyone tests whether the person behaves like a real employee.
The failure often appears as weak joiner-mover-leaver discipline: the new hire is created, but the role is not reconciled against actual work, the access grant is not revisited after the first few interactions, and exceptions are never reviewed. Joiner-Mover-Leaver (JML) Guide is useful here because the problem is lifecycle control, not just one bad credential or one suspicious login.
Teams should also look at whether access governance is strong enough to expose the mismatch early. A lightweight onboarding process can be fast, but if it does not produce reviewable evidence of who approved what and why, unusual access behaviour becomes much harder to challenge later. IAM and IGA Basics helps frame this as an entitlement and approval problem, not only an HR verification issue.
Risk and Threat Considerations
Synthetic hires are risky because they can gain valid access while remaining hard to distinguish from a normal onboarding event. That creates a trusted starting point for data access, fraud, privilege abuse, or follow-on compromise, especially if the account is allowed to accumulate permissions before anyone notices the behaviour is off.
Failure mechanism: Onboarding controls validate identity on paper, but do not sufficiently test role realism, behavioural consistency, or early access provenance, allowing a fabricated hire to inherit legitimate access paths.
Impact: The organisation can end up with an account that looks authorised, can pass routine checks, and may be used to exfiltrate data, expand access, or conceal a broader fraud or infiltration effort.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Synthetic hires exploit weak user identity proofing and login validation. |
| IA-5 — Authenticator Management | Early-life abuse often rides on poorly governed passwords, tokens, or other authenticators. | |
| AC-2 — Account Management | The issue is an account created and used through onboarding with insufficient lifecycle control. | |
| Recommendation — Strengthen organizational user authentication and verify each onboarding identity before granting access. Enforce authenticator issuance, rotation, revocation, and monitoring for newly onboarded accounts. Tie account creation, review, and disablement to validated onboarding and role changes. | ||
| CIS Controls v8 | CIS-5 — Account Management | Synthetic hires are surfaced by weak account lifecycle governance and excess access. |
| Recommendation — Limit and review account provisioning so new users receive only role-appropriate access. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity management must ensure a claimed employee identity is trustworthy before access is granted. |
| Recommendation — Validate onboarding identities and keep authoritative identity records current. | ||
Practitioner Guidance
What to prioritise: Review the first-access window, not just the onboarding record. The highest-value evidence is whether the early access pattern, device posture, and request sequence match the declared role and manager expectations during the first few touchpoints.
What to verify: Confirm that onboarding approvals are traceable to a real manager, a real workstream, and a plausible role profile. If the person can immediately request broad access, move between systems without context, or authenticate in a pattern that does not fit the team, treat it as a control failure until proven otherwise.
Practitioner takeaway: A synthetic hire is rarely exposed by one abnormal act; it is exposed when early-life behaviour fails the “does this look like how this role should actually start?” test.
Related resources from NHI Mgmt Group
- What are the signs that remote onboarding controls are being bypassed by synthetic identities?
- What are the signs that privileged access controls are still implicit?
- What are the signs that CJIS controls are becoming too fragmented?
- What are the signs that clinical access workflows are outpacing identity controls?