Legacy IAM Costs: The Hidden Financial Impact on ROI

A 30-minute access request doesn't look expensive until you multiply it by 400 tickets, 4 approvers, 2 identity systems, and 1 audit that nobody prepared for. That's where the financial impact of legacy access governance shows up, not in the software line item, but in the labor, licenses, delays, and cleanup hiding around it.

I've seen this pattern a bunch. The access process looks fine when you're 80 people. Then you're 300 people, then 700, then 1,200, and suddenly IT is doing detective work all week. Who approved this? Was access removed? Why is this person still licensed? Who has admin access? Fun times.

If you want to see how Jira-native access governance changes the math, Learn more about Multiplier.

Key Takeaways:

• Legacy access tools cost more through manual labor, unused licenses, audit prep, and standing privileges than through subscription fees alone.
• The real financial impact of legacy systems appears when access requests, approvals, provisioning, and evidence live in different places.
• Time-bound access is one of the fastest ways to reduce risk because access expires without someone remembering to clean it up.
• Access reviews should produce revocations and evidence in the same workflow, not another spreadsheet project.
• The cleanest model is simple: request in Jira, approve in Slack or Jira, provision through the identity provider, record evidence in the ticket.

Why Legacy Access Governance Costs More Than Licenses

Legacy access governance costs more because it turns every access change into a manual coordination problem. The ticket is only the visible part. The real cost sits in approval chasing, identity provider work, unused seats, audit evidence, and delayed employee work.

The Legacy Cost Is Mostly Labor

Most finance leaders look at the license line for their IGA tool and call that the budget. Wrong place to look. The bigger cost is the human work around the tool, especially when requests come through Jira, approvals happen in Slack, changes happen in Okta or Entra, and evidence gets rebuilt later.

Picture a normal Tuesday for an IT service manager named Priya. At 9:12 AM, an engineer pings her in Slack for GitLab access. At 10:03, a designer files a Jira ticket for Figma Admin. By lunch, one manager has approved a request by email, ignored another, and asked a clarifying question on a third. By 3 PM, Priya has manually added two users to Okta groups, pasted comments into three tickets, and left one request open because nobody knows who owns the app. Feels like work is moving. The system is leaking money.

The ugly part is that every leak looks small. Five minutes here. Twelve minutes there. One extra Figma seat left active for 60 days. One access review that takes three people two weeks to prepare. That's why the financial impact of legacy setups gets missed. It doesn't arrive as one giant invoice. It arrives as hundreds of tiny tasks nobody can defend as strategic work.

Spreadsheets Turn Audits Into Rework

Legacy audit prep is expensive because teams rebuild the story after the work already happened. The request was in Jira, the approval was in Slack, the access change was in the identity provider, and the review decision was in a spreadsheet. When the auditor asks for proof, someone has to stitch the movie back together frame by frame.

That might be tolerable once a year. Barely. It breaks when you're preparing for SOC 2, ISO 27001, customer security reviews, and internal access reviews at the same time. Security teams don't love spreadsheets. They use them because the real workflow doesn't produce audit-ready evidence by default. That's a reasonable read — spreadsheets are flexible and easy to start with. The problem is they make the cheap version of access governance expensive later.

The best analogy is expense reports. If employees paid for everything on personal cards, sent approvals by text, and uploaded receipts three months later, finance would lose its mind. Yet access governance often works exactly that way. The company grants access first, then tries to reconstruct the controls later. That's a bad financial model disguised as compliance work.

Standing Access Becomes a Balance Sheet Problem

Every unused SaaS seat and forgotten admin role is a line item your CFO is paying for, even if nobody is using it. The risk part gets most of the attention, and it should. Long-lived admin access is dangerous. The finance angle matters too. Every forgotten elevated role and inactive user with access to paid tools is recurring spend with no return.

Stavvy is a good example of what happens when a team takes the problem seriously. After funding and acquisitions, they had long-lived privileged access that didn't fit where the company was going. They moved toward just-in-time access and cut privileged access by 85%, with 1,300+ access requests automatically revoked after approved windows. That number matters because it shows the hidden cost of old habits. Access that doesn't expire becomes work, risk, and waste.

The real question isn't whether legacy access governance has a cost. It's whether you can see it before it compounds.

How to Measure and Reduce Legacy Access Costs

You reduce legacy access costs by measuring the full path from request to revocation, then removing every manual handoff that doesn't require judgment. Start with the work people repeat weekly. Then add expiry, identity provider automation, review evidence, and license cleanup.

Start by Auditing the Request Path

