In December 2025, Salesforce put every AppExchange partner on notice. Connected Apps and External Client Apps that touch customer orgs had to meet a new set of OAuth security controls, and the message was blunt: comply, or face de-listing and suspension of your app's interoperation with Salesforce. For a partner whose business runs on the AppExchange, that is not a warning. That is the whole business on the line.
Most teams read the notice, saw the words "settings toggle," and assumed it was a lunch-break task. It is not. Flip the controls carelessly and you can sign every active user out of your app on their next token refresh. We took the opposite approach. We assessed each package on its own OAuth flow, sequenced the rollout so live customers never noticed, and verified every change before it left a sandbox. Here is the work.
The mandate
Four controls, and the fine print nobody reads
The official compliance date for the headline controls was May 11, 2026, set out in Salesforce's mandatory security update notice for Connected Apps and ECAs. The notice many of us received went further and flagged that Salesforce may begin suspending interoperation of non-compliant apps from June 25, 2026. If your packages are still untouched, that second date is the one that should be keeping you up at night.
PKCE
Proof Key for Code Exchange. Closes the authorization-code interception gap. It only applies to authorization-code flows, so the first job is knowing which of your apps actually run one.
Refresh Token Rotation
Every refresh issues a new token and kills the old one. Powerful, and the one most likely to break you: a single replayed token revokes the whole session. Token storage has to be transactional.
Idle Refresh Token TTL
Tokens idle past 30 days are dead. Rarely-used integrations need a refresh heartbeat, or they silently expire and your customer files a ticket wondering why the sync stopped.
Refresh Token IP Allowlist
Binds refresh to known ranges. Straightforward on paper, real infrastructure work for customers on dynamic IPs. Get the range wrong and legitimate traffic gets locked out.
The proof
The compliance ledger
We do not blanket-toggle controls across a catalogue and hope. We opened a review on every package, confirmed which OAuth flow it actually uses, and remediated only what each one genuinely needed. Here is the status of our in-scope portfolio, straight from our engineering tracker.
| App | Disposition | Status | Reference |
|---|---|---|---|
| Metadata Search | PKCE, RTR and 30-day TTL | Live in production | MS-270 |
| Mass File Migrate | PKCE, RTR and 30-day TTL | Live in production | MFM-283 |
| Azure Integration | PKCE, RTR, TTL plus auth modernization | Live in production | STA-309 / STA-274 |
| Quick Update Translations | PKCE, RTR and 30-day TTL | Live in production | QUT-139 |
| Mass File Upload | PKCE, RTR and 30-day TTL | Live in production | MFU-143 |
We did all of this in a single week. Every app in the register above was assessed, remediated, tested, and rolled out, including the managed-package upgrade pushed to more than 1,000 live customer orgs across our apps, without a single reported regression.
On the controls themselves, we enforced PKCE, Refresh Token Rotation, and the 30-day idle refresh token TTL. The fourth control, the Refresh Token IP allowlist, we assessed and deliberately did not enforce. Our customers connect from dynamic IP ranges, so a static allowlist would lock out legitimate traffic for no real security gain. Choosing not to apply a control where it does more harm than good is part of doing this correctly.
We also reviewed packages that turned out not to run an affected flow. Those we deliberately left untouched. Forcing irreversible controls onto an app for zero security gain is not diligence, it is risk. Knowing the difference is the entire job, and the teams that will get burned are the ones treating "enable everywhere" as a strategy.
For our Azure Integration app we also went a step past the minimum. We had already retired a legacy pattern that passed a Salesforce Session ID into client-side JavaScript and replaced it with a secure, supported authentication flow. That is the kind of hardening that survives the next security review, not just this deadline.
The method
How we shipped it without a single customer noticing
Inventory every Connected App and flow
We mapped each package to the exact OAuth flow it uses. Authorization-code, JWT bearer, server-to-server. The flow decides which controls even apply.
Reproduce in a sandbox, then break it on purpose
We enabled the controls in dev orgs and hit every integration twice. The second refresh is where rotation bugs surface. Ten minutes of this tells you what documentation never will.
Stage the rollout
Controls were sequenced so existing tokens kept working and no live customer was forced to re-authenticate unexpectedly.
Verify, package, and document for the next review
Each change was confirmed against acceptance criteria, packaged, and documented so the authentication story holds up at the next AppExchange security review.
Questions partners keep asking
The short answers
What did Salesforce require AppExchange partners to do?
Four OAuth controls on Connected Apps and External Client Apps: enable PKCE, enable Refresh Token Rotation, set an Idle Refresh Token TTL of 30 days, and configure a Refresh Token IP allowlist. The compliance date for the headline controls was May 11, 2026, with suspension of non-compliant apps flagged from June 25, 2026.
Does every app need PKCE and Refresh Token Rotation?
No. PKCE applies only to authorization-code flows, and rotation applies only to flows that issue refresh tokens. Server-to-server JWT bearer integrations issue no refresh token, so rotation does not apply. Assess each package on the flow it actually uses before enabling anything irreversible.
Can these controls be turned off after they are enabled?
No. Once locked and enforced on a Connected App they cannot be reverted. That is exactly why a staged, sandbox-tested rollout matters. A careless change goes live in front of every customer.
What is the Salesforce PKCE and RTR deadline?
The compliance date for enabling PKCE and Refresh Token Rotation on AppExchange Connected Apps and External Client Apps was May 11, 2026. Salesforce has flagged that it may begin suspending the interoperation of non-compliant apps from June 25, 2026.
What happens if my AppExchange app is not compliant in time?
Salesforce may de-list the app from the AppExchange and temporarily or permanently suspend its interoperation with Salesforce services. For an ISV partner that can interrupt every customer who relies on the app.
Can Satrang make my AppExchange app compliant?
Yes. We are a certified Salesforce PDO and have already shipped PKCE, Refresh Token Rotation and the 30-day idle TTL across our own in-scope apps, in a single week and across more than 1,000 customer orgs. We deliver per-package assessment, implementation, sandbox testing, a customer-safe rollout plan, and review-ready documentation.
Still staring at this deadline? We have already solved it.
If your Connected Apps are not yet compliant, the June 25 suspension date is close and the controls are irreversible. This is precisely the work we just finished across our own portfolio. As a certified Salesforce Partner Development Organization, we can do it for your packages, fast and without breaking your customers.
- Per-package flow assessment so you only change what is genuinely in scope
- PKCE, RTR, Idle TTL and IP allowlist implementation in your codebase
- Sandbox double-refresh testing to catch rotation failures before customers do
- A staged, customer-safe rollout plan for irreversible controls
- Documentation that holds up at your next security review
- Optional ongoing AppExchange engineering and consulting