What “Connected” Actually Means in Identity Governance (and Why Most Integrations Fall Short) 

A read-only connection tells you what access exists. Governance requires the ability to change it. 

“Connected” is one of the most overworked words in identity. On a program status report, an application is either connected or it is not: a green checkmark or a gap to close. The binary is convenient. It is also misleading. Two applications can both be marked connected and mean entirely different things. In one, the identity team can read a list of accounts. In the other, the team can create, change, and remove access on demand. Treating those as the same status is how programs develop a false sense of coverage. 

The Word “Connected” Does Too Much Work in Identity Governance 

Connectivity is not a state. It is a spectrum of capability. At the shallow end, a connection reads account data. It pulls a list of users and their entitlements so the information can appear in a dashboard or a certification campaign. This is aggregation, and it is genuinely useful. It answers the question of who has access to what. But it stops there. Reading access is not the same as governing it. 

A read-only integration is a bit like a smoke detector. It tells you there’s a problem and that’s valuable. But, if you goal is protecting the building, you also need a sprinkler system that responds automatically. Identity governance works the same way. Discovering inappropriate access is only the first step. Reducing risk requires the ability to change that access. 

At the deep end, a connection can act. It can create an account when someone joins, modify entitlements when a role changes, remove access when someone leaves, and confirm that each of those actions actually took effect in the target system. That is what governance requires, and it is a much higher bar than a green checkmark implies. 

Read-only Aggregation Is Not Identity Governance 

The distinction matters because most identity risk lives in the gap between knowing and doing. An access review can surface that a former contractor still has access to a finance system. That finding is only valuable if something removes the access. If the connection is read-only, the review generates a task, the task generates a ticket, and a person somewhere has to log into the application and make the change by hand. The certification closes. The access remains until someone gets to it. 

Read-only aggregation produces excellent reports and incomplete governance. It tells you where the problems are without giving you the means to fix them at the source. 

A report shows you the problem. Governance requires the ability to change it. 

What True Connectivity Requires 

A connection that supports governance has to do four things reliably. 

First, provision. When a person joins or changes roles, the connection creates the account and grants the appropriate entitlements. Not just a login, but the specific access the role requires. 

Second, deprovision. When access should end, the connection removes it, completely and promptly, without depending on a human to remember the steps. This is the capability that most directly reduces risk, and the one most often missing. 

Third, modify entitlements. Real access is not binary. People move between roles, departments, and facilities, and their entitlements should move with them. A connection that can only add or remove an account, but not adjust what that account can do, forces every change into a delete-and-recreate cycle that is slow and error-prone. 

Fourth, verify. This is the capability that is easiest to overlook and the one that separates a governance connection from an automation script. It is not enough to send a deprovisioning instruction. The connection has to confirm that the account was actually disabled in the target system, and to raise a flag when it was not. A task marked complete is not the same as access actually changed. 

Why Most Integrations Stop At Reading 

If deep connectivity is so clearly better, why do so many integrations stop at reading? Because reading is easy and writing is hard. Pulling data out of an application is a low-risk, well-trodden path. Pushing changes into it means understanding the application’s provisioning model, its entitlement structure, its error conditions, and its edge cases. It also means being trusted to make changes in a production system that clinicians, finance teams, or engineers depend on. 

There is also a counting incentive. When success is measured by the number of applications connected, the fastest way to raise the number is to build shallow connections and move on. Once connector count becomes a KPI, organizations naturally optimize for connector count. That’s how libraries of hundreds of read-only integrations get built while the hardest applications remain manual. A library of hundreds of read-only integrations looks impressive on a slide. It does not change what happens when an employee leaves. 

Some connections stop even shorter than reading. They extend single sign-on or credential management to an application so that logins are centralized. That solves an authentication problem, which is worth solving. But controlling how someone signs in is not the same as governing what they can do once they are in, or ensuring their access ends when it should. 

The Better Question To Ask 

The useful question is not whether an application is connected. It is what the organization can actually do with the connection. Can we provision access, or only observe it? Can we remove access automatically, or does removal still depend on a ticket? Can we adjust entitlements as roles change? And when we send a change, do we know it landed? 

Answered honestly, these questions usually reveal that real coverage is narrower than the connector count suggests. Far fewer applications are truly governed than are technically connected. The difference between those two numbers is where audit findings and standing risk accumulate. 

Connected Should Mean You Can Act 

Connectivity should be measured by capability, not by presence. An integration that reads access without the ability to change it is a reporting feed, not a governance connection, and calling it connected hides the gap rather than closing it. The programs that will stand up over the next few years will not be the ones with the largest connector libraries. They will be the ones that can consistently provision, modify, verify, and most importantly, remove access across every application that matters. Identity programs do not reduce risk because they know who has access. They reduce risk because they can change that access when it matters. In identity governance, “connected” should mean that you can act, not just that you can see.