Mandatory Security Requirements for Connected Apps and External Client Apps Required by May 11, 2026

A few weeks ago, an email from Salesforce Partner Programs landed in hundreds of AppExchange partners’ inboxes. The subject line was calm. The content wasn’t.

The message, paraphrased: by May 11, 2026, every Connected App or External Client App provided by an AppExchange partner and in use across production orgs must implement a new set of mandatory security controls. Failure to comply may result in the Partner Application’s AppExchange de-listing and/or Salesforce’s temporary or permanent suspension of the Partner Application’s interoperation with Salesforce’s services.

Read that last sentence twice. That is not a roadmap memo. That is a hard deadline with a suspension clause attached.

In the conversations I’ve had since, the reactions from partner leadership have clustered into three groups:

• The partners who read it carefully, opened a Jira ticket, and started scoping.
• The partners who skimmed it, thought “probably a config change” and moved on.
• The partners who haven’t opened it yet because they were in a board meeting.

If you’re in group 2 or 3, this post is for you. Because this is not a config change. It’s a multi-workstream engineering program with a hard deadline, and the scope is bigger than most partners I’ve spoken to initially assumed.

TL;DR:

– May 11, 2026 is a hard deadline for PKCE and Refresh Token Rotation across every Connected App and ECA you ship.

– For an existing packaged Connected App, meeting that deadline can be as light as a settings toggle plus application-side code changes. Salesforce propagates the settings; customers do not need to re-authenticate.

– But Connected Apps and 1GP are on a sunset path. Spring ’26 already disabled creation of new legacy CAs. Every partner will end up on ECA and 2GP eventually — the question is whether you plan that migration on your schedule or run it under pressure.

– The full ECA migration is a code + infrastructure + packaging + rollout project, and it ends with a new Consumer Key and a coordinated customer re-authentication.

Let’s walk through what’s actually being asked, why Salesforce is asking for it now, and what a realistic plan looks like.

A 30-Second Self-Check

Does any of the following describe your product? Then May 11 is on your roadmap whether you’ve planned for it or not.

☐ You ship a Connected App or ECA inside your managed package.

☐ Your implementation guide documents a Connected App for subscribers to create themselves.

☐ Your onboarding installs a Connected App as unpackaged metadata during setup.

Any yes puts you in scope.

What Salesforce Is Actually Requiring

Salesforce is mandating five security controls across every Connected App (CA) and External Client App (ECA) that AppExchange partners ship.

At the executive level, here is what each control does and what it asks of your engineering team:

Why Salesforce Is Doing This Now

The timeline feels aggressive. It is aggressive. But it isn’t bureaucratic — it’s reactive.

2025 was the worst year for Salesforce customer data in the platform’s history, and OAuth Connected Apps were the attacker’s weapon of choice. ShinyHunters (UNC6040) social-engineered employees at Google and Workday into approving malicious Connected Apps masquerading as Data Loader. The Salesloft Drift supply-chain attack compromised OAuth tokens across 700+ Salesforce tenants through a single trusted integration. In November, Salesforce pulled Gainsight-published apps from AppExchange and revoked all active tokens after another OAuth compromise. By April 2026, attackers were publicly claiming 3M+ records from a Cisco-attributed incident.

Every one of these breaches shared a shape: the attacker didn’t break Salesforce. They walked in through an OAuth connection.

Each of the five mandated controls maps to a specific technique used in a 2025 breach. PKCE closes the code-interception vector. Refresh Token Rotation neutralizes stolen tokens on first reuse. The 30-day idle timeout kills the dormant-token scenario. Static IP binding makes an exfiltrated refresh token useless from any location the attacker isn’t already inside.

The timeline is aggressive because the threat landscape is aggressive. Salesforce isn’t ahead of the market on this. It’s catching up.

Two Timelines: The May 11 Deadline and the Inevitable Migration

Before we get into scope, it helps to separate two different projects the May 11 deadline can trigger — and to be honest about which of them you can defer, and which of them you can’t.

The May 11 Deadline: enable PKCE and RTR on what you already ship. If you have a mature, packaged Connected App already running in customer orgs, meeting May 11 can be relatively light. You enable PKCE and Refresh Token Rotation in the org where the CA was defined, Salesforce propagates those settings to every subscriber automatically, and you update your external application code to handle the PKCE handshake and rotated refresh tokens. No new package version. No Consumer Key change. No customer re-authentication. For many partners, this is the right answer for May 11 — and it is a real option.

It is not a long-term plan.

The inevitable migration: move to ECA on 2GP. Connected Apps and 1GP are being sunset. Salesforce has already disabled creation of new legacy Connected Apps as of Spring ’26. ECA-only capabilities are already shipping. A hard retirement date for legacy CAs hasn’t been announced, but the direction is not subtle. Every AppExchange partner will end up on ECA and 2GP. The only real variable is whether that migration happens on your roadmap, on your timeline, paired with a product investment you would have made anyway — or whether it happens under pressure when Salesforce sets the retirement date and the whole ecosystem scrambles at once.

