The Changing Security Model of Apex in 2026

by Bisera Runcheva

Salesforce is making an important shift in how Apex handles security. With API version 67.0, Apex is moving toward a ”secure by default” model, changing assumptions that Salesforce developers have relied on for years.

What changed?

Previously, Apex database operations such as SOQL, SOSL, and DML ran in System Mode by default. This meant that object permissions, field-level security, and sharing rules were not automatically enforced by those operations.

With API 67.0 and later, database operations now run in User Mode by default. User Mode respects the current user's object permissions, field-level security, and sharing rules. For example, a query can now explicitly define its behavior:

If System Mode is genuinely required, developers can explicitly request it:

This makes the security decision much more intentional: System Mode is something you choose rather than something you get by default.

What about with sharing?

There is another important change. Apex classes compiled with API 67.0 or later that don't specify a sharing keyword now default to with sharing. Previously, classes without an explicit sharing declaration generally defaulted to without sharing.
This means that newer Apex code is increasingly secure by default, while bypassing sharing becomes an explicit decision:

What happened to WITH SECURITY_ENFORCED?

WITH SECURITY_ENFORCED has also been removed for Apex compiled at API 67.0 and later. Salesforce recommends using WITH USER_MODE instead. This is more than a simple syntax change.WITH USER_MODE provides broader security enforcement, including support for polymorphic fields and security checks across the SOQL statement.

What about triggers?

There is an important distinction here: triggers themselves continue to run in a without sharing context, but database operations inside triggers default to User Mode in API 67.0 and later. Therefore, a query inside a trigger can still respect the current user's security even though the trigger itself runs without sharing. This makes it even more important for developers to understand the difference between an Apex execution context and the access mode of an individual database operation.

What does this mean for developers?

Salesforce is moving toward secure-by-default Apex, but developers still need to understand how security works and how their code accesses data. In practice:

The key takeaway is simple: developers still need to think about security when writing Apex. Salesforce is making secure behavior the default, but understanding sharing, permissions, and access levels is still essential to building reliable and secure applications.