Salesforce Certificate Changes: Does Your Org Actually Need to Act?

If you opened your inbox on October 29, 2026, to an email from Salesforce with the subject line “ACTION REQUIRED: Prepare for Certificate Changes”, you might be wondering what you need to do. The email warns of “immediate security vulnerabilities” and “severe service disruptions” unless you prepare for three certificate changes, which is enough to make any Salesforce Admin sit up and pay attention.

The good news is that not every org needs to make changes, and you probably don’t need to drop everything to deal with this email. One of the changes only affects orgs using mutual TLS (mTLS), and its enforcement date has moved to March 15, 2027. The other two are primarily about how Salesforce manages its own certificates and how your IT team maintains the systems that connect to Salesforce.

So, before you start investigating every certificate in your org, let’s break down what’s changing, how to work out whether you’re affected, and what you actually need to do.

First, What Is a Digital Certificate?

Think of a digital certificate as an online identity card. It helps prove that a website, server, or application is what it claims to be, allowing other systems to establish a trusted connection with it. Certificates also help encrypt information sent between systems, so that data cannot easily be intercepted or read by someone else.

In Salesforce, certificates can be used in several ways, including authenticating connections between Salesforce and external systems, securing integrations, and verifying identity when systems communicate with one another. They have an expiry date, so they need to be renewed or replaced periodically to keep those connections working securely.

This is why certificate changes matter to Salesforce Admins. If a certificate expires, becomes unsupported, or no longer meets the requirements of the system it connects to, an integration or other connected service could stop working. The important thing is understanding which certificates your org actually uses and whether any action is needed.

Does Your Salesforce Org Need to Act?

Before getting into any more technical details, there are three questions worth asking. These should help you establish whether your org needs further investigation and, just as importantly, who needs to be involved.

First, does your org use mutual TLS (mTLS)? In Salesforce, go to Setup and search for Certificate and Key Management, then look for a section called Mutual Authentication Certificates. 

There’s one important catch: this section isn’t visible by default, as Salesforce Support needs to enable it. If you can’t see it, or it’s empty, inbound mTLS almost certainly isn’t in use. You can also check whether any users have the Enforce SSL/TLS Mutual Authentication permission.

Second, do any external systems connect to Salesforce? Think about middleware, MuleSoft, on-premises servers, and custom integrations. If the answer is yes, your IT or integration team needs to check how those systems trust Salesforce’s certificates. 

This doesn’t automatically mean anything needs changing, but there are a few questions worth passing on to the people responsible for those connections.

Third, does your team renew any public certificates manually? If you manage public certificates yourself, you’ll need to plan for more frequent renewals as the maximum certificate lifespan gets shorter. 

From March 15, 2027, the maximum lifespan for a newly issued publicly trusted TLS certificate will be 100 days, falling to just 47 days by March 2029.

If none of these questions apply to your org, you’ve covered the main checks raised by the email. If you answered yes to any of them, don’t panic. Let’s look at what each change means and how to decide what needs doing.

Change 1: Dual-Use Certificates (Only If You Use mTLS)

This is probably the most alarming of the three changes, but it only matters if your org uses mutual TLS. If you’ve never heard of mTLS before, don’t worry. The important thing is understanding whether any of your integrations rely on it, rather than becoming a certificate expert overnight.

When a system connects to Salesforce over a normal secure connection, Salesforce presents a certificate to prove its identity. With mutual TLS, the connecting system also presents a certificate to prove its identity. Some organizations have used a single certificate for both purposes, which is where the problem arises.

Under Chrome Root Program Policy v1.8, certificate authorities in Chrome’s trusted list can only issue certificates for identifying websites. According to Salesforce, a certificate can no longer be used for both server and client authentication under these rules, and existing dual-use certificates may not be renewable in their current form after March 2027.

What Do You Need to Do?

If your org uses inbound mTLS with a dual-use certificate, the solution is to move to a dedicated client certificate. Salesforce has confirmed that the following certificate authorities will continue to issue public client-authentication certificates and that their roots are being added to Salesforce’s trust stores.

There’s another detail worth knowing if your organization manages its own certificates. Salesforce says it doesn’t currently support private certificate authorities for mTLS, so although an internal certificate authority keeps you outside Chrome’s rules for publicly trusted certificates, inbound mTLS to Salesforce still requires a certificate from one of the supported public roots listed above.

You don’t necessarily need to manage the replacement certificate yourself, as that responsibility belongs to whoever built and maintains the integration. Your job as the Salesforce Admin is to establish whether mTLS is in use, identify the person responsible, and make sure there’s a plan to deal with any affected certificates before March 15, 2027. 

If your org doesn’t use mTLS, you can move on to the next change.

Change 2: Shorter Certificate Lifespans

This change is worth understanding even if you don’t use mTLS, because it affects how often publicly trusted TLS certificates need to be renewed. A certificate helps establish trust in a secure connection, and the maximum lifespan of certificates issued by public certificate authorities is being reduced in stages.

The CA/Browser Forum has set the following schedule, with the next change arriving in March 2027.

These renewal frequencies are approximate, rather than a requirement to renew every certificate on exactly the same schedule. The important point is that managing public certificates manually will become more time-consuming as their maximum lifespans get shorter.

There are two sides to consider here: certificates Salesforce manages, and certificates your organization manages. Knowing which category your certificates fall into will help you work out whether there’s anything you need to change.

What About Salesforce’s Own Certificates?

Salesforce manages its own certificates and typically rotates them at least 45 days before expiry, sometimes earlier. You don’t need to take over that renewal process, but you should be aware of how your own systems respond when Salesforce changes a certificate.

