Skip to content
SteveTechArcSteveTechArc Courses

Security Keeps Changing

Module 1 of 8 in the chapter Trust, Identity, and Integration Security, chapter 13 of the Integration Architect course. It builds on chapter 12, the shared chapter Keys, Certificates and Trust. Each module stands on its own. Previous: Keys, Certificates and Trust · Next: Protecting What Crosses

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

A Protocol That Was Never Safe

Section titled “A Protocol That Was Never Safe”

Let me start this chapter with a file transfer.

For decades, the way one company sent a file to another was FTP, the File Transfer Protocol. You connected, you sent a username and a password, and you sent the file. Simple, and everywhere. And completely open. The standard’s own security guidance says it plainly: “Standard FTP sends passwords in clear text,” and “All data and control information (including passwords) is sent across the network in unencrypted form” (RFC 2577, FTP Security Considerations (opens in a new tab), IETF, May 1999, checked 2026-11-07).

Remember the bandits in chapter 12? No matter what you do, they’re going to find a way to intercept the message in some form. FTP didn’t even put it in a bottle. Anyone on the path could read the password, and then the files.

The fix wasn’t to stop sending files. It was to send the same files over an encrypted channel: SFTP, file transfer over SSH, or FTPS, FTP over TLS. At Steve Trucking, Keystone’s nightly status file goes as a CSV over SFTP (chapter 5). What if a new partner says, “We just use FTP”? That’s the first conversation, before any other design.

Thought Secure, Then Not

Section titled “Thought Secure, Then Not”

TLS is the secure channel from chapter 12: the handshake that lets two strangers agree on a key in plain sight. And for years, TLS 1.0 was that channel. It was the right answer.

Then weaknesses were found, and the standard changed its mind. Today it says: “TLS 1.0 MUST NOT be used,” because the old versions “lack support for current and recommended cryptographic algorithms and mechanisms” (RFC 8996, Deprecating TLS 1.0 and TLS 1.1 (opens in a new tab), IETF, March 2021, checked 2026-11-07).

Salesforce moved before the standard did. In 2015 it announced: “In early 2017, Salesforce will disable TLS 1.0 and will begin using TLS 1.1/1.2 exclusively,” sandboxes first, on June 25, 2016, then production, on March 4, 2017 (Disabling TLS 1.0: Preparing Mobile SDK Apps for the Big Change (opens in a new tab), Salesforce Developers Blog, November 2015, checked 2026-11-07). Every integration still speaking TLS 1.0 had to change, or stop.

That’s the step that matters for an architect. Nobody did anything wrong. The integration was built on what was secure. The ground moved.

Fine for Its Time, Now Retired

Section titled “Fine for Its Time, Now Retired”

The same thing is happening right now to the ways integrations sign in.

Two OAuth flows that many integrations were built on are being retired on Salesforce, both on February 20, 2027:

Notice the accuracy here. The username-password flow doesn’t send the password in plain text the way FTP did: the request goes over TLS. The problem is different. The integration has to hold a person’s real credentials, and send them every time. These flows were reasonable when they were designed. They aren’t the safest answer anymore, so they’re going. Module 5 teaches what replaces them.

Secure Today, Still Being Hardened

Section titled “Secure Today, Still Being Hardened”

And the flows we use today? They’re secure. They’re also still being hardened, because the attackers moved. Instead of breaking the channel, they steal the tokens (module 3 tells those stories).

So the tokens themselves are changing. Salesforce now recommends refresh token rotation, because “Refresh tokens that can be reused multiple times create a security vulnerability because a single stolen token provides ongoing unauthorized access to Salesforce.” With rotation, each refresh token works once (Enforce One-Time-Use Refresh Tokens with Refresh Token Rotation (RTR) in Salesforce (opens in a new tab), Salesforce Help, published October 21, 2026, checked 2026-11-07). And with DPoP, a token can be tied to the client it was issued to: it “binds access and refresh tokens to a key pair,” so a stolen token can’t be “replayed by a different client” (OAuth 2.0 Demonstrating Proof of Possession (DPoP) (opens in a new tab), Mobile SDK Development Guide, checked 2026-11-07). Module 7 takes both apart.

