Access review solution implementations fail for predictable reasons. Companies buy tools, map out processes, train reviewers, generate reports—then realize six months later that IT is drowning in manual work the tool was supposed to eliminate.

The reviews happen on schedule, auditors are happy, but your team knows the truth: they're still logging into dozens of applications to manually revoke access, still chasing down managers for approvals, still building custom integrations for apps the vendor doesn't support.

These failures aren't random. They follow patterns—patterns that emerge from vendors optimizing their demos for deals rather than outcomes, and from tools built for enterprise environments being sold to mid-market companies with completely different realities.

Once you see the patterns, they're impossible to unsee.

Mistake #1: Selecting Tools That Don't Perform Discovery

Vendors demo governance workflows, not visibility. They show you how to review access once you've told them what applications exist—not how their tool finds applications you don't have in your inventory.

IDP/SSO-based discovery only finds 30-40% of your apps. The rest—direct-authenticated SaaS tools, shadow IT, department purchases—remain invisible. And you can't run access reviews on applications you don't know exist.

You undercount your applications by 2-3x. IT believes they're managing 100 applications. Performing discovery reveals 300+. This isn't a slight miscalculation—it's a fundamentally incomplete picture that creates ongoing headaches.

Here's how it typically goes: Your team evaluates access review tools based on workflow features. Everything looks sophisticated—the UI is clean, the approval workflows are intuitive, the dashboards would look great in a board presentation. You select a tool, start implementation, and discover it can only review a fraction of your applications.

(Congratulations, you just bought a governance tool that assumes you already have complete visibility into your environment—or worse, one that only performs IDP/SSO-based discovery and leaves your team manually tracking the rest.)

Applications proliferate outside IT's control because that's how modern SaaS works. Departments buy tools with corporate credit cards. Employees sign up for services using work email addresses. Someone in marketing activates a new analytics platform, someone in sales adds a prospecting tool, someone in engineering spins up a collaboration workspace.

By the time IT learns about these tools, users have already provisioned themselves and granted permissions to teammates. Now your team is expected to include these apps in access reviews—but the tool you bought can't see them.

An incomplete inventory means incomplete automation, which means more manual work for your team.

Ask vendors specific questions:

• How does your tool perform discovery to identify applications we can't see?
• What methods do you use beyond IDP/SSO integration?
• Can you find tools that employees signed up for independently?
• Does your tool use network traffic monitoring, expense report mining, or browser activity analysis?
• Is discovery performed by the platform itself, or is it a separate module we need to purchase?

If the vendor's answer focuses only on inventorying applications you already manage or relies solely on IDP/SSO-based discovery, that's your signal. It's designed to govern a known application portfolio—which means your team fills the gap manually.

Look for platforms that perform discovery as a core function using multiple methods. A tool with sophisticated workflows that doesn't perform comprehensive discovery forces you to provide an inventory you don't actually have. That's not governance—it's theater.

Mistake #2: Treating Non-Employee Identities as Edge Cases

Contractors, vendors, and service accounts aren't edge cases. Technology companies might have 20-30% contractor populations. Consulting firms work extensively with client partners. Service accounts proliferate across engineering teams. These are normal operations—and they all need access reviews.

Enterprise IGA vendors charge extra for non-employee identities. Their pricing model reflects enterprise environments where full-time employees vastly outnumber contractors. Mid-market companies have different workforce compositions—and different budgets.

Excluding non-employees means incomplete coverage. When auditors ask about contractor access reviews and you explain those aren't covered by your tool, that's a problem you'll have to solve manually.

Organizations implement user access reviews focused on employees, then discover that contractors, vendors, partners, and service accounts create significant coverage gaps. When they ask vendors about reviewing these non-employee identities, they learn about premium pricing tiers or add-on modules.

