"Onboarding apps isn't a problem. That doesn't scare me. It's the continuous maintenance of hundreds and thousands of apps that scares me because my team isn't that big."

That was a client. Sitting across the table. Being more direct than most people are willing to be in that conversation. Everything else, the onboarding, the integration complexity, the budget, those were manageable. The maintenance was not. The permanent, accumulating, never-ending operational load that comes after the project closes.

Onboarding has a finish line. Maintenance does not.

That distinction matters more than most IGA programs account for. Onboarding gets resourced because it has a defined scope and a delivery date. Someone has to approve the budget, staff the project, and sign off on completion. Maintenance becomes part of what the team owns from the moment an application reaches governed state, sitting outside the project plan and absorbed into operational capacity without ever being formally scoped or allocated.

And it accumulates. Gradually. One application at a time. Without triggering a conversation or a budget request.

Every application that reaches governed state adds to the load. Another aggregation to monitor. Another set of entitlements to keep current. Another application to prepare for the next audit cycle. Multiplied across dozens of applications it is manageable. Multiplied across hundreds it becomes something else entirely.

At some point the team stops asking which applications to onboard next. The question becomes how to keep up with what is already governed. Onboarding more applications does not feel like progress at that point. It feels like a threat. Every new application added to the program is another permanent addition to a load the team is already struggling to carry.

One of the heaviest recurring costs is audit preparation. Every governed application needs to prove its governance is current every time the audit cycle comes around. Certifications need to be pulled. Access records need to be validated. Exceptions need to be documented. For a handful of applications that work is manageable. For hundreds it becomes a significant manual effort that lands on the same team every single time. And unlike onboarding, it never gets easier. It just gets bigger.

But audit preparation is only part of the story. The deeper problem is what happens when the maintenance work that should be keeping the governance program current does not get done consistently. Data quality drifts. Aggregations run incomplete. Entitlement mappings stop reflecting reality. Certification results start raising more questions than they answer. None of those things individually destroys confidence in the platform. But accumulated over time, across hundreds of applications, they produce exactly that outcome.

One organization reviews two hundred governed applications manually every three months. These applications are onboarded. The platform is running. But somewhere in the process something broke and the team no longer trusts what the platform is telling them. So every quarter, by hand, they go through two hundred applications to verify what the platform should already know. The fix would require external help, context resurrection, and a budget nobody can justify when the existing team can absorb the work instead. So the manual process continues. The platform sits there. And the team that was supposed to benefit from governance is now burdened by it.

Trust in a governance platform does not break all at once. It erodes. A data quality issue here. An aggregation that ran incomplete there. An entitlement mapping that never quite matched reality. A certification result that raised more questions than it answered. None of those individually would cause a team to stop believing their platform. But accumulated over time, across hundreds of applications, they produce exactly that outcome. A team that technically has a governance program and operationally does not trust it.

This is the maintenance trap. The program succeeds at onboarding applications and then fails to account for what that success costs. The coverage number keeps climbing. The team keeps shrinking relative to the load. And somewhere in that gap, the governed estate starts to degrade in ways that never show up on a dashboard.

The question that follows is the same one that runs underneath every blog in this series. If the maintenance burden of governing thousands of applications became as manageable as the onboarding is becoming, what would a team be capable of? What would full coverage actually look like if the cost of sustaining it stopped being the reason it was never pursued?

The work is not getting harder. It is accumulating. And until the model changes, the team will keep choosing survival over scale.