Salesforce API v67 Introduces Secure by Default Apex: Here’s What Changed

A single line in a class’s meta-XML can now change what data your users see. That is not an exaggeration. Summer ’26 shipped one of the most consequential updates to Salesforce Apex Security in years, and most teams have not noticed yet, because nothing breaks until you bump the API version.

This article breaks down what changed, why it matters, and what to check before your org moves to API v67.

 

Why This Salesforce Apex Security Release Is Different

Most release notes describe new features. This one changes a default assumption Apex developer have relied on since the platform’s early days.

For nearly two decades, Apex database operations ran in system mode unless a developer explicitly said otherwise. System mode ignores field-level security, object permissions, and sharing rules. It assumes the code knows what it is doing and lets it see everything.

That assumption made sense when Apex was written by a small group of platform specialists. It makes less sense today, when orgs run hundreds of classes and integrations written by different teams over many years.

 

The Old Default Nobody Talked About

And here is what comes as a surprise to many programmers: system mode was not some particular mode that you had to enable; it was the default mode. All queries and updates executed in it had full permissions unless additional restrictions were applied.

In practice, most developers never added those checks, not out of carelessness, but because the platform never forced the question. A query like this ran quietly for years:

List<Account> accounts = [SELECT Id, Name, AnnualRevenue FROM Account];

If the running user had no access to AnnualRevenue, the query returned it anyway. The org simply trusted the code.

 

The One Default That Changes Everything

From Salesforce Apex Security API v67 onward, that trust moves from the code to the user’s actual permissions. Any class compiled at this version runs database operations in user mode by default, not system mode.

In practical terms:

• SOQL and SOSL queries respect field-level security automatically
• DML statements respect object and field permissions
• Sharing rules are enforced without extra syntax
• A field the running user cannot see is stripped from results or throws an exception

This is a compiler-level change tied to the API version of the class, not a warning.

A Simple Before vs After Example

// API v66: runs in system mode

// Returns AnnualRevenue even without field access

List<Account> accounts = [SELECT Id, Name, AnnualRevenue FROM Account];

 

// API v67: runs in user mode automatically

// AnnualRevenue is stripped or throws if inaccessible

List<Account> accounts = [SELECT Id, Name, AnnualRevenue FROM Account];

Same code, same query, completely different behavior, because the class now compiles against a newer version.

Why “With Sharing” Becoming the Default Matters

The second change is quieter but just as important. An Apex class at API v67 with no sharing declaration now defaults to with sharing instead of without sharing.

Before this, a class with no declaration usually ran without sharing, ignoring the org’s role hierarchy entirely. A developer who forgot to declare sharing was not just skipping a best practice. They were silently shipping a class that bypassed record-level access controls.

Now, forgetting a declaration is far less dangerous. The safe option is the default, not the exception.

 

Why the Old Security Clause Is Being Retired

If your team has used WITH SECURITY_ENFORCED in SOQL, this part applies directly to you. Salesforce is retiring that clause and replacing it with WITH USER_MODE.

This is not a simple rename. The old clause only checked field access on fields listed directly in the SELECT statement. It missed subqueries and polymorphic fields, and it only surfaced one error at a time, which made debugging painful when several fields were inaccessible.

The replacement fixes these gaps. It enforces sharing rules alongside field and object permissions, covers the full query rather than top-level fields only, and reports every access violation at once.

Swapping the Old Clause for the New One

// Being retired

List<Contact> contacts = [SELECT Id, Name, Email FROM Contact WITH SECURITY_ENFORCED];

 

// Replacement

List<Contact> contacts = [SELECT Id, Name, Email FROM Contact WITH USER_MODE];

Classes compiled at API v67 that still reference the old clause will not compile. This is one of the first things worth searching your codebase for before touching the API version field.

 

How the New Security Model Works in Practice

Behavior	API v66 and Earlier	API v67 and Later
Default database operation mode	System mode	User mode
Default sharing, no declaration	Without sharing	With sharing
Explicit access clause in SOQL	Old security clause	New user-mode clause
Field-level security enforcement	Manual, opt-in	Automatic by default
Trigger execution mode	System mode	System mode, unchanged
Error reporting on violations	First violation only	Full set at once