Before you touch a single tool, run this diagnostic on yourself. Pull 25 recent access requests and trace each from intake to closure. Ask five questions of each ticket: Did the employee request the right app and role without writing a paragraph? Was the approver clear before the ticket was created? Did the identity provider change happen from the workflow, or in a separate admin task? Can an auditor see request, approval, grant, and removal in one place? Did access expire without someone setting a calendar reminder? Score one point per yes. Anything below 4 out of 5, and you have a labor tax hiding in your governance program.

The thresholds tell you where to start. If more than 20% of requests need a follow-up question, your intake is too vague. If more than 10% sit for over 24 hours waiting on approval, ownership is unclear. If any approved request requires someone to copy data from Jira into Okta, Entra, or Google Workspace by hand, you're paying twice for the same decision. I like this test because it doesn't require a maturity model or a consultant. Just pull tickets and follow the trail.

The rule I'd use is pretty blunt. If a request needs more than one system after approval, automate the handoff before you redesign the whole governance program. Big transformation projects sound nice. Removing one repeatable handoff every week actually changes the numbers.

Put Expiry Dates on Risky Access

Time-bound access cuts legacy cost because it changes the default from "remember to remove this later" to "access ends unless there's a reason to extend it." That one design choice matters. A lot. When elevated access has a 1-hour, 6-hour, or 24-hour window, IT doesn't need a cleanup project every month to undo old decisions.

Security teams sometimes push back here, and I get it. Not every access request should expire quickly. A designer who needs Figma every day shouldn't file a new request every morning. Admin roles, production access, finance systems, customer data, and incident-related permissions are different. If access creates real risk, set a short window and make extension easy when the work is still valid.

A practical threshold works better than policy poetry:

1. 1 hour for emergency production access where the task is specific.
2. 6 hours for incident response or time-boxed troubleshooting.
3. 24 hours for elevated app admin work that may span a day.
4. 7 days only when the business task has a known project window.
5. Permanent access only when the role is part of the job, not the task.

The financial impact of legacy access shows up when risky access never expires. Someone has to review it later, justify it later, remove it later, or explain it later. Expiry shifts that burden to the system. That's the part I like most. You stop relying on memory as a control.

Move Access Reviews Out of Spreadsheets

Access reviews reduce cost only when decisions and revocations happen in the same workflow. A spreadsheet review that ends with "please remove these 47 users" is half a control. The expensive half is still sitting with IT, because someone has to translate review decisions into identity provider changes and then prove the changes happened.

The better test is whether a reviewer can make a decision with enough context to avoid rubber-stamping. Last login. Department. Job title. Group membership. Manager. App owner. Without that context, reviewers do what busy people do: they keep everything, because revoking the wrong thing creates pain. Bad review design creates bad review behavior.

Set a minimum context bar before launching a review:

• Show last login for each app where the identity provider has telemetry.
• Show department and job title so the reviewer can spot obvious mismatches.
• Show group membership so the reviewer understands what access means.
• Require a reason for revocation so audit evidence has substance.
• Execute approved revocations through the identity provider, not through a separate ticket queue.

Quarterly reviews should also have a scope rule. If an app has fewer than 10 users and no sensitive data, review it annually unless compliance says otherwise. If an app has admin roles, customer data, financial data, or production access, review it quarterly. Not perfect. Practical. And practical beats a beautiful policy nobody follows.

If you're trying to compare your current access review process against a Jira-native model, see how Multiplier works.

Tie Provisioning to the Identity Provider

Identity provider group mapping is where access governance starts to become financially sane. The request can still begin in Jira. The approval can still happen in Slack or Jira. The actual grant should flow through Okta, Entra, or Google Workspace groups, because that keeps access changes authoritative and reversible.

The common mistake is treating provisioning like an IT task instead of a workflow outcome. A ticket gets approved, then someone logs into the identity provider, finds the user, finds the group, adds the user, updates the ticket, and hopes they didn't miss a step. At small volume, that feels manageable. At hundreds of requests, it becomes a production line built out of copy and paste.

A decent rule: automate any app where you see 15 or more access requests per month. Below that, manual might be fine, especially for weird non-SSO tools. Above that, the math changes. If each request takes 10 minutes of IT time, 15 requests is 2.5 hours a month for one app. Multiply that across 20 apps and you're not dealing with "admin work" anymore. You're funding a hidden operations team.

Luno hit this wall during rapid growth. They had hundreds of routine access requests coming through Slack, email, and Jira, with IT chasing approvals and manually assigning Okta groups. After moving to a self-service app store with automated provisioning, they reported an 80% reduction in IT workload on access requests. Same company. Same access needs. Different operating model.

