Security Keeps Changing

Module 4 of 4 in the chapter Thinking Like an Identity Architect, chapter 1 of Securing Salesforce: Identity and Access. Each module stands on its own.

The question this module answers: Why can’t an identity design be secured once and left alone?

Set once, but not forever

Module 1 said identity is set up once and then it just runs. That’s true of how it feels. It isn’t true of what stays secure.

In my 2024 class, I described one of the OAuth flows, the username-password flow, as deprecated and obsolete. Two years later, Salesforce has set the date it stops working. The same thing is happening across the whole domain: what was normal becomes discouraged, then blocked in new orgs, then retired. The exam guide is aligned to Summer ‘23 (module 2). The platform has moved a long way since.

Here are four changes that matter for this course, each in Salesforce’s own words, each page read again on November 7, 2026. Dates move, so check the current pages for your own org.

1. Two OAuth flows retire on February 20, 2027

OAuth is how apps get access to Salesforce, and Part 2 teaches its flows. Two of them are going away on the same day.

The username-password flow. An app sends a person’s username and password straight to Salesforce to get a token. Salesforce: it “directly passes the user’s credentials in HTTP requests, which presents security risks.” It’s blocked in orgs created in Summer ‘26 and later, and the retirement is enforced on February 20, 2027 (release notes, Summer ‘26 (opens in a new tab)).
The user-agent and hybrid user-agent flows. Salesforce: they’re “insecure because they directly expose access tokens to the browser.” Also enforced on February 20, 2027, and blocked in new orgs created in Winter ‘27 (release notes, Winter ‘27 (opens in a new tab)).

In their place, Salesforce points to the web server flow with PKCE when a person logs in, and the client credentials flow from one server to another. Chapters 9 and 11 teach them. Any integration still built on the old flows stops working on that date.

2. New connected apps can no longer be created

For years, a connected app was how you registered an app with Salesforce. Since Spring ‘26, new orgs have connected app creation turned off by default, and customers can’t turn it back on themselves: they have to ask Salesforce Support. Existing connected apps keep working. For new work, Salesforce’s answer is the external client app, which it calls “the new generation of connected apps” (knowledge article (opens in a new tab)). Chapter 13 covers both.

Multi-factor authentication, MFA, means proving who you are with more than one kind of factor: something you know, such as a password, and something you have or are. Salesforce is now enforcing MFA for “all employee logins, including direct UI and Single Sign-On (SSO), across both production and sandbox orgs.” Enforcement started on July 10, 2026, for sandboxes and July 20, 2026, for production, in stages by release group. Privileged users and admins must use phishing-resistant MFA, such as security keys and the authenticators built into a laptop or phone (Prepare for MFA Enforcement for All Employee Users (opens in a new tab)). Chapter 2, the front door, teaches it.

Notice the words “including… Single Sign-On.” If your people log in through an identity provider, the identity provider’s MFA has to count, and Salesforce has to be told about it. That’s a single sign-on design question, and chapters 2 and 6 come back to it.

4. Device Activation for single sign-on

Device Activation is Salesforce asking a user to confirm a browser or device it doesn’t recognize. It used to apply to direct logins. Now it applies to single sign-on logins too: from January 26, 2026, for OpenID Connect identity providers, and from February 9, 2026, for SAML identity providers. Salesforce skips it when the device is already recognized, when the org’s trusted IP ranges are narrow enough, or when the identity provider used a secure method, such as MFA, and says so in the login (Changes to Device Activation for Single Sign-On (SSO) Logins (opens in a new tab), last updated February 24, 2026). Chapter 6 comes back to it, for SAML: the prompts, and what to check.

The pattern

Put the four side by side and a pattern appears.

The defaults are closing. Things that used to be on are off in new orgs, and you have to open them on purpose, if you can at all.
Secrets are leaving the browser. The retired flows put a password or a token where the browser, or someone watching it, could see it. Their replacements keep them out.
The login is asked for more proof. A password alone isn’t enough for staff; a familiar device, or the identity provider’s word, has to back it up.

Underneath all of them are the security principles: least privilege, defense in depth, failing securely, and need to know. Salesforce is applying them to its own defaults. The Sharing and Visibility course teaches them, with examples, in Four Principles, the Salesforce Way; this course uses them in every chapter. And for the longer story, from protocols that were never safe to tokens still being hardened today, the Integration Architect course has Security Keeps Changing, written for integrations.

How this course dates things

That’s why every platform fact in this course has a date beside it: the day the page was checked. When you read “checked 2026-11-07”, you know how fresh it is, and you know to check again if it’s old. When Salesforce changes something, the module says what was true before, what’s true now, and the date it changed. Not to tell history for its own sake, but because you’ll meet orgs built before the change, and you need to know why they look the way they do.

So treat every design as something you’ll revisit. Put the retirement dates in the plan. Read the release notes for identity every release. Identity runs for years once it’s set up, so somebody has to keep an eye on it.

What’s next

That’s the end of chapter 1. Next, the practice: draw your own login as a swim lane. Then chapter 2, the front door: how Salesforce checks who you are.

What an architect takes from this

Find the retiring flows now. Any integration on the username-password or user-agent flows stops on February 20, 2027.
Build new apps as external client apps.
Plan for MFA on every employee login, phishing-resistant for privileged users, including through single sign-on.
Check what your identity provider tells Salesforce about how the user proved who they are.
Date every decision, and read the identity release notes every release.

Explore

Each page read again 2026-11-07.

Retirement of OAuth 2.0 Username-Password Flow for Connected Apps (Release Update) (opens in a new tab), Summer ‘26 release notes
OAuth User-Agent and Hybrid User-Agent Flows Retirement (Release Update) (opens in a new tab), Winter ‘27 release notes
New Connected Apps Can No Longer Be Created in Spring ‘26 (opens in a new tab), Salesforce knowledge article
Prepare for MFA Enforcement for All Employee Users (opens in a new tab), Salesforce Help
Changes to Device Activation for Single Sign-On (SSO) Logins (opens in a new tab), Salesforce knowledge article