Roughly 90% of the Fortune 500 runs at least one Salesforce product, and for most of them it holds the customer record the entire commercial operation depends on. That concentration is not a secret. Attackers have read the same statistic you have.
What still surprises me is how few security executives can answer one question about it. When a stranger uploads a file to your Experience Cloud portal, what happens to that file, and who owns it if it turns out to be malicious? The question sounds small. It is not. It is an open path into your system of record, and I ask it in nearly every review I run. The room is usually deep in agent permission scoping and AI governance frameworks, and nobody has an answer.
I have spent more than nineteen years architecting and securing Salesforce as a Certified Technical Architect, and I wrote a book on securing its digital experiences. That gap is the most consistent finding of my career when it comes to cybersecurity teams.
The real vulnerability is brand trust bias
I have been arguing this for years, because the pattern repeats with every release. When a major platform ships a security feature, teams adopt the assumption far faster than they read the documentation. Salesforce shipped backup, and teams stopped thinking about backup. Salesforce shipped malware scanning, and teams stopped thinking about malware. The features are real. The assumption is what gets you.
Arctic Wolf put a number on that reflex. In a survey of 1,350 IT and security leaders, 63% had suffered a significant cybersecurity incident in the prior twelve months, and 96% still reported confidence that their teams were keeping pace with the threat landscape. Confidence is not coverage. It only takes one malicious file to find out which one you have, and 63% of those leaders already did.
The Coca-Cola breach had a detail nobody wrote about
In May 2025, a threat group listed the Salesforce database of Coca-Cola Europacific Partners for sale, claiming more than 23 million records across roughly 64 gigabytes. Every story led with the number. The real nailbiter is the date, because some of those records went back to 2016. Nine years of customer data sat in one environment, and the attacker needed no vulnerability and no payload to reach it.
Salesforce told reporters its platform had not been compromised and no known vulnerability was involved. That was true, and it is the most alarming sentence anyone published that week. It also got almost no coverage, because "nothing was broken" is a harder story to write than "23 million records."
What Summer '26 scanning covers, and where it stops
Salesforce made malware scanning for Salesforce Files generally available in Summer '26. It is a real improvement over nothing, and Salesforce documented the limits honestly. Almost nobody has read them, so here they are.
Per Salesforce Help, files are scanned only when they are 100 MB or smaller. Above that, Salesforce does not scan the file and does not block anyone from uploading, previewing, or downloading it. Scanning flags files only when they have a high probability of being malicious, and Salesforce explicitly tells organizations needing more stringent detection to consider a malware scanning partner. That is Salesforce's recommendation, not mine. Uploads through the API are permitted and scanned afterward, so a malicious file can be sitting in your org before any verdict exists. Notifications to your admins are off by default.
Then there is the line that should stop a CISO cold. For any file that was already in your org before scanning was turned on, Salesforce documents that the first download is allowed to proceed, and scanning happens after. Only future download attempts get blocked. Read that as an operator: the file reaches somebody's laptop, and then you find out.
That matters because of what a single file costs. In initial scans of customer environments we routinely find active threats that previous tooling waved through, in one case 298 of them in a single org. Any one of them was enough. IBM's 2026 Cost of a Data Breach Report puts the average United States breach at $11.5 million, with detection, escalation, and lost business driving most of a 12% global rise to a record $4.99 million. An unscanned backlog is a portfolio of files nobody has evaluated, and the downside on any single one runs eight figures.
The scanner reads files, and the attacks stopped being files
Native scanning also does not inspect URLs. Not in a case description, not in a custom field, not anywhere. That would be a footnote if attacks still arrived as attachments.
They do not. Microsoft's Q1 2026 email threat analysis found credential phishing climbed to 94% of all payload-based attacks by March, while traditional malware delivery fell to 5 to 6% of payloads. IBM puts phishing as the most common initial attack vector for the fourth consecutive year, in 17% of breaches, carrying the highest average cost of any vector it tracks. When my team analyzed Microsoft's year-long study of more than 1,000 breached Salesforce environments, the adjacent vector Microsoft pointed at was exactly this: malicious links and files arriving inside Salesforce, in case comments and portal submissions email security never sees. The control Salesforce shipped covers the category that is shrinking, while the category that is growing and costing the most enters your org as text in a field no file scanner will open.
Attackers get to rehearse against the scanner you run
Here is the part that should permanently change how executives think about a free platform control, and it has nothing to do with detection rates.
Every other control in your stack is yours. Your endpoint agent is tuned to your environment, versioned on your schedule, configured by your team. An attacker has to guess at it. The Salesforce native scanner is the opposite. It is free, on by default, and identical in every Salesforce org on earth. There is no threshold to raise, no engine to swap, no sensitivity to tune. It is a checkbox, and you and your competitor and the agency down the street are all running the same one.
That turns reconnaissance into a solved problem. An attacker signs up for a free developer org in minutes, enables the same scanner you enabled, and runs files against it until one clears. The testing happens entirely inside infrastructure they control. It generates no traffic to your org, no failed uploads in your logs, nothing for anyone to notice. There is no cost to being wrong and no risk in trying again. By the time anything touches your environment, the file has already been proven to work.
Because the configuration is universal, one successful test is a universal result. A file built to clear those published limits clears them in every org running native scanning alone. The limits are documented, so the target is documented. A free, homogeneous, undisclosed detection layer is a poor place to make your last stand, and nothing announced for Winter '27 changes the scanning ceiling, the detection threshold, or the API upload path.
We ran that rehearsal ourselves, twice, and published both attempts. The first time, Salesforce missed a live trojan I uploaded. When I repeated the test after general availability, that same trojan came back blocked, so somewhere along the way I contributed to somebody's training data. I found a lesser-known virus in five minutes, an executable carrying a .png extension, and Salesforce accepted the upload and then served me the download. The disguise was not what did it. Their scanner flags high-probability threats, and that virus was not on the list. Our scanner flagged it and held it. There was no zero day, and no nation state involved. There was a free developer org and five minutes.
Watch that side by side rather than taking my word for it, then run the same test in your own sandbox. It costs an afternoon and tells you more than any vendor claim, including mine.
What to put in front of your teams right away
Inventory every path that deposits a file or a URL into your org, including Experience Cloud, Email-to-Case, and API integrations, and give each path an owner. Compare your file size distribution against the 100 MB ceiling. Confirm malicious file notifications are switched on, because they are not by default. Treat every file predating enablement as unscanned inventory and plan a deliberate pass over it rather than letting a user's first download find out for you. Test your configuration in a sandbox against a known sample, because a control nobody has tested is a rumor with a settings page. Extend whatever you do for files to the fields holding links. Then decide, on the record, whether high-probability detection is the right threshold for the data your org holds.
The bill for getting this wrong does not stop at the incident. Our research after the Allianz Life breach, where attackers used social engineering against a Salesforce environment to reach data on roughly 1.1 million people, found that 43% of affected customers went looking at alternatives and 15% said they would not come back. Regulators eventually stop asking. Customers do not.
I have made educating this ecosystem my life's work, and this is the gap I keep coming back to. The Coca-Cola listing was never really about 23 million records. It was about how much data a Salesforce org quietly accumulates, how little of it anyone has examined, and how ordinary the access needed to take it turns out to be. AI is changing how fast attackers work, and that deserves your attention. It has not changed the fact that the most dependable way into an enterprise Salesforce org is something nobody checked.
I host Salesforce Security Office Hours, a free live session that puts the ecosystem's hardest security questions in front of leading Salesforce security practitioners. Join the next one, or catch up on past sessions.
