Why do phishing and fake identities remain so effective against crypto companies?

Crypto organisations often rely on people who can approve releases, manage keys, or sign transactions, so impersonation can translate directly into financial control. Fake identities work because they exploit trust in onboarding, contractor workflows, and internal communication channels before technical safeguards have a chance to intervene.

Why This Matters for Security Teams

Phishing and fake identities stay effective in crypto because the business model concentrates authority in a small set of people and systems. A convincing impostor does not need broad access; they only need enough trust to trigger a key action, approve a payout, or reset a control path. That makes identity abuse far more valuable than generic malware, especially where operations depend on chat-based approvals, outsourced support, or rapid contractor onboarding.

Current guidance from the NIST Cybersecurity Framework 2.0 still applies, but crypto firms face an added problem: identity decisions often happen faster than verification can keep up. Once an attacker gets into an email thread or messaging channel, technical controls may be bypassed by process trust, not by a software flaw. That pattern is visible in cases such as the JetBrains Marketplace AI Plugin Campaign, where trust in a familiar delivery path became part of the attack surface.

The hardest lesson is that crypto environments often reward speed, so impostors exploit the gap between human confidence and control verification. In practice, many security teams encounter compromise only after a signer, operator, or finance approver has already acted, rather than through intentional identity validation.

How It Works in Practice

Crypto phishing succeeds when attackers combine social engineering with identity lookalikes and workflow knowledge. They do not always need a perfect password steal. They can clone a vendor profile, impersonate a contractor in Slack or email, and exploit onboarding habits that assume a known display name equals a trusted person. Once inside that trust boundary, they aim for high-friction actions: wallet approvals, transaction signing, API token access, or recovery processes.

The operational problem is that many organisations still treat identity as a one-time login event. For crypto companies, that is too static. Stronger practice is to bind access to verified workload or human identity, then re-check context at every sensitive step. That means step-up verification for payment or key operations, separation of duties for release and signing paths, and explicit confirmation for changes to wallet, custody, or admin controls. It also means short-lived, scoped credentials instead of reusable secrets that persist across chats, tickets, and automation. The leaked-secret research in The State of Secrets in AppSec shows how long exposure can linger once secrets or credentials are compromised.

• Use phishing-resistant MFA for privileged actions, not just for general login.
• Require out-of-band validation for onboarding, vendor changes, and payout instructions.
• Separate transaction authorisation from message-based requests.
• Rotate secrets and reduce standing access so a fake identity cannot reuse prior trust.

Where organisations are automating identity checks, current best practice is to verify both the person and the request, not the channel alone. The DeepSeek breach and related exposure patterns show how quickly secrets and trust assumptions can become operational risk once they are visible to attackers. These controls tend to break down when approvals are handled in informal chat threads because the process itself becomes the weakest link.

Common Variations and Edge Cases

Tighter identity controls often increase operational friction, requiring organisations to balance fraud resistance against speed in trading, treasury, and support workflows. That tradeoff is real in crypto, where delays can affect customer service, market activity, or incident response.

There is no universal standard for this yet, but guidance suggests that the highest-risk paths deserve the strongest checks. For example, a support agent resetting access for a retail user is not the same as a finance approver signing an exchange transfer. High-trust functions should get stronger controls than routine internal access. The same is true for contractors and temporary operators, whose identities may be legitimate but still have limited assurance and shorter review cycles.

Teams should also watch for edge cases where identity proofing is strong but session control is weak. A verified contractor can still be tricked into approving a malicious request, and a valid admin can still be impersonated through lookalike domains, spoofed numbers, or compromised collaboration accounts. The practical response is layered: harden onboarding, require verifiable change control, and keep privileged access narrowly time-bound. That approach is especially important in environments with heavy wallet automation or outsourced operations, where a single false identity can reach multiple systems before anyone notices.

Related resources from NHI Mgmt Group

• Why do crypto fraud campaigns remain effective against legacy email security?
• Why do phishing and social engineering remain so effective against Web3 organisations?
• When do non-human identities pose the greatest risk to organizations?
• Why do non-human identities create more risk than many human accounts?