Worth noting: triggers still run in system mode regardless of API version. If your trigger logic assumes sharing enforcement, that still needs to be handled explicitly inside handler classes.

 

What Existing Apex Code You Should Review Before Upgrading

None of that makes any difference when it comes to behavior. Classes that were already created in v66 or earlier will continue operating just as they did before your organization adopted Summer ’26. The upgrade only takes effect when the class version reaches 67 or above.

Before raising the version on any class, check for:

• Classes with no sharing declaration, since these start enforcing sharing rules
• Any leftover use of the old security clause, which will fail to compile
• Queries assuming access to fields the running user may not actually have
• Integration users with broad access, whose behavior may look unchanged even when regular users see a difference
• Batch and scheduled Apex that calls into classes with mixed sharing behavior

A fast way to find classes on older versions is a Tooling API query like SELECT Id, Name, ApiVersion FROM ApexClass, filtered for anything below 67.

 

Common Migration Scenarios

• A reporting class built for admins → These often rely on system mode intentionally, since the class should show every record regardless of viewer permissions. An explicit system-mode declaration keeps that behavior instead of leaving it to a changing default.
• A service class with no sharing keyword → This is the riskiest pattern. It likely worked for years because nobody who called it lacked the right access. Once sharing becomes the default, narrower permissions may surface fewer records or new errors.
• A managed package using the old security clause everywhere → This needs a straightforward find-and-replace, but every swap deserves a quick test pass, since the replacement surfaces more violations than the clause it replaces.

Best Practices Going Forward for Salesforce Apex Security

• Declare sharing explicitly in every class, even when the default already gives you the behavior you want.
• Use the user-mode or system-mode clause deliberately wherever access actually matters, instead of depending on the version default.
• Treat any system-mode declaration in a code review as worth double-checking, not routine.
• Test critical flows in a sandbox at API v67 before touching production. Access differences can be subtle: a query returning ten records for one profile might return three for another.
• Review Apex against current security guidance whenever a major release lands, instead of waiting for a support ticket to surface a gap.

Reviewing existing Apex code in light of these practices is precisely what an experienced Salesforce consulting partner excels at because identifying any sharing loopholes in an extensive code requires not only technical know-how but also a systematic auditing process. Companies that lack the resources to do this internally usually resort to external Salesforce development services.

Access control gaps are not unique to Salesforce. OWASP has long listed broken access control among the most common weaknesses in enterprise applications, which is part of why moving secure behavior into the platform default matters so much here. The Apex Developer Guide is worth bookmarking for the full technical detail behind these changes.

 

Conclusion

Nothing breaks the day your org upgrades to Summer ’26. Behavior only changes once a class’s version moves to 67 or later, which puts the timing in your team’s hands.

Treating it as optional is still a mistake. This is one of the largest shifts to how Salesforce Apex Security enforces record-level access since sharing rules were introduced. Reviewing your codebase now beats discovering a gap after a version bump reaches production.

If your team is planning a broader Salesforce implementation refresh this year, folding a readiness check for this change into that same project is a practical way to get ahead of it.

 

FAQs

Is there any impact on my Apex behavior if I upgrade my org to Summer ’26?

No. Classes will retain their existing version and behavior even after the upgrade. The behavior is affected only if you manually upgrade the class version to 67 or above.

Would the old security clause be deprecated immediately?

The old clause works until the class version is 66 or less. Once the class version is upgraded to 67 or above, the clause would no longer work.

What is the way to find classes that can break while implementing this?

Use the Tooling API to query for ApexClass where the version is below 67. Then, check whether there are any such classes which lack sharing declaration and use of the retired clause.

Are triggers impacted the same way as the classes?

Since all the triggers execute in the system mode, irrespective of API version, this change doesn’t have an impact on the trigger. But if the handler classes used in triggers need the sharing enforcement then they need to be reviewed.

Is Salesforce Apex Security v67 now secure by default for all Apex code?

Only those classes that have API version v67 or above. The older classes remain with their old characteristics unless they get explicitly upgraded by anyone, allowing for coexistence of secure by default classes along with the older classes.

For more insights, updates, and expert tips, follow us on LinkedIn.