The IAM gaps that stay hidden on an ordinary day
When an employee changes teams, a contractor finishes an engagement, or a new system goes live, accounts and entitlements do not always change with them. People retain permissions from former roles, supplier accounts outlive contracts, and administrator accounts are used for routine work. During an incident, the question is not only who signed in, but who can access what, who approved it, and whether that access is still needed.
Identity and Access Management (IAM) is the capability to manage identities, establish who or what is requesting access, and determine what that identity may do. Its scope includes employees, contractors, suppliers, administrators, applications, and service identities. It is more than deploying single sign-on or buying an authentication product: access must fit work and risk throughout an identity’s lifecycle.
Start with an inventory of identities and resources
Map identity sources and critical resources before choosing another tool. Identify HR or supplier registries, identity providers, SaaS applications, internal systems, cloud environments, databases, and local accounts outside central control. Then connect each account to a person or accountable owner, employment or supplier status, team, purpose, and current privilege level.
Do not limit discovery to employee accounts. Service identities, API keys, automation, shared accounts, and emergency accounts can affect critical systems and often lack clear ownership. Record a business owner, technical custodian, purpose, credential storage method, review date, and decommissioning process. An unknown owner is a risk to resolve, not a permanent exception.
Design access around duties and risk
Begin with job responsibilities and the tasks people must perform—not a list of individuals to grant access system by system. Create access packages or roles for recurring work, specifying the systems, data, and minimum permissions needed. Separate read, edit, approval, and administration rights to avoid concentrating unnecessary authority in one account.
Role-Based Access Control (RBAC) can group permissions by duty, but too many roles become difficult to govern, while overly broad roles combine people with different risks. Some decisions also need context such as location, device, data sensitivity, time, or request status. A sound design lets approvers understand why access is needed and what it enables instead of guessing from a technical group name.
Control employee and external-user lifecycles
Make joiner, mover, and leaver events trigger consistent access changes. Connect start dates, contract end dates, department, manager, and job role to access workflows. When someone moves teams, review both the new access to add and the old access to remove. If the process only adds permissions, entitlement creep is inevitable.
Contractors and suppliers need an internal sponsor, a defined scope of systems and data, an expiry date, and a reviewable renewal path. Avoid permanent shared accounts across teams. Use individual identities where practical, and ensure contract termination automatically closes accounts and related sessions in high-risk systems.
Protect privileged and non-human identities
Administrator accounts have greater impact than ordinary accounts. Separate daily-use and admin accounts, use stronger authentication proportionate to risk, store credentials in a vault, limit elevated access duration where practical, and log sensitive sessions. NIST’s Zero Trust approach rejects implicit trust based only on network location or asset ownership; identity and authorization are evaluated before access to a resource.
Multifactor authentication (MFA) is important, but it does not replace least privilege, timely deprovisioning, or monitoring of access. Match assurance to the user and resource, especially for administrators and critical systems. Consider phishing-resistant methods for higher-risk cases and design account recovery so it does not become a bypass around the control.
Make approval and access reviews operational
An access request should specify the system, data, role, duration, business reason, and accountable approver. Approval paths can vary by risk: a manager may approve ordinary read access, while sensitive data or administrator access requires a designated data or system owner. Do not route every request through one committee until delays encourage workarounds.
Present access reviews in language approvers can understand: application, risk, grant date, last use, and current business reason. Break reviews into manageable batches and require owners to certify or revoke explicitly. Escalate non-responses and apply a defined decision rule; silence should not be treated as approval.
A 90-day launch and practical measures
Days 1–30: select a clearly consequential scope such as finance, customer data, or administrator accounts. Build a usable inventory, identify identity sources and application owners, and map joiner-mover-leaver gaps. Baseline dormant accounts, admin access, and approval time. Agree principles and decision authority with business, technology, and security stakeholders.
Days 31–60: design roles or access packages for recurring work, refine requests and approvals, and test removal after transfers and contract endings. Review admin and service accounts, and test recovery when MFA or the identity provider is unavailable. Pilot with a limited group and capture workflow friction and operational impact before expanding.
Days 61–90: automate source events where systems are ready, expand risk-based reviews, and give owners a dashboard of pending items and exceptions. Useful measures include time to close accounts after exit, privileged access with a named owner, ownerless identities, inactive accounts still enabled, requests with complete approval evidence, and time spent on access reviews.
Reference guidance: NIST SP 800-63-4, NIST SP 800-207, CISA IAM Best Practices