7 Identity and Access Management Challenges and How to Fix Each One

Your SSO dashboard shows every app connected and MFA enforced for all employees. Then the auditor samples a dozen people who changed teams last year, and their old team's access comes back still attached, approved in last quarter's review.

Identity and access management challenges are the problems that keep a company from knowing who and what can reach each app, keeping that access matched to each identity's current job, and proving both to an auditor. SSO and MFA settled who someone is. The IAM challenges that cost teams now are about what happens to access after it's granted. Password fatigue, BYOD, and MFA rollout still matter, but they're authentication problems most programs already own.

The seven challenges below all happen after sign-in: shadow IT and orphaned accounts sit outside your identity provider, movers keep old access, standing privileges outlive their reason, role-based access control drifts, slow requests lead to overprovisioning, user access reviews turn into rubber stamps, and non-human identities and AI agents run without an owner. They depend on one another, so the order you fix them in matters as much as the fixes. Each comes with evidence, a test to run this week, and a way to close it.

Shadow IT and orphaned accounts sit outside your identity provider

Shadow IT and orphaned accounts sit outside your identity provider (IdP), which governs only the sign-ins that pass through it. They never get its policies, its reviews, or its offboarding. Those accounts live in SaaS tools employees signed up for themselves, apps with their own logins, local admin accounts, on-prem apps that never synced to a cloud directory, and contractor accounts created by hand. We see the gap in three layers: apps no one listed, identities never matched to a person, and permissions you can't see inside the apps you do know about.

In 2024, a financially motivated group used stolen credentials to get into customer accounts on Snowflake's data platform, and Snowflake and Mandiant notified about 165 potentially exposed organizations. Mandiant traced the compromises to accounts with no MFA, infostealer credentials that were in some cases still valid years after they were stolen (the earliest infection dated to November 2020), and no network allow lists. Several infections started on contractor computers that were also used for personal activity. Mandiant found no evidence of a breach of Snowflake's own environment.

Snowflake was a sanctioned platform, and the weak point was how those accounts signed in. An account that signs in with its own password never sees the MFA, rotation, or offboarding your IdP applies, and shadow IT carries the same exposure in apps nobody listed.

How to tell you have it

Export the user list from your five most sensitive apps and match each account against your IdP and your HR platform (HRIS). Accounts that match neither, and apps where sign-in doesn't require SSO, are access your IdP can't see. If you’re early in an identity and access management implementation, this list is the first thing to build.

How Lumos handles it

You get one inventory of the accounts in your connected apps, including the ones your IdP never sees, each tied to the identity behind it and to how often it's used. Lumos builds a single access graph across every connected app, directory, and identity type from 300+ integrations, down to the entitlement and with real usage context. Accounts no one has used in months stand out in that view, next to the access people rely on every day.

At Sun Country Airlines, SOX scope included on-premise apps not synced with any cloud identity provider. Lumos compiled those reviews through integrations with Active Directory, Azure, and the apps themselves, so the airline certified them alongside its cloud apps.

Where to start

List the apps where an account can exist without your IdP knowing, and name an owner for each one by Friday. Include apps contractors manage and anything bought on a corporate card. Then add those owners to your offboarding communication plan, since they’re the only people who can close those accounts when someone leaves.

Movers keep old access in the joiner-mover-leaver process

When someone changes jobs, the new access arrives on day one and the old access usually stays, because nothing in most HR feeds tells IAM to take it away. Joiners and leavers each come with a date, and a leaver's last day anchors every step in employee offboarding best practices. Movers often have no clean date at all, which makes them the hardest of the identity management challenges in the lifecycle to automate.

Many internal job changes never reach IT as an event: an interim assignment, a shift between teams without a new title, or a manager who reassigns someone and forgets to file an access request. People also keep helping their old team for a while after they move, so removing access on day one breaks the handover. Wait with no deadline, though, and nobody comes back to clean it up. Over time, a mover can turn into a superuser.

A September 2026 audit by the DHS Office of Inspector General found that 17% of Customs and Border Protection employees who changed positions inside the agency kept access they no longer needed. CBP traced its access lapses to human error and to not being able to track how account access changed over time. Each move added access, and nothing tracked what it should have taken away.

How to tell you have it

Pull everyone who changed department or manager in the last six months and compare each person's access with a peer in the role they left. Entitlements they share with the old team that the new team doesn't hold are mover residue.

How Lumos handles it

A role change in your HRIS adds the new job's access and retires the old job's access in every connected app. Lifecycle Management treats each HRIS event as an access event, and Albus, the AI built into Lumos, watches role, department, manager, and status changes and applies the matching policy. Lumos also supports delayed removal of a mover's existing access, so the handover gets a deadline. Since August 2026, mover removals run on the same per-app Account Workflows (the steps that grant and remove access in each app) as departures, so every run of your IT offboarding process tests the path a mover takes.

With Lumos, Tekion runs identity for more than 3,000 employees around the world, with global onboarding automated across 200+ SaaS integrations while it cut back access sprawl. Its story lists joiner-mover-leaver lifecycle management among the ways it uses Lumos.

Where to start

