Every IAM best practices list says the same things. This one adds the test: for each of the 10 practices, what the real version looks like, what the counterfeit version looks like, and how to tell which one your organization is running.
The standard IAM best practices list has been stable for a decade: enforce least privilege, run access reviews, automate the lifecycle, use MFA, govern privileged access. Nobody disputes it. Nearly every organization above a certain size will tell you, sincerely, that they follow it.
And yet orphaned accounts keep showing up in audits, breach reports keep tracing intrusions to over-permissioned identities, and access reviews keep certifying access that a week of investigation would have revoked. The gap isn't knowledge. It's that most best practices have a counterfeit: a version that uses the same vocabulary, satisfies the same checkbox, and delivers a fraction of the protection. "We do quarterly access reviews" can describe a rigorous certification of the complete identity estate, or a rubber-stamp exercise over whatever the IdP happens to list. Both sentences are true statements. Only one is the practice.
So this guide does the standard list differently. For each of the 10 practices: what the real version looks like, what the counterfeit looks like, and the evidence test that tells you which one you're running.
10 IAM Best Practices for IT and Security Teams
1. Maintain a Complete Identity Inventory
The practice: a continuously updated inventory of every identity (human and non-human) and every application in use, built through multiple discovery methods, reconciled against reality rather than against the IdP's catalog.
The counterfeit: treating the IdP's user and application list as the inventory. It's complete-looking, it's exportable, and it typically covers 60 to 80% of the actual estate. The shadow SaaS, the direct-signup tools, the OAuth grants, and most non-human identities are absent, which means every downstream practice on this list silently inherits the gap.
The test: when did you last measure the difference between what the IdP knows and what's actually in use? If the answer is "never," the number is unknown and probably large. Organizations that run real discovery typically find 20 to 40% more applications than IT had registered.
2. Enforce Least Privilege as a Process, Not a Provisioning Event
The practice: identities hold only the access their current function requires, maintained over time: role-scoped provisioning at onboarding, revocation of previous-role access at every role change, expiry dates on every exception, and drift detection between reviews.
The counterfeit: least privilege at provisioning time only. The new hire gets a sensibly scoped role bundle, and then five years of role changes, project exceptions, and "temporary" grants accumulate on top, none of them ever removed. The program can honestly say it provisions to least privilege while its tenured employees hold three roles' worth of access.
The test: pick five employees who have changed roles at least twice. Compare their current access to their current role's definition. If the delta is substantial, you're running the counterfeit, and mover-event revocation is the missing mechanism.
3. Automate the Full Lifecycle, Across the Full Estate
The practice: provisioning, mover updates, and deprovisioning triggered by authoritative events (HRMS, contract systems) and executed across every connected application, including the non-SCIM ones, with timestamped records.
The counterfeit: lifecycle automation that reaches exactly as far as SCIM does. The federated applications onboard and offboard cleanly; the other half of the estate runs on a manual checklist with a manual checklist's failure rate. Orphaned accounts then accumulate precisely in the applications outside the automation perimeter, which is also where nobody is looking.
The test: for last quarter's departures, can you produce revocation timestamps for every application each person accessed? Not the IdP's list of their applications; every application. If the evidence exists for a subset, the automation covers a subset.
4. Run Access Reviews That Someone Could Fail
The practice: periodic certification at defined scopes (application, group, or user level) against the complete inventory, by reviewers who aren't certifying their own access, with enough context to make a real decision, and with flagged items remediated on a deadline.
The counterfeit: the bulk-approve review. Three hundred line items, no context on what the entitlements mean or when they were last used, a deadline, and a reviewer who approves everything because investigating anything would take a day. Completion rate: 100%. Governance delivered: approximately zero. A review in which nothing is ever revoked is not a control; it's a record of a control.
The test: what percentage of reviewed items were flagged in the last cycle, and what percentage of flagged items were actually remediated within the window? A healthy program flags something (drift exists everywhere) and remediates nearly all of it. Zero flags or a remediation backlog both indicate the counterfeit.
5. Govern Privileged Access on Stricter Rules
The practice: a separate privileged account register; individual attribution (no shared admin credentials); privileged sessions used only for privileged tasks; monthly rather than quarterly review; immediate rather than next-day deprovisioning at departure; just-in-time elevation where feasible instead of standing privilege.
The counterfeit: privileged accounts treated as ordinary accounts that happen to be important. They sit in the same quarterly review as everything else, a few are shared "for operational reasons," and the departing infrastructure engineer's admin access is revoked on the same 24-hour SLA as their expense tool login.
The test: produce the privileged account register. If it doesn't exist as a distinct artifact with its own review cadence and its own deprovisioning SLA, privileged access is being governed at standard-account strength, which is the counterfeit.
6. Bring Non-Human Identities Under the Same Governance
The practice: service accounts, API keys, OAuth tokens, and bot credentials inventoried with a documented purpose and owner, scoped to minimum permissions, included in review cycles, and retired when their purpose ends rather than when an HRMS event fires (it never will).
The counterfeit: NHIs as an acknowledged blind spot. Everyone knows the service accounts exist; they appear in no inventory, no review, and no offboarding logic. The credential a departed developer created three years ago still authenticates, still holds write access, and will continue to until an incident introduces it to the security team.
The test: how many non-human identities does your organization have? An approximate answer with a source is a pass. "We don't track that centrally" is the counterfeit, and given that NHIs now outnumber humans in most environments, it's a blind spot covering the majority of the identity population.
7. Route All Access Grants Through a Policy-Checked Request Path
The practice: every grant beyond the role baseline flows through a request workflow that records justification and approver, checks the request against policy (including SoD rules and license implications), auto-approves the compliant routine cases, and routes genuine exceptions to a human with context.
The counterfeit: the formal request system that coexists with informal grants. There's a workflow, and there's also the manager who Slacks the application owner, the admin who adds a user directly, the access granted in a hallway conversation. Each informal grant is access with no record, invisible to reviews that check decisions rather than reality.
The test: reconcile actual application access against request records for a sample of applications. Access that exists with no corresponding record is the measure of the informal channel. If the reconciliation has never been run, assume the channel is busy.
8. Enforce Segregation of Duties Across Applications
The practice: a documented ruleset of conflicting permission combinations relevant to your risk profile (payment initiation and approval, vendor creation and payment, provisioning and review), monitored across applications, with detected conflicts either remediated or covered by a documented, approved compensating control.
The counterfeit: SoD as an ERP feature. The financial system's internal role conflicts are configured and checked; the cross-application conflicts (approval rights in the procurement tool plus vendor-creation rights in the finance tool) are invisible, because no single application can see both sides. Single-system SoD passes the audit question while missing the modern conflict surface.
The test: does your SoD ruleset name any conflict whose two halves live in different applications? If every rule is intra-application, the practice is running at counterfeit depth.
9. Make Compliance Evidence a Byproduct, Not a Project
The practice: provisioning records, deprovisioning timestamps, review decisions, and SoD reports generated automatically by the systems doing the work, exportable on demand for whichever framework asks (SOX ITGC, SOC 2, HIPAA, PCI DSS, ISO 27001).
The counterfeit: the pre-audit assembly sprint. Six weeks before the auditor arrives, a team reconstructs the year from tickets, emails, and application logs into spreadsheets that approximate evidence. It usually passes. It also costs weeks, degrades every year as the estate grows, and means the organization only actually knows its access posture once a year, right before someone external checks it.
The test: how long would it take to produce a complete access-control evidence package right now, today, unannounced? Hours means the practice. Weeks means the counterfeit.
10. Measure the Program with Governance Metrics, Not Activity Metrics
The practice: a small set of owned, targeted indicators that measure outcomes: orphaned account rate, deprovisioning SLA compliance, review completion and remediation rates, NHI review coverage, findings-per-cycle trend.
The counterfeit: activity reporting. Tickets closed, logins processed, MFA adoption percentage: numbers that show the program is busy without showing whether access is actually appropriate. An identity program can report healthy activity metrics every quarter of its decline.
The test: does your identity reporting include a single number that would get worse if offboarding quietly started failing? If not, the failure would be invisible until an audit or incident surfaced it, which is the defining property of the counterfeit. The IAM metrics guide covers the full measurement layer with formulas.
What About MFA and Passwords?
Deliberately absent from the list above: authentication practices. Strong MFA (increasingly phishing-resistant methods), sensible password policy, and session controls are genuine best practices, but they're the province of your identity provider and are, frankly, the part most organizations already do reasonably well. The ten practices above cover the layer where the counterfeits live: everything that happens after authentication succeeds. If your authentication posture has gaps, close them with your IdP; the practice worth auditing is whether strong authentication actually covers the full application estate, which loops back to practice 1.
How Zluri Turns the Practices Into Defaults
The pattern across all ten counterfeits is the same: the practice is real but its scope is partial, because the tooling can only reach part of the estate or can only check at intervals. Zluri is an identity security platform built to remove exactly that constraint. It sits on top of your IdP (authentication stays where it is) and makes the full-scope version of each practice the default rather than an aspiration.
Practice 1 runs on IVIP, which discovers human and non-human identities across the estate through 8 discovery methods, producing an inventory that is not bounded by the IdP. Practices 2 and 3 run on the Access Management module: role-based provisioning, mover workflows that revoke as well as grant, and deprovisioning across 300+ integrations with over 1,500 granular actions, non-SCIM applications included, every event timestamped. Practice 4 runs on Access Reviews at application, group, and user level, with usage context attached so reviewers can make real decisions, and remediation executed by the same automation. Practice 7 runs on Access Requests, where policy checks and auto-approval eliminate up to 90% of ticket volume while closing the informal channel. Practice 8 runs on the Segregation of Duties module's cross-application conflict detection. Practices 5, 6, 9, and 10 are carried by IRIS and Zluri's Identity Security Posture Management: continuous monitoring of privileged accounts, NHIs, and drift, with the evidence trail and governance metrics generated as byproducts.
Deployment runs 2 to 3 months, which means the gap between claiming these practices and demonstrating them closes within a quarter.
Book a demo and run the ten tests against your environment
Frequently Asked Questions
What are the most important IAM best practices?
If forced to rank: complete identity inventory first, because every other practice inherits its scope; full-estate lifecycle automation second, because deprovisioning failure is the most commonly exploited gap; and meaningful access reviews third, because they're the mechanism that catches what the first two miss. But the ranking matters less than the honesty test: a partial version of a practice delivers far less than its checkbox suggests, so auditing which version you're running is worth more than adding practices to the list.
How is an IAM best practice different from an IAM policy requirement?
A best practice is the general pattern; a policy requirement is your organization's specific, enforceable commitment to it. "Deprovision promptly" is a practice; "all access revoked within 24 hours of departure, immediately for privileged accounts, with timestamped records" is a policy requirement. Practices become real when they're translated into policy rules specific enough to automate and audit. The IAM policy template provides that translation for all ten practices here.
Why aren't MFA and password policies on the list?
Because they belong to the authentication layer, which your identity provider owns and which most organizations already handle competently. The practices on this list cover the governance layer (everything after login), which is where the gap between claimed and actual practice is widest. The one authentication-adjacent practice worth auditing is coverage: whether strong authentication actually extends across the full application estate, which depends on the inventory practice.
How do we know if our access reviews are effective?
Two numbers: flag rate and remediation rate. An effective review flags something in most cycles (access drift is universal, so a zero-flag review usually means reviewers lacked context or bulk-approved) and remediates 95%+ of flagged items within a defined window. Also check scope: a review covering only IdP-visible identities certifies a partial population regardless of how rigorous the reviewers are.
What is the most commonly failed IAM best practice?
Full-estate deprovisioning. Nearly every organization automates offboarding for its federated applications; very few can demonstrate revocation across the non-SCIM applications, the shadow tools, and the service accounts a departing user touched. It's also the failure with the most direct consequence, because an orphaned account is a standing attack path with a former employee's name on it.
How often should these practices be audited internally?
Quarterly for the high-consequence tests (deprovisioning completeness, privileged account register, orphaned account check), aligned with the access review cadence. Annually for the structural ones (inventory reconciliation, SoD ruleset coverage, metrics review), or immediately after significant change: an acquisition, a major platform migration, or rapid headcount movement in either direction. The IAM audit readiness checklist packages these tests as a runnable instrument.
.svg)
