Identity Dark Matter: Fix Hidden Access Risks in Jira

30 days before an audit, nobody is worried about the access request that went through the proper workflow. The problem is identity dark matter: all the permissions, approvals, exceptions, old licenses, and “temporary” access that exist somewhere, but don’t show up cleanly in the system of record.

And the annoying part is that most of it was created for good reasons. Someone needed GitLab for 24 hours. A manager approved access in Slack. IT added the user to an Okta group. Everyone moved on. Then six months later, you’re trying to prove who approved what, why they still have it, and whether anyone actually reviewed it.

Key Takeaways:

• Identity dark matter builds up when access work happens across Jira, Slack, email, identity providers, and spreadsheets.
• Policy-heavy least privilege fails when there’s no operational workflow to enforce expiry, review, and revocation.
• Access reviews work better when they run like Jira work queues with usage context, not spreadsheet exercises.
• The fastest audit prep is evidence created during normal access work, not rebuilt later.
• If access doesn’t have an owner, a lifespan, and a record, it becomes invisible risk.

Why Identity Dark Matter Builds Up Inside Access Workflows

Identity dark matter builds up when access decisions happen in one place and access changes happen somewhere else. Jira has the request, Slack has the approval, Okta or Entra has the group change, and the spreadsheet has the audit evidence. The access exists, but the story around it is broken.

The Access Request Looks Fine Until Evidence Is Needed

A new employee starts on Monday. By Tuesday afternoon, they’ve asked for Salesforce, Figma, GitHub, a shared drive, and one admin permission because their manager said they’d need it “just for launch week.” IT gets the Jira ticket, then a Slack DM, then a follow-up from the manager, then manually adds the person to the right identity provider groups. Everyone is trying to be helpful. Nobody is trying to create a mess.

The mess shows up later. The Jira ticket says approved, but not by who. The Slack approval is buried. The identity provider shows membership, but not the business reason. The spreadsheet for the audit has a row that says “approved,” which is technically true, but not very convincing if someone asks for the full chain. I’ve seen this pattern a lot. It doesn’t fail because people are careless. It fails because the workflow was never designed to preserve context.

A decent test is simple: pick 10 access grants from the last 90 days and try to answer four questions in under 10 minutes per grant:

1. Who requested the access?
2. Who approved it?
3. What exact group or role changed?
4. When should the access be reviewed or removed?

If you can’t answer at least 8 out of 10 without jumping across tools, you don’t really have access governance. You have fragments. If your team is already feeling this inside Jira, Learn more about Multiplier and look at how the workflow changes when the ticket becomes the evidence trail.

The Real Problem Is the Split Between ITSM and Identity Governance

The common answer is to add more policy. More approvals. More review cycles. More fields on the ticket. Fair enough, because policy does matter. Security teams need guardrails, especially when access touches customer data, finance systems, production, or admin roles.

The problem is that policy without execution creates identity dark matter faster. If a policy says admin access expires after 24 hours, but someone has to remember to remove the group manually, the policy is only a wish. If a quarterly review says “revoke,” but the reviewer’s decision sits in a spreadsheet while IT opens separate tickets, the review didn’t actually finish. It just created more work.

The better frame is operational. Access needs a path. Request, approval, provisioning, expiry, review, revocation, and evidence all need to stay connected. Not conceptually connected. Actually connected. Same record, same ownership, same history. Otherwise, the dark matter keeps growing because every handoff creates a gap.

Audits Expose the Work You Didn’t Track

Audits don’t create the access problem. They just make it visible. A SOC 2 or ISO review asks for proof that access is approved, appropriate, and removed when no longer needed. The NIST SP 800-53 access control family is very clear on this idea: access control isn’t only about granting permissions, it’s also about managing accounts, reviewing access, and enforcing least privilege over time.

And this is where the human part kicks in. It’s Thursday night, the auditor wants evidence by Friday, and someone from IT is pulling screenshots from Okta, searching Slack for approvals, and cleaning up a spreadsheet that nobody fully trusts. That’s a bad way to work. Worse, it rewards the wrong behavior, because the team spends more time reconstructing proof than improving the actual access process.

Identity dark matter is what you get when evidence is treated like an audit project instead of a byproduct of access work.

How to Make Hidden Access Visible Before Audit Season

Hidden access becomes manageable when every entitlement has three things attached to it: ownership, duration, and evidence. The trick is not adding a giant governance program on top of the work. The trick is changing the workflow so the right information gets captured while the work is happening.

