A fake employee is a person who appears to be a legitimate worker or contractor but is operating outside the approved identity, location, or relationship that the organisation authorised. In practice, the account may be valid while the trust in the operator is not, which makes it an identity governance problem, not just an HR issue.
What a fake employee actually represents
A fake employee is not simply someone with a suspicious résumé or poor onboarding paperwork. The core issue is that the organisation believes it has authorised one worker, while the person operating the account or access path is different from the trusted operator the business thinks it has.
That makes the term a governance and trust problem as much as an employment or fraud problem. The account or relationship may look legitimate on paper, but the real risk sits in the mismatch between the approved identity, the approved location, and the approved person using that access.
Why fake employee scenarios matter for access control
Fake employee cases matter because the organisation can grant access to the wrong operator while still seeing all the usual signs of legitimacy, including payroll records, contractor status, or an apparently valid account. In practice, the security failure is not just access creation, but weak validation of who is actually behind that access over time.
This is why fake employee scenarios often expose gaps in identity proofing, contractor oversight, delegated administration, and joiner-mover-leaver processes. When the organisation cannot reliably bind the approved relationship to the real human or external actor, downstream access decisions become easier to abuse and harder to audit.
How fake employee conditions arise
These cases can arise through impersonation, misrepresentation during onboarding, identity substitution, outsourced labour chains, or account handoff after the original approval was granted. The person may pass an initial check, but the trust relationship later drifts away from the actual operator, especially in distributed or remote work models.
They can also emerge when contractor management, HR records, and security controls are disconnected. If one system says the person is valid and another system cannot prove who is actually using the account, the organisation may preserve access long after the real trust basis has changed.
What organizations should understand about the term
The most important distinction is that a fake employee is not just an HR anomaly, and it is not solved by employment classification alone. The security question is whether the organisation can continuously verify the operator behind the account, the relationship behind the approval, and the boundaries of the access that were granted on that basis.
That is why the term belongs in identity governance discussions as well as fraud reviews. It is fundamentally about trust in the authorised relationship, and whether access remains valid when the person using it may not be the one the organisation intended.
Risk and Threat Considerations
Fake employee scenarios create material risk because the organisation may be granting legitimate access to an illegitimate operator. That can expose internal systems, sensitive data, privileged workflows, and third-party trust relationships without triggering the obvious signals associated with a normal account compromise.
Failure mechanism: the attacker or impostor benefits from a valid-looking relationship, then uses the approved account, contractor status, or onboarding record to pass through controls that assume the operator matches the authorised identity.
Impact: organisations can face unauthorized access, fraud, data exposure, privilege abuse, and difficult-to-detect persistence, especially when the trust failure is embedded in normal business records rather than a clearly malicious technical event.
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 NIST CSF 2.0 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) | Fake employee risk hinges on authenticating the real operator behind the account. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Contractor and external worker scenarios depend on verifying non-employees correctly. | |
| AC-6 — Least Privilege | A fake employee becomes more damaging when excess access is already available. | |
| Recommendation — Require stronger identity proofing and authentication before granting organizational access. Apply non-organizational identity controls to verify and track external worker access. Limit granted access to the minimum needed so impersonation yields less exposure. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Fake employee cases are governed by access decisions tied to trusted identity relationships. |
| Recommendation — Bind access to verified identities and remove access when trust in the operator changes. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity management governs how approved identities are established and maintained. |
| A.5.18 — Access rights | Access rights must follow the real approved relationship, not just a nominal record. | |
| Recommendation — Maintain authoritative identity records and verify that access maps to the correct worker. Review and revoke access when the approved relationship or worker status changes. | ||
Practitioner Guidance
Governance implication: treat fake employee risk as a continuous identity and relationship validation problem, not a one-time hiring check. The practical question is whether the organisation can prove that the person using the access is still the same approved actor who justified that access in the first place.
What to watch for: mismatches between approved worker records, physical or remote work expectations, contractor sponsorship, and actual access usage should be treated as a control signal, not just an administrative inconsistency. Where that linkage is weak, the trust basis for the account is weak too.