Salesforce Is Sending CA/ECA Non-Compliance Notices. Read Yours Before You Lock Anything

In the past few days, AgentExchange (formerly AppExchange) partners started receiving an email with a subject line that does not bury the lede: “LEGAL NOTICE: Notice of Partner Application Non-Compliance and Interoperability Suspension.”

Paraphrased: Salesforce’s records show one or more of your Partner Applications hasn’t implemented all four of the mandatory Connected App / External Client App security controls. Enforcement starts June 25, 2026, and after that a non-compliant app can have its ability to interoperate with Salesforce suspended until it’s fixed.

We covered the four controls — PKCE, Refresh Token Rotation, the 30-day Idle Refresh Token TTL, and the Refresh Token IP Range Allowlist — and the migration behind them here. This post is about the email, which has one big problem.

It tells you that you’ve failed. It doesn’t tell you what failed.

What the notice doesn’t tell you

The same story keeps coming up in the Partnerblazer community this week. Partners who enabled all four controls, confirmed them, and locked them on every CA and ECA they ship are getting the notice anyway. People open a support case and get told, in writing, that Support probably can’t help and to go to their PAM. The PAMs often can’t answer it either. And the Idle TTL bug that bit some partners back in April is still marked “under review,” so a chunk of the ecosystem can’t fully comply even if they want to.

You’re in one of two situations, and the email won’t say which:

• You have a real gap. Something you provide is in scope and is missing a control, and it might not be the app you’re thinking of.
• It’s a false positive. You’re compliant and Salesforce’s records are wrong or out of date.

The mistake is deciding you’re in the second group just because you know you’re compliant. Plenty of the partners flagged this week are compliant on the app they have in mind, and still have an unpackaged Connected App from an old onboarding flow, or one parked in their PBO, that nobody has looked at in two years.

How to find the flagged app

There’s no report that hands you the answer, so you reconstruct it by hand. Roughly in this order:

Start with an inventory of every CA and ECA you provide — not only the ones inside your managed package. The requirement covers any CA or ECA you provide or create that’s used in connection with a Partner Application. That pulls in unpackaged CAs installed during onboarding, CAs your install guide tells customers to create themselves, and CAs living in your PBO or namespace org.

Determine what’s actually in scope. The ISVForce guide limits this to any CA or ECA in use across more than two customer production orgs, so a private-listing app or a JWT-Bearer-only integration you’d written off might count — and a staging-only one might not.

Check the real state of all four controls — per app. Not what you meant to set: what’s actually enabled and locked on the version your subscribers are running. Most of the false confidence sits right here.

If you’re sure you’re compliant

Write it down: every app, every control, each one shown as enabled and locked. Then take it to your PAM directly, since Support is sending people there anyway. The difference between getting a false positive corrected and getting stonewalled usually comes down to whether you show up with a per-app breakdown or just the claim that you did everything.

Where we fit in

You’ve got a few weeks until June 25, and the diagnosis Salesforce left out of the email is yours to do. We’re offering a CA/ECA compliance audit before the cutoff: we go through every Connected App and ECA you provide, check the four controls on each, work out what’s genuinely in scope, and tell you whether you’re looking at a real gap or a false positive.

If it’s a false positive, you walk into the PAM conversation with the evidence to prove it. If there’s a real gap, you hear it from us instead of from a suspension on June 25 — and our development team can do the remediation work to close it before the deadline, whether that’s enabling and staging the controls on an existing app or the heavier ECA work behind it.