In the last post I argued that risk does not live in the nodes of a Salesforce org. It lives in the edges, the invisible lines between a certificate and the things that quietly depend on it. This post follows one edge, a composite drawn from outages I have watched unfold the same way across many orgs, and the night it became visible the only way these edges ever do.

The 11pm phone call

It was a Sunday. The integration in question was an inbound nightly data sync for a large customer on the platform: a few million records pushed into Salesforce every night through the REST API, reconciled before the support teams logged in Monday morning. It had run, untouched, for years.

That Sunday it did not run. There was no alert. No red banner in Setup. No row in a Salesforce error log that anyone was watching. The job on the customer's side reported a connection failure and retried a few times, the way it always had during transient blips, and then it gave up quietly. The first human signal arrived Monday: support agents looking at data that was a day stale, then two days stale, then asking why.

By the time the war room opened, the failure was easy to name and impossible to locate. The external system was connecting to Salesforce over mutual TLS, and the client certificate it presented during the TLS handshake had expired. The handshake failed. Every request died at the transport layer, before it ever reached anything in Salesforce that logs, monitors, or alerts.

Why mutual TLS fails in the dark

Most of the monitoring an org invests in watches the application layer: API error rates, failed logins, flow faults, Apex exceptions. Mutual TLS does not fail there. It fails one layer down, during the handshake, when the certificate the client presents does not validate. From Salesforce's side the connection is simply refused. There is no authenticated session, so there is nothing for session-based monitoring to see. From the customer's side there is a generic connection error that looks identical to a network blip.

So the most business-critical inbound integration on the platform went down in the one way that produces no signal anyone was collecting. That is not bad luck. It is the structural property of the dependency. The edge sits below the floor of normal observability.

And the edge had a second property that made the night longer: it spanned two companies. The expired certificate was the client certificate, held and renewed by the customer's integration team. The trust that validated it was the certificate Salesforce checks on each inbound request, configured years earlier in our org. Two organizations, one handshake, and an "owner" that existed in neither place completely.

The traversal nobody could do

When the war room asked the only question that mattered, "what depends on this certificate," nobody could answer it from Salesforce.

Here is what the inbound mutual TLS dependency actually looks like, because the shape of it is the whole point. For an external system to call Salesforce with mutual authentication, three things have to line up:

  • The client certificate (and its intermediate chain) is uploaded to the Mutual Authentication Certificates list in Setup. Salesforce checks it on every inbound request.
  • The request comes in on port 8443, the dedicated mutual-authentication port, not the standard 443.
  • The integration user the call authenticates as carries the Enforce SSL/TLS Mutual Authentication permission, almost always an API-only user buried in a custom profile or permission set.

None of those three facts points at the others. The certificate in the Mutual Authentication list does not say which integration user it protects. The integration user's profile does not say which external system or which nightly job lives on the other end. The nightly job lives entirely in the customer's environment, documented, if at all, in a runbook we had never seen. Reconstructing the edge meant pulling three threads in three different places and a phone call to the customer to find the fourth. That reconstruction is the cost of the outage. The renewal itself is fifteen minutes. Knowing what the renewal touches is the part that took the night.

This is exactly the owner-to-asset hole from the last post. The certificate ran in production. The person who set it up had moved on. The reason it existed lived in someone's memory, and that someone was no longer in the room.

Why 2026 makes this everyone's problem

For most of the platform's history you could survive without a map of these edges, because certificates lasted a year or more. An annual calendar reminder, a renewal once a year, and the gap in your knowledge only got tested every twelve months. The model was fragile, but the failure rate was low enough to hide behind.

That assumption is ending. Driven by the CA/Browser Forum and tracked by Salesforce, the maximum lifetime for CA-signed TLS certificates is dropping on a published schedule: 200 days as of March 15, 2026, 100 days from March 15, 2027, and roughly 47 days from March 15, 2029. Self-signed certificates are exempt from that specific cap, but the operational direction is unmistakable, and the world mutual TLS lives in is moving the same way.

Run the arithmetic on the outage above under that regime. A certificate that used to be renewed once a year is renewed eight or more times a year. An org with a dozen mutual-authentication certificates, split across partner integrations, now faces well over a hundred coordinated rotation events annually, each one spanning two companies, each one capable of failing silently at the transport layer. The calendar-reminder model does not degrade gracefully at that frequency. It collapses.

The thing I want architects to take from this is the same point as the last post, sharpened: every certificate rotation is a dependency-graph traversal. Short-lived certificates do not add eight times the renewal clicks. They add eight times the chances per year to discover, at 11pm on a Sunday, that you never had the map.

What to do before the next renewal window

You do not need a product to start closing this gap. You need to treat the edges as first-class objects. Concretely:

  • Inventory the Mutual Authentication Certificates list today. For each entry, write down four things: the external system on the other end, the integration user it authenticates, the expiry date, and a named human owner on both sides of the handshake. If you cannot fill in all four for a certificate, that certificate is your next outage.
  • Monitor the handshake, not just the app. Application-layer monitoring will not catch a transport-layer rejection. A synthetic check that actually completes a mutual-TLS handshake on port 8443 with the live client certificate, plus an alert on the expiry window well ahead of the date, would have turned this outage into a routine ticket.
  • Treat rotation as a two-party event. You hold the trust configuration in Salesforce; the partner holds the client key and the job that uses it. Rotation needs a sequence both sides agree on, not two calendars that happen to drift.
  • Build the edge map while certificates are still long-lived. The window to do this calmly is now, before the rotation frequency climbs. Mapping the graph under deadline pressure, certificate by certificate, in a war room, is the most expensive possible time to learn it.

The inbound mutual TLS certificate is just the sharpest example, because it fails silently and spans two organizations. The same logic applies to every cert, Connected App, and Named Credential in the org. mTLS is simply where the short-lived certificate era will draw blood first.

That is the gap I have spent the last year and a half building toward closing. I am still not going to name the product in this series, because the series is about the problem and the problem is worth understanding on its own terms. But if your honest answer to "what depends on this certificate" is a phone call and a long night, you already know which side of the gap you are on.

If you want to compare notes on how your team handles mutual TLS and certificate rotation across partner integrations, reach out on LinkedIn. The stories are always the same shape, and I never get tired of hearing how each team found out.

Bergin is the founder of Aetrum LLC, a Salesforce consulting practice focused on integration architecture, security and governance, and contact center modernization in regulated industries. He is a Salesforce Certified Application Architect with 15+ years on the platform. Read Part 1: The hidden dependency graph in every Salesforce org.