In the first post I argued that risk in a Salesforce org does not live in the nodes. It lives in the edges, the invisible lines between an asset and the things that quietly depend on it. In the second post I followed one edge through a single bad night: an inbound mTLS certificate that expired with no owner and no monitoring, and took a nightly sync down at the transport layer.

That post was about a node that fails by expiring. This one is about a node that fails in the opposite way. A certificate that expires fails closed. The handshake breaks, the requests stop, and eventually someone notices the silence. A Connected App does not expire. It keeps working, faithfully, for whoever holds its token. Including, in 2025, for people no one ever meant to authorize.

A certificate's danger is that it stops. A Connected App's danger is that it does not.

The email nobody could answer

Picture the security inbox on a Thursday in late August 2025. The message is the one that landed in thousands of Salesforce customers' inboxes that month: a widely used third-party integration's OAuth tokens may have been compromised, review your connected apps, revoke anything you do not recognize. No outage. Nothing is down. Every dashboard is green. And yet this is worse than the mTLS night, because there is no failure to trace back to a cause. There is only a standing grant of access and a single question that has to be answered fast.

What could that token actually reach?

That is the only question that matters in a breach-notification window, and it is the one almost no org can answer from Setup. The Connected App is right there in the list. Its name is familiar. But the app is a node, and the question is about edges: which run-as identity does it authenticate as, which OAuth scopes did it carry, which objects and fields does that identity see, and what credentials are sitting inside the records it can read. The team can see that the app exists. They cannot see how far it goes.

This was not a hypothetical in 2025. It was the year's defining Salesforce security story, told twice. In August, attackers abused stolen OAuth tokens from a popular chatbot integration to reach hundreds of Salesforce environments, querying objects like Users, Accounts, and Cases and quietly exfiltrating secrets that customers had stored in those records: API keys, warehouse tokens, passwords. In November the pattern repeated through a different set of published apps connected to Salesforce. Salesforce was consistent and, I think, correct in its framing both times: there was no core platform vulnerability. The weakness lived in external apps that held broad, long-lived access, and in orgs that could not say what that access actually touched.

That is an edge problem wearing a breach's clothing. The platform did exactly what it was told. The trust had been granted, years earlier, by someone who is no longer in the room, at a scope nobody had revisited since.

Why a Connected App fails differently

It is worth being precise about why this node is so hard to reason about, because the shape of it is the whole point.

A certificate has one job and a binary state. It is valid or it is expired. When it fails, it fails everywhere it is used, at the same moment, and at least one of those failures is usually loud enough to start an investigation.

A Connected App is not binary. It is a bundle of standing grants, and each grant is a separate edge:

  • The OAuth scopes it was authorized for, which define the ceiling of what any token issued through it can do.
  • The run-as identity behind the flow, very often an integration or API-only user whose profile and permission sets quietly determine the real blast radius, well below the scope ceiling.
  • The consumer secret or JWT signing certificate that proves the app's identity, held partly in Salesforce and partly in some external system or vault.
  • The refresh token policy, which decides whether a token issued once keeps working indefinitely or has to be re-earned.
  • The pre-authorized profiles and permission sets, the list of who is allowed to use the app, which grows every time a new team is onboarded and shrinks approximately never.

None of these is visible as a risk on its own. A Connected App with admin-level scopes is not a problem if its run-as user can only see one custom object. A Connected App with a narrow run-as user is not a problem until someone adds it to a permission set that grants View All Data. The risk is never in the node. It is in the particular combination of edges, and that combination is exactly what Setup does not draw for you.

The traversal nobody could do

Go back to the breach email. To answer "what could that token reach," a team has to walk the graph by hand:

Start at the Connected App. Read its authorized scopes. Find the identity the integration runs as. Open that user's profile and every permission set assigned to it, and reconstruct the union of objects, fields, and system permissions it holds. Now ask which of the records that identity can read contain secrets of their own, because the 2025 campaigns were not after Salesforce data for its own sake. They were after the credentials customers had stored inside it, the keys that open the next system.

Every step of that lives in a different corner of Setup, and not one of the corners points at the next. The Connected App's scope list does not name its run-as user. The run-as user's profile does not name the app. The permission sets do not announce that they widened an integration's reach. The secret in the field does not know it sits inside the blast radius of an OAuth grant configured three years ago. Reconstructing the path is the cost of the incident. Revoking the token is two minutes. Knowing what the token touched is the part that consumes the war room, and the same owner-to-asset hole from the first post is sitting right in the middle of it: the person who scoped this app left, and the reason it has the access it has left with them.

