10 Salesforce Security Tips Architects Need to Know in 2026

The OAuth tokens stolen from Salesloft Drift last August are still being used to breach organizations today. The Grubhub breach recently announced proves the pattern: attackers harvested credentials during the summer 2025 campaign and used them five months later to access Salesforce and Zendesk data. ShinyHunters is now demanding ransom for records stolen across multiple intrusions. Supply chain compromises don’t end when the headlines fade.

According to the IBM 2025 Cost of a Data Breach Report, 97% of organizations that experienced an AI-related security breach lacked proper AI access controls, and 63% of breached organizations had no AI governance policies in place. The gap between AI adoption and security oversight already exists, and threat actors are exploiting it.

For Salesforce Architects, the architectural decisions made today determine whether organizations become tomorrow’s headlines. We’ve unpacked 10 insights from industry experts featured on our Salesforce Security Office Hours that you will want to read and what the experts featured on want you to know.

Tip 1: Architect for Blast Radius, Not Convenience

The pattern across every major Salesforce ecosystem breach in the past 18 months is the same: a single compromised integration exposed far more than it should have.

When Salesloft Drift was breached, attackers didn’t just access Salesloft data. Attackers harvested OAuth tokens that provided pre-authenticated access into hundreds of Salesforce orgs. One vendor compromise cascaded into what Google Threat Intelligence estimated at 1.5 billion records across 700+ companies.

The architectural failure wasn’t the breach itself. The failure was the decision to connect multiple systems through shared integration users with broad permissions. When one vendor was compromised, the blast radius expanded to include every system that shared those credentials.

This is why isolation matters. Dedicated integration users per vendor, scoped to minimum necessary permissions, with IP restrictions tied to known vendor infrastructure. As Adam Olshansky, Senior Salesforce Technical Architect at Google Play, put it during his Security Office Hours session: “Use the principle of least access when it comes not only for users and setting up your security model, but for connected apps and integrations as well. One integration user per vendor limits your blast radius when breaches occur.”

The Salesforce Well-Architected Framework emphasizes this through the Trusted pillar, which focuses on security, compliance, and reliability as foundational requirements for any solution. The difference between containing an incident and explaining to the CISO why a single breach exposed the entire customer database comes down to how integrations are architected.

For a deeper dive into integration user security, watch the session on Architecting Trusted Salesforce Solutions.

Tip 2: Understand That Detection Takes 204 Days Without Proper Monitoring

The average organization takes 204 days to detect a breach. Add another 70 days to contain it. That’s nearly nine months of attackers inside the environment, mapping systems, escalating privileges, and exfiltrating data before anyone notices. Matt Myers, Salesforce CTA and CEO/CoFounder of EzProtect, frames it bluntly: “Why people have breaches that go on for 204 days. People are in your house, walking around, you don’t even know they’re there for 204 days.”

In Salesforce environments, this translates to complete data extraction. Attackers don’t browse leisurely. Attackers systematically export data through mass SOQL queries, access records through API calls that never appear in standard reports, and establish persistence through additional OAuth connections and scheduled jobs.

Event monitoring isn’t optional. Salesforce Shield provides real-time visibility into API usage, login patterns, record access, and anomalous behavior. Without it, detection depends on manual review of setup audit logs and connected app usage screens, a process that rarely catches sophisticated attacks in time. Learn more about Shield capabilities in the Event Monitoring Trailhead module.

Learn more about breach detection and response in the session covering the Threat Response Lifecycle for Salesforce Administrators.

Tip 3: Make a Plan to Migrate to External Client Apps Now

Salesforce is pushing organizations toward External Client Apps because Connected Apps have a fundamental architectural problem: Connected Apps are globally available by default. An app defined in one org can authenticate into another without installation. External Client Apps close that gap with a default-secure architecture that requires installation before use.

This isn’t a settings change. External Client Apps introduce a fundamentally different authorization model with tighter scoping, improved token lifecycle management, and clearer separation between first-party and third-party integrations. Organizations treating this as lift-and-shift will miss the security benefits and potentially break production integrations.

The September 2025 Connected App restrictions made the direction clear. Samarth, Senior Software Engineer at PayPal, doesn’t mince words: “Migrate to External Client Apps. Don’t wait for forced migration. Salesforce is no longer adding features to Connected Apps. You’re missing out on security advancements by not migrating.” Architects still designing with Connected Apps are building on infrastructure that’s already being deprecated.

