4 Identity and Access Management
Learn how identity, authentication, authorization, access-control policies, and account-protection practices work together to manage access to organizational resources.
and access foundations
and access management (IAM) governs how people, devices, and software identities are created, verified, and given access to resources. Its aim is to ensure each receives only the access it needs, and only for as long as it needs it.
An represents an entity, such as a person, computer, or application, in a system. It may have attributes such as a username, department, job role, or device status. An links an to a particular service and its permissions.
From claims to access decisions
Access decisions involve several distinct steps:
Identification: An entity claims an , for example by entering a username.
: The system checks evidence that the entity controls the claimed . A password, security key, or device certificate can serve as an authenticator.
: The system decides what the authenticated may do, such as read a file or approve a payment.
Accounting and auditing: The system records activity so actions can be reviewed and investigated.
Authentication does not, by itself, grant permission to every resource. Successfully signing in to a company portal proves control of an , but authorization rules may still prevent that from viewing payroll records.
Limit and divide permissions
means granting only the permissions a user, process, or device needs for its assigned task. For example, a support specialist may need to reset user passwords but not change payroll settings. A program that only reads records should not be permitted to delete them.
Apply by using standard accounts for routine work and separate, controlled administrator accounts for privileged tasks. Grant access to specific resources and actions rather than broad, unrestricted access. Remove or reduce access when duties change or no longer require it, and review permissions regularly while logging important actions.
divides sensitive work so one person cannot complete every step alone. One employee might create a payment while another approves it. This reduces the chance that a single mistake or compromised can cause serious harm.
Models for controlling access
An access-control model describes how a system decides whether an action is allowed. Organizations may combine models, each of which expresses access policies differently.
: A resource owner can grant or revoke access to that resource. For example, a document owner can share a file with selected colleagues. DAC offers flexibility but can make permissions harder to oversee.
: A centrally enforced policy compares security labels and user clearances, and users cannot freely change the policy. For example, a system may allow a user with the required clearance to view a document marked at that classification. MAC supports centrally enforced restrictions.
: Permissions are assigned to roles, and users receive access through their assigned roles. For example, a “billing clerk” role can view invoices and record payments. RBAC is often straightforward to administer when jobs are stable.
: A policy evaluates attributes of the user, resource, requested action, and sometimes the environment. For example, a clinician may view a patient record only when assigned to that patient and using an approved device. ABAC can express more context-sensitive rules.
Protect credentials and recovery methods
Use unique passwords. Reuse can let an attacker use credentials exposed in one breach to try other accounts. A password manager can generate and store long, unique passwords; protect it with a strong master password and MFA.
requires evidence from more than one factor: something you know, such as a password; something you have, such as a security key; or something you are, such as a biometric. When available, prefer phishing-resistant methods such as passkeys or security keys. A one-time code can improve security over a password alone, but it is not phishing-resistant because a fake site may relay the code to the real service.
Protect recovery methods by storing backup codes securely, keeping recovery email and phone details current, and securing recovery accounts with strong authentication. Never share authentication codes in response to an unsolicited message or call. To reduce phishing risk, use a trusted bookmark or enter the known address for important services rather than following unexpected sign-in links. Check that a login request is expected before approving it.
Manage privileged identities and changes
Restrict administrator accounts and monitor their use. Give applications or automated services their own managed identities instead of shared human credentials.
Manage access throughout the lifecycle: create accounts through an approved process, change permissions when responsibilities change, promptly disable accounts when they are no longer needed, and periodically review access lists.
For example, an administrator may provision an individual for a new billing employee, assign the billing role, and require MFA. The employee can view and update invoices but cannot approve their own payments. When the employee changes teams, billing access is removed; when employment ends, the is disabled.