Find the Requests That Never Became Evidence

Start with the weird stuff. The edge cases. The access requests that came through Slack because Jira felt too slow, the manager approvals that happened in email, the “can you just add me quickly?” requests during incidents, and the old spreadsheet rows that nobody wants to touch. That’s where identity dark matter usually lives.

I’d run a 30-day sample before touching tooling. Pull recent access changes from your identity provider, then match them back to Jira tickets. If a group membership changed and you can’t find the ticket, approval, or business reason, flag it. Not to blame anyone. To see the shape of the problem. The first time you do this, the results are usually uncomfortable. Good. That means you found something real.

Use a simple scoring method:

1. Green: Request, approval, group change, and owner are all visible in one record.
2. Yellow: Evidence exists, but you need two or more tools to reconstruct it.
3. Red: Access exists, but the approval or reason is missing.
4. Black: Access exists, nobody knows why, and no owner is obvious.

If more than 20% of sampled grants are yellow or worse, don’t start with another policy doc. Fix the intake and evidence path first. A policy won’t save a workflow that can’t remember what happened.

Split Access by Lifespan, Not by Application

Most access programs categorize by app. Salesforce access. GitHub access. Snowflake access. That makes sense on paper, but it misses the operational question that matters more: how long should this person have the access?

Some access should be standing. A finance employee needs finance systems. A designer needs design tools. No drama there. Some access should be temporary by default. Admin access, production access, sensitive data access, incident access, migration access, and “I need this for one project” access should all have a lifespan. If the request doesn’t define the lifespan, the system will default to forever. And forever is where least privilege goes to die.

A rule I like: if the access increases risk or cost, force a duration. Not a vague expiry field that someone ignores. A real duration tied to automatic removal. One hour, six hours, 24 hours, seven days. Pick ranges that match the work. Production break-glass access may only need one hour. A contractor project might need 30 days. Different jobs, different clocks.

The concession here is that time-bound access can annoy people if it’s applied badly. If a sales rep loses CRM access every day, you’ve created nonsense. But for elevated access, time limits reduce cleanup work because the access removes itself when the job is done. That’s the trade. A tiny bit more structure up front, much less detective work later.

Make Approval Location Match Where Decisions Happen

Approval workflows fail when they ask people to leave their normal work pattern. If managers live in Slack all day, forcing them into a separate identity portal for every low-risk decision slows everything down. They’ll miss it, delay it, or approve in a side channel. And there you go. More dark matter.

A better rule is to keep the decision where the person already works, while keeping the record in the system of record. That distinction matters. Slack can be the place where the approver clicks approve. Jira can still be the place where the request, decision, provisioning result, and audit history live. Chat should not become the record. Chat should be the interface.

The decision mechanism is pretty simple:

1. If the access is low risk and mapped to a standard role, allow manager or app owner approval in the normal work channel.
2. If the access is high risk, require a named owner and a time limit.
3. If the approver isn’t clear, block the request until ownership is fixed.
4. If the approval happens outside the ticket, treat it as incomplete evidence.

A fast approval that creates clean evidence is better than a slow approval in a perfect portal nobody uses. I know some security teams prefer dedicated IGA portals, and in very large enterprises with complex segregation of duties, that can be valid. But for Jira-heavy teams in the mid-market, the extra portal often becomes another place to reconcile. More control in theory. More gaps in practice.

If you want to see how this looks when approvals stay tied to Jira while people act from Slack, See how Multiplier works.

Treat Access Reviews Like Work Queues, Not Spreadsheets

Quarterly access reviews often become spreadsheet theater. Export users. Send tabs to app owners. Wait. Chase. Get partial answers. Copy decisions somewhere else. Open revocation tickets. Chase those too. Then save the spreadsheet as evidence and hope nobody asks how complete it really was.

I’m being a little harsh, but only because the pattern is so common. A review is not done when someone marks “revoke” in a cell. A review is done when the access is actually removed, the reason is recorded, and the evidence is linked back to the review. Anything short of that leaves identity dark matter behind, because the decision and the action drift apart.

Access reviews should run like operational queues:

1. Scope the apps that matter.
2. Assign one accountable reviewer per app or group.
3. Show the reviewer user attributes, department, group membership, and last login.
4. Force a keep or revoke decision.
5. Execute revocations through the identity provider.
6. Write the outcome back to the ticket or campaign record.

