A claims batch ran at 2 a.m. on a Saturday, the way it had every night for two years. It assembled the night's submissions, opened a callout to the payer gateway, and posted them. At 2 a.m. on this particular Saturday it opened the callout and got back a TLS handshake failure. No claims posted. The retry logic did exactly what it was told and tried again every fifteen minutes until the queue backed up, and by the time the on-call engineer was paged on Monday morning the backlog was three days deep and the payer's intake window for two of those days had already closed.

The trace took an hour. The callout used a Named Credential. The Named Credential looked healthy. The endpoint was reachable. The authentication settings had not changed. What had changed was a certificate, renewed eleven days earlier by someone on the platform team who had been told to "rotate the expiring cert" and had done exactly that, cleanly, without ever being shown that a nightly callout to a payer depended on it.

Nobody made a mistake in the usual sense. The system simply did not connect a certificate to the integration that consumed it, and so the renewal and the outage looked, to everyone involved, like two unrelated events eleven days apart.

This is the failure mode I want to take apart in this post, because the Named Credential is where it most often hides.

What a Named Credential actually is now

If your mental model of a Named Credential is the older one, a single object holding a URL and a login, it is worth resetting. In Winter '23 Salesforce split the concept in two and now strongly recommends the newer model over the legacy one, which is deprecated and slated for removal.

The split is clean once you see it. A Named Credential specifies the callout endpoint and the transport, while an External Credential holds the authentication protocol and the principals that authorize the caller. One External Credential can back many Named Credentials. The protocol on the External Credential is selected from a fixed set, and it is the protocol choice that determines whether a certificate is in the picture at all.

That is the part most inventories miss, and it is worse than one hidden field. The certificate can attach to either object, depending on the protocol. A client certificate for mutual TLS attaches to the Named Credential itself, at the transport layer. A signing certificate for a JWT based OAuth flow attaches to the External Credential, at the authentication layer. An inventory that walks one object and not the other sees half the dependencies.

Where the certificate actually enters

For outbound callouts, Salesforce acts as the client, and there are two protocol situations where a certificate in your org becomes load-bearing.

The first is mutual TLS. When the remote endpoint requires two-way TLS, Salesforce has to present its own client certificate during the handshake, and that client certificate is selected on the Named Credential itself. The certificate and its private key live in Certificate and Key Management, and the Named Credential points at them by reference. Production endpoints generally require that certificate to be CA-signed, though Salesforce will present whichever certificate the Named Credential names. The handshake is decided at the transport layer, before any application-level authentication runs, which is precisely why an expired client certificate produces a raw handshake failure rather than a clean 401. (Inbound mTLS, where Salesforce is the server, is a different setup and was covered in Part 2 of this series.)

The second is OAuth where the assertion is signed. In the JWT Bearer Flow, and in the Client Credentials with JWT Assertion variant, Salesforce builds a JSON Web Token, signs it with the private key of a signing certificate that the External Credential references, and posts it to the remote token endpoint, which validates the signature against the public certificate it holds. Here the certificate is not in the TLS handshake at all. It is in the token request. When it expires, or is rotated without the public key being re-shared, the handshake still succeeds, the callout reaches the token endpoint, and the token request fails. The failure surfaces as an authentication error, one layer up from where mTLS fails, which is why the same root cause can look like two different incidents depending on which integration tripped.

There is a third certificate in the room, the remote server's own certificate, validated by Salesforce against its trust store. You do not manage that one, but it expires too, and when it does the symptom is indistinguishable at first glance from your own certificate expiring. Worth ruling out early; not worth owning.

What expiry and renewal actually do

The expiry case is the obvious one. The certificate passes its validity date, the handshake or the token request stops succeeding, and every callout that depends on that certificate fails. The blast radius is not the certificate, and not even the object that references it. It is every Apex class, every Flow, every scheduled job, and every External Service registration that issues a callout through any Named Credential in that chain, whether the certificate sits on the Named Credential or on the External Credential behind it. One leaf, many dependents.

The renewal case is the one that bites teams who think they have the expiry case handled. Renewing a certificate is not automatically transparent to the things that reference it. If the replacement is imported under a new name, or imported correctly but never re-selected on the object that references it (the Named Credential for an mTLS client certificate, the External Credential for a JWT signing certificate), or rotated on the remote side without the public certificate being re-shared, the reference breaks even though a valid certificate now exists in the org. The renewal looks complete from the Certificate and Key Management page. The dependency is still pointing at the old artifact, or at nothing. This is the eleven-days-later outage from the top of this post, and it is a renewal problem dressed up as an expiry problem.

Why the native tooling will not show you the blast radius

Certificate and Key Management will tell you when a certificate expires. It will not tell you what consumes it. The expiry date is an attribute of the certificate, sitting on the certificate, with no edge drawn outward to the Named Credentials and External Credentials that reference it, or the Apex and Flows and jobs at the end of the chain.

The dependency surfaces exist in pieces. You can chase some references through metadata and the dependency API where it has coverage, you can read the External Credential to see which protocol and which certificate it names, and you can grep your Apex for callout references. What you cannot do natively is sit in front of one expiring certificate and read off, in one view, the full set of integrations that will fail when it lapses. The information exists. It is not assembled. And an answer that requires assembling six sources by hand under a Monday-morning backlog is not an answer anyone reaches for at 2 a.m.

The shape this leaves behind

Stand back from the specifics and the structure is a directed dependency, with the certificates at the bottom and everything operational depending on them:

Apex class / Flow / Scheduled job / External Service
        |
        | calls (callout:Name)
        v
Named Credential ............ holds mTLS client certificate   (transport layer)
        |
        | references
        v
External Credential ......... holds JWT signing certificate   (auth layer)

Two certificates, two different objects, one callout. The mTLS client certificate sits on the Named Credential. The JWT signing certificate sits on the External Credential behind it. Either one expiring takes the callout down. Read the chain bottom to top, starting from a certificate you are about to rotate, and it is a renewal checklist. Read it top to bottom, starting from the nightly job that just failed, and it is an incident trace. The same edges serve both directions, which is the whole argument of this series: the value is not in any single node, it is in the edges that connect a certificate's expiry date to the business process that quietly depends on it.

Once you can see that chain, a different question becomes unavoidable. The certificate has an expiry date, but does it have an owner? The Named Credential has a consumer, but does anyone know they are on the hook when it breaks? Seeing the dependency tells you what will fail. It does not yet tell you who should have been paged, or who should have approved the renewal, or who finds out first. That is the next layer, the shape that maps owners onto assets, and it is where Part 5 goes.

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, Part 2: The inbound mTLS certificate nobody owned, and Part 3: The Connected App nobody scoped.