Protecting What Crosses
Module 2 of 8 in the chapter Trust, Identity, and Integration Security, chapter 13 of the Integration Architect course. Each module stands on its own. Previous: Security Keeps Changing · Next: The Three Doors
The question this module answers: TLS protects the connection. What protects the data, and what should never travel at all?
The Channel Ends at Every Stop
Section titled “The Channel Ends at Every Stop”What protects a message between Salesforce and another server? TLS, from chapter 12. And it does, very well.
But follow a real message. It starts in Salesforce, goes to the middleware, say MuleSoft, and from there to the destination. Each hop is its own TLS connection. The message is encrypted on the wire to the middleware, and then, inside the middleware, it’s readable again: in memory, in its logs, in its queue if it waits. Then it’s encrypted again for the next hop. When you use TLS, you’re encrypting the channel. At each stop, the message is back to clear text. That’s how the pattern is designed.
The channel is encrypted hop by hop. The data can be encrypted end to end.
Sometimes that’s not enough. The message goes through hops you don’t trust, or a partner relays it, or it lands in a queue or a file share on the way. Then you encrypt the data itself: seal the payload in Salesforce, so it travels through every hop sealed, and only the destination can open it.
Sealing the Payload
Section titled “Sealing the Payload”In Salesforce, the tool is the Apex Crypto class. It “Provides methods for creating digests, message authentication codes, and signatures, as well as encrypting and decrypting information” (Crypto Class (opens in a new tab), Apex Reference Guide, checked 2026-11-07). Encrypt with encrypt or encryptWithManagedIV, sign with sign, check a signature with verify. You can encrypt in Salesforce, put the result in a platform event or an API call, and it travels sealed to the one system that can read it.
Two things to know before you reach for it.
It’s rare. I’ve used it maybe five or ten times in ten years. Usually transport-level security is enough, and the endpoint already has its own restrictions. Seal the payload when you have a real reason not to trust the stops in the middle, not by default.
The key becomes the problem. The moment you do your own encryption, you’ve moved the risk to the key. Where is it? Who can read it? How is it rotated, and what happens to old messages when it is? You have to know the algorithm, and you have to agree it with the other side. Don’t build a very strong locked door and then leave the back door open by storing the key somewhere careless. Named credentials and protected settings are where keys and secrets belong, never a record or the code (module 8).
Encrypting and signing answer different questions. Encryption says nobody else can read this. A signature says this really came from us, and nobody changed it. A webhook that proves itself with an HMAC signature, from chapter 8, is the second kind, and it’s far more common in integrations than the first.
At Rest Is a Data Decision
Section titled “At Rest Is a Data Decision”Once the data lands, in Salesforce or anywhere else, protecting it there is a different question: field-level security, encryption at rest, masking, Shield. The Data Architect course takes that apart, from classification to the protection matrix to when encryption is worth its cost (Classify, Then Protect), and chapter 6 of this course classifies what each integration carries.
For an integration architect, the habit is to think of it as a dial: field-level security, then stronger encryption at rest, then your own cryptography, each step stronger and each with more to manage. And first ask the client what their regulations require. If they’re under heavy regulation, they’ve usually already chosen. If not, you’re asking them, and you decide together.
What Never Travels
Section titled “What Never Travels”And then there’s data you never store at all.
A credit card number. The three- or four-digit security code on the card. A PIN. I’ve turned customers down when they wanted to store them in Salesforce. Don’t store them. Don’t let an integration carry them in. If you find them, get them out.
That isn’t just my rule. The payment card industry’s standard says sensitive authentication data, “including card validation codes and values,” can’t be stored after the payment is authorized, “even if the data is encrypted” (FAQ 1210 (opens in a new tab), PCI Security Standards Council, checked 2026-11-07, on PCI DSS requirement 3.3.1). PCI’s storage guidance adds: “Never store the personal identification number (PIN) or PIN Block,” and the card number itself must be “rendered unreadable anywhere it is stored” (PCI Data Storage Do’s and Don’ts (opens in a new tab), PCI Security Standards Council, 2008, checked 2026-11-07). Storing card data brings everything that touches it into the standard’s scope: the org, the integrations, the people.
That doesn’t mean you can’t take payments. You use a payment gateway, which holds the card, and Salesforce keeps a token that stands for it. The integration carries the token, never the card.
Look for it in the places nobody designed. I’ve seen it most at nonprofits: someone emails a card number and PIN, and email-to-case turns it into a record with an attachment. Email is the worst. The integration you didn’t build is still an integration.
Not Over the Internet
Section titled “Not Over the Internet”Sometimes the security team’s requirement isn’t about the data. It’s about the road: “This traffic doesn’t go over the public internet.”
If the other system runs in AWS, Salesforce has an answer for that: Private Connect. In Salesforce’s words, it lets you “route your cross-cloud traffic through the connection instead of over the public internet,” using AWS PrivateLink (Secure Cross-Cloud Integrations with Private Connect (opens in a new tab), Salesforce Help, checked 2026-11-07). It works both ways.
Private Connect: the same calls, off the public internet, in both directions.
Know its edges before you promise it (Considerations for Private Connect with AWS (opens in a new tab), Salesforce Help, checked 2026-11-07):
- AWS only. If the other system lives elsewhere, it isn’t the answer.
- An add-on license, and each license gives one connection in each direction.
- Inbound uses port 443. “Private Connect inbound doesn’t support port 8443, because that port is used by mTLS.” So you can’t have both Private Connect inbound and Salesforce’s inbound two-way TLS on the same calls. If the requirement says both, that’s a conversation to have early.
The road is private; the channel is still TLS; the data can still be sealed. They stack.
Proving the Caller
Section titled “Proving the Caller”One more protection belongs here, because it’s part of the road too: two-way TLS, where the client proves who it is with a certificate before anything else happens. Chapter 12 set it up on Salesforce in both directions: calling out, with the client certificate on the named credential; and calling in, with a certificate from a public authority, an API Only user, and port 8443 (Proving the Client Too).
When do you ask for it? When the integration must prove the machine, not just a password or a token: system-to-system connections carrying sensitive data, and anywhere a stolen secret alone mustn’t be enough. On Hyperforce, where IP addresses change, it’s also the replacement for locking a user to a list of addresses, as chapter 12 explains.
Five Layers, Not One
Section titled “Five Layers, Not One”Put the module together and you have layers, each answering a different question:
| Question | Answer |
|---|---|
| Can anyone on the road read it? | TLS, on every hop |
| Can the stops in the middle read it? | Seal the payload, when you can’t trust them |
| Should it travel at all? | Never card numbers, security codes or PINs: a gateway and a token |
| Does it go over the public internet? | Private Connect, if the other side is in AWS |
| Is the caller who it says it is? | Two-way TLS, when a secret alone isn’t enough |
Not every integration needs all five. Every integration needs an answer to all five.
Test knowledge. TLS encrypts the channel, hop by hop; data is readable again at each endpoint. For end-to-end protection through intermediaries, encrypt the payload (Apex
Cryptoclass: encrypt, sign, verify, MAC), and plan the key management. Never store card numbers, card security codes or PINs: use a payment gateway and tokens (PCI DSS). Private Connect routes traffic between Salesforce and AWS over AWS PrivateLink, inbound and outbound, as an add-on; inbound doesn’t support port 8443. Two-way TLS proves the client with a certificate.
What an Architect Decides Here
Section titled “What an Architect Decides Here”- For each integration, whether TLS on each hop is enough, or the payload is sealed end to end because of a stop you don’t trust.
- If you seal it: the algorithm, the key, where the key lives, and how it’s rotated, agreed with the other side.
- What never travels: card data, security codes and PINs kept out by design, with a gateway and tokens, and a check for the places nobody designed.
- Whether the traffic may use the public internet, and if not, Private Connect for AWS, or the network answer for anything else.
- Which integrations must prove the machine with two-way TLS, and how that sits with Private Connect.
Explore
Section titled “Explore”- Crypto Class (opens in a new tab): Apex Reference Guide (checked 2026-11-07)
- FAQ 1210 (opens in a new tab) and PCI Data Storage Do’s and Don’ts (opens in a new tab): PCI Security Standards Council (checked 2026-11-07)
- Secure Cross-Cloud Integrations with Private Connect (opens in a new tab) and Considerations for Private Connect with AWS (opens in a new tab): Salesforce Help (checked 2026-11-07)
- Classify, Then Protect: the Data Architect course, protection at rest
- Proving the Client Too: chapter 12, two-way TLS on Salesforce