Identity and Access Management (IAM)

Identity and Access Management (IAM) is the set of policies, processes, and technologies that ensure only authenticated (identity-verified) and authorised (permission-granted) entities – people, devices, or services – can touch digital resources. It sits at the heart of every secure system.

At its simplest, IAM revolves around three building blocks often remembered by the acronym AAA: Identification, Authentication, and Authorization, with a fourth pillar, Accounting. Identification is the act of claiming an identity – like typing a username or swiping a smart card. Authentication is the process of verifying that identity claim, such as by checking a password, a fingerprint, or a one-time code from a phone. Authorization then dictates what that verified identity is allowed to do: view a document, delete a record, or only read an application’s dashboard. Accounting (sometimes called auditing) logs every action, so an organisation always has a reliable trail of who did what and when.

IAM is not just about human beings. In modern IT, devices (a server in a datacentre), services (a nightly backup script), and APIs (an online payment gateway) all need identities. A service account in Microsoft Entra ID, for instance, lets a web application connect to a database without a human entering a password. These non-human, machine identities now outnumber human identities in many businesses.

Authentication factors fall into three broad categories: something you know (password, PIN), something you have (smart card, hardware token, authentication app), and something you are (fingerprint, iris pattern, voiceprint). Using more than one factor is called multi-factor authentication (MFA). Two-factor authentication (2FA) is simply MFA with exactly two different factors. Single sign-on (SSO) improves usability by letting a user authenticate once and then access multiple applications without re-entering credentials, relying on a central identity provider. Behind the scenes, protocols such as SAML and OpenID Connect shuttle trust between the identity provider and service providers.

Once authenticated, what a user can do is governed by an access control model. Discretionary Access Control (DAC) lets the owner of a file decide who can read or write it – think of sharing a Google Doc. Mandatory Access Control (MAC) uses labels (like ‘Top Secret’) and is typical in military environments; users cannot override the policy. Role-Based Access Control (RBAC) gives permissions based on job roles – everyone in the ‘Finance’ role can access the accounting system. Attribute-Based Access Control (ABAC) is more granular: it considers attributes of the user, the resource, and the environment, such as granting access only if the user is a manager AND the request comes from a corporate laptop AND it is within business hours.

IAM also handles provisioning (creating accounts when someone joins), deprovisioning (removing accounts when someone leaves), and access reviews (certifying that permissions are still appropriate). In cloud environments, IAM capabilities are often delivered as a service, such as Cloud IAM in Google Cloud or AWS IAM, or through identity platforms like Microsoft Entra ID. These services let administrators define extremely fine-grained policies – for example, ‘Allow this group to read objects in this storage bucket from this virtual network only’.

Without IAM, you could not implement two of the most fundamental security principles: least privilege (giving people only the permissions they genuinely need) and separation of duties (ensuring no single person can approve and execute a sensitive action, like paying an invoice). IAM is therefore not a single product but a living framework that touches every corner of IT.

A mid-sized e-commerce company, TrendyGadgets, hires a new developer, Priya. On her first day, an IT administrator does not simply hand over a username and password. They follow a structured IAM workflow.

The administrator opens the company’s identity provider – Microsoft Entra ID – and creates a new user object. They enter Priya’s full name, department, job title, and a corporate email address. During this provisioning step, an automated workflow triggers: Entra ID automatically adds her to the ‘All Developers’ group, which grants baseline access to the source-code repository and the internal wiki. The administrator also assigns her a specific IAM role that permits her to read but not modify the customer database, because her current project only requires read access.

Before handing over the credentials, the administrator enforces MFA. Priya must install the Microsoft Authenticator app on her company phone and register it. The system will now require her password plus a time-limited code from the app every time she logs in from a new location. The administrator also configures a Conditional Access policy: if the sign-in attempt comes from outside the country, it is blocked entirely, even with correct credentials.

Priya logs in for the first time at her office desk. The identity platform identifies her claim (username), authenticates her (password + MFA app), and then checks authorization. RBAC groups grant her access to the code repository and the project management tool. She cannot open the HR portal because her account lacks that role assignment.

Every action Priya takes – logins, file accesses, permission changes – flows into a logging system such as Microsoft Sentinel. The security operations team uses these audit trails daily. When a suspicious login attempt from another continent is blocked by Conditional Access, an alert fires in the SOC dashboard. The IAM framework not only enabled Priya to work securely on day one, but also gave the business ironclad control and visibility over its digital identities.