Treat May 11 as a critical deadline for the bare minimum, not a destination. The hotfix buys you time. It does not buy you out.

You are on the immediate migration path if any of the following are true:

• You need to build new Connected App functionality. (New legacy CAs can no longer be created.)
• Your product uses the “subscriber creates the Connected App post-install” pattern. (Security Review won’t accept this going forward for any flow where the ISV holds the Consumer Key.)
• You’re on 1GP and want packaged ECA metadata. (ECA metadata only works in 2GP.)
• You want to use ECA-only capabilities as they ship.

If you’re in one of those situations, the hotfix isn’t really available to you — you’re on the full migration right now. If you’re not, you have a choice about timing. But not about destination.

The Scope Is Bigger Than Most Partners Think

Here is where, in my experience, most partner conversations take a turn.

The instinct — especially if your current packaging is tidy — is to think: “We have one Connected App in our managed package. We’ll update it, ship a new version, done.”

Unfortunately, the scope is broader than that.

All Connected Apps you provide are in scope for PKCE and RTR, packaged or not. The Salesforce requirement doesn’t apply only to CAs bundled inside your managed package. It applies to any CA or ECA that is “included or used in connection with a Partner Application, provided or created by the Partner, and in use by production orgs.” That includes:

• Connected Apps inside your managed package.
• Connected Apps installed as unpackaged metadata during implementation.
• Connected Apps documented in your implementation guide for customers to create themselves.
• Connected Apps running on your side of the integration, living in your Partner Business Org, Namespace Org, or any org you use to mint credentials.

The “customer creates the Connected App post-install” pattern is effectively dead. For any flow that requires the ISV to hold the Consumer Key — JWT Bearer being the most common example for server-to-server integrations — the guidance is clear: documenting this for the subscriber to do post-install will fail AppExchange Security Review. If your ISV needs the credentials, you must package the ECA and distribute it. No more install guides that say “now go to Setup → Connected Apps and create one with these settings.”

Uninstalled Connected Apps are not a loophole. If your product relies on a Connected App installed via unmanaged metadata during onboarding, Salesforce Support has confirmed these still need to meet the PKCE and RTR requirements. A hard retirement date for this pattern hasn’t been published yet, but the direction is unambiguous: they’re being phased out.

New Connected Apps can no longer be created. As of Spring ’26, creation of new legacy Connected Apps is disabled by default. If your migration plan requires a brand-new CA for some edge case, that path is already closed without a support override. You’re building ECAs from here on.

ECAs require 2GP. This is the dependency a lot of 1GP ISVs haven’t fully internalized. ExternalClientApplication and ExtlClntAppOauthSettings metadata cannot be added to a 1GP managed package. If you’re still on 1GP and you need a packaged ECA, you’re running a 1GP-to-2GP migration in parallel with your CA-to-ECA migration, and both have to land before May 11. (We wrote about the 1GP-to-2GP business case here — worth a read if you’re still debating the timing.)

If any of those bullet points describe your situation, your scope just expanded.

Why This Is a Development Project, Not a Configuration Change

The rest of this piece is about the ECA migration in detail — the work you will do eventually, and the work you may be doing right now if you’re on the immediate migration path.

Partners tend to underestimate how much of the ECA migration lives outside the Connected App metadata.

Your application code needs real changes. PKCE requires the code verifier/challenge handshake on every OAuth flow. RTR requires your token store to persist the new refresh token after every exchange — and if you have multiple workers hitting the same Salesforce tenant, you now have a distributed-systems problem around token locking. Get that wrong and you’ll see intermittent authentication failures in production that are genuinely hard to debug.

Your server-side infrastructure needs static IPs. The IP allowlist is an additional control, not mandatory for May 11, and it is effectively inapplicable to public-facing mobile applications where clients connect from arbitrary consumer networks. If you do adopt it for a server-to-server integration on AWS, GCP, or Azure, you may currently be using elastic or dynamic egress. Moving to a static IP range means NAT gateways, Elastic IPs, egress controllers, or a dedicated proxy layer — and then coordinating with Salesforce Support to register those ranges, one at a time, without removing the old ones until the new ones are confirmed active. This is cloud engineering work on your side of the integration, not Salesforce work.

Your infrequent integrations need a heartbeat. The 30-day idle timeout means any integration that might sit idle for longer — a rarely-used customer, a seasonal workload, a backup flow that only fires on certain conditions — will silently lose its refresh token. The fix is a lightweight heartbeat service refreshing tokens every 25–28 days. That’s new infrastructure with its own health monitoring.

Your ECA origin org becomes a critical dependency. When you package an ECA, you generate the global Consumer Key in your Dev Hub (or equivalent packaging org) and that org becomes the source of truth for every subscriber’s credentials via Salesforce’s global replication. If you lose access to that org, deactivate the ECA, or delete it — every subscriber breaks. That has implications for org governance, MFA enforcement, user offboarding, and backup that most partners have never had to think about for a Connected App.

What the Official Guidance Doesn’t Tell You (Yet)

Partners who’ve been in the Partnerblazer Slack and on the phone with Salesforce Support over the past few weeks are seeing three consistent patterns.

