Why security comes before everything else
Security should be built into the way your Salesforce platform is managed, not treated as an occasional exercise. As Salesforce becomes increasingly central to customer, commercial and operational data, the risks extend beyond simple user access, covering permissions, data visibility, integrations, connected applications, API access, authentication, configuration changes and the protection of sensitive information. A multi-role approach ensures these areas are considered as part of the ongoing management of the platform, helping identify vulnerabilities early, maintain appropriate controls and reduce the risk of data loss, inappropriate access or disruption to the business.
Salesforce advisories now expect customers to review connected apps, rotate secrets and monitor APIs as routine work. That rarely fits inside a solo Admin week, and it is almost never the thing that gets prioritised when there is a release to ship. So it waits, and the gap widens quietly.
Where security sits in the sequence
Security is pillar one because the other four all widen the surface it protects.
Protect your Salesforce environment
Salesforce asks every customer and ISV partner to review and secure their applications on an ongoing basis.
“Immediately review all applications for signs of malicious activity or vulnerabilities, implement recommended security controls, and rotate secrets or tokens.”
Salesforce
These are vital steps designed to protect Salesforce environments against potential compromise but for many organisations, it’s a lot to take on without dedicated security and DevOps resources.
Salesforce advisories now expect customers to review connected apps, rotate secrets and monitor APIs as routine work. That rarely fits inside a solo Admin week, and it is almost never the thing that gets prioritised when there is a release to ship.
Not sure where you stand? The health check is fifteen questions, about five minutes, and needs no access to your org.
The surface you are defending
Attack methods evolve continuously. The places an org can be reached are more stable, and there are a manageable number of them. A policy organised around those surfaces tends to stay useful as the methods change.
The shape of the risk has changed materially in the last eighteen months, and not in the direction most people expect. The dominant pattern is no longer someone guessing a password. It is abuse of legitimate, authorised third-party connected apps. Attackers have stolen OAuth tokens from software vendors and used them to query Salesforce data across hundreds of customer orgs at once, and have phoned employees to talk them into approving a malicious app.
The organisations caught in that wave included Cloudflare, Zscaler, Palo Alto Networks, CyberArk, Cisco, Tenable and Proofpoint. The breadth of that list is the useful part: these were well-resourced organisations with mature security functions.
For anyone running integrations, the practical implication is that every authorised connected app forms part of the attack surface, and remains so after the person who approved it has moved on. Integration remains worth doing. It benefits from a register of what is connected and a review cadence to match.
The eight surfaces
| Surface | The question to answer |
|---|---|
| Identity and authentication | Is MFA genuinely everywhere, including integration users and admins? Is there step-up authentication on the actions that matter? |
| Connected apps and OAuth | Who approved each one, what scopes does it hold, when was it last reviewed, and who finds out if that vendor is breached? |
| Permissions | Are permissions managed through permission set groups, and is the list of people holding Modify All Data known and current? |
| API and integration users | Are integration users scoped to the objects and fields they need? Broad access granted to a service account persists quietly. |
| Data at rest | Where is the sensitive data, is it classified, is it encrypted, and is anything sitting in a text field that belongs in a secret manager? |
| Export and extraction | Who can pull tens of thousands of records into a spreadsheet? From June 2026 Salesforce requires step-up authentication for large report exports. |
| Configuration change | Who can alter security settings, and would anyone know if they had? |
| Monitoring and response | Is Event Monitoring in place, and would an unusual volume of queries be noticed by a person who would act on it? |
What a security policy has to decide
A policy is not a document you write once. It is a set of standing answers to questions that will definitely come up:
Salesforce Shield adds Platform Encryption, Event Monitoring, Field Audit Trail and Data Detect. It is genuinely useful and it is a real licence cost, so it is worth deciding which of those four you actually need rather than buying the bundle because it sounds thorough.
Nothing above this is safer than the layer under it
Security is the first of the three foundations, and it is the one the other four inherit most directly. Every permission you grant, every connected app you authorise and every integration user you create is quietly borrowed by whatever you build next.
That is why an over-permissioned profile is not a tidiness problem. It is a set of actions that automation, integrations and eventually an AI agent will all be entitled to take on somebody’s behalf.
The Salesforce Security Review
A fixed-price engagement that applies Salesforce’s own security guidance to your org. The price is set by the size and complexity of the estate, agreed before we start, so you know the cost up front whether you are running one org with forty users or several with several thousand.
Ideal for teams without the internal bandwidth to handle this in-house.
Why choose C24
- Trusted Salesforce Partner with deep security and integration expertise
- Certified consultants experienced across CRM, ERP, and API environments
- Proven track record delivering secure, compliant Salesforce solutions for UK organisations
Security never stands still, neither do we.
Salesforce security guidance moves with every release and every advisory. Two recent examples of us working through the detail so our clients do not have to.
The Quiet Expansion of the Salesforce AdminAI isn’t replacing the Salesforce Admin. As the platform accumulated twenty years of capability, the role quietly broadened, reshaping how…Read the article
Salesforce Customers Should Review Certificate Architecture Ahead of June 2026 ChangesRecent Salesforce security guidance has highlighted upcoming changes to Salesforce certificate architecture that may affect organisations…Read the articleSecuring your environment is your responsibility
Salesforce has made its position clear: securing your environment is the customer responsibility, not the platform.
A review is a snapshot. Keeping it true is what a managed service is for, whether or not you have an admin of your own.
Salesforce security: frequently asked questions
The platform itself is among the most secure in the industry. Most real-world risk lives in configuration: over-permissioned profiles, stale connected apps, unrotated secrets and unmonitored APIs. That is what a security review addresses.
A structured audit of your org configuration, apps, integrations and access model against Salesforce security best practice, producing a prioritised report of risks and fixes.
A deep review annually, a lighter check quarterly, and immediately after any major Salesforce advisory or a change in your integration landscape.
Yes, as a separately agreed work package. The review ends with a prioritised remediation plan, and the fixes are then scoped and quoted against it, so you approve the cost before any work begins. Most clients ask us to carry it out. The plan is written to be handed over, so your own team can take the work on, and we will brief them.
Any org where Salesforce holds data you would not want to lose or leak, and especially orgs where one admin carries security alongside everything else.
Yes. Security management is included in every managed service plan: connected app review, token rotation, permission hygiene and monitoring, run continuously rather than as an annual event. That works whether you have an internal admin or none at all.