Measure License Waste by Last Login

License waste is usually easier to prove than access risk because money has a receipt. Pull your top 20 SaaS apps by spend and compare paid seats against last login activity. If someone hasn't logged in for 30, 60, or 90 days, you have a decision to make: keep, reclaim, or document a reason to exclude them.

Don't treat every inactive user the same. Executives may need access rarely. Contractors may be between projects. Some roles need emergency access even if usage is low. Fine. Build exclusions. The mistake is leaving every inactive account alone because a few have a legitimate reason.

A simple reclamation policy:

1. 30 days inactive for high-cost tools with broad employee access.
2. 60 days inactive for role-specific tools where usage is less regular.
3. 90 days inactive for lower-cost tools or apps with seasonal usage.
4. Manual review for executives, legal, finance, and security exceptions.
5. Automatic removal only after warning the user and giving them a grace period.

The financial impact of legacy license management isn't just wasted seats. It's the recurring meeting where IT, finance, and app owners argue over who still needs what. Last login data gives that conversation a spine. Without it, everyone has opinions. With it, you have a starting point.

Build a Weekly Access Cost Scorecard

A weekly scorecard keeps access governance from becoming a quarterly panic. You don't need 40 metrics. You need a small set that shows where money and risk are leaking. Request volume, approval time, manual provisioning time, expired access, inactive licenses, and review completion tell you most of what you need.

Keep the first version painfully simple. One page. Six numbers. Green, yellow, red. If approval time jumps, look at ownership. If manual provisioning time grows, map more apps to identity provider groups. If inactive licenses pile up, tighten reclaim rules. If access reviews miss deadlines, reduce scope or add better context for reviewers.

Track these every week:

• Total access requests opened and closed.
• Median approval time by app owner or manager.
• Number of manual provisioning actions.
• Count of time-bound grants created and revoked.
• Inactive paid seats by app.
• Access review decisions pending, kept, and revoked.

The scorecard works because it turns legacy cost into something you can manage before audit season. The fastest win is usually exposing the repeatable waste every Friday until nobody can ignore it anymore.

How Multiplier Makes Access Governance Auditable

Multiplier makes access governance auditable by keeping requests, approvals, provisioning actions, access reviews, and revocations tied to Jira records. It works through Jira Service Management, Slack, and your identity provider, so evidence is created during normal work instead of rebuilt later.

JSM Access Reviews With Enforced Revocations

Multiplier's Access Reviews replace the spreadsheet version of certification with a campaign workflow inside Jira Service Management. Admins choose approved applications, assign reviewers, and give reviewers context like user attributes, groups, last login, and recommendations. Reviewers mark Keep or Revoke, and revocation decisions can remove users from relevant identity provider groups while creating Jira evidence. The review doesn't stop at a decision — it connects the decision to the change.

Multiplier also gives compliance and IT a cleaner record for the audit story. The reviewer, the decision, the reason, the user, the app, and the removal live together instead of being split across sheets and screenshots. Audit prep becomes less about rebuilding evidence and more about exporting what already happened.

Time-Based Access Through IDP Groups

Multiplier's Time-Based Access makes elevated access temporary by default. A requester chooses a duration, like 1, 6, or 24 hours. After approval, Multiplier adds the user to the mapped identity provider group and starts the timer. When the window expires, it removes the group membership and records the change back in Jira. Automatic revocation requires access to be provisioned through identity provider group membership — an important boundary. Purely manual or non-SSO grants can't be auto-removed the same way.

That's where the earlier cost model changes. The 1,300+ automatically revoked access requests in the Stavvy story didn't happen by accident. They came from designing access with an end date. Multiplier supports that pattern with the Application Catalog, Approval Workflows, Slack approvals, and Automated Provisioning via identity provider groups. Employees request sanctioned apps through JSM or Slack. Approvers act in the systems they already use. The identity provider executes the changes. Jira keeps the evidence trail.

Stop Paying for Access Work Twice

The financial impact of legacy access governance is not one cost. It's the same work paid for twice. First, IT pays to process the request. Later, security and compliance pay to prove the request was handled correctly.

The fix is not another portal for employees to ignore. The better model is to put governance where access work already happens, then connect it to the identity provider so approvals turn into real changes. Request in Jira. Approve in Slack or Jira. Provision through Okta, Entra, or Google Workspace. Expire risky access automatically. Review access with usage context. Keep the evidence on the record.

That's how you stop treating audit readiness like a cleanup project.