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

Overview

Salesforce has set a May 11, 2026 deadline for all AppExchange partners to implement four mandatory security controls on Connected Apps and External Client Apps, with a fifth recommended on top. This is not a roadmap memo — it is a firm deadline with consequences for non-compliance, including potential de-listing and service suspension.

Five security controls, four of them mandatory

Context: why this matters now

The 2025 threat landscape drove this urgency. Attackers didn't break Salesforce — they walked in through an OAuth connection. Notable incidents included:

• ShinyHunters social-engineering employees to approve malicious Connected Apps
• Salesloft supply-chain attack compromising 700+ tenants
• Gainsight-published apps revoked after OAuth compromise
• Cisco-attributed incident exposing 3M+ records

Each mandated control directly addresses techniques exploited in these breaches.

Two distinct projects

It's important to separate the two pieces of work the deadline forces partners to plan for.

The May 11 hotfix. For existing packaged Connected Apps, partners can enable PKCE and RTR through settings toggles, with Salesforce auto-propagating changes to subscribers. This requires application-side code updates but avoids Consumer Key changes and re-authentication.

The inevitable migration. Connected Apps and 1GP are sunset paths. Spring '26 already disabled new legacy Connected App creation. Migration to External Client Apps on 2GP (second-generation packaging) is mandatory eventually — the variable is timing.

Treat May 11 as a critical deadline for the bare minimum, not a destination.

Scope expansion points

Partners frequently underestimate scope. The requirements apply to:

• Connected Apps within managed packages
• Unpackaged Connected Apps installed during implementation
• Connected Apps documented for subscriber creation post-install
• Any Connected App living in partner org infrastructure

Additionally, the "subscriber creates the Connected App post-install" pattern is effectively deprecated for flows requiring ISV Consumer Key control.

Development complexity beyond configuration

Code changes

PKCE requires verifier/challenge handshakes on every OAuth flow. RTR demands new token storage after each exchange, creating distributed-systems challenges in multi-threaded environments.

Infrastructure requirements

Static IP binding necessitates NAT gateways, Elastic IPs, or dedicated proxy layers on cloud platforms — not Salesforce work, but integration engineering work.

Infrequent integration solutions

The 30-day idle timeout requires heartbeat services refreshing tokens every 25-28 days for rarely-used workflows, adding new monitoring infrastructure.

Origin org dependencies

Packaged ECAs make the Dev Hub org a critical dependency. Loss of access breaks every subscriber's credentials.

Implementation guidance gaps

Three patterns are showing up in early partner experiences:

1. Inconsistent scope guidance from different Salesforce contacts
2. Late control availability (April release for two controls, weeks before deadline)
3. Tooling rough edges including secret rotation errors, CLI case-sensitivity issues, and packaging configuration quirks

The rollout program

Even with code complete by late April, the deployment represents roughly halfway done. Full ECA migration requires:

• Customer communication with advance notice and downtime windows
• Re-authentication handshake requiring action on the customer side (new Consumer Key = required re-auth)
• Post-deployment monitoring tracking authentication success, IP mismatches, rotation failures
• Legacy deprecation — maintaining both versions until all customers migrate

For enterprise-heavy customer bases, this multi-month coordination happens outside engineering teams.

Where we fit in

Aquiva Labs offers specialized support for:

• Lighter PKCE/RTR enablement on existing packaged CAs
• Full ECA migration with 1GP-to-2GP conversion
• Static IP infrastructure in AWS/GCP
• ECA packaging and Security Review resubmission
• Customer rollout program management

Key takeaway for late starters

Partners who miss May 11 aren't immediately de-listed, but the conversation shifts from readiness to explaining delays. Ship the May 11 hotfix early, then plan the full ECA migration on your own roadmap rather than under pressure. That sequencing is how our Salesforce security practice runs these engagements: buy the deadline back first, then do the migration properly.

Connected App security requirements: quick answers

What are the four mandatory security controls for Connected Apps and External Client Apps?

PKCE on the authorization code flow, Refresh Token Rotation, a 30-day idle timeout on refresh tokens, and an IP range allowlist for refresh-token use. Salesforce lists IP monitoring as a fifth, recommended control. All four were due on every Connected App and External Client App an AppExchange partner ships by May 11, 2026, and Salesforce began enforcing on June 25, 2026.

What does Salesforce's PKCE requirement change in my OAuth flow?

Every authorization code exchange has to carry a code verifier and its hashed challenge, so an intercepted authorization code is useless without the verifier that only your client holds. For an existing packaged Connected App, Salesforce lets you turn PKCE and Refresh Token Rotation on through settings that propagate to subscribers, which means no new Consumer Key and no forced re-authentication. The client code still has to generate and send the verifier, so the toggle is the smaller half of the work.

Will the 30-day idle timeout break an integration that only runs monthly?

Yes, unless something refreshes the token first. A refresh token that sits unused for 30 days expires, so a quarterly sync or a month-end job comes back to find its credentials dead. The fix partners are shipping is a heartbeat that exercises the refresh token every 25 to 28 days, plus monitoring so you find out when the heartbeat itself stops.

Which Connected Apps are in scope for the mandatory controls?

Every Connected App or External Client App you provide that is used with your partner application, whether or not it sits inside the managed package. That pulls in unpackaged apps installed during onboarding, apps your install guide tells customers to create themselves, and apps parked in your Partner Business Org or namespace org. The ISVforce Guide limits the requirement to apps in use across more than two customer production orgs, so a private listing or a JWT-only integration you had written off may still count, and a staging-only app may not.

What happens if a partner missed the May 11, 2026 deadline?

Missing the date did not de-list anyone. What it triggered was a legal notice titled "Notice of Partner Application Non-Compliance and Interoperability Suspension", and since June 25, 2026 Salesforce can suspend a non-compliant app's ability to interoperate with the platform until the controls are in place. Several partners who had enabled everything received the notice anyway, usually because of an unpackaged Connected App they had forgotten about, so the first job is a per-app inventory and the second is taking that inventory to your Partner Account Manager. We walk through both in how to read the non-compliance notices.

Is the May 11 work the same as migrating to External Client Apps?

No. Enabling PKCE and Refresh Token Rotation on an existing packaged Connected App is a hotfix that gets you past the deadline. The migration is separate: Connected Apps and first-generation packaging are both sunset paths, Spring '26 already blocks new Connected App creation by default, and the destination is an External Client App on a second-generation package. That move changes the Consumer Key, so it comes with customer communication and a re-authentication handshake, and it deserves its own slot on your roadmap.