Four Steps, One Lesson

Section titled “Four Steps, One Lesson”
Security keeps changing Security keeps changing: four steps down a line, numbered. 1, insecure from the start: FTP, where the password crossed the wire as plain text; the same files now move over an encrypted channel, SFTP or FTPS. 2, thought secure, then not: TLS 1.0, where weaknesses were found, and the standard now says it must not be used; Salesforce switched it off, sandboxes in 2016 and production in 2017. 3, fine for its time, now retired: OAuth flows that send a password or hand the token to the browser; Salesforce retires them in 2027. 4, highlighted, secure today, still being hardened: the tokens integrations use now; each refresh token works once, and tokens can be tied to the client. Underneath: something secure yesterday may not be secure today or tomorrow; keep evaluating. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-03", "id": "DGM-INT-TW-01", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "flow/sequence 0.1.0", "theme": "stevetecharc 1.4.0"} Insecure from the start FTP: the password crossed the wire as plain text The same files now move over an encrypted channel: SFTP or FTPS. Thought secure, then not TLS 1.0: weaknesses were found; the standard now says it must not be used Salesforce switched it off: sandboxes in 2016, production in 2017. Fine for its time, now retired OAuth flows that send a password, or hand the token to the browser Salesforce retires them in 2027. Secure today, still being hardened the tokens integrations use now Each refresh token works once; tokens can be tied to the client. 1 2 3 4 WHAT HAPPENED Something secure yesterday may not be secure today or tomorrow. Keep evaluating. HOW TO READ IT 1 the order a step the step that matters most what comes next © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Insecure from the start, thought secure, fine for its time, secure today: and today isn’t the last step.

Here’s the lesson I want you to take into every integration you design. Security isn’t something you look at once. It’s something you keep evaluating, as systems and capabilities change. Something secure yesterday may not be secure today or tomorrow, and we need to be ready to evolve and address it.

That changes what “done” means. An integration isn’t secured on go-live day. It’s secured on go-live day, and then it has to stay that way.

What It Means for Your Integrations

Section titled “What It Means for Your Integrations”

Three habits follow from it.

Know what every integration uses. For each arrow on the landscape: how it travels (FTP or SFTP, which TLS), and how it signs in (which OAuth flow, which kind of credential). That’s the inventory from chapter 5, with two more columns. You can’t retire what you can’t find.

Read the release updates. Both retirements above came as Salesforce release updates, announced releases ahead, with a date. Someone owns reading them, three times a year, and checking the inventory against them.

Plan the change before the date. When something you use is retiring, the work is a project: a new flow, new credentials, a test, a cutover. February 20, 2027 is a deadline, not a suggestion.

The Rest of This Chapter

Section titled “The Rest of This Chapter”

Chapter 12 gave you the ground under all of it: keys, certificates and the handshake. This chapter builds the integration on top.

  • Module 2: protecting what crosses, past the channel.
  • Module 3: the three doors attackers used in 2024 to 2026.
  • Module 4: one integration, one identity.
  • Module 5: choosing a flow.
  • Module 6: what to build on.
  • Module 7: tokens as a design decision.
  • Module 8: secrets, and your lab bench.

Test knowledge. Know which mechanisms are retired and why, in Salesforce’s words: TLS 1.0 (off in production since March 4, 2017); the OAuth username-password flow (“directly passes the user’s credentials”) and the user-agent and hybrid user-agent flows (“directly expose access tokens to the browser”), both retired February 20, 2027, with web server with PKCE or client credentials in their place. Know what today’s hardening adds: refresh token rotation and DPoP.

What an Architect Decides Here

Section titled “What an Architect Decides Here”
  • For every integration: how it travels and how it signs in, written in the inventory, with the date you checked.
  • Who reads the release updates, and checks the inventory against them, every release.
  • What retires next in your landscape, and the date the replacement is live, well before Salesforce’s.
  • What you’d say to a partner on plain FTP, or any channel that sends a password in the clear, before anything else is designed.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.