Salesforce sent administrators an email titled ACTION REQUIRED: Prepare for Certificate Changes. It reads like an emergency. For most people who simply log in and do their work, it is not. It is a warning that some of the digital IDs your systems use to talk to Salesforce are about to be printed under stricter rules. If nobody checks which IDs you have, a data sync or a partner connection can stop the day that ID is renewed.

Your Salesforce admin needs the technical walk-through. This page is the one to forward to a director, a board, or a program lead.

Salesforce is not turning the lights off

A certificate is a digital ID card. Websites and integrations show it to prove they are who they claim to be, the same way a building badge proves you work there.

The companies that print those public ID cards, and the browsers that accept them, changed the rules. Salesforce is passing the change along because some customer connections depend on those cards. Ordinary login from a current laptop or phone already follows the new rules. You do not need a project to keep staff in the system tomorrow morning.

The connections that can break are the quiet ones: a nightly sync, a partner feed, a login that uses a certificate instead of a password, or a server your team configured years ago with a short list of “we only trust this one issuer.”

One badge that was doing two jobs

Picture a badge that both opens your office door and proves your identity at a partner’s security desk. For years, one purchased certificate could do both jobs: identify a website, and identify a system logging in.

Printers of public certificates are being told to stop making that combo badge. A new public certificate can open the door (identify a website) or it can identify a connecting system. Not both.

The badge already in your pocket keeps working until the date printed on it. Nothing expires early because this email arrived. The problem shows up when someone reorders. The printer hands back a door badge only. The partner’s desk then refuses the connection, even though the old badge worked last month.

Salesforce’s own guidance says that if a system is presenting a certificate into Salesforce, you should buy the “prove who you are” badge from an issuer Salesforce actually accepts, and confirm that before you pay. A private badge your company prints itself is fine for some other jobs, including when Salesforce is the one showing an ID to your server, and for single sign-on. It is the wrong purchase for the “log in to Salesforce by certificate” job. Your admin can confirm which job each certificate has. The details are in Salesforce’s certificate guidance.

Visitor passes that expire faster

Public website certificates are visitor passes. A stolen pass should not be useful for a year, so the printers agreed to shorten them.

  • A new pass issued today lasts at most 200 days. That rule is already in effect.
  • From March 15, 2027, a new pass lasts at most 100 days.
  • From March 15, 2029, a new pass lasts at most 47 days, about seven weeks.

The pass already clipped to someone’s jacket keeps its original date. The shorter life appears the next time you order one. There is no single morning when every connection dies.

Salesforce replaces the passes on its own standard addresses. You replace the ones your team bought: a custom web address, or a certificate an integration presents. If renewal is a reminder on someone’s calendar, that process will not survive a pass that lasts seven weeks. It has to be automatic, or it will be forgotten.

Certificates used only to sign a login between your company and Salesforce, the ones you exchanged directly for single sign-on, are a different kind of ID. They are not on this shortening schedule.

The door list at the club

When one of your servers calls Salesforce, it checks Salesforce’s ID against a list of printers it trusts. Think of a door person with a list of which ID issuers are allowed in.

Phones and up-to-date laptops carry the long public list, the one Mozilla maintains. A Java server, a MuleSoft job, an API gateway, or an old integration box often has a short handwritten list with a single name on it. Salesforce has already used more than one printer, and it may switch again. It has not announced the date of the next switch.

If your server only accepts yesterday’s printer, it will refuse Salesforce even while Salesforce is up and your laptop still connects. Updating the laptop does not update that server. Someone has to open the server’s list and trust the full public set, not one favorite name.

This does not apply to IDs you exchanged by hand for single sign-on. Those are trusted because you and the other party agreed on that exact card. Leave those alone.

Five questions for this week

You do not need to collect the certificates yourself. You do need a named owner and a straight answer.

  1. Which of our connections log in by showing our own certificate, or show a certificate to a partner?
  2. When does each of those expire, and will the company that issued it still sell that kind of certificate at renewal?
  3. Which servers talk to Salesforce with their own trust list (MuleSoft, Java, a gateway, an old integration server)? Does that list include the current public set, or one pinned issuer?
  4. Do we host our own certificate on a Salesforce web address, or did anyone hard-code a specific Salesforce certificate into an integration?
  5. If someone says this is already finished, what was checked, on what date, and which connections were tested in a sandbox?

A sensible sequence is an inventory in November, a test in a sandbox before the end of December, and the real switch, with the old certificate still accepted until the new one is proven, before March 2027. DigiCert stops renewing the combo badge on March 1, 2027. The broader public rule for new certificates is March 15, 2027.

What you can safely ignore

  • Staff who only open Salesforce in a current browser.
  • The certificate on Salesforce’s own standard addresses, unless your team uploaded one or pinned a specific certificate in code.
  • Single sign-on certificates you and your identity provider exchanged directly. They still expire on their own dates. They are not part of the seven-week public-certificate rule.

The webinars in the email

The message lists three live sessions. Salesforce said recordings will not be shared, so the useful move is to have the admin and the integration owner attend one of them. The times were in the email, not on Salesforce’s public events page, so use the registration link from that message:

  • November 4, 2026, 9:00 a.m. UTC
  • November 4, 2026, 3:00 p.m. UTC
  • November 5, 2026, 11:00 p.m. UTC

A webinar explains the rules. It does not inventory your org.

Frequently asked questions

Is Salesforce going down?

No. This is about certificates on integrations. People who sign in with a current browser are mostly outside it. A connection can still stop on the day its certificate is renewed.

Do we have to act this week?

Someone should find out which connections use your certificates, when they expire, and which servers keep a private trust list. If that work is already done and tested, Salesforce says there is nothing further to do.

Why are certificates getting shorter?

So a stolen public certificate is useful for less time. New ones are already capped at 200 days, then 100 days in March 2027, then 47 days in March 2029. Certificates you already hold keep their printed expiration date.

Who owns this?

The Salesforce admin, the person who runs integrations, and whoever buys certificates. Not the people who only use Salesforce during the day.