Salesforce Identity is Salesforce's identity and access management layer for authenticating users and controlling access to Salesforce resources. It typically uses SSO, MFA, connected apps, and permission sets to manage login, session control, and authorised API access within the platform.
How Salesforce Identity Works
Salesforce Identity is the platform layer that turns login into controlled access. It sits between the user and the org, using authentication signals, session handling and access policy to decide who can enter, what they can reach, and which connected services can act on behalf of the user or organisation.
That makes it more than a sign-in feature. In practice, Salesforce Identity is part of the trust boundary for the CRM itself, because a misstep in authentication, token handling or app approval can expose records, automation paths and API access inside the platform.
Core Capabilities and Control Points
The main control points are SSO, MFA, connected apps, permission sets, session policy and authorised API access. Together, these control how a user is proven, how long a session remains valid, and which apps or integrations can reach Salesforce data and functions.
Connected apps are especially important because they extend the identity layer beyond interactive logins. A connected app can become a durable access path if its scopes, approvals or tokens are too broad, and permission sets can quietly expand effective access even when the login experience looks unchanged.
For a deeper security view of these platform controls, see the Salesforce Security Guide, which covers connected apps, permission sets, login activity and Salesforce hardening.
Why Salesforce Identity Matters
Salesforce often becomes a system of record, a workflow engine and an integration hub at the same time. That means identity decisions influence confidentiality, integrity and operational trust, not just convenience. If the identity layer is weak, attackers or unauthorised users may move from a single login to data export, automation abuse or API-driven access.
Identity controls also affect governance. Permission sets, app approvals and session rules can drift over time, especially in large orgs with many admins, integrations and business units. The result is usually not one dramatic failure but accumulated exposure that is harder to notice than a classic perimeter issue.
Identity and Access Risks in Salesforce
The biggest risks come from token theft, overprivileged integrations, weak MFA coverage and poorly governed connected apps. A stolen OAuth token or overly trusted third-party app can preserve access even when a password changes, which makes the access path harder to detect and revoke than a normal login.
These risks are compounded when Salesforce is connected to other SaaS platforms. In that case, a compromise in one service can become a route into Salesforce data, and Salesforce credentials or tokens can become part of a broader cross-platform attack path. For an example of that pattern, see Salesloft OAuth token breach.
Another useful reference point is Gainsight Salesforce breach 2025, which shows how long-lived OAuth tokens can remain an active exposure long after the original authorization event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Salesforce Identity authenticates workforce users before platform access. |
| AC-2 — Account Management | Salesforce Identity governs user and app access lifecycle inside the org. | |
| IA-5 — Authenticator Management | The term involves MFA, tokens and login-session credentials used by Salesforce. | |
| Recommendation — Enforce IA-2 for workforce login assurance and session entry to Salesforce. Apply AC-2 to provision, review and revoke Salesforce access promptly. Use IA-5 to manage token, MFA and credential lifecycle for Salesforce access. | ||
Practitioner Guidance
Why practitioners should care: Salesforce Identity should be treated as an access-control plane, not just an authentication front end. The practical question is whether every connected app, session rule and permission set still matches a current business need and a current trust assumption.
What to watch for: Review whether admin privileges, token lifetimes and connected-app approvals are expanding faster than business ownership. If a user or integration can reach sensitive CRM data without a clear justification, the identity model is drifting from control into exposure.
Teams that want a broader governance lens can use the Identity Security Programme Guide to place Salesforce Identity within a wider access-management operating model.
Related resources from NHI Mgmt Group
- Who should own Salesforce forensic readiness in an identity programme?
- How should teams automate Salesforce user provisioning when access depends on HR data and identity events?
- What is the difference between MFA on direct logins and MFA through an SSO identity provider for Salesforce access?
- Should teams treat third-party Salesforce packages like part of the identity perimeter?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org