Most security leaders know their application coverage is incomplete. Very few will say so out loud. Admitting you don't have full visibility into your own application landscape is a conversation that is very hard to have with a board, a regulator, or an auditor. So the gap stays where it is, understood privately, unacknowledged publicly, and unresolved operationally.
What identity security is meant to do
At its core, identity security is about answering two questions: who has access to what, and should they have it? Those questions sound simple. In practice they define the entire discipline. And they are simultaneously a security imperative and a compliance requirement, the same question asked for two different purposes.
The difference is not the question. It is the scope. Compliance asks it about the applications tied to a specific regulatory framework. Security asks it about everything. That single distinction, everything versus in scope, is where identity governance and identity security begin to pull apart.
This is not a governance problem. It is a scope problem. Most organizations are governing the right way. They are just governing too small a portion of the environment to make a meaningful difference in their actual security posture. The scope of identity governance has never matched the scope of identity risk.
The denominator problem
Ask any IAM team how many applications exist in their environment and you will rarely get a confident answer. Ask how many are currently governed and the gap between the two answers tells you everything you need to know.
The coverage conversation in IGA almost always starts with a percentage. How much of the portfolio is governed. How much is still outstanding. But there is a more fundamental question that rarely gets asked first: a percentage of what exactly? Because if the organization does not have a reliable count of everything that exists in its environment, then the coverage number is not measuring a gap. It is measuring a guess.
This is the denominator problem. And it is more common than most organizations want to acknowledge. The applications that are known, inventoried, and being actively tracked represent only part of the landscape. The rest exists in the gaps, business units that adopted tools without IT involvement, employees using SaaS applications that never went through a formal procurement process, shadow AI tools being used daily that nobody has mapped, and systems inherited through acquisitions that were never fully catalogued. The denominator keeps growing. The governance program does not.
When this reality surfaces inside an organization the reaction is rarely shock. Most teams already know. The more common response is quiet acknowledgment followed by a return to the work already in front of them. The gap is understood privately, accepted operationally, and left unaddressed because addressing it feels like a problem too large to start.
That is not negligence. That is what institutional resignation looks like in practice. And it is one of the most honest descriptions of where most IGA programs actually are today.
Where unknown applications come from
The sources of unknown applications are not a mystery to most security teams. Shadow IT, SaaS sprawl, shadow AI, acquisitions, every organization is dealing with some combination of all of them. The landscape keeps growing faster than any inventory process can keep up with. The problem is not awareness. Most teams know the gap exists. The problem is that knowing it exists and having a reliable way to measure it, let alone close it, are two very different things. And until you can answer the question of how many applications actually exist in your environment, every coverage conversation is built on an incomplete foundation.
Shadow AI deserves its own moment
Shadow AI brings the same challenges as shadow IT, unknown applications, unmanaged access, no ownership, no lifecycle governance. The difference is the stakes. These tools are not just accessing data. They are processing it, analyzing it, and in some cases transmitting it outside the organization entirely. An unsanctioned SaaS tool sitting idle is a risk. An unsanctioned AI tool actively ingesting sensitive data, financial records, employee information, customer data, intellectual property, and sending it to an external model is a different conversation entirely. And unlike traditional shadow IT where employees were working around IT, shadow AI is often being actively encouraged by leadership while the security team is still trying to build a basic inventory of what tools are in use.
The budget cycle trap
The budget conversation is where ambition fades. Not because organizations stop caring about coverage. But because the cost to onboard each application forces a choice between depth and breadth that should never have to be made. The roadmap gets cut to fit the budget. The deferred apps roll to next year. Next year the same conversation happens. And somewhere in that repeating cycle, full coverage stops feeling like a goal and starts feeling like a fantasy. The economics broke the ambition. And until the economics change, the pattern will not.
A different approach to building the inventory
Most organizations have some form of application inventory. A CMDB, a spreadsheet, a procurement list, something. The problem is not that the list doesn't exist. The problem is that it is rarely current, rarely complete, and rarely owned by anyone with an incentive to keep it accurate. It becomes stale the moment it is created because nobody is responsible for maintaining it.
The answer is not a better discovery tool. It is a formal certification process applied to the application portfolio itself. The same way IGA certifies whether users should still have access to applications, organizations should be certifying whether applications should still exist in the environment, who owns them, whether they are still active, how long they are expected to last, and what data they touch. And critically, are there new applications in use that are not yet on the list?
That last question is what separates a certification campaign from a simple inventory review. It does not just validate what is known. It actively solicits what is unknown. Making that process formal and recorded changes the accountability dynamic entirely. Application owners are asked directly. Their response, or their silence, goes on record. Knowingly failing to disclose an application that later becomes part of a security incident is a very different conversation than simply not knowing it existed. The certification campaign does not just build a better inventory. It creates accountability where none existed before.
A framework for prioritization
Prioritization is inevitable. The question is whether it is deliberate or reactive. Under the current model, the criteria organizations use to prioritize onboarding are shaped entirely by the economics of how long it takes.
Today, lifespan disqualifies applications. When onboarding takes months, spending that time on an application with a short remaining life rarely makes sense. Compress that timeline to days and lifespan becomes a sequencing decision, not a reason to defer.
Today, risk profile becomes a gating filter. Organizations can only afford to onboard so many applications, so only the highest risk ones make the cut. Change the economics and risk profile becomes what it was always supposed to be, a way to determine order, not eligibility.
Today, business impact stops conversations. The disruption and coordination required to onboard an application often outweighs the perceived benefit. Reduce the effort and that calculation changes entirely.
Today, budget determines scope. Organizations govern what they can afford to govern, not what they should govern. Change the cost per application and the budget conversation stops being about which applications to sacrifice.
None of these principles produce a perfect answer. But every one of them is shaped by a single variable: how long onboarding takes. Compress that timeline and the entire prioritization conversation changes. Lifespan becomes a sequence decision. Risk profile becomes an ordering tool. Business impact becomes manageable. The question worth asking is not which applications deserve governance. It is what becomes possible when the cost of governing them drops.
What Target teaches us about perimeters
The Target breach is one of the most referenced examples of how lateral movement turns a limited entry point into a catastrophic outcome. A vendor portal. Stolen credentials. And a path through the network that reached 1,797 point of sale systems. We cannot say with certainty what governance controls were or were not in place around that portal. But the question it raises is one every organization should ask about their own environment. If an application with external access and real credentials was compromised today, how far could an attacker go? If that application was outside your governance program, would you even know it had been compromised? If the identities accessing it had never been reviewed or certified, what would contain the damage?
The lesson from Target is not about HVAC systems. It is about the applications that sit at the edges of the governed perimeter, the vendor portals, the third party connections, the systems that carry credentials and network access but never made it onto anyone's governance roadmap. If those applications were governed, the calculus changes. Not because breaches stop happening. But because governance limits how far they travel.
Anything with network access and credentials is an identity risk. The compliance model defines a perimeter. The security model says there is no perimeter.
Closing
The coverage gap is not a mystery. Most security leaders already know it exists. The visibility problem is understood. The denominator is unknown but suspected. The prioritization decisions are reactive but rational given the constraints. None of this is a surprise to anyone who has run an IGA program for any length of time. The question that rarely gets asked is not why the gap exists. It is what would change if the economics and the timeline of closing it were fundamentally different. If onboarding an application took days instead of months, the lifespan objection disappears. The budget cycle trap loses its grip. The backlog becomes manageable. The certification campaign produces a list that can actually be acted on. Time stops being the enemy of coverage. The scope of governance starts to approach the scope of risk. None of that is possible inside the current model. But the question is worth sitting with: what becomes possible when the cost and the time required to govern an application drop low enough that the only real question is where to start?