A company can issue the right laptop, require multifactor authentication and still give access to someone it never intended to hire. The gap is between the identity on the employment record and the person operating the device.
Remote hiring fraud turns recruitment into an access problem. A developer account may reach source code, cloud services, internal conversations and customer records before anyone notices that the person doing the work is different from the candidate who was interviewed.
A background check examines information about an identity. Authentication checks the credentials presented to a system. Neither, on its own, establishes that the same individual passed the interview, received the laptop and is using it today. That distinction should shape onboarding, access reviews and incident response.
What the October FBI alert establishes
The FBI’s October 13, 2026 advisory describes North Korean IT workers using stolen identities and paid facilitators to obtain remote jobs. Helpers may attend interviews, supply established professional accounts or host company laptops for remote operation. These hosting arrangements are often called laptop farms. Some jobs are subcontracted. The agency also reports theft of corporate information, extortion and threats after termination. [1]
The alert identifies unapproved remote control, hardware access, unexplained software and repeated identifier changes as signals to assess together. It warns that individual indicators overlap with legitimate employment and calls for coordinated review across HR, IT, security and management.
One employment record can hide several operators
Consider a company that hires a developer and ships a managed laptop to an approved address. Someone else remotely operates that machine. The employer may see an enrolled device and a valid session even though the operator was never approved. A delivery receipt and a successful login answer different questions from identity verification.
The account stays the same. The operator may not.
Remote control or unapproved delegation can separate the person doing the work from the identity attached to the account.
Would this session be able to export customer data or create another credential without a separate approval?
Completing assigned work does not settle the question. A person can produce useful code while retaining unnecessary access, sharing credentials or delegating work without approval. Conversely, an unusual work schedule or a software installation is not proof of deception. The investigation needs evidence of the account’s use and a fair process for resolving discrepancies.
Verify the person without treating every difference as fraud
NIST’s identity proofing guidance separates validating evidence from establishing that the applicant is its rightful owner. It also calls for privacy protections and ways to handle legitimate exceptions. This is a useful design reference for a hiring process, not a claim that every employer must implement a federal identity assurance program. [2]
A camera check can contribute evidence, but it is not a complete verification method. A substitute can join a call. Documents can be altered. Use an appropriate proofing process and confirm employment references through independently obtained contact details. Keep a clear route for candidates to explain mismatches or provide alternative evidence.
Carry the result into onboarding. Document who approved the hire, the agreed work location, who may handle the laptop and how delivery changes are verified. A late address change should trigger a check through an established contact channel, not an automatic rejection.
Collect only the personal information needed for the process. Restrict access to identity documents and set retention limits. Hiring controls should not turn a personnel file into an unnecessary collection of sensitive records.
Give each team a question it can answer
A joint review works better when teams know what to bring. Use the employee account and device identifier to connect relevant evidence. Keep raw identity documents within the team responsible for handling them.
Does the record hold together?
Compare the approved identity, references and verified changes. Record unresolved discrepancies and the explanation provided.
Who can operate this device?
Review remote support exceptions, software inventory and device handling. Endpoint telemetry may not reveal every external hardware control path.
What can this account reach?
Trace repository access, data exports, new tokens and privileged sessions. Compare activity with the assigned work.
Is delegation authorized?
Confirm who performs the work and which contractors are approved. A missed meeting or a time zone difference needs context.
For example, an unexplained remote support tool, a disputed delivery address and a request for broad production access warrant a coordinated review. A developer using Homebrew for an approved build process does not. Write down both the reason for escalation and the evidence that could resolve it.
Limit what a fraudulent account could do
Identity checks reduce uncertainty about the person. Authorization limits the consequences when those checks fail. NIST’s zero trust architecture makes the corresponding technical distinction: network location or device ownership should not confer implicit trust, and access decisions concern specific resources. [3]
- Start with the assigned task. Define which repositories and environments a new hire needs. Give development accounts test data. Require an explicit decision before granting production access.
- Separate high impact actions. A code contribution should not automatically carry permission to export customer records, change payroll details or create privileged credentials. Identify the approver for each operation.
- Make remote support an owned exception. Maintain an approved tool list, an accountable support team and records of sessions where available. Alert on deviations without assuming that every remote connection is malicious.
- Look beyond the central login. Inventory personal access tokens, SSH keys, cloud credentials, application sessions and integrations the account can create. Disabling SSO may leave some of them usable.
- Review privilege changes. Before expanding access, resolve outstanding identity or device concerns through the same documented process. Avoid informal exceptions made solely because a project is urgent.
These controls do not prove who is typing. They reduce the amount of authority that an incorrectly approved person can exercise and improve the evidence available when something goes wrong.
A practical test for startups and larger teams
Use a designated test account with the same permissions as a typical new developer. Work in an agreed test environment and use synthetic records. Do not probe an employee’s private accounts or move real customer data to demonstrate a weakness.
How far does one ordinary account get?
- Read
- Can it open unrelated repositories or production customer records?
- Delegate
- Can it create a token or invite another account with broader access?
- Export
- Can it download a large dataset without approval or useful audit evidence?
- Retain
- After revocation, do sessions and derived credentials still work?
For a startup, begin with the code host, identity provider and production cloud account. Assign one person to resolve each unexpected permission. A larger company should repeat the exercise across subsidiaries, contractor portals and applications outside central SSO. The deliverable is a list of access paths, responsible owners and verified fixes.
Measure whether the team detects an agreed test export and how long complete revocation takes. Record which credential remained valid and why. A policy stating that access ends immediately is less useful than evidence that the applications enforce it.
Plan the response before confronting a suspected impostor
When evidence suggests unauthorized operation, involve security, HR and the responsible manager. Preserve relevant logs and device evidence, assess immediate exposure and agree the timing of containment. Coordinate employment decisions and communications with the appropriate advisers. For a suspected active compromise, agree urgent access restrictions with the incident lead. For a planned departure, coordinate revocation with the offboarding schedule.
Check the full access inventory, including tokens, recovery methods and delegated accounts. Record what was revoked, what remains under investigation and who owns the next action. Establish a safe channel for staff receiving threats and avoid asking individual managers to negotiate payments.
The FBI directs affected organizations to its field offices and IC3. Report through IC3 where applicable. Elsewhere, identify the relevant local reporting channel as part of the incident plan. Keep evidence available to the responders handling the case.
What this means for companies hiring across Latin America
A company hiring across countries needs a consistent process for employees, agencies and independent contractors. Clarify who is authorized to do the work, where company equipment will be used and whether subcontracting is permitted. Review exceptions with the same care as the original hire.
The FBI advisory does not establish a prevalence rate for Latin America. The regional relevance here is our assessment of a shared hiring model, not a claim that a particular country or workforce is suspect. Nationality, accent and location alone are not evidence of fraudulent intent.
For professionals, requests to lend an identity, attend another person’s interview or host unexplained company equipment should prompt careful verification through an independent channel. A legitimate support or subcontracting arrangement should be disclosed to the employer and have an identifiable owner.
The useful connection to AI agent governance
A human impostor and a compromised AI workflow are different problems. The shared design question is narrower: what may a valid credential do when the system cannot safely assume the intent of its operator?
For agents, define the owner, permitted tools and task scope. Require approval for consequential changes and retain action records. Human identity proofing remains a separate responsibility. Our AI agent governance work addresses delegated authority, while a scoped assessment can examine the application permissions and access paths involved.
If your teams need to work through the process together, training can use a hiring scenario to connect the decisions made by HR, IT and engineering. Agree the audience and scope before selecting exercises.
Sources and scope
Reviewed October 14, 2026. The advisory summary describes the FBI’s findings. The diagram, team questions and test plan are Oktsec’s analysis.
- FBI IC3: North Korean IT Workers Expanding Use of Facilitators, Broadening Recruitment, October 13, 2026. Alert I-101326-PSA.
- NIST SP 800-63A-4: Digital Identity Guidelines, Identity Proofing and Enrollment, 2025.
- NIST SP 800-207: Zero Trust Architecture, August 2020.