If you're building zero trust controls for SaaS access in spreadsheets, you're not building zero trust. You're rebuilding audit evidence one ticket at a time, usually after the access risk already turned into license waste.
And honestly, that's where a lot of IT and security teams get stuck. They buy the idea of zero trust. Least privilege. Verify every request. Remove access when it's no longer needed. Good stuff. The day-to-day still runs through Jira tickets, Slack pings, identity provider group changes, and someone exporting a spreadsheet two days before the audit.
Key Takeaways:
- Zero trust controls for SaaS access only work when approvals, provisioning, revocation, and evidence live in the same workflow.
- The hidden cost isn't just security risk. It's unused licenses, stale privileges, and audit evidence rebuilt after the fact.
- If access isn't removed automatically after inactivity, expiry, or role change, your control is really just a reminder.
- Jira and Slack already carry most of the access workflow, so forcing users into another portal usually adds friction.
- The better model is to make access temporary, usage-aware, and tied to the identity provider from the start.
Why Zero Trust Controls Break When Access Work Splits Across Tools
Zero trust controls break when the request, approval, provisioning step, and audit record happen in separate systems. The handoff creates delay, missing evidence, and stale access. For SaaS access, the real weak point is usually the gap between Jira, Slack, the identity provider, and the spreadsheet someone keeps for audit season.
I've seen this pattern a bunch. Someone asks for access in Slack because it's faster. A manager replies with a thumbs up. IT opens Okta or Entra, adds the person to a group, then updates a Jira ticket if they remember. Three months later, the person has changed teams, the license is still active, and no one has a clean record of why access was granted in the first place.
That sounds like a process problem. It's actually a zero trust problem.
The access request is not the control
The ticket is not the control. It's the receipt. The control is whether the right person approved the right access, whether the identity provider changed the right group, whether the access expired when it should, and whether the evidence is complete enough that an auditor doesn't need a treasure hunt.
Picture a workplace technology manager at 9:17 AM on a Tuesday. Their queue: 38 open access tickets in Jira, 12 Slack DMs asking for status, and a CFO Loom video about climbing SaaS spend. Two requests are for admin access. One is for a contractor who leaves Friday. Five are for apps the requester hasn't logged into since August. That person isn't doing governance. They're playing traffic cop with a stack of receipts.
If your team is already running access through Jira and Slack, the next move is not another detached portal. The better move is to make the workflow you already use enforce the control. For teams trying to connect service desk work with real access enforcement, Learn more about Multiplier in the context of Jira-native governance.
SaaS waste is an access governance signal
Unused licenses are a control failure with a monthly invoice attached. If someone hasn't logged into a paid SaaS app in 30, 60, or 90 days, the question is not only "why are we paying for this?" The better question is "why does this person still have access?"
A fair counterpoint: some users need access even if they rarely log in. Executives, auditors, legal teams, and incident responders can be legitimate exceptions. Fine. Build exclusions. If your default state is "keep paying until someone notices," you're not running zero trust controls for SaaS access. You're running trust-by-renewal-date.
Think of a building where every contractor, intern, and former employee still has a working badge in the bottom of a drawer somewhere. Nothing has gone wrong yet, but the security model is just hope wearing a lanyard. SaaS works the same way. The door is an identity provider group. The lost inventory is budget, customer data, and audit confidence. The drawer is your spreadsheet.
The broken part isn't the policy deck. It's the missing execution layer.
How to Build Zero Trust Controls That Actually Remove Access
Zero trust controls for SaaS access need four operating rules: request from an approved catalog, approve based on risk, provision through the identity provider, and revoke based on time or usage. If any of those four steps are manual, the control will eventually fail under ticket volume, team changes, or audit pressure.
The core idea is pretty simple. Stop treating access as a one-time grant. Treat it like a lease. Someone gets the app, role, or group membership they need, for the reason they gave, for the amount of time or activity pattern that makes sense. After that, the system should challenge the access again.
Start by diagnosing where access really leaks
Before you write a single policy, run this diagnostic. Pull 20 recent access requests and try to answer four questions for each one in under 5 minutes: who approved it, which identity provider group changed, when access should end, and where the evidence lives. If you can't answer all four for more than 5 of the 20 requests, your zero trust controls aren't operational yet — they're aspirational.
I'd start with five questions. Not because five is magic. Because anything more turns into a workshop nobody wants to attend. Ask these:
- Where did the request start? Jira, Slack, email, direct DM, or a side conversation?
- Who approved it? Manager, app owner, security, or "whoever replied first"?
- What changed in the identity provider? Specific group, role, license, or account status.
- When should access end? Fixed expiry, inactivity threshold, employment change, or no expiry.
- Can an auditor follow the story? One ticket, one timeline, one proof trail.
Miss two or more answers across the 20 requests, and the fix isn't policy writing. It's workflow repair. The policy probably already says the right thing. The work just doesn't follow it.
We saw this with a fintech that had grown to nearly 1,200 employees. Access requests were coming through Slack, email, and Jira, and IT was manually chasing approvals and assigning Okta groups. Standard requests took 5 to 30 minutes each. After the workflow moved into a governed Jira model with automated provisioning, IT workload on access requests dropped 80%. Same policy intent. Very different operating model.
Make the app catalog the front door
What if employees couldn't request an unapproved app even if they tried? That's what a real catalog does. Employees pick the app, the role, and the reason from one list. The request creates a tracked workflow. If an app isn't approved, it doesn't appear as a normal request option. Not a spreadsheet. Not a wiki page. A real catalog.
This sounds basic. It's where a lot of teams go wrong. They start with the hardest governance problem first, like quarterly certification or privileged access. Meanwhile, 70% of daily access noise is routine SaaS requests with missing context. Fix intake first. The rest gets easier because every downstream step has cleaner data.
The threshold I'd use: if an app gets more than 10 access requests per month, put it in the catalog with mapped roles. Under 10, keep it tracked but don't over-engineer. There's a real downside to catalog work — someone has to define owners, roles, and group mappings, and that's a real time investment. Worth it for the top 15 apps by volume. Not worth it for every niche tool on day one. The honest tradeoff: you'll under-govern the long tail for a quarter while you fix the head.
For a 500-person advertising company, Tuesday became the ugly day. New hires started Monday, then the next day IT got flooded with app requests that lacked details. The better model was a self-service app catalog inside Jira, with sanctioned apps and clear roles. They processed 500+ app requests in 6 months and saved 70+ hours of IT time. Not because the team worked harder. Because the request had structure before it hit the queue.
Use risk to decide approval depth
Approval workflows should get stricter as risk goes up. Low-risk access can be approved by a manager or even auto-approved when policy allows. Admin roles, production systems, finance tools, and sensitive datasets need the app owner or security involved. If every request gets the same approval path, your team either slows everything down or rubber-stamps risky access.
A simple rule works well. Split apps into three groups:
- Low-risk apps: collaboration tools, read-only knowledge tools, basic employee apps
- Medium-risk apps: customer systems, finance-adjacent apps, tools with export rights
- High-risk apps: admin consoles, production access, privileged identity groups
Low-risk requests should close fast. Medium-risk requests need the right owner. High-risk requests need time limits by default. If a high-risk role is requested for more than 24 hours, require a stronger reason or a second review. Not because 24 hours is perfect, but because permanent admin access should feel abnormal.
Security folks sometimes push for more approvers everywhere. I get the instinct. More eyes feels safer. After two approvers, you often add more delay than judgment — each extra approver adds hours of latency and catches almost no new issues, because the second reviewer already cleared the substantive risks. The better control is precise routing, time-bound access, and automatic removal. Approval is the gate. Revocation is the part people forget.
Provision through groups, not human memory
Zero trust controls only become reliable when the approved workflow changes access through the identity provider. The key is group mapping. A catalog role maps to an Okta, Entra ID, or Google Workspace group. Approval moves the ticket forward. The identity provider group changes. The ticket records what happened.
That chain matters because identity providers are usually the source of truth for SaaS access. NIST's zero trust model talks about continuous evaluation and least privilege in SP 800-207, but the operating version of that idea is boring. It means the access grant should be authoritative, reversible, and tied to the system that actually controls access.
Manual provisioning breaks that chain. Someone copies a username, opens the identity provider, picks a group, hopes it's the right one, then leaves a comment. Works at 20 requests a month. At 200, mistakes show up. At 2,000, the whole model becomes expensive.
The conditional rule is blunt: if an app supports identity provider group-based access, humans shouldn't be the normal provisioning path. Reserve manual steps for apps without reliable SSO or group support. When manual access is unavoidable, still create the ticket, approval, owner, and review trail. Manual doesn't mean invisible.
The team-level payoff is real. When the approved request triggers the group change, IT stops being the person who clicks the button. They become the team that designs the guardrails. Much better job.
Set expiry for privileges and inactivity for licenses
Time-based access and usage-based reclamation solve two different problems. Time-based access reduces risk from standing privilege. Usage-based reclamation reduces waste from unused SaaS licenses. Put both in place and you get a much cleaner zero trust control model for SaaS access.
Privileged access should almost always have a clock. One hour for quick production checks. Six hours for incident work. Twenty-four hours for longer operational tasks. If someone needs it again tomorrow, they can request it again. Annoying? Maybe a little. Long-lived admin access is one of those things everyone agrees is bad, right up until someone has to remove it manually.
License reclamation needs a different test. Start with 30 days of inactivity for expensive apps ($30+/seat/month), then add a 7-day grace period so users can keep access by logging in or responding. For lower-cost apps, 60 or 90 days is more reasonable — the reclamation effort has to be worth less than the license. The point isn't to yank access randomly. The point is to make inactivity visible and reversible.
SaaS sprawl keeps getting worse because apps are easy to buy and hard to clean up. Okta's Businesses at Work report has tracked how app usage keeps spreading across companies, especially as teams add specialized tools. More apps means more access paths, more licenses, and more evidence to explain later.
When inactivity and expiry are part of the workflow, the cleanup doesn't depend on someone having a slow Friday.
Run reviews from the system of record
Access reviews should test whether the access story still makes sense. Reviewer, user, app, group, last login, recommendation, decision, and revocation should live together. If reviews happen in spreadsheets while requests happen in Jira and grants happen in the identity provider, the review is already behind.
A good review process has a narrow scope. Start with 10 to 20 high-risk or high-cost apps, not every app in the company. Give reviewers usage context, like last login and department. Ask for a Keep or Revoke decision. Then make revocation executable, not advisory.
A common mistake is treating access reviews as compliance theater. Export users. Send spreadsheet. Get approvals. Store file. Everyone survives. Nobody improves. And the same stale access comes back next quarter.
A better rule: every review campaign must remove something or prove why nothing should be removed. If a campaign reviews 1,000 entitlements and revokes zero, either your access posture is amazing or your reviewers are rubber-stamping. Usually it's the second one.
The mid-process move that matters is connecting reviewer decisions to the actual removal path. When Keep or Revoke only updates a spreadsheet, IT still has work to do. When Revoke removes the identity provider group membership and records it back to the ticket, the review becomes a control instead of a report. If your access reviews still create cleanup work after decisions are made, See how Multiplier works with Jira-based campaigns and identity provider revocation.
There are exceptions. Some regulated teams need evidence exports for GRC platforms. Some apps won't have clean login data. Some access has to be verified manually because the system doesn't expose enough detail. All valid. The commitment should still be the same: the review result needs to connect to a real access change.
How Multiplier Enforces Access in Jira
Multiplier helps teams standardize SaaS access requests and approvals through Jira Service Management and Slack, while using identity provider group mappings to carry approved changes through to provisioning and removal. The workflow doesn't stop at approval, and the access change and audit trail stay tied to the Jira issue.
Jira and Slack become the control surface
Multiplier gives employees a Jira-native app catalog where they request approved applications and roles, with Slack available for requests and approvals. Approvers can act from Jira or Slack, and the workflow still writes back to the Jira issue. That matters because the audit trail is created while the work happens, not rebuilt later.
Once a request is approved, automated provisioning can add or remove users from mapped identity provider groups in Okta, Entra ID, or Google Workspace. Time-based access can add a duration, then remove the group membership when the window ends. For routine SaaS waste, Auto Reclaim can use last-login data from the identity provider, apply inactivity thresholds and grace periods, warn users, and revoke access if they remain inactive.
The important constraint is worth saying out loud. Automatic revocation depends on access being controlled through identity provider group membership. If an app isn't connected or doesn't provide useful login telemetry, no system can magically reclaim every license. Fair enough. For the apps that do connect cleanly, the manual follow-up starts to disappear.
Reviews and reclamation close the loop
Access Reviews in Multiplier run inside JSM, with reviewers seeing user attributes, groups, last login, and recommendations. A reviewer can mark Keep or Revoke, and revocations remove users from the relevant identity provider groups. Jira tickets document the change, which gives IT, security, and audit the same record to work from.
That closes the loop most access programs miss. Request in one place. Approval in one place. Grant through the identity provider. Remove based on expiry, inactivity, or review decision. Evidence attached to the work. Not fancy. Just much harder to break.
Make Zero Trust Controls Boring Before Audit Week
Zero trust controls for SaaS access should feel boring most days. The employee requests the right app, the right person approves, the identity provider changes the right group, and the system removes access when the reason disappears. Boring is the goal.
The mistake is waiting until audit week to prove control. By then, people are hunting through tickets, screenshots, Slack threads, and CSV exports. And everyone knows the story is messier than the policy says.
Build the evidence while the work happens. Make access temporary where risk is high. Reclaim licenses when usage goes stale. Run reviews where the original access record already lives. Then zero trust becomes less of a slogan and more of an operating rhythm.
Frequently Asked Questions
How do I set up time-based access with Multiplier?
When submitting an access request through Jira Service Management or Slack, pick the duration you need — 1 hour, 6 hours, 24 hours. After approval, Multiplier provisions the access and sets a timer. When the window closes, the identity provider group membership is removed automatically. If you need more time, just request it again. Access only lives as long as the reason for it does.
What if I need to reclaim unused licenses?
If you want to reclaim unused licenses, use Multiplier's Auto Reclaim feature. Here’s how: 1) Set inactivity thresholds in Multiplier for your applications (like 30 days without login). 2) Define a grace period to give users a chance to log in before their access is revoked. 3) Multiplier will automatically notify users who exceed the inactivity threshold. If they don’t log in during the grace period, their access will be revoked, and a Jira ticket will document the change. This process helps reduce unnecessary SaaS spending by ensuring licenses are only assigned to active users.
Can I automate access approvals in Multiplier?
Yes, you can automate access approvals in Multiplier by setting up approval workflows. Here’s how: 1) In the Multiplier settings, map approval workflows to specific applications, designating who the approvers are (like managers or app owners). 2) When a request is submitted, it will automatically transition to 'Waiting for Approval' status, and approvers will receive notifications in Jira or Slack. 3) Once approved, Multiplier will automatically provision the access and update the Jira ticket. This streamlines the approval process and ensures that every request is tracked and documented.
When should I run access reviews with Multiplier?
Quarterly is a reasonable default, but also run reviews after org changes — team restructures, layoffs, role shifts. In Multiplier, create a review campaign and pick the apps you want to cover. Reviewers see each user's last login, department, and group memberships, then mark Keep or Revoke. Revoke decisions remove the identity provider group membership automatically and document it back to Jira. Start with your 10 to 20 highest-risk or most expensive apps before going broader.