The scope guidance is inconsistent. Ask three people at Salesforce — support rep, partner account manager, someone at office hours — whether a specific kind of Connected App is in scope, and you’ll often hear three different answers. Uninstalled CAs, subscriber-created CAs, CAs used only in your staging environments — each of these has prompted conflicting guidance depending on the source. This is normal for a rollout this size three weeks in. The safest default: if your product relies on it and customers are using it, assume it’s in scope and plan accordingly.

Two of the five controls landed late. The Refresh Token Idle Timeout and IP Range Allowlist settings became available to partners in April, roughly four weeks before the deadline. Documentation at release was thin, and the edge cases partners care about (infrequent integrations, multi-region deployments, failover scenarios) aren’t fully covered in public docs. If your team is estimating from official material alone, expect discovery time.

Tooling has rough edges. We’ve seen secret rotation error out for packaged ECAs in specific configurations — the kind of issue you only find by trying it. The ECA metadata has case-sensitive retrieval quirks in the Salesforce CLI. .forceignore patterns for packaged vs non-packaged ECA metadata are easy to get wrong and produce opaque packaging errors. None of these are showstoppers, but each one burns a day or two the first time you hit it.

None of this is a reason to wait. It’s a reason to plan for discovery time in your estimate — and a reason to lean on people who’ve already hit the walls.

The Rollout Is Its Own Project

A scope note: the rollout program described here applies when you ship a new ECA, because the new ECA has a new Consumer Key. If you’re only enabling PKCE and RTR on an existing packaged Connected App as a hotfix for May 11, Salesforce’s automatic propagation does most of this work for you and customers generally don’t need to re-authenticate. When you eventually run the full ECA migration, this is the program that lands on your desk.

Here is the part of the ECA migration that catches even disciplined engineering teams off guard. Assume, optimistically, that by end-April you have a new package version ready. Code is updated. Infrastructure has static IPs. ECAs are packaged. Everything passes internal testing.

You are roughly halfway done.

Because the new ECA has a new Consumer Key, every existing customer must re-authenticate to establish a new handshake between your service and their org. That means a coordinated rollout with several moving pieces:

• Customer communication. Every existing customer needs advance notice, a downtime window (even if small), clear instructions, and a support channel.
• The re-authentication handshake. In most flows this is a one-time action, but it requires someone on the customer side to do it. Large enterprise customers move slowly. Some will need a scheduled maintenance window.
• Post-deployment monitoring. You’re watching authentication success rates, IP mismatches, token rotation failures, and RTR race conditions under real production load.
• Legacy deprecation. Only after every customer is on the new ECA can you remove the legacy Connected App from your package. Until then, you’re maintaining both.

If you have 500 customers, the re-authentication phase alone is a multi-month program run by customer success and support, not engineering. If you’re enterprise-heavy, with customers who don’t touch their integrations between QBRs, expect a long tail.

Where Aquiva Labs Fits In

I’ll be direct. This is a significant body of work, landing in a narrow window, in a year where most engineering teams already have Agentforce on their roadmap, AgentExchange positioning to figure out, and probably more than one customer escalation demanding attention.

We’re hearing a consistent message from partners: “We understand what needs to happen. We don’t have the bench to do it on this timeline without dropping something else.”

That’s the gap Aquiva Labs is built for. As a Salesforce Summit Partner and Expert PDO, we’ve worked both timelines with AppExchange partners — from the lighter PKCE/RTR enablement on an existing packaged CA to meet May 11, through the full ECA migration with 1GP-to-2GP as a blocker, static IP infrastructure in AWS/GCP, ECA packaging, Security Review re-submission, and the customer rollout program.

The first conversation we have with any partner starts with use-case evaluation. What does your integration actually look like — server-to-server, mobile, hybrid? Which of the five controls are genuinely mandatory for your scenario, and which are optional? Which parts of your codebase actually change? From there we scope the three things that matter: the truly mandatory actions to meet May 11, the rollout plan for those changes, and the migration strategy to ECA + 2GP on a timeline that fits your product roadmap rather than Salesforce’s.

If your engineering bench is already committed, we can act as the delivery team on this program and keep your internal roadmap intact. If your team wants to lead it but needs specialist help on specific workstreams — packaging, infrastructure, or the rollout program — we can plug in there.

If You’re Reading This After May 11

You are not without options — but your options narrow. Salesforce will continue to offer office hours and support channels. Partners in flight will not be delisted the same day. But the conversation shifts from “we’re on track” to “we’re explaining why we’re late.” That’s a different conversation with your customers, your security teams, and your Salesforce account team.

The better version of this story is the one where you ship the May 11 hotfix early, plan the full ECA migration on your own roadmap rather than Salesforce’s, and keep your AppExchange listing exactly where it is through both transitions.

Need Help Shipping Your Connected App to External Client App Migration?

We’ve done this work for other AppExchange partners. We can scope yours in a short conversation and tell you honestly whether the timeline is still achievable with your current plan — and what to change if it isn’t.

Let’s Talk →