This is the second of the four shapes I named in the first post, the Connected App to credential dependency, and it is the one with the highest stakes, because its failure mode is not a stale dashboard. It is data leaving the building.

Why 2025 and 2026 make this everyone's problem

For most of the platform's history you could carry an unscoped Connected App indefinitely and never pay for it, the same way you could carry an unmonitored certificate. Two forces ended that, and they arrived close enough together that most teams are absorbing both at once.

The first force is the breach wave above. It established, in public and at scale, that an over-permissioned app holding long-lived tokens is the most attractive entry point into a Salesforce org, and that the orgs which suffered most were the ones that could not quickly answer the reach question.

The second force is Salesforce's own response, and it is structural. As of the Spring '26 release, Salesforce has disabled the creation of new Connected Apps by default across both the UI and the Metadata API, except through package installation, and re-enabling it now requires a request to Salesforce Support. The forward path is the External Client App, a redesign of the same idea with explicit application identity and cleaner scope boundaries. This followed the September 2025 restrictions on uninstalled connected apps, which now require a specific permission to authorize and which blocked the OAuth device flow outright.

Read those two forces together and the position is uncomfortable. The breach wave told every org to scope down its Connected Apps. The platform change told every org to migrate them. And both of those instructions are graph traversals, not button clicks.

You cannot scope down what you cannot map. You cannot migrate an app to an External Client App without knowing which run-as identity it authenticates, which flows and Apex callouts assume it exists, which integration breaks the morning after you move it, and which pre-authorized profiles need to come along. The migration is not a rename. It is the same edge-walk the breach email demanded, run again under a different deadline. An org that could not answer the reach question in August is the same org that cannot safely answer the migration question now.

The point I want architects to take from this is the one from the first two posts, sharpened a third time. In the certificate posts it was: every certificate rotation is a dependency-graph traversal. Here it is: every Connected App is a standing grant of reach, and every audit, every token revocation, and every migration off it is a traversal of edges you probably never drew. The breach made that traversal urgent. Spring '26 made it mandatory.

What to do before the next notification

You do not need a product to start closing this gap. You need to stop treating Connected Apps as a list and start treating each one as a set of edges. Concretely:

  • Inventory every Connected App and name its run-as identity. For each app, write down four things: the OAuth scopes it holds, the user or integration identity it authenticates as, the consumer secret or signing certificate behind it, and a named human owner. If you cannot fill in all four, that app is your blast radius and you do not know its size. Salesforce Ben's admin's guide to auditing connected apps is a good operational starting point.
  • Compute the real reach, not the scope ceiling. The scopes set the maximum. The run-as user's profile and permission sets set the actual blast radius. Walk that union for every integration app and ask the credential question: of the records this identity can read, which ones hold secrets that open another system. That is the path the 2025 campaigns walked, and it is the path your audit has to walk first.
  • Lock the front door with API Access Control. Restricting API access to an allowlist of approved connected apps, and setting Permitted Users to admin-approved rather than all users, turns the open question of "who can connect what" into an explicit decision you control.
  • Treat the External Client App migration as a mapping exercise, not a config change. Before you migrate an app, reconstruct its full edge set. The migration deadline is the cheapest reason you will ever have to draw this map. Drawing it later, in a breach window, is the most expensive.
  • Watch the grant, not just the login. Connected App OAuth usage tells you which apps are actually issuing tokens and authenticating sessions. An app that appears in that usage and not in your inventory is the shadow integration you were about to be surprised by.

The Connected App is the sharpest example of this shape because it does not fail by stopping. It fails by reaching further than anyone remembered granting, silently, for as long as a token stays valid. The same logic runs through every Named Credential and every External Credential in the org, which is where this series goes next.

That gap, between the access you think an app has and the access it actually has, 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 could this token reach" is a long afternoon in Setup and a few phone calls, you already know which side of the gap you are on.

If you want to compare notes on how your team scopes, audits, and migrates Connected Apps, reach out on LinkedIn. The stories are the same shape every time, and the teams telling them are rarely the careless ones. They are the ones whose orgs got big enough that the map fell out of one person's head.

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