What happens when Salesforce admins rely on default settings instead of a reviewed security baseline?

Default settings can leave the org exposed when business requirements change faster than the security profile. Over time, permissive password rules, weak session controls, or relaxed identity checks can remain in place even after the org becomes more sensitive or more widely used. The result is a mismatch between operational convenience and the level of protection the data and users actually need.

Why default Salesforce settings become risky as the org changes

Default configuration is not a neutral state. It reflects a starting point, not a lasting security decision. In Salesforce, the risk emerges when users, data sensitivity, integration count, and business criticality grow, but authentication, session, and sharing choices are never revisited. That is how a low-friction setup can become a control gap without any obvious change event.

What matters is the mismatch between the org’s current exposure and the assumptions baked into the original baseline. A setting that was acceptable for a small pilot can become too permissive once more roles, more external connections, and more sensitive records are added.

Default settings also tend to be inherited as “safe enough” simply because they are familiar. Practitioners should treat them as provisional until they are reviewed against the real operating model, because convenience often outlives the context that made the default acceptable.

Where the security profile usually drifts away from the baseline

The most common drift shows up in authentication and session handling. Password length, login challenge requirements, session timeout, and trusted network assumptions can all remain at permissive defaults even after the org starts handling higher-value data or broader user populations. At that point, the security profile no longer matches the business impact of compromise.

Another drift point is authorization shape. Profiles, permission sets, object access, and sharing rules can accumulate over time in ways that are operationally convenient but harder to defend. When no one rechecks the baseline, access often expands faster than the review process does.

Integration and identity sprawl can intensify the problem. More connected apps, more admins, and more exceptions all increase the chance that a default or inherited control remains in place after the original assumption has been invalidated. For broader control guidance, teams often anchor baseline review to ISO/IEC 27002:2022 Information Security Controls and hardening expectations such as CIS Benchmarks, then adapt those ideas to the Salesforce operating model.

What the mismatch means in practice

The practical consequence is not that the system is “misconfigured” in the abstract. It is that the org may be defending a newer, more exposed environment with an older, less restrictive security posture. That gap can make ordinary account compromise, unauthorized access, or weak session reuse materially more damaging.

Once the baseline lags behind reality, the organization can also lose the ability to explain why a control exists. If a setting was never reviewed, it is difficult to defend it as an intentional risk decision. That weakens governance, complicates audits, and makes remediation slower because the team must first rediscover why the default remained in place.

The right comparison is not default versus custom. It is current exposure versus explicit control intent. A reviewed baseline turns security settings into a managed decision, not an inherited accident.

Risk and Threat Considerations

When Salesforce defaults are left untouched, the main risk is silent exposure growth. As the org becomes more business-critical, permissive authentication or session settings can give attackers more room to reuse accounts, exploit weak controls, or move through connected services with less friction.

Failure mechanism: The control fails because the environment changes faster than the baseline review cycle, so inherited settings keep governing a more sensitive org than they were designed for.

Impact: The result can be unauthorized access, broader blast radius after compromise, and a harder-to-defend security posture because the organization cannot show that the setting was deliberately chosen for current risk.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
ISO/IEC 27001:2022	A.5.15 — Access control	Default Salesforce settings often drift into access control weakness as the org changes.
	A.8.9 — Configuration management	The question is about relying on unchanged defaults instead of a reviewed baseline.
Recommendation — Review and tighten access rules when the business context changes. Maintain and review secure configuration baselines for the live environment.
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	This directly addresses default settings versus reviewed hardening baselines.
Recommendation — Standardize and enforce secure configuration baselines across the org.
NIST SP 800-53 Rev 5	CM-2 — Baseline Configuration	The issue is failure to review and update the security baseline over time.
	AC-6 — Least Privilege	Permissive defaults often leave users with more access than they need.
Recommendation — Establish and maintain configuration baselines that reflect current risk. Limit permissions to the minimum required for each role or process.

Practitioner Guidance

What to prioritise: Review the settings that most directly shape exposure first: authentication strength, session duration, trusted access paths, and privileged access boundaries. Those controls create the biggest difference between an acceptable default and a risky one.

What to verify: Confirm that each retained default is still justified by current business use, data sensitivity, and user population. If the org has added more integrations, more external users, or more sensitive objects, the burden of proof should shift toward tightening, not preserving convenience.

What good looks like: The baseline is documented, periodically reviewed, and traceable to the actual Salesforce deployment model. Teams can explain why each key setting is permissive, restrictive, or exception-based, and can show who approved that decision.

Practitioner takeaway: Treat Salesforce defaults as a temporary starting point, not a standing security posture, and revalidate them whenever the org’s sensitivity or complexity changes.