Make "mover" a formal lifecycle event this quarter, with a default grace period and a named person who confirms the old access is gone when it ends. Start with the moves your HRIS records least reliably, like interim assignments and team changes without a new title.

Standing privileges outlive the reason they were granted

Most access is granted for a reason that ends (a project, an incident, a quarter-end close), and almost none of it comes with an end date. Access gets added through many doors, including requests, birthright bundles, project grants, incident elevations, and nested groups. It leaves through two: a review or a departure. People pile up access over time and rarely lose it, which is why we think time-bound access should be the default and standing access the exception someone justifies.

The NSA and CISA name the same pattern in their joint advisory on the ten most common misconfigurations their red and blue teams found in large organizations. One is improper separation of user and administrator privilege, covering excessive account privileges, elevated service account permissions, and elevated accounts used for everyday work. The agencies add that as organizations grow, changes in account management, personnel, and access requirements commonly lead to privilege creep. Spotting where creep has already set in takes its own signals, covered in how to detect privilege creep and access sprawl.

How to tell you have it

Count the admin and production grants in your five most sensitive apps that have no expiry, then check how many were used in the last 30 days. The unused ones are standing access with no reason left.

How Lumos handles it

Elevated access arrives when the work needs it and leaves on its own. In the Lumos AppStore, people request access in Slack, Teams, the web, the CLI, or their IT service management (ITSM) tool, and Albus recommends the shortest window that fits. The Access Request Agent, an AI agent in Lumos, grants access for exactly as long as someone needs it, then revokes it on its own.

Code42 used to grant permanent access to sensitive apps with no view of who used it or for how long. Now verified on-call engineers get access to sensitive databases within seconds during an incident through pre-approved groups, and Lumos removes it within a few hours. Time-based access helped cut Code42's privileged access by 67% across its tech stack.

Where to start

Pick the admin role your on-call team requests most and make it time-bound this month. On-call access makes a good first candidate, since every incident already has a start and an end.

Role-based access control drifts after every reorg

A role is a decision someone made about a job, and after a reorg or two, nobody can tell you what that decision was. Role-based access control drifts from there. Roles get built for a team, then copied ("give her the same access as him"), extended for exceptions, and multiplied by region and product line. The catalog either explodes into thousands of near-duplicates or collapses into a few broad roles that grant too much, and either way, reviews and least privilege stop working.

An accounts payable role starts as access for the few people who pay invoices. Over a few reorgs, it picks up a reporting tool for an analyst who transferred in, admin rights in the general ledger for one quarter-end close, and vendor portal access for a project that wrapped up last year. The owner can still explain each permission, but no one can say what the whole bundle is for or who should hold it now. A role no one can explain can't be reviewed, and a role that can't be reviewed gets approved.

How to tell you have it

Take your ten most-assigned roles or groups, find each one's owner, and ask them to say in one sentence what the role is for and who should hold it. Any role without an owner or an answer is drift.

How Lumos handles it

Roles get built from how people work now, with the reason for each one written down and kept current as the company changes. Albus ingests HRIS data, app assignments, and usage logs and proposes role-based and attribute-based (RBAC and ABAC) policies, explaining why each role exists so you tune the assumptions instead of approving them blind. It starts in copilot mode, and policy changes get shared, commented on, and drafted in Lumos before they go live.

Netskope uses Lumos's agentic role mining to turn HRIS assignments, usage, and business context into access policies with fewer roles to manage. People stay in the loop for high-risk cases.

Where to start

Before your next review cycle, retire or rewrite one role its owner couldn't explain, and record its reason alongside the new version. Start with a role that grants admin or production access.

Slow access requests lead to overprovisioning

Slow access requests lead to overprovisioning, because when a simple request takes days, people stop asking for what they need and start asking for everything they might need. The workarounds are familiar: broad birthright bundles granted just in case, a new hire's access copied from a peer, and shared logins passed around a team. Each one trades a ticket for standing access and leaves no record of why. The governed path has to be the fastest path, or people find a faster one.

Slow access usually gets filed as a productivity complaint, which keeps it with the help desk and off the risk register. The cost shows up later, in the review that has to certify everything the workarounds granted and in the copied profile that carries a former teammate's admin rights into a new job.

How to tell you have it

Measure the median time from request to access for your ten most-requested apps, and count how many new hires last quarter got access copied from a peer. A median measured in days, or copied profiles no one can account for, means the workarounds are winning.

How Lumos handles it

Routine access lands in minutes under rules people approved, and requests that need a decision go to the person who owns that permission. Pre-approval rules grant routine requests with no one in the loop, and approvers can respond inline in Teams. In Slack, the Access Request Agent, now in beta, takes a request in plain language.

ChargePoint used to run access requests and reviews through tickets and spreadsheets, a manual process the team says was prone to human error and often left employees overprovisioned. Its 500 to 600 monthly request tickets across 70+ apps now route through Lumos, managers approve, and employees get access within minutes.

Where to start

Pick the three apps people most often get through a copied profile and give them a self-service path with an approver and an expiry. Count copied profiles again next month to see whether the number fell.

User access reviews turn into rubber stamps

