Salesforce Connected App to ECA: What the May 11, 2026 Deadline Actually Requires (and What It Doesn’t)

If you’re an AppExchange partner, you’ve read the email by now. Salesforce has put a hard deadline on the calendar (May 11, 2026) for a set of mandatory OAuth security controls covering every Connected App and External Client App that ISVs ship. The penalty clause is what wakes people up: AppExchange de-listing, plus temporary or permanent suspension of your application’s interoperation with Salesforce.

The deadline is real. The controls are non-negotiable. But the way it’s been communicated has caused two opposite reactions, both wrong: "It’s just a settings toggle, our team will handle it before lunch" and "This is a full ECA migration, we have to redo everything before May 11." The truth sits between those two and depends heavily on what you actually ship today.

This post is the version of the analysis we wish we’d had on day one, written for ISV engineering and product leads who need to know, accurately, what’s in scope, what isn’t, and what the realistic plan looks like.

TL;DR

For the partners who’d rather skim than scroll:

What you have to do by May 11, 2026:

1. Enable PKCE and Refresh Token Rotation on every Connected App or ECA your team owns in your ISV infrastructure orgs: PBO, packaging org, namespace org, any dev org you mint credentials in.
2. Update your application code to handle the PKCE handshake and persist rotated refresh tokens after every exchange.
3. Build a heartbeat or scheduled refresh if your integration can sit idle for more than ~25 days.
4. Plan for static egress IPs if your refresh-token-issuing flows run from a server you control. Salesforce’s current position is that the IP Allowlist is mandatory too, despite the short notice.

What you don’t have to do by May 11, but should be thinking about:

1. A full 1GP to 2GP migration. Salesforce permits a sidecar 2GP package containing only the ECA, installed alongside your 1GP core. That breaks the dependency between the May 11 deadline and a multi-quarter migration project.
2. The full CA-to-ECA migration, with its new Consumer Key and coordinated customer re-authentication, is on the roadmap eventually for everyone, but it doesn’t have to land on May 11 if your existing packaged Connected App can be kept compliant via the settings toggle. Plan it on your timeline, not Salesforce’s.

A few things that aren’t quite as scoped as you may have read:

1. PKCE only applies to authorization code flows. If you’re not running one, you’re not implementing it.
2. RTR only applies to flows that issue refresh tokens. JWT Bearer integrations (the workhorse for server-to-server ISV setups) don’t issue refresh tokens, so RTR is structurally not applicable.
3. Connected Apps that subscribers create themselves in their own orgs are not in scope for May 11. That’s the customer’s CA, not yours. The next AppExchange Security Review is a different conversation.

Why this is more work than it looks:

1. RTR has a nasty failure mode for multi-worker setups. Any attempt to redeem an already-rotated refresh token is treated as evidence of a stolen-token incident, and Salesforce invalidates every active refresh token for that user-app pair. One buggy retry can drop the whole session.
2. Token storage needs to be transactional, with a single writer per refresh-token chain.
3. Static egress, when you don’t already have it, is multi-week cloud engineering work on your side of the integration.
4. Mobile applications can’t realistically meet the 30-day idle timeout via a server-side heartbeat. The refresh token sits on the device, not on a server you control. That one is awkward and there isn’t a clean answer yet.

The full reasoning, the path options, and a realistic checklist are below.

What Salesforce is actually mandating

Five controls. Two are available today. Two became visible to partners around April 13, roughly three weeks before the deadline. One is operational, not technical.

If you’re estimating the work and assuming you’ll get final implementation guidance with comfortable headroom, you won’t. Plan for discovery time.

Who is in scope (and who isn’t, despite what you may have read)

The clearest read of what Salesforce is asking: the controls apply to Connected Apps and ECAs created in your ISV infrastructure orgs: your Partner Business Org, your packaging orgs, your namespace org, any developer org you use to mint credentials your customers consume. Packaged or not. If your subscribers are talking to your service using credentials your team owns, the May 11 controls apply.

Two cases that often get pulled into scope incorrectly:

Connected Apps your customers create themselves. If your implementation guide instructs the customer to set up their own Connected App and you do not own the Consumer Key, the May 11 mandate doesn’t apply. That’s the customer’s CA, not yours. Your next AppExchange Security Review will likely push back on this pattern for any flow where the ISV ends up holding credentials, and packaged ECA replaces a lot of these patterns going forward, but the May 11 hammer doesn’t hit you here.

Edge cases packaged ECA doesn’t yet support. SAML is the example most often raised. If your integration depends on a flow not yet covered by packaged ECA, you may legitimately still need a customer-created CA today, and Salesforce’s current position is that those edge cases will be addressed before the customer-created pattern is fully retired.