For a complete walkthrough of OAuth flows and External Client Apps, watch What You Need to Know About Salesforce’s External Client Apps to Enhance Security.

Tip 4: AI Amplifies Existing Governance Gaps

If the Salesforce environment has governance gaps, AI agents will find them faster than any human attacker could. This isn’t a future problem. AI-related breaches are already happening, and the pattern is consistent: the AI didn’t create the vulnerability. The AI exposed what was already broken.

Consider an AI case summary agent with inherited access from an over-permissioned integration user. The agent isn’t misbehaving when it reads internal escalation notes and confidential comments. The agent is doing exactly what permissions allow. The exposure happens because the architecture was never designed to restrict it. Srinivas Sandiri, Technology Leader and Salesforce Security Architect, captures this dynamic perfectly: “AI is not bringing any new risk to your architecture. It just amplifies whatever architecture you already have. Treat AI like an untrusted user with a very basic, specific job.”

Years of cloned profiles, accumulated permissions, and integrations scoped broader than necessary create massive exposure that’s difficult to audit. AI agents operating at scale will find every gap in the permission model. Salesforce Agentforce brings autonomous AI capabilities to the platform, making proper permission architecture more critical than ever.

Watch the full session on Zero-Trust Architecture for Salesforce in the AI Era.

Tip 5: Bridge the Gap Between Security Teams and Salesforce Teams

Most organizations have experienced security professionals who don’t understand how Salesforce operates and can’t speak the language of Salesforce teams. Meanwhile, Salesforce teams know some security but lack the depth of experience a dedicated security professional brings. This disconnect creates blind spots that attackers exploit.

Beech Horn, Technology Engagement Manager and Architect at Banham Patent Locks Ltd, describes the challenge: “You have experienced security teams who do not understand the way Salesforce operates, who cannot speak the language of those teams. Meanwhile, you have teams experienced with those products who typically know some security, but do not have the wealth of experience a security professional may have.”

The root cause of most Salesforce breaches isn’t technical. The root cause is organizational. 99% of Salesforce projects lack dedicated security roles. Organizations discover breaches through extortion emails, realize proper auditing was never configured, and still don’t hire for the expertise needed. Security teams need to learn Salesforce-specific concepts like sharing rules, permission sets, and connected app authorization. Salesforce teams need to understand security frameworks like NIST Incident Response. Neither team can protect the organization alone.

For strategies on building domain expertise across teams, watch How Security Teams Can Master Salesforce Domain Expertise.

Tip 6: Code Readability Is Security Readability

Vibe coding is already happening in Salesforce orgs. Agentforce Vibes turns natural language into production-ready Apex, flows, and integrations. Whether sanctioned or not, teams are using AI to generate code. The same principles that make AI effective at generating code also determine whether that code is secure.

The insight that changes how architects think about this: code that’s readable for the AI coding partner is also auditable for the security team. If Agentforce can’t understand the architecture, neither can the people protecting it.

Token efficiency isn’t just about cost. Bloated context windows create blind spots where vulnerabilities hide. Low-token guardrails get followed while verbose policies get hallucinated around. AI remembers fragments, not intent. Concise security guides embedded in the workflow beat scattered policies every time.

The teams shipping AI-generated code safely aren’t reviewing every line manually. Those teams built DevOps foundations where source control, code review, and deployment gates catch mistakes before production, whether mistakes come from humans or AI.

Tip 7: Shift Security Left in the Pipeline

Security can’t be a gate at the end of the deployment pipeline. By the time code reaches production review, the cost of fixing vulnerabilities has multiplied. The teams that catch issues early spend less time in emergency remediation later.

Secret scanning, credential management, and just-in-time access for service accounts aren’t optional extras. One leaked credential and one over-privileged service account can put the entire Salesforce org at risk. Mala Punyani, Director of Engineering at DocuSign, advises teams to “start with credential security. It delivers quick wins before you tackle the harder problem of legacy code scanning. Continuous auditing matters more than one-time guardrails.”

Enterprise organizations that have solved this problem didn’t add more tools. Those organizations integrated security into existing workflows so security happens automatically rather than as an afterthought. The shift-left approach builds security champions within development teams so security expertise is distributed rather than bottlenecked.

Watch the full session on Shift Left Security for Salesforce Teams.

