What are the signs that Salesforce security settings are no longer aligned to the organisation’s baseline?

What Salesforce security drift looks like in practice

When Salesforce security settings stop matching the organisation’s baseline, the most visible clue is inconsistency between what the control standard says should exist and what the org now enforces. That can show up as password policy differences, weaker login controls, changed session behaviour, or protection features that were switched off, overridden, or left behind after a change window.

Another sign is that the platform’s posture no longer looks stable over time. A healthy baseline is not just a one-time configuration target, it is something you can keep rechecking. If the same settings drift repeatedly, the issue is usually not a single bad change but a control process that is failing to preserve the baseline.

That is why configuration drift matters more than isolated preference changes. A single setting may look minor on its own, but once multiple security controls diverge, the org is no longer operating from a consistent security model. In practice, that means the baseline is no longer the source of truth for day-to-day administration.

Which signals usually point to loss of baseline alignment

Three patterns usually stand out: declining health score, repeated high or medium risk findings, and the same recommendations reappearing after they were supposedly fixed. Those signals indicate the org is not just dealing with new risk, it is failing to keep the underlying control state aligned with the intended standard.

Drift is also more credible when it affects controls that are usually tightly governed, such as password length, login attempt thresholds, session timeout values, or clickjack protection. If those controls differ from the baseline, the deviation is not cosmetic, it changes the effective security posture for users and sessions.

It is also worth treating repeated recommendations as evidence of remediation weakness. When the platform keeps surfacing the same issue, either the setting was not fully corrected, another process reversed it later, or there is no reliable ownership for keeping the control in place.

Why recurring findings usually mean governance has become fragmented

Recurring findings are often a sign that governance has been reduced to ad hoc fixes. The organisation may still be reacting to alerts, but it is no longer operating a repeatable control model that preserves the baseline across releases, admin changes, and exception handling.

That matters because Salesforce security settings are not just technical preferences, they are policy enforcement points. If the organisation cannot show why a setting changed, who approved it, and when it will be reviewed again, the baseline has effectively become advisory rather than operational.

Over time, this creates control drift across teams and environments. One admin may harden a setting, another may loosen it to solve a business issue, and unless governance is strong enough to detect and reverse that change, the org slowly moves away from the intended standard.

Practitioner Guidance

What to verify: Treat any repeated finding as a signal to check whether the current configuration still matches the approved baseline, not whether the last remediation ticket was closed. Confirm the live setting, the exception history, and whether the change was intentionally approved or simply left behind.

What to prioritise: Focus first on controls that materially change account and session exposure, especially authentication, session management, and browser protection settings. Those are the settings where drift most quickly turns into user-facing risk.

Common mistake: Do not treat a green follow-up after a one-time fix as proof that governance is working. If the same recommendation returns, the real issue is usually control ownership or change discipline, not the individual setting itself.

Practitioner takeaway: The important question is not whether a single Salesforce setting changed, but whether the organisation can reliably prevent, detect, and explain drift before the baseline stops being meaningful.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities in Salesforce?
• What are the signs that an organisation’s identity security baseline is not enough to stop account takeover?
• What are the signs that a PKI is no longer aligned with how the organisation actually runs its environment?
• How should security teams prioritise NHI remediation in cloud environments?