One scope claim worth taking as firm: the mandatory controls apply to any CA/ECA in use by more than two customer production orgs. Two-or-fewer is currently treated as out of scope, with a strong recommendation to implement anyway.

PKCE and RTR don’t apply to every OAuth flow

This is a piece of nuance worth slowing down for, because most public summaries are flatly wrong on it.

PKCE is a control on the authorization code flow family (Web Server, User-Agent variants). If you’re not running an authorization code flow, PKCE is not a thing you implement.

Refresh Token Rotation only applies to flows that issue refresh tokens in the first place. The JWT Bearer flow (the workhorse for server-to-server ISV integrations where the customer pre-authorises the ISV once and the ISV mints short-lived access tokens on demand) does not issue refresh tokens. RTR is structurally not applicable to a pure JWT Bearer integration.

This matters because the entire conversation about race conditions, token-locking, and the new cascade-invalidation failure mode only applies if your architecture uses refresh tokens. Map your actual flows before you panic about your distributed systems design.

Where you do issue refresh tokens, the race condition story is real and a little nastier than the official guidance lets on. Once a refresh token has been rotated, attempting to redeem the old one is treated as evidence of a stolen-token incident, and Salesforce invalidates every active refresh token for that user-app pair. Token storage needs to be transactional, with a single writer per refresh-token chain.

Two paths to compliance, and a third that most write-ups miss

Almost everyone summarising this deadline lumps the work into a single big migration. It’s actually three different shapes of project.

Path A, the lightweight hotfix

If you have a packaged Connected App live in customer orgs today, and your OAuth flow is one where PKCE and RTR are applicable, you have a lightweight option for May 11. Enable PKCE and RTR on the Connected App in the source org where it was originally defined; Salesforce propagates those settings to every subscriber automatically. No new package version, no Consumer Key change, no customer re-authentication. The work that lands on your team is application-side: implement the PKCE handshake, persist rotated refresh tokens, harden your token storage against concurrent writes.

This is the right answer for May 11 for a lot of partners. It is not a long-term plan (Connected Apps and 1GP are visibly being sunset), but it buys you time.

Path B, the full ECA migration

This is the work most of the panicked write-ups are describing. New ECA created in your source org, ECA metadata packaged into a 2GP managed package, application code updated for the new Consumer Key, Security Review re-submission, and a coordinated re-authentication across every customer because the new Consumer Key means a new handshake. The re-authentication phase alone is its own program: comms, downtime windows, support coverage, and a long tail of enterprise customers who don’t move quickly between QBRs.

Path C, the sidecar 2GP

The path most public summaries miss, and the one that changes the calculus for partners on 1GP. You do not need to migrate your core 1GP package to 2GP in order to ship a packaged ECA. Salesforce permits standing up a separate 2GP package that contains only the ECA metadata, distributed alongside your existing 1GP managed package. Installation becomes a two-step process. Not elegant, but it breaks the dependency between the May 11 deadline and a full 1GP-to-2GP migration project.

If you’ve been reading that the May 11 deadline forces 1GP partners to run a 1GP-to-2GP migration in parallel with the ECA migration before May 11, that’s not what Salesforce is actually saying. The sidecar 2GP is a real, supported pattern.

Gotchas worth knowing now

A few things that will save you a day each:

• ECAs cannot be created in scratch orgs. Create them in your Partner Business Org or Dev Hub. The packaging error from a scratch-org-created ECA is not obvious about the cause.
• Don’t share the Consumer Secret in Security Review submission. Share the Consumer Key only.
• ECA metadata names are case-sensitive in CLI retrieves. ExternalClientApplication and ExtlClntAppOauthSettings. Exactly those.
• Static IP changes need a precise sequence. Add new ranges via a Salesforce support case, wait for confirmation, do the infrastructure cutover, then raise a follow-up case to remove the old ranges. Removing old ranges before new ones are active fails every customer’s authentication immediately.
• "Source org," not "packaging org." The org that owns the global Consumer Key is the source org. The distinction matters for governance, MFA enforcement, and break-glass procedures.

Mobile is the awkward case

If your integration is a mobile app, the 30-day idle timeout is the control that’s going to hurt the most. A typical user might open your app two or three times a year. There is no realistic server-side heartbeat that helps you here, because the refresh token sits on the device. The current best-effort answer is push notifications nudging users back into the app within the 30-day window plus graceful re-authentication when they miss it. The user-experience cost of forcing re-auth every 30 days for an inactive user is not nothing.

