Yesterday Salesforce sent an email to all customers titled “Marketing Cloud Engagement Secret Expiration and Time-To-Live (TTL)”. If your Marketing Cloud instance communicates with any external system via API (and most production environments do), this change requires action. All existing client secrets for Marketing Cloud Engagement Installed Packages will expire on September 30, 2026. To avoid service disruption, secrets must be rotated before that date. Before discussing what exactly needs to be done, it is worth revisiting a few basic concepts: API calls, client credentials, and how integrations are configured in Marketing Cloud Engagement.

What is an API call?

In the context of Marketing Cloud, an API call is simply a request sent by one system to another system to perform an action automatically. Instead of a user logging into Marketing Cloud and clicking buttons, an external application sends a request over the internet, asking Marketing Cloud to do something on its behalf. Typical examples include creating or updating contacts, inserting data into Data Extensions, triggering sends, retrieving analytics, or starting Journeys. Because these requests can modify data and execute actions at scale, Marketing Cloud must verify that the calling system is authorized.

Client ID and Client Secret: what they actually are

API authentication in Marketing Cloud Engagement commonly uses OAuth 2.0 credentials generated inside an Installed Package. These credentials consist primarily of two elements:

• Client ID: a public identifier for the integration
• Client Secret: a private key used to prove the caller’s identity

The Client ID can be thought of as a username for the integration, while the Client Secret functions as its password. When an external system wants to interact with Marketing Cloud, it sends these credentials to request an access token. If the credentials are valid, Marketing Cloud issues a token that allows the system to perform API operations according to its assigned permissions.

The critical point is that the Client Secret must remain confidential. Anyone who obtains it can potentially authenticate as the integration and gain access to the environment. In practice, this could allow sending emails, modifying subscriber data, or extracting information. For this reason, client secrets should be treated with the same level of care as administrative passwords.

Installed Packages and Server-to-Server integrations

In Marketing Cloud Engagement, API integrations are configured as Installed Packages. An Installed Package acts as a container that defines how an external system connects and what it is allowed to do. The most common integration type is Server-to-Server Integration. This model allows one system to communicate with Marketing Cloud automatically, without any user interaction or user interface. It is widely used for backend integrations, data pipelines, and automated processes. Creating such an integration typically involves the following steps:

1. Navigate to Setup in Marketing Cloud
2. Open Installed Packages
3. Create a new package and provide a name
4. Add a component of type API Integration
5. Select Server-to-Server Integration
6. Assign the required scopes and permissions
7. Save the configuration

After saving, Marketing Cloud generates the credentials required for authentication, including the Client ID and Client Secret, as well as the authorization endpoints used to obtain tokens. The Client Secret is stored within the Installed Package configuration. Administrators can view details of the integration by navigating to:

Setup → Installed Packages → [Package Name] → API Integration

These credentials are then configured in the external system that will call the API.

What exactly is changing?

Salesforce is introducing mandatory expiration for client secrets as a security enhancement. Historically, secrets could remain valid indefinitely, which posed a risk if credentials were exposed and forgotten. Under the new policy, every client secret will have a 180-day time-to-live (TTL). After this period, the secret becomes invalid and can no longer be used to obtain access tokens. Existing secrets have been assigned a fixed expiration date:

September 30, 2026

Additionally, secrets generated after March 26, 2026 follow a new format. They are longer (64 characters) and begin with the prefix SFMC_, making them easier to identify as Marketing Cloud credentials.

Another important aspect of the update is that secrets belonging to dormant integrations (those that had not requested a token for 180 days) were already invalidated earlier in March 2026. This reduces the attack surface associated with unused or forgotten integrations. Salesforce has indicated that the change is driven by observed security threats involving exposed credentials being used to gain unauthorized access, send phishing messages, or extract data.

What needs to be done?

Organizations using Marketing Cloud APIs must rotate their client secrets before the expiration date. Secret rotation means generating a new secret, updating all systems that use it, and retiring the old one. If the rotation is not completed in time, affected integrations will stop working because authentication will fail.

From an operational standpoint, the most important step is identifying where each secret is used. In complex environments, the same credentials may be configured in multiple applications, middleware layers, scheduled jobs, or cloud services. Once the new secret is generated inside the Installed Package, it must be activated and then propagated to every dependent system. After updating configurations, integrations should be tested to confirm that token requests and API operations function correctly. Only after verification should the old secret be removed or allowed to expire.

How to approach rotation safely?

Although the process itself is straightforward, the impact of mistakes can be significant. A failed integration might not always produce obvious errors; it could silently stop syncing data or triggering messages. A practical approach is to treat secret rotation as a controlled deployment activity. First, inventory all Installed Packages and determine which ones are actively used. Then coordinate with system owners to update credentials during a maintenance window if necessary. After updating configurations, validate critical workflows end-to-end (data ingestion, triggered sends, Journey entry events, any automation relying on API data). Salesforce also recommends rotating secrets regularly, ideally every six months, rather than waiting until expiration. This reduces risk and ensures that the organization maintains a tested process for credential renewal.

Final thoughts

This update does not introduce new functionality but enforces a long-standing security best practice: credentials should expire and be rotated regularly. For many organizations, Installed Packages were configured years ago and rarely revisited. The September 30, 2026 deadline effectively forces a review of all API integrations. While this requires effort, it also provides an opportunity to clean up unused packages, tighten permissions, and verify that integrations are documented and understood.

If your Marketing Cloud environment interacts with external systems (which is almost always the case) plan the rotation process well in advance. Failure to rotate client secrets before the deadline will result in authentication failures and potential disruption of critical processes.

Rotate Client Secrets Before September 30, 2026

Official documentation: Rotate an OAuth 2.0 Secret