Borrowed Identity

Expanded Definition

A borrowed identity is a persona an attacker uses to inherit trust, not to prove it. In NHI security, the attacker does not need to steal the underlying account immediately; they may log in through a compromised recruiter profile, reuse a vendor’s session, or operate from a contractor identity that already carries access. That makes the activity look legitimate to systems, humans, and sometimes even logging pipelines.

The term sits alongside impersonation, account takeover, and credential abuse, but it is narrower in one important way: the borrowed identity is valuable because the trust relationship already exists. In crypto and adjacent high-value workflows, this often means the identity has access to private channels, onboarding paths, wallet operations, or privileged coordination steps. Guidance varies across vendors on whether a borrowed identity should be treated as a type of compromised account, a social engineering outcome, or an authorization failure, but in practice it is all three.

For background on how NHIs become a systemic trust problem, see the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0 for the governance lens around identity risk. The most common misapplication is treating a borrowed identity as simple credential theft, which occurs when defenders focus on the login event and ignore the trust channel that made the account believable.

Examples and Use Cases

Implementing detection and response for borrowed identity scenarios often introduces friction, because stronger verification can slow down legitimate partner, recruiter, or investor interactions and create more manual review.

• A fraudster uses a compromised recruiter account to request private candidate or project information, relying on the company’s normal trust in hiring communications.
• An attacker borrows a vendor identity to move through procurement or support workflows and ask for wallet-related changes that would be suspicious from an unknown sender.
• A spoofed investor persona joins a deal room or messaging thread, then presses for sensitive documents, seed phrases, or off-platform movement into crypto custody workflows.
• A contractor identity is reused after access should have been revoked, allowing the attacker to blend in with expected project chatter and access paths.

NHIMG’s 52 NHI Breaches Analysis shows how often trust-heavy identities become entry points, and the pattern is reinforced in the Top 10 NHI Issues. For a broader control context, the NIST Cybersecurity Framework 2.0 supports identity verification, access governance, and response discipline.

Why It Matters in NHI Security

Borrowed identity matters because the security failure is not always the account itself. It is the trust that surrounds the account, including expectations about who can ask for what, which channels are legitimate, and which transactions should bypass friction. Once a borrowed identity is accepted, attackers can use it to chain social engineering with NHI abuse, move laterally through business workflows, and trigger actions that appear authorised.

This is especially dangerous in environments where third parties, contractors, and temporary collaborators already have broad access. NHIMG research shows that 92% of organisations expose NHIs to third parties, which expands the attack surface for identity borrowing and trust abuse. When defenders miss this pattern, they often chase the wrong signal, such as a suspicious IP or a reused token, while the real issue is a legitimate persona being used for illegitimate intent.

Organisations typically encounter the consequence only after a trusted account is used to approve, request, or exfiltrate sensitive access, at which point borrowed identity becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Identity Blast Radius
• What is a Non-Human Identity (NHI)?
• What is the difference between NHI and machine identity?
• What is the difference between an identity, a credential, and a secret?