There’s a credible argument that 60 days would be a much more workable threshold for genuine mobile use cases without weakening security posture. Worth feeding back to your Salesforce account team if mobile is your primary distribution channel.

A realistic triage checklist

Where you start depends on how much runway you have. Same work, different cuts.

If you have a week or more left:

1. Inventory your CAs and ECAs across every ISV infrastructure org, packaged or not.
2. Map each one to its OAuth flows. PKCE applies to authorization code flows; RTR applies to flows that issue refresh tokens.
3. Decide the path per app. Hotfix on existing CA (Path A), full ECA migration in core package (Path B), or sidecar 2GP (Path C). Different apps in the portfolio can take different paths.
4. Stand up static egress for any server-to-server integration that issues refresh tokens. Longest-lead infrastructure item. Start now.
5. Build the heartbeat for any integration that can sit idle for more than ~25 days.
6. Audit your token storage for transactional semantics under concurrency.
7. Plan the customer rollout if you’re shipping a new ECA. Comms, downtime windows, re-auth instructions, support coverage.
8. Submit (or re-submit) for AppExchange Security Review. Plan for at least one round of findings.

If you have days left:

Cut to the controls Salesforce can verify on the deadline.

1. Toggle PKCE and RTR on every CA/ECA your team owns in source orgs. The setting flip propagates to subscribers automatically and is the visible compliance signal.
2. Ship the application-side code to handle the PKCE handshake and persist rotated refresh tokens. Without it, the toggle breaks your own integration.
3. Drop in a minimum-viable heartbeat for any flow that can sit idle past 25 days. Even a scheduled refresh stub is enough to keep tokens alive.
4. Send a written posture update to your Salesforce account team. Which controls are live, which are in-flight, target date for the rest. This is what protects you against de-listing while the longer items finish. Static egress, full ECA migration, and customer rollout typically land here.
5. Defer Path B / sidecar 2GP / Security Review re-submission to a planned roadmap. None of those are getting cleanly across the line in days.

If May 11 has already passed:

1. Confirm what’s actually live in your source orgs. Any toggle that flipped is good evidence; absence of one is the gap.
2. Open the conversation with Salesforce now. A written remediation plan ahead of an enforcement notice is different from one filed after. Include a dated control-by-control status.
3. Land PKCE + RTR + persisted refresh tokens first. It’s the cheapest item that moves you out of the highest-risk bucket.
4. Watch for partner comms about de-listing or interop suspension. Triage any customer-impacting alerts ahead of the next package push.
5. Treat the rest as a normal program. Static egress, ECA migration, sidecar 2GP, Security Review re-submission. Sequence on your roadmap, not Salesforce’s clock.

Honest read on any of the three buckets: complex external clients (multi-worker server-to-server integrations on flows that issue refresh tokens) are unlikely to be fully clean on day one. The conversation worth having internally is which controls you have live, which you have an in-flight plan for, and how you communicate that posture to Salesforce, before they ask, not after.

How Beyond The Cloud can help

This deadline lands in a year where most ISV engineering teams already have Agentforce on the roadmap, Security Review re-submissions in flight, and customer commitments that don’t pause for platform mandates. The work itself isn’t conceptually hard. It’s just a lot of it, on a tight clock, with discovery time built into nearly every step.

That’s the gap we work in. Beyond The Cloud is a Salesforce-focused engineering team with deep AppExchange and ISV experience, and we’ve helped partners ship through every flavour of platform transition. For the May 11 deadline specifically, we can help with:

• Scope evaluation. Mapping your actual OAuth flows to the five controls, identifying which apply, and separating the "must do by May 11" from the "plan on your roadmap." A short conversation can save weeks of misdirected engineering work.
• Connected App to External Client App migration. New ECA creation, packaging, application-side changes for the new Consumer Key, Security Review re-submission, and the customer rollout program.
• 1GP to 2GP migration. Whether that’s the full migration on your own timeline, or the sidecar 2GP pattern as the fast-path option for May 11.
• OAuth and infrastructure work. PKCE and RTR implementation in your external application, transactional token storage for multi-worker setups, static egress design for AWS / GCP / Azure, and the heartbeat service for infrequent integrations.
• Delivery capacity. If your engineering team is already committed and you need a delivery partner to run the program end-to-end while your internal roadmap stays intact.

If you want a second pair of eyes on your scope decisions, your packaging strategy, or any part of the application-side work, reach out at contact@beyondthecloud.dev or via LinkedIn. A short conversation will tell you honestly whether your current plan still hits the deadline, and what to change if it doesn’t.