Even well-protected Salesforce environments face a real identity risk: credential stuffing.
Your environment can get breached not because your defenses failed, but because someone reused their password somewhere else.
Credential stuffing turns someone else’s breach into your Salesforce problem.
Real protection is knowing which credentials are already compromised before attackers use them.
What credential stuffing means inside Salesforce
Credential stuffing is simple. Attackers use stolen username and password pairs from previous data breaches and test them across other platforms, including Salesforce, hoping they still work. They may use bots to make job more efficient.
Because many users reuse passwords, it works more often than anyone admits.
Cloudflare found that 41% of successful logins across web services involved already compromised passwords (Cloudflare).
Even at a 0.1% success rate, testing one million stolen pairs can still yield 1,000 valid logins.
This matters to you if your users, including your partners, log into Salesforce. (Worth reading again.)
Why Salesforce is uniquely at risk
Credential stuffing is dangerous anywhere, but in Salesforce it hits harder because the platform connects people, data, systems and automation.
Internal users
Corporate credentials often overlap with personal ones. A password leaked from a consumer service can still unlock Salesforce.
Even with MFA, attackers use push-bombing or token replay to bypass weak implementations.
Once inside, they can export customer lists, modify records, or plant phishing links inside trusted workflows.
Community users (Salesforce Experience Cloud)
Partners, suppliers, and customers connect through portals built on Salesforce Experience Cloud using Salesforce community user accounts. Their accounts often fall outside corporate Identity and Access Management controls and rely on weak or reused credentials from personal or small-business sites – a habit attackers know and exploit.
Many of these accounts may already be compromised: users can be logging in with credentials that appeared in past breaches, giving attackers a legitimate way in.
A single compromised partner login can expose customer data, initiate fraudulent orders, or abuse OAuth connections to integrated apps.
The recycled credential paradox
Credential reuse isn’t just that people are lazy, but a reality that comes with scale.
People manage dozens of accounts and reuse passwords to remember them. In reality, 44% of employees reuse passwords for both personal and work accounts (Cloudflare).
IBM’s Cost of a Data Breach Report 2025 shows breaches involving stolen or compromised credentials cost USD 4.81 million on average and take 292 days to contain, which is the longest of any vector (IBM).
Reused passwords link personal exposure to corporate systems. One password, used twice, can open your Salesforce org.
Despite identity risks such as credential compromises having been such a longstanding security problem, there are blind spots that have not been mitigated by widely adopted security tools so far.
Salesforce community users present one of such blind spots. The main risks stem from the following:
- Weak password hygiene is the norm for external users: Partner users often don’t follow the same password policies as internal employees.
- Password reuse is even more common in partner portals: Lack of oversight means many reuse passwords from personal or previous accounts.
- High likelihood of credential compromise: External users may be logging into your Salesforce with credentials exposed in past data breaches.
The external users may not care, and they shouldn’t be expected to be responsible of your environments identity security either. As a Salesforce customer, you carry the full risk – whether it be data leakage or financial fraud. A compromised community user account is your problem to solve.
Does MFA stop credential stuffing in Salesforce?
MFA greatly reduces successful credential stuffing but does not remove credential-based risk. Attackers bypass MFA through fatigue, AiTM, token theft, and connected-app/OAuth abuse. To stay protected you need layered controls: phishing-resistant MFA, strict OAuth/token hygiene, behavioral monitoring (e.g. Event Monitoring), and breach-intelligence that finds exposed credentials before the attacker logs in.
Why traditional defenses miss it
Credential stuffing is not random guessing. It is automated logins with leaked, valid credentials. Your defenses must be different to match that.
Credential stuffing is automation with valid credentials.
Attackers use breach lists and bots to try known username/password pairs across sites. Brute-force blockers do not stop valid logins and attackers who already have the password. A successful login might be suspicious.
MFA reduces risk but gaps remain.
MFA blocks many password-only attacks, but push-bombing, social engineering, SIM swap, token theft, and OAuth approvals can bypass weak implementations.
Detection tools rarely see exposure before login.
Most controls act at authentication time and do not ingest breach feeds by default. Without exposure feeds, you often only spot abuse after the attacker is inside.
Failed-login alerts are unreliable.
Credential stuffing can produce little failed-login noise because attackers focus on credentials that are valid. You can’t rely on failed-login alerts alone, because attackers use what already works.
What credential stuffing looks like in Salesforce
Typical signals of credential stuffing on Salesforce include:
- Successful logins from unusual IPs or countries
- Sudden bursts of activity across many accounts
- Quiet data exports or API queries
- Fraudulent actions in Experience Cloud portals (fake orders, edited invoices)
- Abnormal OAuth authorizations or token use
Here’s an example: A partner reused their password from an old forum. Attackers acquired those login details, and logged into the partner portal with them, performed fraudulent actions in critical business processes (think placing fake orders and manipulating ones already there), injected phishing links into business processes, exported files and sensitive data – without triggering login-failure alerts.
Lateral movement in Salesforce: a risk scenario
The Dreamforce keynote put it plainly: attackers no longer treat identity as a single target — they treat it as a route. Once an attacker compromises a partner or community account through credential stuffing, that account becomes a source of reconnaissance and a social-engineering platform. From there the attack moves from identity to identity. The attacker uses what they learn to phish an internal employee, create or abuse OAuth tokens, or install connected apps, where each step widens the “blast radius”. The defensive response must treat every account as a potential pivot point, not only the obvious admin seats.
This is how a lateral movement can spiral in Salesforce:
- Initial foothold: An attacker obtains credentials from a public breach or phishing campaign targeting a partner or contractor (accounts often lack SSO/MFA and reuse passwords).
- Legitimate access: The attacker logs in to Experience Cloud or another Salesforce entry point; an activity that looks “normal” to network/endpoint tools.
- Credential harvesting & reconnaissance: Inside the org the attacker views org metadata, shared files, user lists, connected app configurations, and org roles, which is key information used to tailor follow-up attacks.
- Lateral movement via identity: The attacker crafts targeted phishing or social engineering (internal messages, file attachments, case comments) to compromise an internal user. Alternatively, they create or abuse OAuth tokens / connected apps to persist access beyond a password reset.
- Automation & scale: Malicious actors can abuse Agentforce-style workflows or API automations to execute actions at scale, exfiltrate data, or trigger business-process fraud while blending into routine activity.
- Outcome: Data exfiltration, fraud, or long-term persistent access across cloud systems.
How to defend your Salesforce environment
Stopping credential stuffing isn’t about blocking logins. It’s about seeing risk early and responding fast.
- See credential exposure before attackers do
Monitor your Salesforce user population, from employees and admins to Experience Cloud/community users, against breach-intelligence feeds. Identity Protection in WithSecure Cloud Protection for Salesforce scans user identifiers inside Salesforce and flags exposures so you can prioritize remediation. Note: detection does not automatically disable accounts, but visibility is the first step in response and investigation. - Strengthen access hygiene
Enforce MFA and SSO consistently, retire unused accounts, and require admin approval for connected apps. Limit OAuth scopes, enable refresh-token rotation, and assign a unique, least-privilege integration user to each app. For external/community users, require SSO or force a Salesforce password reset when you detect exposure. These steps reduce the attack surface for credential-reuse and OAuth abuse. - Monitor and respond (correlate telemetry with exposure intelligence)
Feed Event Monitoring and Shield logs into your SOC so you can correlate exposure alerts with post-login behavior (e.g. mass exports, unusual token refreshes, new geographies). When exposure plus suspicious activity appear, you can take appropriate actions such as lock the account, revoke tokens, force a reset, and notify your incident team.
Reality check: exposure visibility is critical but not sufficient alone. Treat credential-exposure scanning as an early-warning signal and combine it with phishing-resistant MFA, OAuth/token hygiene, strict connected-app policies, segmentation, and automated revocation to prevent account takeover.
The edge of your Salesforce environment is identity.
Attackers exploit human behavior. Identity is the edge of your Salesforce environment, and visibility is the baseline of your defenses.
Identity Protection in WithSecure Cloud Protection for Salesforce delivers visibility directly in Salesforce, detecting exposed Salesforce user credentials before attackers use them.
