The Guide to Identity and Access Management (IAM) for Security and IT Teams

Your identity program looks finished. Every app sits behind SSO, MFA is on everywhere, and new hires have access before their first standup. Then someone pulls the last sign-in date for every admin in your finance app, and a third of them haven't touched it in months, though last year's review approved every one.

Most identity and access management programs have made sign-in fast and automatic. What each identity can reach after sign-in is where they fall behind, because that access gets checked when it's granted, again at review, and rarely in between. Here's what IAM covers, how it works, and how often its parts get rechecked. After that come a federal audit of unused privileged accounts, three ways to keep access current, what AI agents change, and three metrics for how far your access lags.

What is identity and access management (IAM)?

Identity and access management (IAM) is how an organization controls who and what can reach its apps and data, at sign-in and every day after. It covers the policies, processes, and tools that create identities, verify them, decide what they can do, and prove those decisions to an auditor.

At Lumos, we judge an IAM program by how current its answer is to who holds what, and whether they should. In our experience, most programs can confirm who someone is at sign-in, and far fewer can say what each identity holds today and whether it still needs it. The second half is where an identity and access management strategy should start, with a map of where access gets granted and where it never gets taken back.

The population is wider than your employee roster, because contractors, service accounts, API keys, OAuth grants, and AI agents acting for a person all hold access. Most programs start with employees and contractors, the scope of workforce identity and access management, and bring machine identities in later. Customer identity and access management (CIAM) applies the same ideas to the people who buy from you, and this piece sticks to the identities that work for you.

How does identity and access management work?

IAM works through four functions: identity, authentication, authorization, and governance. Together they answer two questions for every person, service, and agent in your environment: who or what is this, and what may it do?

Identity comes first. Employees get a directory record sourced from the HRIS, while contractors and vendor staff often get one an admin or sponsor creates by hand. Service accounts, API keys, and agents get theirs from the platform that created them, and that record is what the other three functions read.

Authentication proves the identity at sign-in, through SSO, MFA, and increasingly passkeys, with SAML and OIDC carrying the sign-in between your identity provider and each app. Authorization decides what the identity can do once it's in. That decision lives inside each app as roles, groups, and entitlements, assigned by job function under role-based access control (RBAC) or by attributes like department and location under attribute-based access control (ABAC).

Governance is the check on the other three. It covers the lifecycle changes when people join, move, and leave, with SCIM carrying the account creation and removal those changes trigger. It also covers the access reviews that ask whether a grant still fits and the audit trail that proves both happened.

These four functions don't run at the same pace. Authentication happens in the moment, at every sign-in, while the identity record and the access attached to it change only when something updates them.

How often IAM rechecks authentication and authorization

IAM rechecks authentication at every sign-in, while most programs recheck authorization only when access is granted and at a quarterly or annual review. Sign-in also got most of the last decade's budget and attention in the programs we see.

Authentication runs on every sign-in. Sessions and conditional access policies evaluate in milliseconds, MFA adds a step the person completes, and the whole check repeats at the next sign-in.

Authorization is everything an identity holds once it's inside: entitlements, roles, admin rights, tokens, and grants in each app. Between grant and review, it also changes when HR data changes, if lifecycle is automated. The gap between the two cadences is access lag, the time between when a grant stops matching a real need and when anyone checks it. The three practices below are ways to shorten it.

The NIST Cybersecurity Framework 2.0 puts both in one place. Its Protect function has a single category for identity management, authentication, and access control, called PR.AA. Subcategory PR.AA-03 asks that users, services, and hardware are authenticated, and PR.AA-05 asks that access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, with least privilege and separation of duties. Only the authorization outcome mentions a review.

Here's how often each part of IAM gets rechecked in most programs, what goes stale between checks, and what keeps it current. The first row is authentication, and the other five are the access each identity holds.

‍

The five access rows are where audit findings tend to come from. Fill in the recheck column with your own cadence for your ten most sensitive apps. Any row where the honest answer is "at grant" is access nobody has looked at since the day it was given.

