Discovery should trigger more than termination. The FBI reports that some DPRK IT workers exfiltrate proprietary data and later extort victims by threatening to release stolen code or information unless paid. That means security teams should review access, check for data exfiltration, and preserve evidence before assuming the matter is only a personnel issue.
What discovery usually means operationally
Finding a fake employee is not the end state; it is the point at which the organisation has to determine what the actor touched, what they could still reach, and whether any access pathways remain live. In practice, the most important question is not who the person claimed to be, but whether the account, device, or credentials were used to obtain data, privileges, or persistence. The FBI has warned that some DPRK IT workers combine access with later extortion, which makes identity discovery a security and evidence problem, not just an HR problem. NHI Mgmt Group research shows 97% of NHIs carry excessive privileges, which is why broad access review is usually more urgent than a simple termination workflow. Ultimate Guide to NHIs — Key Challenges and Risks
Discovery should also change the incident posture. A fake employee can leave behind valid credentials, API keys, cloud sessions, payroll or identity-system changes, and copied source code. If the actor blended into normal onboarding and ticketing, then the company may need to treat the case as a compromise of trust and access governance, not merely a policy violation. In practice, many security teams encounter the true blast radius only after the account has already been deactivated.
How companies should respond after identity fraud is confirmed
The first response is to stop assuming the account history is benign. Teams should review authentication logs, privilege grants, data transfer paths, device posture, and any linked service accounts or automation credentials that may have been issued during employment. If the fake employee used remote work arrangements, contractors, or outsourced onboarding, the review should also include identity proofing gaps, access approvals, and whether the same contact details were reused across systems. That matters because a fake worker often succeeds by passing as a low-risk user while quietly accumulating access over time.
At a practical level, the response sequence is usually:
- Freeze active sessions and rotate any credentials tied to the person, device, or workflow.
- Preserve logs, ticket history, file access records, source control activity, and chat exports before deleting data.
- Check whether the account touched code repositories, cloud consoles, secrets stores, or admin tooling.
- Validate whether any delegated access or shared credentials were created to support the role.
- Assess whether the issue extends to third-party vendors, payroll, or identity proofing providers.
That review is often broader than teams expect because false identity can be used to create long-lived access paths, not just a single account. NHIMG data shows only 20% of organisations have formal offboarding and revocation processes for API keys, which is relevant when a fake worker has been given machine-access credentials alongside human access. OWASP Non-Human Identity Top 10 NHI Lifecycle Management Guide
These controls tend to break down when identity proofing, access provisioning, and offboarding are fragmented across HR, IAM, IT, and engineering because no single team can see the full trust chain.
Where the real damage and edge cases appear
Tighter post-discovery containment often increases disruption, requiring organisations to balance speed of removal against the need to preserve evidence and avoid breaking business processes. The biggest edge case is when the fake employee did not just hold a login, but also created follow-on trust: new API keys, delegated admin rights, repository access, or access tokens that outlived the person’s account. Another common complication is that the actor may have used legitimate work output to mask exfiltration, so a clean termination record does not mean clean data handling.
There is also a governance trade-off. If the organisation focuses only on the individual, it may miss the control failure that allowed the impersonation in the first place: weak proofing, poor supervision of remote onboarding, excessive privilege, or no offboarding for non-human credentials. The most useful lens is to ask what access would still remain useful to an adversary after the employment relationship is ended. Current guidance suggests that is where the residual risk usually lives.
For teams that manage contractors or globally distributed workers, the edge case is scale: one fake identity can be less damaging than the process gap it reveals across multiple intake channels. That is why identity fraud cases often become a trigger for broader access governance remediation, especially where accounts, secrets, and approvals were issued on trust rather than verified role necessity.
Risk and Threat Considerations
A fake employee creates both insider-threat exposure and identity-governance failure. The material risk is that the person may have used legitimate access to exfiltrate data, plant persistence, or create a future extortion channel after discovery. When the actor is disguised as staff, normal trust assumptions can delay detection and widen the blast radius.
Failure mechanism: The risk materialises when identity proofing is weak, privilege is excessive, and offboarding is incomplete. An impersonator can obtain credentials, copy source code or sensitive files, create additional access paths, and retain valid tokens or shared secrets after the account is removed.
Impact: Organisations may face data theft, source-code exposure, unauthorised administrative access, operational disruption, and later coercion if stolen material is used for extortion or leverage.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Identity Inventory and Lifecycle Management | Fake employees often leave behind human and machine access that must be inventoried and revoked. |
| NHI-03 — Privilege and Access Control | Impersonation becomes damaging when the actor accumulates excessive or delegated access. | |
| NHI-05 — Secrets and Credential Management | Discovery must include API keys, tokens, and shared secrets the impersonator may have obtained. | |
| Recommendation — Inventory every account and credential tied to the fake employee and revoke anything still active. Review and reduce privileges that exceeded the role’s verified business need. Rotate exposed secrets and invalidate tokens linked to the suspect identity or workflow. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | A fake employee case hinges on access review, removal, and least-privilege enforcement. |
| CIS-8 — Audit Log Management | Logs are needed to reconstruct what the impersonator accessed and whether data left the environment. | |
| Recommendation — Remove unauthorized access paths and verify every remaining entitlement is role-justified. Preserve and review logs before deleting evidence needed for incident reconstruction. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | The core threat is abuse of legitimate-looking credentials and identities for unauthorized access. |
| Recommendation — Hunt for valid-account abuse patterns and verify whether the identity was used beyond its intended role. | ||
Practitioner Guidance
What to prioritise: Treat the case as a containment-and-forensics event first, not a personnel action. Preserve evidence, inventory every access path, and assume there may be non-human credentials or delegated privileges still active.
Decision rule: If the fake employee ever touched production systems, code repositories, or secrets stores, prioritise credential rotation and blast-radius review before deciding whether the account deletion alone is sufficient.
What to verify: Confirm who approved access, which systems were reached, whether sessions were reused across tools, and whether any service credentials, API keys, or shared passwords were issued to support the role.
Practitioner takeaway: The important judgement is to look past the false identity itself and determine whether the organisation has already lost control of the access it granted under that identity.
Related resources from NHI Mgmt Group
- Why does identity matter more when vulnerabilities are discovered faster than they can be patched?
- Why do still-valid secrets matter after public disclosure?
- Who is accountable when a fake company tenant is used to solicit employee activity?
- What happens after attackers get valid credentials in a SaaS or corporate environment?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
