Security teams should tighten access around remote work by treating every login as potentially higher risk. Limit exposure with least privilege, restrict trusted locations where possible, and monitor for unusual activity in real time. The goal is to preserve data security even when office-based assumptions no longer hold and users connect from devices or networks the organisation cannot fully control.
How to govern Salesforce access for remote work on unmanaged endpoints
Governance starts by assuming the endpoint and network are outside corporate control, then compensating with access policy rather than trust. That means tighter privilege, stronger authentication, conditional access, and clearer session oversight for Salesforce, especially where users can reach customer or commercial data from personal devices and home networks.
Remote access governance should also account for the fact that Salesforce is often a high-value SaaS control point, not just another application. If the access path is weak, the blast radius can include records, exports, workflows, connected apps, and downstream integrations that inherit the same trust.
Why unmanaged devices change the Salesforce access model
Unmanaged devices remove several assumptions that security teams usually rely on: device posture, patching, local encryption, endpoint detection, and the ability to enforce policy on the host. A home network is usually a weaker signal than the user identity itself, so the control focus should shift from location trust to risk-based authentication and least privilege.
For Salesforce, that typically means reducing what a session can do even after login. Treat browser sessions, tokens, and connected apps as part of the access surface, because a successful sign-in is not the same as a safe session.
Controls that matter most for Salesforce governance
Start with role and permission hygiene. If users only need a narrow slice of CRM data, make sure profiles, permission sets, and sharing rules reflect that minimum access. Then layer in conditional access, MFA, and session controls so that remote access is constrained when device assurance is low or when the login pattern looks unusual.
Monitoring should be tuned to Salesforce activity, not just identity events. Unusual report exports, privilege changes, API access, new connected app grants, and logins from unfamiliar geographies are all signals that the control model may be too permissive or that an account has already been abused.
Where possible, pair Salesforce governance with broader access hardening guidance such as the NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls, which both reinforce access control, logging, and monitoring discipline. The same pattern is also reflected in CIS Controls v8, especially around access management, audit logging, and secure configuration.
Risk and Threat Considerations
Unmanaged endpoints increase the chance that valid Salesforce access becomes the easiest path to data exposure. The main risk is not only credential theft, but also session misuse, malicious browser extensions, token replay, and silent data extraction through reports or APIs that look legitimate at first glance.
Failure mechanism: A user authenticates from a device the organisation cannot inspect or control, then an attacker, compromised browser, or overly broad session inherits enough trust to read, export, or alter Salesforce data without tripping basic perimeter controls.
Impact: The result can be customer data loss, account takeover, fraudulent workflow changes, unauthorized exports, and a broader compromise of integrated SaaS services that rely on the same identity path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Remote Salesforce access depends on access control and authentication discipline. |
| Recommendation — Apply PR.AA-05 to enforce stronger authentication and least-privilege access for remote Salesforce users. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Salesforce governance for remote users hinges on limiting what each session can do. |
| AU-6 — Audit Review, Analysis, and Reporting | Remote SaaS access needs monitoring for unusual login and data-exfiltration patterns. | |
| Recommendation — Limit Salesforce privileges so unmanaged-device users can access only the minimum required data and functions. Review Salesforce audit activity for exports, privilege changes, and anomalous access patterns. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The question is fundamentally about controlling remote access to a business application. |
| CIS-8 — Audit Log Management | Monitoring is needed to detect misuse of valid Salesforce sessions and privileges. | |
| Recommendation — Restrict Salesforce access paths, roles, and approvals for unmanaged remote use. Centralize and review Salesforce logs for suspicious logins and high-risk actions. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access policy and conditional trust are central to governing remote Salesforce use. |
| Recommendation — Define and enforce access rules that reflect remote-work risk and data sensitivity. | ||
| OWASP ASVS | V8 — Authorization | Salesforce sessions must be constrained by authorization, not just successful login. |
| Recommendation — Ensure the application authorizes every sensitive Salesforce action by privilege and context. | ||
Practitioner Guidance
What to prioritise: Give priority to the combination of identity assurance and session restriction, not to network location alone. If you cannot verify device health, compensate by narrowing what a remote session can access and by requiring stronger step-up checks for sensitive actions.
What to verify: Confirm that Salesforce profiles, permission sets, connected apps, and export rights are all reviewed together. A common mistake is to harden login while leaving data export, API access, or delegated application trust unchanged.
Practitioner takeaway: For unmanaged remote access, the safest Salesforce posture is one where login is only the start of trust decisions, not the point at which trust is granted.
Related resources from NHI Mgmt Group
- How should security teams adapt SOC 2 controls when employees work remotely across unmanaged networks and devices?
- How should security teams govern non-human identities in Salesforce?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