The IAM security risk when access outlives its use

Access lag builds quietly, and a July 2026 audit of the Federal Housing Finance Agency's information security program, run by Sikich for FHFA's Office of Inspector General, shows how. The setting was ordinary: a cloud workflow platform, a dozen privileged accounts, SSO, and an annual review.

The platform's admins signed in through SSO tied to the enterprise directory, and the app kept their privileged accounts enabled as long as the directory account was active, whether or not anyone used the app. As of November 25, 2025, 5 of the 12 enabled privileged accounts (about 42%) had gone more than 35 days without use or had never logged in to the app at all. The three that had never logged in weren't disabled until 73 to 538 days of inactivity.

The app's owner had reauthorized all five in the August 2025 annual review. That review didn't look at last-login activity, so nothing on the reviewer's screen showed the accounts were idle.

FHFA management disagreed with both access recommendations. It argued that privileged users work across many enterprise apps through SSO, and that a quiet account doesn't prove someone lacks a business need. The auditors kept their findings: neither the inactivity rule nor the annual review caught the idle accounts, and the review ran without the one data point that would have shown the drift.

Both sides are reading different rows of the table above. The directory answered the second row correctly, since these admins were still active, while the fourth row, privileged access inside the app, waited for an annual review that couldn't see whether anyone used it. IAM security can't stop at the sign-in, because findings like this one start with an active identity holding access nobody uses.

Pull the last sign-in date for every admin in your three most sensitive apps and set it beside the approvals from your last review. Every idle admin your reviewers approved is your version of this finding, and your next identity and access management audit will likely run the same test.

Give privileged access an end date with time-bound grants

Privileged access that expires on its own never needs a reviewer to notice it, which makes the end date the cheapest way to keep access current. Time-bound and just-in-time access grant the exact permission for a set window, then remove it automatically. Access resets without a ticket or a review, and the grant leaves a record of who had it, why, and for how long.

At Code42, Christian Wimpelmann, Manager of Identity and Access Management, defines least privilege as "the right access for the right amount of time." His team had handed out permanent access to sensitive apps without knowing who held it or for how long. It then put time-based access on its most critical apps, and privileged access fell 67% across the stack. Verified on-call engineers get pre-approved access to sensitive databases within seconds during an incident, and it comes off within a few hours.

Lumos now runs the same pattern through an agent. The Access Request Agent in its Identity Agent Force grants access for the length of time the work needs and revokes it when that window closes, so nobody has to remember to take it back.

Some access has to stand, like a payroll admin's role or a service account's scope. Keeping that access right is the job of policy and review, which the next two sections cover.

Why to write access control policies from how access is used

Most standing access comes from roles nobody has reread since they were written, so the access control policy itself has to read usage. Birthright rules and roles get written once from an org chart, and then the org changes around them while the roles stay put. Roles that keep pace with the org chart are one of the identity and access management benefits a static role model can't deliver.

A policy that reads usage shows you which grants in a role have stopped earning their place before a reviewer has to find them. In Lumos, every app and permission in an access policy carries a plain-language insight, such as Essential or Rarely Used, backed by assignment and usage percentages and refreshed at least weekly. A "Rarely Used" grant inside a role is access lag showing up in the policy itself. Albus, Lumos's AI agent for identity governance, can draft the change, and nothing publishes until an admin confirms it.

At Netskope, Lumos role mining built access policies from assignment data, usage data, and business context, and elevated access now comes as just-in-time grants that expire automatically. Standing access fell 80%.

Roles written this way still need someone to confirm them. That's the review's job, and it works only when the reviewer sees the same usage data the policy reads.

Use access certification as the check on everything else

The access review, or access certification, is the scheduled check on whatever the other controls missed, so it should show the reviewer what changed and how each grant gets used. A reviewer who sees no usage data approves what's in front of them, the way the annual review in the audit above approved five idle admin accounts.

