The May 11 Connected App Deadline

The Summer '26 sandbox refresh got most of the attention this weekend, but the more consequential clock for Salesforce's partner ecosystem runs out on Monday. May 11, 2026 is the hard deadline for every AppExchange ISV to enable PKCE and Refresh Token Rotation on every Connected App and External Client App they ship. Miss it, and Salesforce can de-list the package from AppExchange or suspend its OAuth interoperation with customer orgs entirely. With 48 hours to go, partners are pushing last-minute hotfixes, customers are getting re-authentication emails they did not expect, and admins are being asked to sign off on changes most of them have not seen documented anywhere outside the partner portal.

Here is what changes on Monday, why Salesforce is forcing the issue, and what admins, developers, and ISVs should do today.

What May 11 actually requires

Salesforce is mandating four production OAuth controls and one monitoring recommendation on every Connected App or External Client App that an ISV ships to more than two customer production orgs. The list, after months of partner-portal back-and-forth, is now finalized:

1. PKCE (Proof Key for Code Exchange) for every authorization-code OAuth flow. PKCE binds the start of the OAuth dance to the token exchange so an intercepted authorization code is useless without the matching code verifier. It does not apply to JWT Bearer flows because those never see a browser redirect.
2. Refresh Token Rotation (RTR) on every flow that issues a refresh token. Each refresh request returns a brand-new refresh token; reuse of an old one is treated as evidence of theft, and Salesforce invalidates every active refresh token for that user-app pair. JWT Bearer is again exempt because it does not issue refresh tokens.
3. Refresh Token Idle Timeout of 30 days. Unused refresh tokens silently expire after a month. Mobile apps and infrequently-run integrations are the obvious losers here.
4. Refresh Token IP Range Allowlist restricting redemption to a list of static ISV IP addresses. This is the single largest infrastructure change for partners running on serverless or auto-scaling clusters.
5. Refresh Token IP Monitoring is recommended, not required. Salesforce will alert on geographic anomalies and unusual usage patterns even without an explicit allowlist.

PKCE and RTR have been configurable for months, but the last two controls only became toggleable around April 13, giving partners a tight four-week window to plumb everything through their token-storage layers. Beyond the Cloud's public guide calls multi-worker token persistence "the hardest part of the whole project," because rotated refresh tokens have to land in the store atomically across every worker that might race to redeem the next call - or one stale worker invalidates the whole session.

The scope language matters too. Customer-created Connected Apps - the ones an admin spins up in their own org for an internal Heroku integration - are not in the May 11 mandate. The deadline applies to apps that ISVs distribute, including:

• Connected Apps inside managed packages.
• Apps documented in implementation guides for the customer to create.
• Apps installed as unpackaged metadata at setup time.
• Anything sitting in a partner's namespace org or business org that customers authenticate against.

If your ISV team owns the credential, the deadline applies. If your customer owns it, it does not.

Why Salesforce is forcing it: 2025 was the worst year on record

The reason the Trust org is willing to threaten AppExchange de-listings is that 2025 was, by Salesforce's own internal language, the worst year for customer-data security in the platform's history. Three incidents in particular forced the policy:

• The Salesloft Drift supply-chain breach (August 2025). Threat cluster UNC6395, as documented by Google Cloud Threat Intelligence, used compromised OAuth tokens from the Drift integration to silently exfiltrate Cases, Accounts, Users, and Opportunities from more than 700 Salesforce tenants. The blast radius included Cloudflare, Cisco, and a long list of other enterprise customers. Salesloft pulled Drift offline; Salesforce removed the app from AppExchange and revoked every active token associated with it.
• The ShinyHunters / UNC6040 social-engineering campaign. Throughout the second half of 2025, threat actors persuaded employees at Google, Workday, and other large customers to approve malicious Connected Apps that impersonated Data Loader. Once authorized, the apps had legitimate OAuth grants and were difficult to detect from inside the org.
• The Gainsight incident (November 2025). Salesforce pulled Gainsight-published packages from AppExchange and revoked tokens after another OAuth compromise of an ISV-owned Connected App.