A practical threshold: if a reviewer has more than 150 users in one review batch, split it. Past that point, rubber-stamping risk goes up because the reviewer stops evaluating and starts clearing the queue. Smaller batches with better context beat one giant certification that nobody trusts.

Use Login Activity to Find Dead Licenses Before Renewal

SaaS waste is usually treated as a finance problem, but it’s also an identity problem. A paid license with no recent login is often a stale entitlement. Maybe the person changed roles. Maybe they left the project. Maybe access was granted for one task and never removed. Whatever the reason, unused access is both cost and risk.

The clean way to handle it is to combine login activity with a grace period. Don’t yank access the second someone crosses an inactivity threshold. Send a warning. Give them time to log in if they still need it. Then remove access if they stay inactive. That feels fair to employees and gives IT a defensible record.

A decent starting rule:

1. Use 30 days of inactivity for expensive collaboration tools.
2. Use 60 to 90 days for lower-cost tools where usage is seasonal.
3. Exclude executives, service accounts, and teams with known usage quirks.
4. Require a Jira record for every reclaimed license.
5. Review reclaimed access monthly before renewals.

Verizon’s 2024 Data Breach Investigations Report keeps showing how much access and credential exposure matter in real incidents. That doesn’t mean every unused SaaS seat is a breach waiting to happen. It means stale access deserves a workflow, because old permissions have a habit of being useful to the wrong person later.

How Multiplier Writes Governance Into Jira

Multiplier makes the access record the center of the workflow, not an afterthought. Requests start in Jira Service Management or Slack, approvals stay tied to Jira issues, and provisioning runs through Okta, Entra ID, or Google Workspace groups. The point is simple: less identity dark matter because fewer actions happen off-record.

Access Reviews and Revocations Tied to Jira Issues

Access reviews work better when reviewers can see context and act in the same flow. In the Jira-native review workflow, reviewers see user attributes, group memberships, last login, and recommendations before they decide keep or revoke. When they revoke, the change can remove the user from the relevant identity provider group and create Jira evidence.

That matters because the old review process breaks at the handoff. A reviewer says revoke in a spreadsheet, then IT has to perform the change somewhere else, then someone has to prove the change happened. One missed handoff creates identity dark matter again. Inside a Jira workflow, the decision, action, and evidence stay linked. Not glamorous. Very useful.

A few capabilities matter most here:

• Access review campaigns in JSM: Reviewers work from Jira instead of passing spreadsheets around.
• Usage context: Last login and user attributes make the review less of a guessing exercise.
• Enforced revocations: Revoke decisions can trigger identity provider group removal.
• Audit-ready exports: Campaign results can be exported for audit evidence, including Vanta workflows where configured.

Luno is a good example of why this matters. As they grew to nearly 1,200 employees, routine access requests came through Slack, email, and Jira, and IT had to chase approvals and manually assign Okta groups. They later cut access request workload by 80%. The lesson isn’t “buy a tool and relax.” The lesson is that access governance gets easier when the workflow stops scattering decisions across five places.

Requests, Approvals, and Provisioning in One Path

The request path matters because every access grant starts as a tiny operational choice. An employee needs an app. They choose a role. A manager or app owner approves. The identity provider group changes. If that all stays connected to the originating Jira issue, you get a clean trail. If not, you get another invisible grant that someone has to explain later.

Multiplier supports that path through a JSM application catalog, Slack requests and approvals, approval workflows, automated provisioning via identity provider groups, and time-based access for temporary permissions. Access can be granted for a chosen duration, then removed when the timer expires, as long as the access is tied to identity provider group membership. That boundary matters. Purely manual or non-SSO grants still need manual handling.

Synthesia is a useful pattern here. During 4x growth, a four-person IT Ops team supported 420+ employees and processed 3,800+ access requests in a year, with 75% fully automated. That only works when low-risk access follows a standard path and higher-risk access still has control. Not everything should be automatic. But the repeatable stuff absolutely should be.

When you’re ready to turn access reviews, approvals, and revocations into Jira-native evidence, Get started with Multiplier.

The Access You Can’t See Is the Access You Can’t Govern

Identity dark matter isn’t some abstract security concept. It’s the residue left behind when access work happens outside the record: approvals in Slack, changes in the identity provider, review decisions in spreadsheets, and audit proof rebuilt later by tired people.

The fix is not more policy by itself. Policy matters, but automation-first least privilege is what makes the policy real. Give every request an owner, every risky permission a lifespan, every review decision an action, and every change a Jira record. Then audit prep stops being a scavenger hunt.