(Because apparently contractors don't need access reviews unless you pay extra to acknowledge their existence.)

External users handle customer data, access financial systems, work in production environments. Service accounts run automated processes, integrate systems, execute scheduled tasks. Reviews that exclude these identity types miss significant exposure.

The risk from non-employee access often exceeds employee risk. Contractors retain access after engagements end. Vendor access persists after contracts terminate. Partner access remains active long after collaborations complete. Service accounts accumulate without documentation.

Audit findings routinely flag orphaned contractor access or undocumented service accounts that should have been caught in reviews.

Ask vendors specific questions:

• Do you charge separately for non-employee identities?
• Are contractors, vendors, and partners included in the base platform?
• Can you review service account access?
• What's the pricing model for external users?
• How do you handle contractor offboarding and access termination?

Calculate your total identity population including all types. If contractors represent 25% of your workforce and the vendor charges per-identity for them, your total cost might be 25% higher than employee-only pricing suggests.

The issue isn't just cost—it's whether the tool covers what you need to review, or whether your team ends up managing a parallel manual process.

Mistake #3: Accepting Jira Tickets Instead of Actual Remediation

"Automated access reviews" often just means automated email sending. The tool routes approvals and collects decisions. Then it creates Jira tickets for your team to manually revoke access.

Most tools can only remediate SSO-federated applications. That's 30-40% of your apps. The other 60-70% get Jira tickets—automatic remediation for a subset, manual work for everything else.

Binary revoke isn't enough—you need granular modifications. Sometimes users need access but shouldn't be admins. They need the tool but not the pro license. If the tool can only do full revoke, your team handles the nuanced changes manually.

Organizations implement "automated" access reviews that identify inappropriate access, collect reviewer decisions, and then... create Jira tickets. Months later, the access still exists because IT prioritized other work. The remediation backlog grows to hundreds of incomplete tasks.

(If the vendor says "seamlessly integrates with your existing workflows," that's code for "your team is doing the actual work.")

Here's what those Jira tickets actually mean in practice: log into Slack, remove 8 users. Log into GitHub, remove 6 users. Log into Salesforce, downgrade 4 users from admin to standard. Log into Notion, change 3 users from pro to basic licenses. Log into Figma, remove 5 users. Then repeat for the next 15 applications.

A review covering 20 applications with 50 users each generates hundreds of remediation actions. Even with a low denial rate—say 5-10%—that's 50-100 manual tasks landing on your team.

Manual remediation creates predictable problems. IT teams prioritize urgent issues over remediation tasks, so the backlog grows. Access that should be removed remains active for weeks or months.

For compliance purposes, you can document that inappropriate access was identified and marked for removal. But if the access never actually gets removed—or takes months to remove—the operational value is zero.

Ask vendors specific questions:

• Does your tool actually revoke access or just create Jira tickets?
• Can you remediate access for applications not connected to our SSO?
• Can you do granular modifications—downgrade roles, adjust licenses, modify permissions—or only binary revoke?
• Can you downgrade admin users to standard users instead of removing access completely?
• Can you adjust license types (pro to basic) without removing the user?
• What happens if remediation fails? How do you track and retry?

Watch vendor language carefully. "Integrated remediation workflows" often means ITSM ticketing integration—a fancy way of saying "we'll create a Jira ticket for your team to handle manually."

This is what closed-loop remediation actually means: the review happens, decisions get made, and access gets changed automatically without manual IT intervention. That's the difference between buying automation and buying a ticket generator.

Mistake #4: Ignoring Post-Acquisition Complexity

Tools built for single-tenant environments break when you acquire companies. Suddenly there are multiple IDP tenants, duplicate applications across regions, and conflicting identity data. The tool you bought can't handle it.

IDP consolidation takes years—or never happens. It keeps getting deprioritized for more urgent initiatives, so both IDPs operate in parallel indefinitely. Your access review tool needs to handle this reality, not assume you'll fix it first.

Your team ends up doing manual data aggregation. When the tool can't see across multiple IDPs or application instances, someone has to pull the data together manually every review cycle.

Organizations implement access reviews assuming a single identity provider and consistent application instances. The implementation works initially, then breaks when organizational structure changes through growth, acquisition, or geographic expansion.

(But don't worry—the vendor will be happy to scope a custom professional services engagement to handle your "unique requirements.")

Most mid-market companies reaching 500-5,000 employees have grown through acquisitions, geographic expansion, or business unit proliferation. Multiple application instances exist because different regions or business units deployed the same tool independently. Marketing runs one Salesforce instance, sales runs another. Engineering has GitHub instances for different product lines.

Conflicting identity data exists when the same person has accounts in multiple systems with different attributes, roles, or email addresses. Access reviews need to understand these are the same person, not separate users—or your team spends hours reconciling duplicate entries.

Tools that can't handle this complexity force you into painful choices: delay access reviews until after complete IDP consolidation (which might never happen), manually aggregate data across multiple instances, or accept incomplete coverage that misses entire populations.

Ask vendors specific questions:

• How do you handle multiple IDP tenants?
• Can you review access across multiple instances of the same application?
• How do you resolve identities when the same person exists in multiple systems?
• Do you charge extra for multi-instance support?
• Is this built into the platform or requires professional services?

Look for platforms where multi-instance support is built-in rather than an expensive add-on. This signals the vendor designed for organizational complexity rather than assuming simple single-tenant environments that don't exist in mid-market companies.

Mistake #5: Optimizing for Compliance Instead of Security

Compliance matters—but stopping there wastes your investment. When you have a SOC 2 audit next quarter, that's your immediate priority. You need to pass the audit. The mistake is buying a tool that can only do the minimum.

Compliance-only reviews become rubber-stamping exercises. Reviewers receive lists of users and permissions with no context. They approve everything because they can't make informed decisions.

You invest in a tool and still have the same problems. Dormant accounts remain. Excessive privileges continue. Contractors retain access after leaving. The audit passes, but your team still deals with access issues the tool didn't catch.

Let's be clear: compliance matters. When you have a SOC 2 audit next quarter or a SOX certification deadline, that's your immediate priority. Nobody's arguing against that.

The mistake isn't prioritizing compliance. The mistake is stopping there.

(Congratulations, you're compliant. You also spent budget on a tool that doesn't actually solve your access problems.)

Compliance-driven access reviews devolve into rubber-stamping exercises. Reviewers receive lists of users and permissions with no context. Without information about which accounts are dormant, which users have excessive privileges, or which external users should have lost access, reviewers approve everything.

What else are they supposed to do? Deny access to someone they don't recognize and hope that person wasn't actually supposed to have it?

The review satisfies compliance requirements—periodic reviews happened, stakeholders participated, documentation exists—while missing actual issues. But hey, the audit passed.

Ask vendors specific questions:

• How do you help reviewers identify problematic access?
• Can you flag dormant accounts, excessive privileges, or external users automatically?
• Do you support continuous monitoring or only periodic campaigns?
• What metrics can you report beyond compliance process metrics?
• Can you prioritize high-risk access for more frequent review?

The best tools treat compliance as the foundation and actual access management as the goal. You're already investing in a tool—make sure it solves problems beyond generating audit documentation.

Mistake #6: Underestimating Total Cost of Ownership

Software licensing is only 20-40% of total cost. Implementation, integration, ongoing operations, and your team's time make up the rest. The sticker price is just the entry fee.

CLI-based workflows mean hidden staffing costs. If the tool requires command-line interfaces for advanced operations, you need team members who know scripting—or you're paying to train them, or hiring consultants.

"Cheaper" tools with limited integrations cost more in year one. Tools that connect with only 150-200 applications require your team to build custom integrations for the rest. That work—building it, maintaining it, troubleshooting it—adds up fast.

Organizations select access review tools based on software licensing costs. One vendor quotes $30,000 annually, another quotes $50,000. The organization selects the cheaper option. A year later, they've spent $80,000 on the "cheaper" tool once implementation, integration, and ongoing operational costs are included.

(And if the tool gives you a command-line interface for "advanced workflows," congratulations—you now need team members who know scripting, or external consultants. All of which cost more than the license fee you were trying to save on.)

Vendors emphasize software licensing in initial conversations because that's the number that sounds good in procurement meetings. Buyers compare sticker prices without accounting for implementation effort, integration development, or ongoing administrative overhead. The full cost doesn't become visible until after purchase, at which point switching would cost even more.

The larger costs break down into:

Implementation effort: Professional services, internal project management time, integration development, process design, reviewer training.

Integration work: Custom connector development for applications without out-of-the-box support, API integration for remediation, data pipeline setup for multiple IDPs.

Ongoing operations: Administrator time managing the platform, reviewer time conducting reviews, IT time following up on manual remediation tasks.

Opportunity cost: What else could the team build or fix with the time spent on access review administration?

A tool costing $30,000 annually that requires 20 hours per month of IT administration has a real cost closer to $70,000 when your team's time is valued. A tool costing $50,000 annually with full automation might have total cost of $55,000.

Ask vendors specific questions:

• What professional services do you recommend for our environment?
• How many custom integrations will we need to build?
• What ongoing administrative effort should we expect?
• How much time do reviews typically require from IT?
• Does your tool require CLI knowledge for advanced workflows?
• How many out-of-the-box integrations do you support?

Calculate total cost of ownership including all components, not just software licensing. Build a TCO model that includes licensing, implementation, integration, operations, and switching cost.

True automation—where the tool performs discovery, routes reviews, collects decisions, and remediates access automatically—costs more upfront but less over time. The TCO comparison favors tools that truly automate versus tools that automate only the easy parts and dump the hard parts on your team.

The Pattern Worth Noticing

These six mistakes share a common origin: vendors build tools for how they wish mid-market companies worked, not how they actually work.

They assume you have complete visibility into your applications. You don't. They assume your applications are federated through SSO. They're not. They assume your workforce is mostly full-time employees. It isn't. They assume your team has bandwidth for manual remediation. You don't. They assume you'll grow in neat, linear ways. You won't. They assume compliance is all you need. It isn't.

The tools are built for a company that doesn't exist. And then they're sold to yours—with your team absorbing the gap between what the tool does and what you actually need.

The question isn't whether your next access review implementation will face these challenges. It will. The question is whether the tool you select was designed for those challenges from the start—or whether you'll discover the gaps six months in, after the contract is signed and your team is stuck making it work.

See how Zluri's visibility-first platform was built for the company you actually have.