Reviewers make real decisions when the review carries its own context. As user access review software, Lumos builds each review from entitlement-level data across your identity provider, HRIS, and apps, cloud and on-premises included. Albus brings forward how grants are used and what was decided last cycle, so owners see only what changed. Rejected access comes off through the same deprovisioning workflows the rest of the platform uses, and removals leave a workflow record, with evidence attached by file, link, or ticket for any step a person completes.

Sun Country Airlines shows why scope matters as much as speed. After its 2022 IPO, SOX required access reviews for every in-scope app, including on-premises apps no cloud identity provider synced, and one team member ran them on screenshots, spreadsheets, and email. Sun Country now pulls access from its directories and the apps themselves, and reviewers see only what changed. It saves more than 50 hours a quarter across 13 business-critical apps, with managed service accounts and privileged access certified too.

The apps Sun Country's cloud identity provider never saw were in scope, and the review covered them. Governance has to reach access that sign-in never touches.

How agentic IAM checks what AI agents do

When an AI agent works on someone's behalf, every tool call it makes is an access decision. Agentic IAM, the part of IAM that governs AI agents and the access they use, has to reach that action itself. Coding and workflow agents act with the permissions of the person who runs them, many times a minute.

That person was authenticated once, when the session started. The grants behind the agent's work may not be reviewed for months, and in between, the agent runs on standing permissions.

In September 2026, we extended Lumos from governing who holds access to governing what happens after it's granted, starting with the tool calls employees' AI agents make. In the coding agents it supports, MCP Governance, in beta, sits in the path of each tool call and logs it against the person behind it. It allows or denies the tool based on what that person holds in Lumos.

It ships set to Allow, so nothing breaks on day one, and it never stores prompts, model responses, or tool results. You add policies tool by tool as you learn what your agents touch.

The identities agents run on need an owner too. Lumos's non-human identity inventory, also in beta, keeps an owner and a business justification on record for service accounts, service principals, and API identities. Agents also change who requests access and how fast it gets used, two shifts AI identity and access management has to plan for.

A per-call check moves enforcement to the speed of each action, but it can only apply the access on record. If that record is stale, the agent gets a fast yes on access that should have expired, which is why the expiry, policy, and review work above comes first. The same best practices for identity and access management carry over to agents, starting with an owner, scoped access, and a fast way to revoke it.

List the AI agents in your company that act with an employee's access today, then name who would know if one called a write tool it shouldn't. Any agent without a name next to it is running on access nobody is watching.

Three IAM metrics that show how far access lags

Three numbers show how much access lag your program carries, and most teams can pull all three this month. They map to the three practices above, in order. Track them alongside your other identity and access management metrics, and watch which way they move.

Expiry coverage

Expiry coverage is the share of privileged entitlements that carry an end date. Standing admin grants used only during incidents are the first ones to convert.

Unused standing access

Unused standing access is the share of admin and sensitive entitlements in your most important apps with no use in 90 days. A permission most holders of a role haven't used in that window is a candidate to move out of the role and into a request. To build the list, start with the people who hold admin rights. The Entitlements tab on a person's identity in Lumos lists every active entitlement they hold across connected apps, ready to check against last-use data.

Review context

Review context is the share of last cycle's review decisions made with usage data on screen. That share is the honest measure of how much your review checked.

Run access governance as fast as the sign-in

More of the identities in your environment act without an interactive sign-in, from service accounts to pipelines to agents, so a growing share of your risk sits in the access they hold. For most teams, sign-in is already built, so the work left is access governance.

This month, measure access lag with the three numbers above. This quarter, give privileged grants end dates and put usage beside every review decision. Your IAM program is only as current as the access it checks least often.

You can move all three of those numbers from one place. In Lumos, the Access Request Agent puts end dates on privileged grants, policy insights flag permissions a role's holders rarely use, and Albus shows reviewers usage and last cycle's decisions. All three read the same entitlement-level record across your identity provider, HRIS, and apps, on-premises included, so expiry, policy, and review work from the same facts. Bring your three numbers to a Lumos demo, and we'll show you which grants, roles, and reviews to fix first.

‍