Tip 8: Build Certification Depth Beyond Salesforce Credentials

Salesforce certifications alone aren’t enough anymore. AI is changing the shape of risk inside the platforms Salesforce professionals already know, and the margin for error is shrinking. Traditional admin and architect certifications don’t cover AI governance or enterprise security fundamentals.

Credentials like CISSP, ISO 42001, IAPP AIGP, and DASA Agentic AI Enterprise Strategist complement Salesforce expertise by building judgment for situations where there’s no clear right answer. Security certifications teach how to make decisions when choosing between imperfect options, not memorizing tools.

Blanca Leon-Carter, MBA, Founder and Chief AI Officer at LeonAI Labs, summarizes the shift: “AI did not create new governance problems. It exposed the ones that were already there.” Agentic systems amplify whatever discipline already exists in the organization. Strong governance accelerates value. Weak governance accelerates failure. Responsible AI must be explainable, constrainable, auditable, and stoppable.

Watch the full session on Security Certifications for Salesforce Professionals in 2026.

Tip 9: Plan for Recovery Before the Breach Happens

Every organization will experience a security incident. The question isn’t if but when. The organizations that recover quickly are the ones that planned the recovery before the breach happened.

OAuth token inventory and revocation procedures matter because when Salesforce revokes tokens at 7:57 PM on a Tuesday, the team needs to know what broke and how to respond by morning. Incident response playbooks with pre-defined communication protocols matter because scrambling to figure out who to notify while attackers are still in the org is how small breaches become PR disasters.

Backup and restoration procedures must account for changed record IDs. When records are restored from backup, record IDs change, breaking every integration that references them. What looks like a simple restore becomes weeks of emergency re-mapping across SAP, ERP systems, and data warehouses. Some companies take six months or longer just to recover from a breach, and cleanup itself can be almost as costly as the actual breach.

For a complete breach response framework, watch From Prevention to Recovery: Your Complete Salesforce Data Breach Response Plan.

Tip 10: Enable IP Restrictions on Every Request

Most organizations configure IP restrictions on login but miss a critical setting: enforcing IP restrictions on every request, not just the initial authentication. OAuth connections are established sessions. IP ranges won’t block attackers who’ve already authenticated unless the system is checking every connection.

The session settings checkbox that enables this behavior is easy to miss. But the difference is significant. Without it, an attacker who obtains a valid session token can access the org from any IP address. With it, even valid tokens are rejected when requests come from unexpected locations.

Connected app IP restrictions have an additional caveat: Connected app IP restrictions only check on initial connection, not ongoing requests. For stronger protection, configure IP ranges at the profile level for integration users, and create dedicated profiles per external vendor with vendor-specific IPs.

For more on connected app security requirements, watch A Complete Guide to New Salesforce Connected Apps Security Requirements.

Quick Reference: 10 Architectural Decisions That Matter

We also know that you may not have time to dive into each specific tip and video. So we created a quick cheat sheet for you busy Salesforce Architects, reading skimmers, and/or those that want to turn this into an action plan for your teams. 

1. Rotate tokens immediately when any connected vendor discloses a breach—stolen tokens become breaches months later.
2. Zero Trust means internal controls, not just perimeter authentication. OWDs, sharing rules, and permission set groups protect the data.
3. Migrate to [External Client Apps](https://trailhead.salesforce.com/content/learn/projects/build-integrations-with-external-client-apps/create-and-configure-an-external-client-app) now. Connected Apps remain globally available by default.
4. One integration user per vendor limits blast radius and makes incident response possible.
5. Design permission models assuming AI will eventually use them.
6. Admin-approve connected apps. User self-authorization creates shadow admin scenarios.
7. Build security certifications beyond Salesforce credentials.
8. Plan recovery before the breach—record ID changes during restoration break integrations for months.
9. Enable IP restrictions on every request, not just login.
10. Bridge the gap between security teams and Salesforce teams. Neither can protect the organization alone.

We hope that you enjoyed this article and that you begin to put these Salesforce security practices into practice immediately. You and your future teams will thank you for it. 

Join Us for Salesforce Security Office Hours

Every session referenced in this article came from this live community series hosted by Matt Myers, Salesforce CTA and CEO/CoFounder of EzProtect and industry experts from Google, PayPal, DocuSign, and across the ecosystem with live Q&A. Bring your burning questions and we will see you online.