Identity and access management is one of the most consequential audit areas because almost every technical control depends on knowing who or what is acting and whether that subject has appropriate authority. An IAM audit is therefore broader than checking password settings or sampling a few user accounts. It should evaluate identity lifecycle, authentication, authorization, privileged access, service identities, federation, access review, monitoring, and the governance that ties those controls to business ownership.<\/p>\n
The current CISA<\/a> outline includes identity and access management within Protection of Information Assets while also requiring auditors to evaluate governance, operations, security programs, and control effectiveness. The ISACA certifications<\/a> connects IAM to information-security management and risk. A strong audit asks whether access is correctly granted, appropriately constrained, periodically revalidated, promptly removed, and supported by evidence that management can rely on.<\/p>\n The most reliable IAM controls begin before authentication. Every identity should have an authoritative source, a business owner, a reason to exist, and a defined lifecycle. Employees may originate from HR, contractors from a vendor-management process, customers from an application registration flow, and service accounts from an engineering workflow. The auditor should understand those sources before testing downstream access.<\/p>\n Joiner, mover, and leaver processes deserve separate attention. New access should be based on an approved role or request; transfers should trigger removal of privileges that no longer fit; terminations should revoke access within a defined period. Many organizations handle joiners well but accumulate excessive privilege when movers retain old roles after changing departments.<\/p>\n Auditors should test the timeliness and completeness of deprovisioning across more than the central directory. SaaS accounts, local application users, VPN profiles, cloud roles, API tokens, certificates, shared secrets, and privileged vault entries can survive after the employee record is disabled. Effective termination means removing usable authority, not merely setting one directory flag.<\/p>\n Orphaned identities are a strong audit signal. Accounts without an active owner, inactive users with permissions, nonhuman accounts tied to former projects, and guest accounts with no sponsor can indicate lifecycle weakness. Population analysis can identify these conditions before detailed sampling begins.<\/p>\n Lifecycle testing should trace a sample from authoritative source through every provisioning layer. HR records, identity governance workflows, directory groups, SaaS roles, local accounts, and privileged platforms can each introduce delay or divergence. End-to-end tracing is stronger than reviewing any one system in isolation.<\/p>\n Authentication controls should reflect account risk. Administrative and remote access typically require stronger assurance than low-risk self-service functions. Auditors should evaluate password policy, MFA coverage, phishing-resistant options, device or contextual controls, session management, and the exceptions that permit weaker methods.<\/p>\n Multi-factor authentication<\/a> is valuable, but the audit should not stop at the enrollment percentage. Recovery and reset paths may bypass the normal factor. Help-desk identity verification, backup codes, alternate email, temporary access passes, lost-device workflows, and administrative resets should be tested because attackers often target the recovery process.<\/p>\n Authentication logs can provide evidence of control operation. Repeated MFA denials, legacy protocols, impossible travel, abnormal device enrollment, or sign-ins from unusual networks may reveal both security events and policy gaps. The auditor should verify that important events are retained, reviewed, and routed to an accountable team.<\/p>\n The management focus of CISM<\/a> is relevant because authentication is not just a technical setting. Policy, awareness, incident response, exception governance, and metrics determine whether the mechanism remains effective as users and threats change.<\/p>\n Recovery controls should be tested as a separate authentication path. Help-desk resets, backup factors, recovery codes, temporary access passes, and administrator overrides can bypass stronger sign-in requirements. Attackers often target these exception paths because they are less visible than normal authentication.<\/p>\n Federated identity and single sign-on<\/a> can centralize authentication and reduce password sprawl, but they can also concentrate trust. Auditors should identify which identity providers are trusted, which applications accept their assertions, what claims are used, how signing keys are rotated, and how external tenants or partners are distinguished from internal users.<\/p>\n A successful federated login does not prove that the user should have a particular application role. The relying service may map a directory group, claim, or attribute into permissions, and that mapping is part of the authorization control. Auditors should test both the identity-provider side and the application side so privilege does not hide behind the convenience of SSO.<\/p>\n Federation lifecycle is also important. Old trusts, test identity providers, expired partner relationships, and applications that no longer have owners can remain active long after their business purpose ends. An inventory of federation relationships and relying parties supports periodic review and certificate rotation.<\/p>\n External identities should have clear sponsorship and expiry. Guest users can become a long-lived access path when invitations are accepted once and never revalidated. Audit samples should include guests and partners rather than focusing only on employees.<\/p>\n Federation reviews should verify trust configuration on both sides. Issuer validation, audience restrictions, certificate or key rotation, allowed domains, claim mapping, and session duration all influence risk. An apparently secure identity provider cannot compensate for a relying application that accepts overly broad assertions.<\/p>\n Authorization should be understandable in business terms. Roles, groups, attributes, and policies need owners who can explain what access they grant and why. A role named \u201cPowerUser2\u201d may be technically valid but difficult for a manager to review. Auditors should examine whether entitlements are grouped into meaningful access packages and whether high-risk permissions are clearly identified.<\/p>\n Role-based access control can simplify review, while attribute-based models can incorporate resource sensitivity, device state, location, or transaction context. The ideas behind dynamic access control<\/a> are relevant because modern access decisions may be contextual rather than fixed. Auditors need to understand the policy logic, not just a static list of group memberships.<\/p>\n Least privilege should be tested through effective permissions. Nested groups, inherited roles, wildcard policies, resource ownership, and default grants can produce authority that is not obvious from the primary assignment. Where platforms provide permission analyzers or access-graph tools, auditors can use them to identify paths to sensitive actions.<\/p>\nStart with the identity lifecycle, not the login screen<\/h3>\n
Audit authentication strength and recovery together<\/h3>\n
Distinguish federation and SSO from authorization<\/h3>\n
Test authorization against least privilege and business need<\/h3>\n