Treat onboarding and offboarding as a security control, not just an HR workflow. HR and IT should coordinate every access change, review roles and permissions at the point of hire and departure, and remove access as soon as it is no longer needed. A formal process reduces the chance that former employees retain access to sensitive records or privileged functions.
What changes when someone changes role or leaves a Salesforce environment?
The security problem is not the employee change itself, it is the access residue that can remain behind it. When a user moves teams or exits, their Salesforce role, permission sets, sharing access, connected-app access, and report or export capabilities can outlive the business need that justified them. The control objective is to remove those paths quickly and verify that sensitive records are no longer reachable.
Role change is often the hardest moment because users still need some access, but not all of it. That means teams should distinguish between a transfer, a temporary assignment, and a full departure, then narrow access to the new job function rather than carrying forward the old one. Departure should be treated as a complete revocation event, with the strongest attention on admin-style privileges and any access that can expose large data sets.
Salesforce data exposure also depends on how access is inherited. A person may lose a named role but still retain access through permission sets, public groups, delegated administration, API tokens, or app integrations. That is why a clean review has to cover the user account and the surrounding access model, not just the visible profile assignment.
How should the access removal process work in practice?
Use a joiner-mover-leaver process that is triggered by HR status changes and executed by IT or identity administrators without delay. The process should confirm the new business need, remove obsolete access, and recheck any exceptions that were granted for projects, support duties, or temporary coverage. For leavers, disable the account or remove interactive access first, then revoke any remaining access paths that could still reach Salesforce data.
The review should be precise enough to catch indirect access. In Salesforce, that usually means checking profiles, permission sets, permission set groups, role hierarchy, sharing rules, manual shares, connected applications, API access, and any privileged admin capabilities. If a user had elevated rights, verify that reports, exports, and bulk data operations are also removed, because those are common ways data exposure persists after a role change.
Teams also need a clean handoff for ownership. If a departing employee owned reports, dashboards, flows, approval steps, or integrations, reassign those objects before the account is closed so that business processes do not break. A good offboarding process removes access while preserving continuity, which reduces the temptation to leave stale access in place “just in case.”
Controls for identity lifecycle and least privilege are well covered in Salesloft OAuth token breach, Klue OAuth Supply Chain Breach, and The 52 NHI Breaches Report, which show how stale or overextended access can expose Salesforce-connected data paths.
What should teams verify before they consider the change complete?
Verification matters more than the ticket closure. Teams should confirm that the former user cannot log in, cannot use an active session, cannot authenticate through a federated path, and cannot reach Salesforce through an API key, OAuth grant, or connected app that was left behind. For movers, they should also confirm that the user still has only the minimum access needed for the new role, not a mix of old and new privileges.
Good verification includes checking both direct and inherited access, then sampling the data that mattered most during the person’s old role. If the user handled sensitive accounts, contracts, pricing, HR cases, or customer exports, validate that those records are no longer visible or exportable. The test is practical: if the person’s old credentials or role could still read the records, the offboarding is incomplete.
Automation helps, but it should be paired with periodic recertification of privileged and exception-based access. A change process can be fast and still miss edge cases if nobody reviews temporary access, integration accounts, or manually granted exceptions after the original business need ends. For broader access-control guidance, see the NIST Cybersecurity Framework 2.0, NIST SP 800-53 Rev 5 Security and Privacy Controls, and NIST Privacy Framework, which all support disciplined control over access, governance, and data exposure.
Risk and Threat Considerations
Role changes and departures are high-risk moments because stale access can be quietly reused before anyone notices. The main exposure is not only insider misuse, but also forgotten permissions, inherited sharing, and active tokens that keep working after the business need has ended. In Salesforce, that can translate into unauthorized record visibility, data export, or use of connected applications that still trust the old user state.
Failure mechanism: Access is removed at the user record but not across permission sets, sharing paths, tokens, sessions, or connected apps, so the former user still reaches sensitive data.
Impact: Sensitive customer, commercial, or operational records can be exposed after the role change or departure, and the organisation may not detect it until data has already been viewed or exported.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | User role changes and departures require timely account removal and access changes. |
| AC-6 — Least Privilege | Role changes should shrink access to only what the new function needs. | |
| IA-5 — Authenticator Management | Offboarding must invalidate credentials, tokens, and other authenticators that may still work. | |
| Recommendation — Revoke or adjust accounts promptly when employment status or job role changes. Limit Salesforce access to the minimum permissions required for the current job. Rotate or revoke authenticators and tokens when users leave or change roles. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Role transitions require controlled access assignment and removal across the information environment. |
| A.5.18 — Access rights | Leavers and movers need prompt review and revocation of access rights. | |
| Recommendation — Apply formal access rules for role changes and departures. Review and remove access rights as soon as they are no longer required. | ||
Practitioner Guidance
What to prioritise: Put leavers and privileged movers first. If a user had export rights, admin rights, or broad sharing visibility, treat the change as a data-exposure event, not a routine account update.
What to verify: Confirm that revocation covers the full access chain, including sessions, OAuth grants, connected apps, permission sets, and any manual shares. A closed ticket is not enough unless the account can no longer reach the records.
What good looks like: The user keeps only the access needed for the new role, or loses all access on departure, and the organisation can show a repeatable review trail for who approved the change, what was removed, and when it was validated.
Practitioner takeaway: The safest Salesforce offboarding process is the one that removes every practical path to the data, not just the visible login.
Related resources from NHI Mgmt Group
- What happens when organisations do not deactivate IAM accounts as users change roles or leave?
- How can organisations reduce the blast radius of compromised agent identities?
- Should organisations prioritise external exposure or internal credential governance first?
- How do organisations reduce the dwell time of exposed credentials at scale?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
