NHI Forum
Read full article here: https://www.token.security/blog/salesforce-connected-apps-navigating-nhi-security-risks-and-best-practices/?utm_source=nhimg
Salesforce is a crown jewel application for many enterprises. It holds customer records, revenue pipelines, contracts, and sensitive business data — the kind of information attackers dream about. And yet, Salesforce security often falls into a no-man’s land:
- IT assumes the business owns it.
- Security teams assume Salesforce admins own it.
- Business units assume Ops will take care of it.
The result? Ambiguity, shadow integrations, and permission sprawl.
What makes Salesforce especially tricky is its identity model. Unlike many enterprise systems that separate human users from non-human accounts, Salesforce often treats both the same way. That means your automated integrations, marketing apps, and reporting tools all look like “users” — blurring the lines between humans and non-human identities (NHIs).
And nowhere is this more dangerous than with Connected Apps.
Connected Apps: Powerful but Risky Gateways
Connected Apps let external systems interact with Salesforce — everything from marketing automation tools, reporting platforms like Power BI, to e-signature services like DocuSign.
They typically authenticate using OAuth, SAML, or OpenID Connect:
- OAuth - Allows the app to act on behalf of a user, within the limits of defined scopes.
- SAML / OIDC - Extend single sign-on (SSO), making it easier for users to log in across systems.
Think of Connected Apps like hotel key cards. Ideally, each card only opens the specific doors it needs. But in many Salesforce orgs, one card ends up unlocking half the hotel.
Salesforce’s Permission Model: Profiles vs. Permission Sets
Salesforce permissions are layered:
- Profiles – Required for every user. They define the baseline — what a user can and cannot do by default.
- Permission Sets – Extra privileges layered on top, following Salesforce’s “grant-only” model.
In theory, this allows fine-grained control. In practice, misconfigurations are rampant:
- Too many System Admins - The all-powerful profile gets handed out too easily.
- Permission sets wasted - Even carefully built least-privilege sets get ignored if the underlying profile is already over-permissive.
It’s like putting a high-security lock on your front door but leaving the garage wide open.
Hidden NHI Risk: One User, Many Apps
A surprisingly common pattern is using a single Salesforce user for multiple Connected Apps.
- It seems efficient (fewer accounts, less admin overhead).
- But in reality, it’s a privilege accumulation nightmare.
That one user gradually collects permissions to satisfy the needs of each app. In practice, every app tied to that identity inherits its combined power.
If compromised, that single integration user can become an all-access backdoor to Salesforce.
Real-World Fallout: When Profiles Go Wrong
Here are two anonymized but very real examples:
Scenario |
Intended Access |
Actual Access |
Fallout |
Sales rep |
Manage their own opportunities, run pipeline reports |
“Modify All” on Accounts & Contacts via cloned System Admin profile |
Bulk edit wiped 1,800 customer records, 2 days of restores |
Account exec |
Edit their own deals, run quota reports |
“View All Data” + export permissions |
Exported every account & contract, data later surfaced at competitor |
Both stemmed from overpowered profiles undermining well-intentioned permission sets.
Best Practices for Securing Salesforce NHIs
Here’s a structured playbook to avoid permission chaos and NHI risk in Salesforce:
- Dedicated Integration Users
- Create a separate user for each Connected App.
- Yes, it’s more work. But it prevents privilege bleed and isolates risk.
- Enforce Least Privilege
- Start every user with a minimal baseline profile.
- Layer on specific permission sets only as needed.
- Continuous Monitoring
- Review OAuth grants and API logs regularly.
- Watch for anomalies — apps making calls outside their normal behavior.
- Tame the System Admin Problem
- Limit System Admins to the bare minimum.
- Use granular permission sets instead of cloning admin-level profiles.
- Regular Audits
- Conduct quarterly reviews of profiles, permission sets, and Connected Apps.
- Remove unused integrations and stale OAuth grants.
Why This Matters
Salesforce is no longer “just a CRM” — it’s a mission-critical data hub. Connected Apps multiply its power, but also its exposure. Mismanaged NHIs here can lead to data exfiltration, compliance violations, and reputational harm.
Bottom line
Keep it lean, keep it watched. Treat Salesforce Connected Apps with the same rigor you apply to IAM in AWS or Azure.
And if your organization is serious about building maturity in NHI security, it’s time to look beyond ad hoc fixes. Structured training and platforms purpose-built for NHI visibility and governance — like Token Security and the NHI Foundation Training Course — can help you operationalize these best practices before attackers find the gaps.
If your Salesforce org has more Connected Apps than you can count, now’s the time to tighten the controls. Join the NHI Foundation Training Course and learn how to build a least-privilege, lifecycle-governed, ITDR-ready strategy for all non-human identities.