An access review is only a control if it changes access, and many campaigns make approving everything the reviewer's fastest path. They ask for full re-certification every quarter, show entitlement names reviewers don't recognize with no usage data beside them, and have no link between a rejection and a removal. That's how user access reviews turn into rubber stamps. Of the identity governance challenges here, it's the one an auditor samples directly, because the review is the evidence.

In May 2026, the Labor Department's Office of Inspector General published its FY 2025 information security report, performed by KPMG. It listed findings issued from the department's financial statement audit, which was still under way, including users of financial applications who reviewed their own access during the annual reauthorization. Other users were removed late from a financial application after the reauthorization process. A campaign can close on schedule with self-certifications and late removals inside it.

How to tell you have it

Take last quarter's campaign and count three things: the share of items approved, the reviewers who certified their own access, and the rejected items still active today. A high approval rate with any self-reviews or live rejections means the campaign produced paperwork and no decisions.

How Lumos handles it

Reviewers see only what changed and what's risky, and every rejection becomes a removal with evidence. In Lumos user access review software, delta reviews surface only what's new since the last cycle, while Albus carries forward usage patterns, prior decisions, and known exceptions and flags anomalies, separation-of-duties (SoD) violations, and privileged access. The Access Review Agent certifies the safe access on its own and brings people only the items that need a human call. Rejected access is revoked automatically and tracked in your ITSM tool with evidence at each step.

Marqeta moved access reviews off CSV files, tickets, and manual steps into Lumos. Its second round of reviews was 40% faster than the first, because delta reviews let managers focus on what changed since the last cycle.

Where to start

Before the next campaign, turn on removal for rejected items and block self-review, then compare the approval rate with last quarter's. If it doesn't move, your reviewers still can't tell what they're looking at.

Non-human identities and AI agents run without an owner

Non-human identities and AI agents run without an owner because nothing ties them to a manager, an HR record, or a last day. Engineers and vendors create service accounts, API keys, OAuth apps, and agents to get work done, and many of them hold broad, long-lived access. Most authenticate with static secrets, and no one reviews them, because there's no one to ask. That makes ownership the first of the identity security challenges to solve here, and in every enterprise we've analyzed, 95% or more of non-human identities have no assigned owner.

Treasury's December 30, 2024 letter to the Senate Banking Committee shows how far a machine credential can reach. A third-party remote support provider told Treasury that a threat actor had obtained a key the provider used to secure its cloud-based support service, and with it the attacker reached some Treasury workstations and unclassified documents. Treasury attributed the intrusion to a Chinese state-sponsored group, and the service was taken offline. The credential that opened the door belonged to neither a person nor Treasury, and no joiner-mover-leaver process would ever have touched it.

AI agents widen the gap, since many act with the access of the person who started them, at a speed no review cycle matches. Agents bring agentic AI governance challenges of their own, and they start from the same place non-human identity security does: a named owner who stands in for the HR record.

How to tell you have it

Count the service accounts, API keys, and OAuth grants in your three most critical apps and write down an owner for each. Then count the blanks, since these are the accounts an identity and access management audit tends to miss.

How Lumos handles it

Machine identities and agents get a named owner, and their access gets reviewed like a person's. Lumos discovers non-human identities, including service accounts, agents, and workload identities, across your IdP, cloud infrastructure, and SaaS apps, and maps each one to a human owner. The Agent Ownership Finder, one of the AI agents in our Identity Agent Force, gives each new agent an owner before it gets to work. For the coding agents it supports, MCP Governance, which governs the tools those agents call, ties each tool call to the person who triggered it.

Where to start

Give the machine identities in your three most critical apps an owner and a review date this quarter, and treat each blank as an open finding. Start with the credentials a vendor holds, since those are the ones your own processes are least likely to reach. Then give every AI agent a human owner and an end date, the first step in AI agent identity and access management.

Which identity and access management challenges should you fix first?

Start with the accounts your identity provider can't see, because identity and access management challenges depend on each other and the order you fix them in decides whether each fix holds. You can't review access you can't see, and you can't mine clean roles from access that movers never gave back. The table puts the seven in the order we'd fix them.

‍

Reviews come sixth, even though most teams start there because the auditor asks for them. A review run before the first five fixes certifies the backlog instead of clearing it, and the fixes ahead of it shrink the next campaign. To track whether a fix holds over time, pair the tests with identity and access management metrics that have an owner and a trigger.

Run the seven tests this month and start with the lowest-numbered one that fails. Rerun that test next quarter to confirm the fix held.

Govern what happens after sign-in

Go back to the auditor's sample of people who changed teams. SSO and MFA answered who they were. Nothing in that answer touched the access they kept, requested, or were copied into afterward.

Run the seven tests, start where the first one fails, and walk into the next audit with removals on record alongside the approvals. Your next finding won't be about who signed in. It'll be about what they kept.

Lumos is identity governance software for every identity after sign-in, starting with one access graph across your apps and lifecycle changes driven by your HRIS. Access expires on its own, roles come from real usage with the reason attached, and routine requests clear in minutes. Delta reviews remove what's rejected, and every machine identity and agent gets an owner. Book a demo and run the seven tests against your own apps.

‍