The potential problem is with systems on your side that rely on a specific Salesforce certificate rather than trusting the certificate authority that issued it. This is known as certificate pinning, and it can cause problems when Salesforce rotates a certificate that a connecting system expects to remain the same.

Salesforce strongly recommends against certificate pinning. It isn’t supported on Hyperforce or for Marketing Cloud Engagement, and pinning the Salesforce mobile app’s certificate can lock users out after a rotation until the app is updated or reinstalled. If your organization uses certificate pinning, your IT or integration team should review the configuration and move away from it in line with Salesforce’s guidance.

What About Certificates Your Team Manages?

This is where Salesforce Admins may have more work to do, particularly if your team creates and renews certificates manually. The shorter lifespans apply to new certificates issued by public certificate authorities, regardless of who buys them. Existing certificates keep their current expiry dates, while self-signed certificates aren’t affected by these new limits. Self-signed certificates created in Salesforce still expire after one year.

Salesforce identifies several areas where your own certificates might be used, including encryption in transit and at rest, certificate-based authentication, some single sign-on configurations, and custom domains served using your own certificate. If your team manages certificates for custom domains, Salesforce suggests considering its CDN for Experience Cloud sites or using a third-party service that manages certificates for you.

The key question is how your team will handle renewals when certificates need replacing several times a year, rather than once annually. You don’t necessarily need to automate everything immediately, but it’s worth identifying which certificates your team manages manually and deciding who will own the process as renewal cycles get shorter.

How Can You Make Certificate Renewals Easier?

There are two practical steps to consider, starting with making sure the right people know when a certificate is approaching expiry. Salesforce provides an Expired Certificate Notification permission, which you can assign to the admins who need alerts about certificates stored in your org. Bear in mind that these notifications don’t cover Salesforce’s own TLS certificates, so they won’t replace any monitoring your IT team already has in place.

The second step is to look at automation. Salesforce supports certificate creation and renewal through the Metadata API Certificate type, which can help reduce the amount of manual work involved and make it less likely that a renewal gets missed. 

Your job is to check with your IT or infrastructure team whether any systems or integrations connected to Salesforce rely on public TLS certificates, who manages them, and whether they have a plan to handle the shorter renewal periods.

Change 3: Root Certificates and Trust Stores

This is the change where your IT or integration team will probably need to get involved, but you don’t need to understand every technical detail to know what to ask them.

A trust store is essentially a list of certificate authorities that a system trusts. When a system connects to Salesforce, it checks the certificate Salesforce presents and whether that certificate can be traced back to a trusted authority. Salesforce guarantees that its certificates chain to a root on Mozilla’s Server Authentication (SSL/TLS) Root Certificates List, and recommends that systems connecting to Salesforce trust all the roots on that list.

Why does this matter? Salesforce may change which root provider it uses, so a system that trusts only one particular root could run into connection problems if Salesforce switches to another. Most modern operating systems include standard trusted roots by default, which means the systems worth checking are those with custom enterprise trust stores, often found in middleware or older servers.

Could Older Integrations Be Affected?

Potentially, yes. Salesforce also highlights the cryptographic algorithms its TLS certificates use, including RSA keys of 2,048 to 4,096 bits or ECDSA curves, with certificates signed using SHA256 or stronger. Most modern systems should support these requirements, but older integrations may need a closer look.

Salesforce specifically flags integrations built on Java or SAP that are more than ten years old. If they run JDK 8 or earlier, they may need additional files to support these algorithms, so your IT team should check the systems involved rather than assuming they’ll continue to work without any changes.

Two further details from Salesforce’s email are worth passing on: self-signed and custom CA-signed certificates are exempt from this requirement, and MuleSoft administrators are directed to separate MuleSoft guidance. If your organization uses MuleSoft, make sure the people responsible for those integrations have the relevant documentation.

What Should You Ask Your IT Team?

Rather than trying to investigate every server yourself, your role is to pass the following questions to your IT or integration team so they can establish whether anything needs changing:

• Do the systems connecting to Salesforce trust all the roots on Mozilla’s Server Authentication list?
• Does anything pin a specific Salesforce certificate instead of trusting its issuing authority?
• Are any integrations still running JDK 8 or earlier?

These questions should give the relevant team a clear starting point. Your job is to make sure the checks have an owner and that any issues affecting Salesforce integrations are addressed before they cause disruption.

Your Salesforce Certificate Checklist

By now, you should have a clearer idea of which changes might affect your org and who needs to be involved. To make the next steps easier, here’s a checklist you can work through without having to tackle every item yourself.

• Check Setup → Certificate and Key Management for mutual authentication certificates, and check which users have the Enforce SSL/TLS Mutual Authentication permission.
• If mTLS is in use, identify the integration owner and confirm there’s a plan to replace any affected dual-use certificate before March 15, 2027.
• Assign the Expired Certificate Notification permission to the admins who need alerts about expiring certificates stored in your org.
• Ask IT to check trust stores, certificate pinning, and Java versions for systems that connect to Salesforce.
• If your org uses its own certificate for a custom domain, consider whether the Salesforce CDN, for Experience Cloud sites only, or a managed certificate service would make renewals easier.
• Make a list of public certificates your team renews manually and decide who will manage the increasingly frequent renewal process.

You don’t need to complete every item personally, as some checks belong with IT, security, or the people responsible for integrations. The aim is to establish whether your org is affected, make sure the right people know about any required changes, and avoid leaving certificate renewals until the last minute.