Every Salesforce org has a graph nobody drew.

It is the set of invisible lines between a Connected App and the Named Credentials it backs, between a certificate in Certificate and Key Management and the seven outbound integrations that pin to it, between a SAML signing certificate and the Identity Provider config that depends on it, between a Connected App's pre-authorized profile list and the eight new hires who joined the team last quarter.

Nobody drew it. Nobody owns it. And nobody can find it when something breaks at 11pm on a Sunday.

I have spent 15 years on this platform. The last decade of that was at AOL and Yahoo, running customer support and subscription engagement systems at a scale where one expired cert took down enough integrations to fill a war room. The decade before that taught me one thing that has stayed true across every org I have touched since: the graph that runs your org is not the graph in your architecture diagrams.

The architecture diagrams show ten boxes and twelve arrows. The real graph has eighty-seven nodes and somewhere north of two hundred edges, and most of them only become visible the moment one of them breaks.

The four shapes of the graph

I want to be concrete about what I mean by "the graph," because handwaving about complexity does not help anyone fix anything. There are four classes of dependency that live inside almost every production Salesforce org, and they are the four that quietly compound until something gives.

  1. Certificate-to-integration dependencies. A single certificate in Certificate and Key Management can be referenced by an outbound Apex callout, a Named Credential, a SAML SSO config, a JWT-based Connected App, and a Mutual Authentication endpoint. Five things. One cert. When that cert expires, five things break, but only one of them shows up on the monitoring dashboard. The other four show up in a Slack message from a confused user three days later.
  2. Connected App-to-credential dependencies. A Connected App holds OAuth scopes, a consumer key, a JWT certificate, a refresh token policy, an IP allowlist, and a pre-authorized profile or permission set list. Each of those is a separate dependency edge. The Connected App is the visible node. The edges are not.
  3. Named Credential-to-everything dependencies. Named Credentials are the cleanest pattern Salesforce has ever shipped for managing outbound auth, and they are also the most opaque. A single Named Credential can be referenced by dozens of Apex classes, flows, External Services, and Agent actions. When you rotate the underlying credential, who told you which of those will fail?
  4. Owner-to-asset dependencies. Every certificate, Connected App, and Named Credential has an "owner" in the sense that someone, somewhere, knows why it was created. Six months later that person left the company, the wiki page they wrote got archived, and the asset still runs in production. The graph has a hole where the owner used to be.

These four shapes are not exotic. They exist in every org I have audited, including the ones run by very good teams.

Why the graph stays hidden

Salesforce gives you the nodes. Setup shows you certificates. Setup shows you Connected Apps. Setup shows you Named Credentials. Security Center will tell you which ones are misconfigured against a baseline. Shield will tell you what happened to them. Event Monitoring will tell you who touched them.

What Salesforce does not give you, because it is not Salesforce's job to give you, is the edges. The lines between nodes. The "this cert is used by these three Connected Apps and that Named Credential and this outbound flow" view that turns a list of assets into an actual map.

The reason this matters is that risk does not live in the nodes. Risk lives in the edges.

A cert by itself is not a risk. A cert that expires in 12 days and is referenced by your billing system's Mutual Authentication endpoint is a risk. The cert is the same cert in both cases. What changed is your knowledge of where the edge goes.

The compounding problem

Here is what happens in a healthy org over time.

Year one: a sharp architect sets things up cleanly. There are six certs, four Connected Apps, three Named Credentials. The architect knows what each one does. The graph is small enough to hold in one person's head.

Year two: the org grows. New integrations get added. Old ones get duplicated rather than refactored, because refactoring is risky and shipping is rewarded. The original architect moves to a new project, or a new company. There are now fourteen certs, eleven Connected Apps, nine Named Credentials. Nobody holds the whole graph in their head anymore.

Year three: the org has merged with two other orgs. The graph has tripled. Half the certs have unclear owners. Three Connected Apps were created for proofs of concept that became production without anyone noticing the transition. Two Named Credentials reference credentials in a password vault whose admin left the company.

Year four: someone rotates a cert because they were told it was expiring. Three integrations break that nobody knew were tied to that cert. Two of them are silent failures. One of them is the inbound API that the largest customer uses for nightly data sync. The customer calls. The war room opens.

This is not a story about negligence. This is what happens when the visible model (a list of certs in Setup) drifts further and further from the actual model (a graph of edges between certs and the things that depend on them).

What the 2026 enforcement wave is really doing

The industry shift to short-lived certificates (the move from 365-day to 200-day to eventually 47-day certificate lifetimes) is being framed in most Salesforce coverage as a renewal-frequency problem. "You used to rotate once a year, now you rotate eight times a year, plan accordingly."

That framing misses the actual challenge. The renewal frequency is the surface. The actual challenge is that every rotation event is a graph traversal event. Every time a cert rotates, the team needs to know which Connected Apps, Named Credentials, outbound integrations, and SSO configs depend on it. The cost of rotation is not the cost of clicking "renew." It is the cost of knowing what will break if you click the wrong "renew."

Multiply that by 8x annual frequency, and you do not get 8x more clicking. You get 8x more opportunities for the graph to bite you.

This is the part I want every architect reading this to internalize: the short-lived certificate era is a dependency-graph era. If you do not have a map of your edges, you are about to have eight times the chances per year to discover you needed one.

The map you cannot buy from Setup

I have worked with Security Center extensively. It is a genuinely good product. It tells you which of your orgs are deviating from a baseline policy, and it does that well. AppOmni does excellent work on the broader SaaS security posture management category, and I would recommend them to any large enterprise that needs a multi-cloud SSPM platform.

Neither of those tools is built to draw the dependency graph inside a single org. That is a different problem with a different shape. It is not "is this misconfigured against a baseline." It is "what depends on what." It is graph traversal, not policy evaluation.

This gap is the gap I have spent the last 18 months thinking about, and the next post in this series is going to walk through a specific outage story that made me certain this was a problem worth dedicating a product to. I will not name the product in this series yet. The series is about the problem, not the pitch.

But if you are reading this and you can name three certs in your production org without opening Setup, and you can name what each of those three certs is used by, and you can name who owns each one, you are in the top 5% of teams. Most of the orgs I see, even at sophisticated companies, cannot pass that test.

That gap, between the graph in your head and the graph in the org, is where the next two years of pain is going to live.

In the next post, I walk through a specific real-world outage involving an inbound API mTLS certificate that nobody knew was up for renewal, and what the 2026 move to short-lived certificates means for teams that are still managing this with calendar reminders.

If this resonated, I would love to hear how your team currently tracks cert and integration dependencies in your org. Reach out on LinkedIn.

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 2: The inbound mTLS certificate nobody owned.