A built-in assessment that reviews common security settings and highlights weak areas in a Salesforce environment. It helps teams evaluate password policies, session controls, and related configuration choices, but it does not replace broader monitoring, access design, or data loss prevention for sensitive content.
What the Salesforce Health Check actually does
Salesforce Health Check is a built-in review of common org security settings. It gives teams a baseline score or status view for settings such as password policy, session controls and similar configuration choices, so they can spot weak defaults quickly. It is a useful starting point, but it is not a full security assessment.
Because the assessment is configuration-driven, it can only reflect what Salesforce can see in the org at that moment. It will not tell you whether a risky access pattern, a compromised integration, or sensitive data exposure is already happening outside the narrow settings it evaluates.
Which settings it helps you review
The value of the check is that it focuses attention on controls that often drift over time: password length and expiry, session timeouts, login restrictions, and other baseline hardening choices. Those settings matter because they shape how easily an account can be guessed, reused, or left active longer than intended.
For organisations that rely heavily on Salesforce, this makes the check a practical hygiene tool. It can show where the org is permissive, where standards are inconsistent across profiles or users, and where configuration has fallen behind current expectations for access control.
What it does not replace
Health Check is not a substitute for a broader security programme. It does not replace access design, continuous monitoring, data loss prevention, review of connected apps, or control over exports and API-based access. A “good” score can coexist with poor governance elsewhere in the environment.
That is why the check should be treated as one signal among several. If the surrounding architecture allows overbroad permissions, weak third-party access, or sensitive data to move through integrations unchecked, the org can still be exposed even when the baseline settings look acceptable.
For a broader view of Salesforce hardening and adjacent controls, see the Salesforce Security Guide.
How teams should interpret the result
A Health Check result is best read as a configuration baseline, not a verdict on the overall security posture of the CRM. A low score usually points to missed hardening opportunities, while a higher score only means the evaluated settings are closer to the recommended baseline.
Teams should use the result to prioritise follow-up review, especially where the org supports sensitive customer data, regulated records, or high-volume integrations. In practice, the real question is not only whether the settings are strong, but whether the broader Salesforce operating model is being governed well enough to keep those settings meaningful.
Baseline scores are also easy to overtrust when there are many external access paths. One strong example of why that matters is the Salesloft OAuth token breach, which shows how Salesforce data exposure can come through integration trust rather than the org’s local settings alone.
Related Salesforce exposure patterns also appear in the Gainsight OAuth breach and the Klue OAuth Supply Chain Breach, both of which underline how third-party access can bypass the confidence implied by a baseline health score.
Risk and Threat Considerations
Salesforce Health Check can create a false sense of security if teams treat it as a complete control test. The main risk is not the score itself, but the assumption that a strong score means the org is safe when access paths, integrations, and data movement may still be weak.
Failure mechanism: Weak password, session, and related baseline settings make account misuse easier, while third-party tokens, connected apps, or permissive access paths can preserve attacker access even after the local settings are improved.
Impact: Sensitive CRM data can be exposed, exported, or manipulated through legitimate-looking access, and post-incident review becomes harder if teams relied on the check instead of broader detection and governance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Salesforce Health Check evaluates password and session settings that affect authenticator lifecycle and strength. |
| AC-2 — Account Management | Org hardening depends on account and access governance beyond the baseline settings Health Check scores. | |
| AC-17 — Remote Access | Session controls and login restrictions in Salesforce map to remote access governance. | |
| Recommendation — Review and tighten authenticator settings, expiry, and reuse rules for Salesforce users. Validate account provisioning, review, and deprovisioning around Salesforce access. Enforce session limits and access conditions for Salesforce logins and remote use. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Health Check is a configuration baseline, so misconfiguration is the core security concern it highlights. |
| Recommendation — Harden Salesforce configuration settings and correct insecure defaults that increase exposure. | ||
| CIS Controls v8 | CIS-5 — Account Management | The term is about assessing security settings that support account and access hygiene in SaaS environments. |
| Recommendation — Audit and reduce unnecessary access paths in Salesforce user and admin accounts. | ||
Practitioner Guidance
Why practitioners should care: Use Health Check as an entry point for hardening, not as evidence of full control coverage. The most useful interpretation is often the gap between the recommended baseline and the way the org actually grants access, manages sessions, and governs connected applications.
What to watch for: Pay special attention when the org contains sensitive customer records, many integrations, or multiple admin teams, because those conditions make baseline settings only one part of the exposure picture. If the environment changes quickly, the check can become stale as soon as new access paths or apps are added.
Practitioner takeaway: A good Health Check result should trigger confirmation, not complacency, because Salesforce security depends on the wider access and data-control model around the org, not just the settings the tool scores.
Related resources from NHI Mgmt Group
- How should security teams use a Salesforce health check to improve org security without disrupting day-to-day operations?
- How can operators tell whether a health check is actually useful?
- What breaks when remote access MFA does not check device health and session context?
- How should organisations perform a segregation of duties health check in Oracle ERP environments?
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 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org