2 Identity and Access Management
Learn how identity and access management verifies identities, grants and limits permissions, and manages accounts throughout their lifecycle.
Purpose of and access management
and access management (IAM) is the set of policies, processes, and technologies used to manage identities and control access to systems and information. A sound IAM program helps ensure that the right person or service receives the right access, for the right purpose, for only as long as needed.
, , and
An represents a person, service, device, or other entity in a system. It is usually associated with an identifier, such as a username or service-account name, and attributes such as department, role, or employment status.
and are related but distinct steps. answers who or what is requesting access: the entity proves control of an authenticator associated with its . answers what that authenticated entity is allowed to do: a policy evaluates the request and permits or denies a particular action on a resource.
For example, an employee may use a password and a security key to authenticate to a company portal. establishes the employee’s ; then determines whether the employee may view a particular payroll record. alone does not grant permission to every resource.
factors and strength
factors are commonly grouped into three categories:
Something you know: a password or PIN.
Something you have: a hardware security key or a device holding a cryptographic key.
Something you are: a biometric characteristic, such as a fingerprint.
uses two different factor categories. Two passwords are not MFA because both are knowledge factors. MFA reduces the risk that a stolen password alone will be enough to access an account.
Phishing-resistant methods, such as security keys that bind to the legitimate service, provide stronger protection against fake sign-in pages than codes that users manually enter. The appropriate strength depends on the risk and the system’s requirements.
and access-control models
policies can be implemented using different access-control models:
: Permissions are assigned to roles, and users receive roles based on their job duties. A “payroll specialist” role may allow access to payroll records, while a “viewer” role allows read-only access.
: A policy evaluates attributes of the requester, resource, requested action, and sometimes the environment. For example, a clinician may view a patient’s record only when assigned to that patient’s care team and using an approved device.
: A resource has a list of identities or groups and the actions each is allowed to perform.
Organizations can combine these approaches. Whatever model is used, permissions should be understandable, consistently enforced, and reviewed as business needs change.
Apply least privilege
The means granting only the access needed to perform assigned tasks—and no more. It applies to people, applications, services, and automated processes. A staff member who only needs to read reports should not be permitted to change them; an application should not have broad administrator access when a narrower permission will suffice.
Practical safeguards include:
Use separate standard and administrator accounts for users who perform administrative work.
Limit privileged access to authorized roles and monitor its use.
Grant elevated permissions temporarily when possible, then remove them when the task ends.
Separate duties when one person should not control every step of a sensitive process.
Review permissions regularly and remove access that is no longer needed.
Least privilege limits the damage that can result from mistakes, misuse, or a compromised account.
Manage the
Account management covers an account from creation through eventual removal. A reliable process typically includes these stages:
Request and approval: A manager or resource owner requests access for a defined business purpose. Approval should come from someone authorized to grant it.
Provisioning: Create the , assign appropriate methods, and grant only approved roles or permissions. Record who approved the access and why.
Changes: When a person changes jobs, teams, or responsibilities, reassess access. Remove permissions that are no longer necessary before or when granting new ones; otherwise, access can accumulate over time.
Review and monitoring: Periodically confirm that accounts, roles, and privileges remain appropriate. Record and review important account changes, such as creation, modification, disabling, and termination.
Deprovisioning: When employment or another legitimate need for access ends, promptly disable or remove the account and revoke associated access, sessions, and credentials as appropriate.
The same lifecycle applies to nonhuman identities, including service accounts, application identities, and automation accounts. Each should have an accountable owner, a defined purpose, restricted permissions, protected credentials, and a process for rotation and retirement. Temporary and emergency accounts should be controlled and disabled when no longer required.
Access through an employee’s lifecycle
A new analyst needs access to a reporting system. The manager requests a read-only analyst role, and the data owner approves it. The analyst enrolls a second factor and signs in. The system authenticates the analyst, then checks the role to decide whether the requested report can be viewed.
If the analyst later transfers to another department, IAM staff review and update the permissions. When the analyst leaves the organization, the account and related access are disabled or revoked.