Aquiva blog
Mandatory Security Requirements for Connected Apps and External Client Apps Required by May 11, 2026
Salesforce has set a firm May 11, 2026 deadline for five new security controls on Connected Apps and External Client Apps. Here's what AppExchange partners actually need to ship — and what comes after.
Overview
Salesforce has issued a mandatory deadline requiring all AppExchange partners to implement five new security controls for Connected Apps and External Client Apps by May 11, 2026. This is not a roadmap memo — it is a firm deadline with consequences for non-compliance, including potential de-listing and service suspension.
Five mandatory security controls
| Control | Status | Purpose | Development requirements |
|---|---|---|---|
| PKCE | Mandatory by May 11 | Neutralizes authorization code interception | Code verifier/challenge generation in OAuth flow |
| Refresh Token Rotation (RTR) | Mandatory by May 11 | Single-use tokens invalidate after use | New token storage logic; race condition handling |
| 30-day idle timeout | Mandatory by May 11 | Dormant tokens expire | Heartbeat service for infrequent integrations |
| IP range allowlist | Mandatory by May 11 | Restricts token usage to approved IPs | Static IP infrastructure across integration systems |
| IP monitoring | Additional control | Alerts on suspicious usage | Operational monitoring discipline |
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:
- Inconsistent scope guidance from different Salesforce contacts
- Late control availability (April release for two controls, weeks before deadline)
- 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.