Notifications
Clear all
Topic starter
24/06/2026 9:23 pm
TL;DR: Salesforce’s expanding mix of users, integrations, APIs, and automated workflows is widening the attack surface while secrets sprawl, over-privilege, and weak auditability make authorization harder to govern, according to Entro Security. The core issue is not just access volume but the assumption that quarterly reviews and static permissions can keep pace with fast-moving non-human identities.
NHIMG editorial — based on content published by Entro Security: Salesforce Security Challenges, Authorization, and Access Management
Questions worth separating out
Q: What breaks when Salesforce integrations rely on broad service account access?
A: Broad service account access breaks containment.
Q: Why do Salesforce environments make secrets management harder than many other SaaS platforms?
A: Salesforce environments spread credentials across code, metadata, external systems, and automation chains, which makes inventory and rotation difficult.
Q: How do security teams know whether Salesforce access reviews are actually working?
A: Access reviews are working only if they remove stale privileges before they become usable in production.
Practitioner guidance
- Consolidate Salesforce credential ownership Assign every API key, token, and certificate to a named owner and a single authoritative source of truth.
- Break broad integration accounts into narrow principals Create separate service accounts or OAuth clients for each integration and scope them to the minimum objects, fields, and records they require.
- Replace calendar-based reviews with change-triggered governance Trigger recertification when a role changes, an integration is added, a scope expands, or a credential is rotated.
What's in the full article
Entro Security's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance on OAuth 2.0 and JWT flows for Salesforce integrations.
- Practical examples of rotating service-account credentials across connected apps and automation tools.
- Implementation detail for field-level security, record-level security, and Salesforce Shield usage.
- Monitoring patterns for Event Monitoring dashboards and anomaly detection across API activity.
👉 Read Entro Security's analysis of Salesforce authorization and access management →
Salesforce security: what IAM teams need to tighten now?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 6:35 am
Salesforce security is really a non-human identity governance problem with human spillover. The article is clear that APIs, service accounts, and automated workflows now sit beside users in the same trust boundary. That means IAM teams cannot treat Salesforce as a pure SaaS access problem, because authorization failures increasingly begin with NHIs that are over-scoped, under-monitored, and hard to retire cleanly. The practitioner conclusion is that Salesforce governance has to be designed around principal type, not just application tier.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed, 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to the same report.
A question worth separating out:
Q: Who is accountable when a Salesforce integration is over-privileged and causes data exposure?
A: Accountability should sit with the business owner of the integration, the identity team that approved the scope, and the platform team that failed to constrain it. Shared responsibility does not mean shared ambiguity. Every high-risk integration needs a clear owner, an expiry or review trigger, and an auditable approval chain.
👉 Read our full editorial: Salesforce security and access management are under strain
