Why do MFA and SSO not stop Salesforce data theft in social-engineering attacks?

Because the attacker is often not trying to beat the login flow. They are trying to persuade a user or support desk to approve a connector, reset path, or other downstream action that is already trusted by the platform. MFA can authenticate the session and still leave authorisation integrity unprotected.

Why This Matters for Security Teams

MFA and SSO are strong at verifying a login, but Salesforce theft in social-engineering attacks usually happens after the session is already trusted. The attacker is not always cracking passwords; they are persuading users or support staff to approve a connected app, grant OAuth consent, or reset an access path. That shifts the problem from authentication to authorisation integrity, where the platform may happily accept a legitimate action that was manipulated into existence.

This is why defenders should read incidents through an NHI and access-governance lens, not only an identity login lens. The same pattern appears in broader compromise cases documented in the 52 NHI Breaches Analysis and the Ultimate Guide to NHIs — Key Challenges and Risks, where trusted non-human access paths become the real target. Current guidance also aligns with the NIST SP 800-63 Digital Identity Guidelines position that identity proofing and authentication do not by themselves guarantee safe downstream authorization. In practice, many security teams encounter Salesforce abuse only after a legitimate approval path has already been used to export data or mint tokens, rather than through an obvious login failure.

How It Works in Practice

Social-engineering attacks against Salesforce usually exploit the trust chain around the platform, not the password prompt. A user may be tricked into approving a malicious OAuth connector, a help desk agent may be convinced to reset a session or connect a third-party app, or an attacker may persuade an admin to grant a broader permission set than intended. Once the platform sees a valid, user-approved action, MFA has already done its job and cannot stop the misuse.

That is why practical defense has to move toward runtime authorization, tighter app governance, and short-lived credentials. Security teams should treat connected apps, API tokens, and integration identities as NHIs with explicit ownership, scoped permissions, and revocation paths. The NHI lifecycle controls described in the Ultimate Guide to NHIs — Why NHI Security Matters Now become directly relevant here, because the compromise often lands in the token layer rather than the user password layer.

• Require explicit admin approval for high-risk OAuth scopes and connected apps.
• Use least privilege on integrations, especially for export, bulk read, and API access.
• Monitor for new consent grants, token minting, unusual app installs, and permission changes.
• Rotate and revoke secrets quickly when a support interaction or approval is suspicious.
• Correlate user actions with platform events so a benign login does not mask a dangerous downstream grant.

For threat modeling, map the abuse chain against the MITRE ATT&CK Enterprise Matrix and validate high-risk identity workflows against the NIST SP 800-53 Rev 5 Security and Privacy Controls. These controls tend to break down when support processes can override technical safeguards without strong approval logging and step-up verification.

Common Variations and Edge Cases

Tighter OAuth and admin controls often increase operational friction, requiring organisations to balance user productivity against the risk of delegated abuse. That tradeoff is especially visible in Salesforce-heavy environments where business teams depend on fast app approvals, external CRM tools, and delegated support workflows.

There is no universal standard for this yet, but current guidance suggests treating high-risk consent and token issuance as separate from ordinary SSO assurance. MFA may still be valuable for session integrity, yet it does little if the attacker convinces a privileged user to authorize a connector or if an admin workflow silently expands access. The edge case that most teams miss is the help desk: a well-crafted reset or verification request can create the same outcome as a stolen password, even though the login itself was never defeated.

In more mature environments, defenders are adding policy checks for consent, just-in-time access for privileged actions, and stronger review of connected apps. Security operations can also use incident patterns from Salesloft OAuth token breach and the AI-driven threat intelligence in Anthropic — first AI-orchestrated cyber espionage campaign report to understand how persuasion, automation, and delegated trust combine. The hardest cases are environments with weak admin separation and broad third-party integrations, because the attacker can convert one trusted approval into durable data access.

Related resources from NHI Mgmt Group

• Why do MFA and SSO not stop token replay attacks?
• How should security teams govern non-human identities in Salesforce?
• Why do Salesforce integrations increase NHI risk?
• Why is it important to integrate identity and data governance?