The pattern across all three is the same: a long-lived refresh token sitting in a third-party system gets stolen, the attacker exchanges it for a fresh access token, and Salesforce - which had no way to know the token was being redeemed by the wrong party - happily honored the request. PKCE blocks the front door. RTR makes a stolen token expire on first reuse. The IP allowlist makes the token unusable from anywhere outside the ISV's static egress range. Together they retire the trust model that broke in 2025.

This is also why the timing matters strategically. Salesforce's fiscal Q1 FY27 earnings call is on May 27, three weeks after the deadline. Analysts will press Marc Benioff on Trust posture and on whether the Agentforce 360 opening to ISV partners introduces new attack surface. Having every AppExchange Connected App on PKCE and RTR by then turns a hard question into a talking point.

Three compliance paths and what each costs

The Aquiva Labs breakdown and the Beyond the Cloud field guide both converge on three paths an ISV can take. The right one depends on packaging maturity and how much customer-side coordination the partner can absorb.

Path A: the May 11 hotfix. Enable PKCE and RTR on the existing Connected App in the source org, ship application-side code that handles the PKCE handshake and persists rotated refresh tokens, and let Salesforce propagate the toggles to every subscriber automatically. No new Consumer Key, no customer re-authentication, no package version bump. This is the path most partners are on right now. The risk is that flipping the toggle without correctly persisting rotated tokens silently breaks the partner's own integration in production.

Path B: full Connected App to External Client App migration. Rebuild the package against External Client Apps, which are the second-generation packaging successors to Connected Apps. This requires a new Consumer Key, a coordinated re-auth across every customer install, static egress infrastructure (NAT gateways, Elastic IPs, or proxies), and a heartbeat service to refresh tokens on integrations that run less than once a month. It is a multi-month rollout. Most partners are deferring this until Q3 or Q4.

Path C: sidecar 2GP package. Ship a separate second-generation managed package that contains only the ECA, alongside the existing first-generation package that contains the rest of the metadata. This avoids the full migration but requires ISVs that are not yet on 2GP to do a 1GP-to-2GP migration first, which is itself a large project.

The Spring '26 release already disabled net-new Connected App creation in customer orgs by default, so the ECA migration is inevitable for any partner planning to add new integrations after this year. The May 11 deadline is the security floor, not the finish line.

What it means for practitioners

Three things to do this week.

• Admins: Inventory every Connected App and ECA in your production org and tag each one as customer-created or ISV-shipped. Pull the OAuth Usage report from Setup, sort by last login, and confirm anything ISV-owned is being re-authorized after the toggles flip. If a vendor has not sent you a customer comms email by Monday, escalate. Existing Connected Apps will keep working, but any vendor that quietly enables RTR without persisting rotated tokens will break your integration in production within hours.
• Developers and architects: If you maintain a homegrown integration that lives inside your own Connected App, this deadline does not technically apply to you, but the platform direction does. Move new integrations to External Client Apps, enable PKCE on any authorization-code flow you control, and audit every long-lived refresh token in your token store. The Salesloft and ShinyHunters incidents were both refresh-token compromises that PKCE alone would not have prevented. Layered controls are now the baseline.
• ISV partners on Path A: Ship the application code today. Test PKCE and RTR end-to-end in a sandbox, confirm rotated refresh tokens land in your store atomically across every worker, and have your Trust contact on standby for Monday morning. If you are not going to make it, file the partner exception request before close of business Friday rather than risking a de-listing notification.

The May 11 deadline is the most consequential platform-policy date Salesforce has set since the TLS 1.0 retirement. It will not be the last. Expect formal end-of-support timelines for legacy Connected Apps, an enforcement push on the Spring '26 creation block, and tighter scoping of OAuth grants over the next two release windows. The orgs that come out clean are the ones that treat this week as the start of the program, not the end of it.