Salesforce Just Locked the Doors: What Enforced Security Means for Your Org

For years, Salesforce’s security posture worked like a recommendation. Best practices were published, admins were nudged, and plenty of orgs quietly stayed on older, looser configurations because nothing forced the change. That era is ending. Salesforce has been steadily converting recommended security settings into enforced ones, and organizations that never got around to the recommendation are now getting the requirement, on Salesforce’s timeline, not theirs.

What “enforced” actually changes

The practical difference is simple and unforgiving. A recommended setting sits in a checklist someone can defer. An enforced setting activates on a release date whether or not anyone read the release notes. Integrations built against the looser configuration can break. API calls that worked can start failing. Access patterns nobody audited in years suddenly get flagged.

Who gets caught off guard

Almost never the org that’s actively maintained. It’s the org running on institutional memory. The integration a vendor built three years ago and nobody has touched since. The permission set copied from a template in 2022 and never revisited. The API user with more access than the current use case actually requires. None of that was necessarily wrong when it was built. It’s the accumulated debt that enforced security is now collecting.

What to audit before the next release

Four places, in priority order:

1. API access and permission sets. Who and what can call your org, and does the actual access match the actual current need, not the need from whenever it was configured.
2. Third-party integration health. Every connector, every AppExchange package, every custom integration, checked against the current security requirements rather than the ones in place when it was built.
3. Session and authentication settings. Especially anything still running on older, more permissive defaults because nobody actively changed them.
4. Field-level and object-level security. The layer most likely to have drifted quietly as roles, teams, and data models changed over the years.

The agentic AI connection

This isn’t a tangent from the rest of this series. It’s the same theme from a different angle. Every AI agent this series has discussed needs API access, permissions, and data visibility to function. An org with drifted security debt isn’t just exposed to a compliance flag. It’s exposed to an agent inheriting broader access than intended, silently, because nobody re-audited permissions before pointing an agent at the org.

The move that costs nothing but attention

Enforced security releases come with a notice window. The org that reads it and audits ahead of the deadline has a calm week. The org that waits finds out what broke live, usually during a release nobody was watching for.

Mar Dat includes a security and access audit in every readiness engagement, specifically because agent rollouts inherit whatever gaps already exist. Book a Discovery Call to get ahead of the next enforced release.