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. And that gap between everything and in scope 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.
The landscape that governance cannot keep up with
Shadow IT, SaaS sprawl, shadow AI, acquisitions, every security team knows what these are and every security team is dealing with some combination of all of them. The point is not what they are. The point is what they represent collectively: an application landscape that grows continuously while the governance program moves in annual budget cycles. The gap does not grow because organizations stop paying attention. It grows because the economics of governing each application make it rational to let certain categories of applications accumulate outside the program indefinitely.
Shadow AI is worth a separate moment because it changes the risk profile of the entire category. It brings the same governance 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.
Acquisitions are where all of these problems arrive simultaneously and at scale. An acquisition does not introduce the problem of unknown applications. It just makes the problem impossible to ignore. If your application discovery process was already broken before the acquisition, it will not improve because the deal closed. You now have two unknown portfolios and a mandate to merge them. Two IAM systems running in parallel. Two security policies in conflict. Two audit frameworks producing findings with no clear owner. The initial unraveling of the acquired company's current state alone is a gigantic project before any integration work begins. And before you can merge two governance frameworks, you have to understand what you are governing. If that visibility did not exist before the acquisition, the merger does not create it. It just makes the absence more expensive.
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 does not 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, what data they touch, and whether there are applications currently 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, it is almost always reactive, shaped less by security logic and more by a single practical constraint: how long onboarding takes.
That one variable distorts every decision downstream. Lifespan becomes a disqualifier instead of a sequencing input. Risk profile becomes a gating filter instead of an ordering tool. Business impact stops conversations before they start because the coordination required to bring an application into governance often outweighs the perceived benefit. Budget determines scope, not the other way around. The result is a prioritization framework that looks deliberate on a roadmap and is driven almost entirely by economics in practice.
None of these are the wrong criteria. Lifespan, risk profile, business impact, and budget all belong in a mature onboarding strategy. The problem is what they become when the cost and time of onboarding are too high. They stop being tools for making better decisions and start being justifications for making fewer ones.
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 point of sale systems across thousands of locations. 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 any specific system. 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 attribute and policy based access controls move access decisions closer to real time, reducing the window where unnecessary access exists and limiting what is available when something goes wrong. When something does go wrong, knowing who has access to what is the difference between containing an incident and watching it spread.
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 left is where to start?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. And that gap between everything and in scope 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.
The landscape that governance cannot keep up with
Shadow IT, SaaS sprawl, shadow AI, acquisitions, every security team knows what these are and every security team is dealing with some combination of all of them. The point is not what they are. The point is what they represent collectively: an application landscape that grows continuously while the governance program moves in annual budget cycles. The gap does not grow because organizations stop paying attention. It grows because the economics of governing each application make it rational to let certain categories of applications accumulate outside the program indefinitely.
Shadow AI is worth a separate moment because it changes the risk profile of the entire category. It brings the same governance 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.
Acquisitions are where all of these problems arrive simultaneously and at scale. An acquisition does not introduce the problem of unknown applications. It just makes the problem impossible to ignore. If your application discovery process was already broken before the acquisition, it will not improve because the deal closed. You now have two unknown portfolios and a mandate to merge them. Two IAM systems running in parallel. Two security policies in conflict. Two audit frameworks producing findings with no clear owner. The initial unraveling of the acquired company's current state alone is a gigantic project before any integration work begins. And before you can merge two governance frameworks, you have to understand what you are governing. If that visibility did not exist before the acquisition, the merger does not create it. It just makes the absence more expensive.
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 does not 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, what data they touch, and whether there are applications currently 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, it is almost always reactive, shaped less by security logic and more by a single practical constraint: how long onboarding takes.
That one variable distorts every decision downstream. Lifespan becomes a disqualifier instead of a sequencing input. Risk profile becomes a gating filter instead of an ordering tool. Business impact stops conversations before they start because the coordination required to bring an application into governance often outweighs the perceived benefit. Budget determines scope, not the other way around. The result is a prioritization framework that looks deliberate on a roadmap and is driven almost entirely by economics in practice.
None of these are the wrong criteria. Lifespan, risk profile, business impact, and budget all belong in a mature onboarding strategy. The problem is what they become when the cost and time of onboarding are too high. They stop being tools for making better decisions and start being justifications for making fewer ones.
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 point of sale systems across thousands of locations. 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 any specific system. 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 attribute and policy based access controls move access decisions closer to real time, reducing the window where unnecessary access exists and limiting what is available when something goes wrong. When something does go wrong, knowing who has access to what is the difference between containing an incident and watching it spread.
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 left is where to start?