When a synthetic identity gets through onboarding, the attacker can operate with apparently valid credentials and normal employee trust. That can lead to malware deployment on company devices, access to internal systems over VPN, and longer term abuse of data, accounts, and business processes. The damage often emerges only after the attacker has already established a foothold.
How a synthetic identity turns remote hiring into an attacker foothold
A synthetic identity is valuable to an attacker because it can survive ordinary hiring checks and then behave like a normal employee after access is issued. The real risk is not just “passing onboarding”, it is gaining a believable employment record that unlocks device enrollment, remote access, collaboration tools, and trust from HR, IT, and service desk processes. The longer that trust exists, the more broadly the attacker can blend in.
That blend-in effect matters because remote roles often reduce face-to-face verification and shift more control to credentials, email, and workflow approvals. Once the account and device are in place, the attacker can use routine business processes as cover for malicious activity, including credential harvesting, malware staging, and attempts to reach internal resources that would be harder to touch from outside.
When the subject is employee onboarding fraud, the central security question is whether the organisation has enough identity proofing, approval friction, and post-hire monitoring to keep a fabricated person from becoming a durable enterprise trust anchor. For a broader identity view, NHI Mgmt Group’s Ultimate Guide to NHIs is useful for understanding how valid access can still be unsafe when it is overtrusted or poorly governed.
Remote hiring also creates a time gap that attackers exploit. A synthetic identity may look clean at hire time, but the consequences appear later, after the actor has had time to establish relationships, collect data, and widen access through routine requests. That delayed detection is why this problem is often treated as an identity fraud issue first and a malware or insider-threat issue second.
What the attacker typically does after getting hired
Once inside, the attacker usually starts with low-noise actions that look like normal employee setup or productivity work. They may log in from expected geographies, complete onboarding tasks, request access that appears role-consistent, and use collaboration channels to avoid standing out. The objective is to turn initial employment into a stable operational base before moving to more visible abuse.
From there, the attack path often expands in phases. The attacker may enroll a managed laptop or use a company-issued device to introduce malware, abuse VPN or SSO access to reach internal systems, and probe shared services, file stores, ticketing platforms, or finance and HR workflows. If the role has enough trust, the attacker can also pivot through internal messaging and support processes to collect resets, approvals, or additional permissions.
There is a strong parallel to account- and identity-driven compromise patterns seen in real breach cases. NHI Mgmt Group’s 52 NHI Breaches Analysis shows how valid access can be used as a launch point for lateral movement and persistent abuse, even when the original foothold looks routine. The same operational lesson applies here: once trust is issued, the attacker does not need to break in again to keep moving.
In practice, the damage can include data theft, financial fraud, internal sabotage, or support for later compromise of other accounts. A remote employee position is especially useful because it gives the attacker a legitimate communications path, a reason to handle sensitive workflows, and a plausible explanation for why activity is happening outside a physical office.
What organisations should watch before trust becomes persistence
The hard part is that synthetic identity abuse is often a governance failure before it becomes a technical incident. If hiring, identity proofing, device provisioning, and access approval are treated as separate queues, an attacker can pass each step in isolation while still creating a dangerous overall outcome. The control problem is really about consistency across the whole employment lifecycle.
That means teams should pay attention to mismatches that are easy to dismiss individually but meaningful in combination, such as thin or reusable identity evidence, rapid movement from hire to privileged access, unusual remote onboarding patterns, and employee records that are difficult to validate independently. The more the organisation relies on automated trust handoffs, the more important it becomes to verify the evidence behind those handoffs.
For practitioners who want a broader control lens, CISA’s cyber threat advisories help connect identity abuse to the wider fraud and intrusion patterns defenders need to hunt for. For identity-proofing depth, NIST’s Digital Identity Guidelines remain a strong reference for how assurance should be matched to risk, especially when remote onboarding carries real downstream impact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST SP 800-63, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL — Identity Assurance Level | Synthetic identity hiring abuse hinges on the strength of remote identity proofing. |
| AAL — Authenticator Assurance Level | The attacker’s foothold depends on the strength of the remote authenticator used after hire. | |
| Recommendation — Match onboarding proofing strength to the access and impact the remote role will receive. Require phishing-resistant authenticators for remote access that can reach internal systems. | ||
| CIS Controls v8 | 6 — Access Control Management | The issue is unauthorized enterprise access gained through a fraudulent employee identity. |
| 8 — Audit Log Management | Synthetic identity abuse is hard to spot without logging of onboarding, access, and use patterns. | |
| Recommendation — Restrict initial access, review entitlements, and remove unused access paths quickly. Centralize and review logs for onboarding anomalies, remote access, and privilege changes. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | The scenario depends on identity proofing, authentication, and access decisions across the hire lifecycle. |
| DE.CM — Continuous Monitoring | Detecting a hired attacker depends on monitoring behavior after the fake identity is onboarded. | |
| Recommendation — Align identity proofing and access control to the risk of the remote role before granting access. Monitor for anomalous remote onboarding, access drift, and unusual post-hire activity. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | The attacker uses legitimate employee credentials and trust to operate inside the environment. |
| T1566 — Phishing | Synthetic identity campaigns often support credential collection and initial trust-building. | |
| Recommendation — Hunt for valid-account use that does not match expected role, time, or location patterns. Investigate social-engineering paths that helped the attacker acquire or sustain access. | ||
Practitioner Guidance
What to verify: Treat the hiring decision and the access decision as separate risks. Before trusting a remote hire, verify that the identity evidence, device enrollment path, and role-based access request all line up, because a convincing résumé does not reduce identity fraud risk.
Decision rule: If the role can reach internal systems, finance workflows, customer data, or privileged support paths, require stronger proofing and tighter initial access than you would for a low-impact remote user. If the person immediately needs broad access, treat that as an escalation condition, not a normal onboarding shortcut.
What practitioners underestimate: The attacker’s advantage is often patience. The goal is not just to get hired, but to remain believable long enough to turn one approved account into repeatable access, routine trust, and hard-to-detect abuse.
Practitioner takeaway: Synthetic identity attacks succeed when organisations trust the employment story faster than they verify the person, the device, and the access pattern.
Related resources from NHI Mgmt Group
- What do teams get wrong about detecting attacker persistence in cloud identity and access management?
- What are the risks of using static credentials in MCP servers?
- What is the impact of using hard-coded credentials on security?
- Why does identity matter more when vulnerabilities are discovered faster than they can be patched?