For years, Salesforce security guidance came with an asterisk. MFA was "strongly recommended." Permission set groups were a "best practice." Least-privilege access was something you got to eventually, after the more urgent tickets were closed.
That asterisk is gone. In 2026, Salesforce moved from recommending security controls to enforcing them — with real deadlines, and real consequences for orgs that miss them. If your org hasn't been keeping up, this is the year that catches up to you.
Here's what actually changed, and what to do about it.
MFA Is No Longer Optional — For Anyone
Salesforce has offered a way to waive multi-factor authentication for specific users for years. That waiver is being eliminated. As of the 2026 enforcement rollout, every employee user has to complete MFA on every login — whether they're logging in through the direct UI or through SSO.
If your org has been leaning on an SSO setup that quietly bypassed MFA, or a handful of "legacy" users with the waiver permission still attached, this is the point where that stops working. Developer Edition, trial, and scratch orgs are exempt. Production orgs are not.
What to check now: audit who in your org still has the MFA waiver permission, and confirm your SSO configuration actually sends the identity signals Salesforce needs to validate that MFA happened upstream. A lot of orgs assume their SSO provider is "handling MFA" when the handoff to Salesforce isn't configured to prove it.
Admins Need More Than a Code Now
Standard MFA — an authenticator app code — still covers most users. It doesn't cover admins anymore. Anyone with elevated permissions like Modify All Data, Customize Application, or Author Apex is now required to use phishing-resistant MFA: security keys, biometric authenticators, or passkeys. Six-digit codes don't qualify.
This is a direct response to how credential attacks have changed. Phishing kits that harvest MFA codes in real time are common enough now that a code — even a time-limited one — isn't considered a reliable second factor for the accounts that can do the most damage. A stolen admin session is a much bigger problem than a stolen sales rep session.
What to check now: identify every user with Modify All Data, Customize Application, or Author Apex, and get them onto a passkey or security key before enforcement hits. This is also a good moment to ask whether all of those users actually need that level of access — which leads to the bigger structural issue.
Report Access Now Gets Its Own Scrutiny
Two changes specifically target reports and data exports, and they matter because reports have quietly become one of the most common ways sensitive data leaves an org.
Time-based step-up authentication: users now have to re-verify their identity within a configurable window — somewhere between 2 and 120 minutes — before accessing certain reports. Admins control the interval through Session Security Level Policies, but the control itself isn't optional anymore.
Anomalous activity detection: Salesforce now runs machine learning against report viewing and export patterns. If someone starts pulling reports in a way that doesn't match their normal behavior — a bulk export at 2am, a user suddenly viewing records outside their usual territory — the system triggers additional verification automatically, and can block access entirely if the user can't complete it.
What to check now: make sure every user who regularly works with reports has a registered verification method — MFA, phone, or email — before this activates. A user who gets locked out of reporting because they never finished MFA setup is going to file a ticket, and you'd rather catch that now than during a board meeting.
Large Data Exports Get a Default Guardrail
For orgs using Salesforce Shield or Event Monitoring, there's a new default Transaction Security policy that automatically applies to any export exceeding 10,000 records. It ships on by default, which means orgs with existing export-heavy processes — data syncs, backup jobs, integration pulls — need to review their existing policies before this auto-deploys on top of them.
There's also a new permission, Modify Transaction Security, that's now required alongside Customize Application to change these policies. That's a meaningful shift: the person who can customize your org's configuration is no longer automatically the person who can touch your security transaction policies.
What to check now: if you're on Shield, review what currently exports more than 10,000 records — reports, integrations, scheduled jobs — before the default policy lands on top of a process nobody's watching.
The Bigger Shift: Permission Sets Aren't a Nice-to-Have Anymore
None of the enforcement above works well in an org that's still profile-heavy. If your access model is built around a handful of sprawling profiles that each carry a mix of object permissions, field-level security, and system permissions, identifying who actually has Modify All Data or Customize Application — the users now subject to stricter MFA requirements — becomes a manual audit instead of a query.
The permission-set-led model Salesforce has been pushing for years is now doing real work in 2026: profiles handle baseline settings, and permission sets and permission set groups handle almost everything else. The advantage isn't just cleaner administration. It's that when a new enforcement rule shows up — like phishing-resistant MFA for a specific set of permissions — you can actually answer "who does this apply to" in minutes instead of days.
Permission set groups specifically are worth a second look if you haven't touched them. They let you bundle related permission sets into a single assignable unit that represents a job function — "Sales – Standard Access," "Finance – Read Invoice Data" — and they support muting, which lets you strip out a specific permission from the group without touching the underlying permission sets. That's the kind of granularity that makes an access model easy to reason about instead of something only the person who built it understands.
What to check now: if your org is still running on wide profiles with permission sets bolted on as an afterthought, this is the year to change that — not because it's best practice, but because the enforcement rules Salesforce is rolling out assume you can answer "who has this permission" cleanly.
What This Means If You're Running Agentforce
If your org has Agentforce agents live, the access model matters even more. Agentforce agents inherit the access of whatever they're configured to run as — they respect the same sharing rules, field-level security, and permission structure as any other user. An agent connected to a bloated profile with more access than it needs isn't a hypothetical risk; it's a live one, since the agent can act on that access without a human double-checking every step.
The same audit that clean access management requires for human users applies to agents now too: know exactly what an agent can see and touch, keep it scoped to what the use case actually needs, and don't assume the Einstein Trust Layer's guardrails are a substitute for a properly scoped permission set.
The Bottom Line
Salesforce spent years telling admins what good security looked like and leaving the timeline up to them. In 2026, the timeline became fixed. MFA, step-up authentication for reports, transaction security for large exports — these aren't recommendations anymore, they're defaults with enforcement dates attached.
The orgs that are going to have a rough few weeks are the ones that treated "best practice" as optional and never got past wide-open profiles and waived MFA. The orgs that are fine are the ones that already had clean permission set architecture and registered MFA — because for them, this rollout is mostly a non-event.
If you're not sure which one you are, that's worth finding out before an enforcement date finds out for you.
Sources
- Salesforce Is Tightening Security Across Every Org — Salesforce Break
- Security-Related Product Updates to the Salesforce Platform: User Identity, Data Protection, and Access Controls — Salesforce Help
- Salesforce Summer '26 Release Notes: The Agentic Enterprise Meets Enforced Security — SFDC Penguin
- 8 Salesforce Permission Sets Tips — Salesforce Ben
- Salesforce Roles vs Profiles (and Permission Sets): The Complete 2026 Guide — DESelect
- Agentforce Security in Salesforce: Use Cases & Best Practices — Reco
- Security, Data Privacy, and Regulatory Considerations with Agentforce — RevenueOps LLC