A borrowed identity is an account or persona that an attacker uses to appear legitimate without owning the underlying trust relationship. In this article’s context, it includes impersonated investors, recruiters, vendors, or contractors used to gain access to sensitive crypto workflows.
What Makes a Borrowed Identity Dangerous
A borrowed identity works because it borrows legitimacy, not necessarily access rights. The attacker is exploiting trust in a known persona, such as a recruiter, investor, vendor, or contractor, so the interaction can look routine while the real actor remains unauthorised. That makes the technique especially effective in workflows where trust, speed, and informal verification matter.
The danger is not only impersonation. A borrowed identity can be used to trigger approvals, solicit sensitive information, redirect payments, or gain entry into systems and channels that would resist an obviously unknown actor. In crypto environments, the harm can move quickly from social trust to transaction-level exposure.
How Borrowed Identity Enables Access
Borrowed identity typically sits at the boundary between social engineering and access abuse. The attacker may present as a legitimate external participant in a business process, then use that persona to open a conversation, move it to a trusted channel, or persuade a target to relax scrutiny. The trust relationship is the asset being hijacked.
This differs from simple account takeover. In account takeover, the attacker controls the account itself. In borrowed identity abuse, the attacker may never need to compromise the real owner; instead, they mimic a role or relationship closely enough that the target treats them as legitimate. That is why these attacks often pair with phishing, pretexting, fake domains, cloned profiles, or message thread hijacking.
Where Organisations Become Exposed
Borrowed identity becomes most dangerous in environments with weak verification of who is actually behind a request. If teams rely on display names, familiar signatures, or historical context alone, an impostor can blend into normal workflows. This is especially risky where approvals, fund movement, wallet changes, vendor onboarding, or support requests can be triggered from ordinary communication channels.
Exposure also increases when the organisation has fragmented ownership of external relationships. If no one is clearly responsible for validating investor, recruiter, vendor, or contractor communications, impostors can exploit gaps between business teams, security, and operations. The result is a trust gap, not just a technical gap.
For broader identity and access controls that reduce trust abuse across people, systems, and delegated access, see Identity Security Programme Guide.
Detection, Response, and Identity Recovery
Detection starts with recognising that the warning signal is behavioural, not just technical. Requests that shift channels, increase urgency, ask for exceptions, or seek sensitive workflow changes deserve scrutiny even when the persona looks familiar. In practice, teams should correlate message patterns, account relationships, and request history rather than treating familiarity as proof of legitimacy.
If a borrowed identity is used successfully, the response should focus on containment of the trust path as well as the individual message or account. That means reviewing all communications and approvals associated with the impersonated persona, checking whether any credentials, tokens, session links, or workflow permissions were exposed, and examining whether the impersonation led to additional access or fraudulent action.
Related hardening guidance for identity and access paths is captured in IAM and Identity Provider Buyer's Guide and Top 10 NHI Issues, both of which are useful when borrowed trust later overlaps with account and credential abuse.
Risk and Threat Considerations
Borrowed identity is dangerous because it turns trust into an attack surface. The attacker does not need to defeat technical controls first if they can persuade a target that the request comes from a legitimate relationship. That makes the technique effective for fraud, initial access, and follow-on privilege abuse in sensitive business workflows.
Failure mechanism: The impostor exploits role familiarity, weak caller verification, or trust in an existing relationship to bypass scrutiny and induce an action that would not be granted to an unknown requester.
Impact: The organisation may disclose sensitive information, approve fraudulent activity, alter payment or wallet instructions, or expose downstream systems and accounts to further compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1585 — Establish Accounts | Borrowed identity often relies on fabricated personas used to gain trust. |
| T1656 — Impersonation | The term directly describes an attacker presenting as a trusted person or role. | |
| T1078 — Valid Accounts | Borrowed identities frequently aim to appear as a legitimate account or relationship. | |
| Recommendation — Map impersonated personas to account-creation abuse and hunt for supporting infrastructure or profiles. Validate requests through an independent channel when impersonation is suspected. Review legitimate-looking access paths for abuse and unusual request context. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Borrowed identity abuse succeeds when a trusted persona can trigger excessive access or action. |
| IA-2 — Identification and Authentication (Organizational Users) | The term depends on proving that a requester is who they claim to be. | |
| Recommendation — Limit what any approved role or channel can approve, reveal, or initiate. Require stronger authentication before sensitive approvals or workflow changes. | ||
Practitioner Guidance
Why practitioners should care: Borrowed identity is a control problem as much as a fraud problem. Security teams, finance, procurement, recruiting, and support functions need a shared expectation that familiar-looking requests still require verification when the request is materially sensitive or unusual.
Common misunderstanding: A polished profile, known name, or prior conversation does not prove legitimacy. The safe assumption is not "this person is real", but "this request must be validated through an independent path before action is taken."
Practitioner takeaway: Treat borrowed identity as a trust-validation failure, not just a phishing variant, and design your controls so legitimacy must be proven through a channel the attacker cannot easily copy.
Related resources from NHI Mgmt Group
- Why do AI agents need their own identity instead of borrowed human credentials?
- What is the difference between an agent acting under a borrowed user session and an agent acting under its own identity?
- What is the difference between agent identity and borrowed human access?
- Why do borrowed credentials make AI agents a higher-risk identity class?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org