🔑 Identity & Access Management (IAM): MFA, RBAC, and Least Privilege

What IAM Is, and Why Identity Is the New Perimeter

Identity & Access Management (IAM) is the discipline of ensuring that the right people and machines have the right access to the right resources, at the right time, for the right reasons. It spans the policies, processes, and technologies that govern who a user is and what they are allowed to do.

For decades, security relied on a network perimeter: a hardened firewall separated a trusted internal network from the hostile internet. Cloud services, remote work, mobile devices, and third-party integrations have dissolved that boundary. There is no longer a single edge to defend.

Instead, identity has become the new perimeter. Access decisions follow the user and the workload wherever they are, rather than depending on the network they connect from. Every authentication and authorization event becomes a control point. This makes IAM the foundational layer beneath nearly every other security capability.

Core Concepts: The AAA Model

IAM is often framed around AAA: Authentication, Authorization, and Accounting. It helps to add a fourth concept up front: identification.

• Identification — the claim of who you are (a username, email, or service ID). It is asserted, not yet proven.
• Authentication — proving that claim is genuine (verifying a credential such as a password, token, or biometric).
• Authorization — deciding what an authenticated identity is permitted to do (which resources and actions).
• Accounting — recording what happened, so activity can be audited, billed, or investigated.

The most common confusion is between authentication and authorization. Authentication answers "who are you?" while authorization answers "what may you do?" You can be perfectly authenticated and still be denied an action because you lack permission. Keeping these two phases distinct is essential to designing sound access systems.

Authentication Factors, MFA, and the Decline of Passwords

Authentication relies on one or more factors, traditionally grouped into three categories:

• Something you know — a password, PIN, or passphrase.
• Something you have — a hardware token, smartphone, or smart card.
• Something you are — a biometric such as a fingerprint, face, or iris.

Multi-Factor Authentication (MFA) requires factors from two or more distinct categories. Combining a password with a one-time code from a phone is far stronger than either alone, because an attacker must compromise two independent things.

Passwords are the weakest link. They are reused across sites, phished, guessed, and leaked in bulk breaches. Even MFA based on SMS codes is vulnerable to SIM-swapping and real-time phishing proxies.

The industry is shifting toward passwordless authentication built on FIDO2 and passkeys. These use public-key cryptography: a private key never leaves the user's device, and a phishing-resistant challenge is signed locally. Because the credential is bound to the legitimate site's origin, passkeys defeat most phishing and credential-replay attacks entirely.

Authorization Models and Least Privilege

Once an identity is authenticated, an authorization model decides what it can access. Two models dominate:

• RBAC (Role-Based Access Control) — permissions are bundled into roles (e.g. "Billing Clerk", "Network Engineer"), and users are assigned roles. It is simple to reason about and audit, but can suffer "role explosion" as edge cases multiply.
• ABAC (Attribute-Based Access Control) — decisions are computed from attributes of the user, resource, action, and environment (department, data classification, time of day, device posture). It is far more flexible and context-aware, at the cost of greater complexity.

Many mature organizations blend the two: RBAC for coarse-grained baseline access and ABAC for fine-grained, conditional rules.

Above any model sits the principle of least privilege: every identity should hold only the minimum permissions needed to perform its function, and no more. Least privilege shrinks the blast radius of any compromised account.

A closely related control is separation of duties (SoD): no single person should control an entire sensitive process end to end. The person who requests a payment should not also approve it. SoD prevents both fraud and single points of catastrophic error.

Identity Lifecycle, SSO, and Federation

Identities are not static; they must be managed across their whole lifecycle, often called joiner–mover–leaver:

• Joiner — provisioning accounts and baseline access when someone is hired.
• Mover — adjusting access when they change roles, ideally removing old permissions, not just adding new ones.
• Leaver — promptly deprovisioning all access when they depart.

Failures here create the orphaned and over-privileged accounts discussed below. Automated provisioning reduces manual error and ensures deprovisioning actually happens.

Single Sign-On (SSO) lets a user authenticate once and access many applications without re-entering credentials. Federation extends trust across organizational or domain boundaries so an identity from one provider is accepted by another. Three protocols underpin most of this:

• SAML 2.0 — an XML-based standard widely used for enterprise web SSO between an identity provider and service providers.
• OAuth 2.0 — an authorization framework for delegated access; it lets an app act on a resource on the user's behalf via access tokens. It is not, by itself, an authentication protocol.
• OpenID Connect (OIDC) — a thin identity layer built on top of OAuth 2.0 that adds authentication and standardized user-identity tokens (ID tokens).

Underneath, directory services store identities and group memberships. LDAP is the long-standing protocol for querying directories; Active Directory is the dominant on-premises implementation, and cloud directories such as Entra ID serve the same role for modern, internet-facing estates.

Privileged Access Management and Secrets

Administrator, root, and service accounts are the highest-value targets because they can change configurations, read everything, and cover their tracks. Privileged Access Management (PAM) applies extra controls specifically to these accounts:

• Credential vaulting — privileged passwords and keys are stored in a vault and never known directly by humans.
• Session brokering and recording — admins connect through a controlled gateway that logs the session.
• Just-in-time (JIT) access — privileges are granted only for the moment they are needed and automatically revoked afterward, eliminating standing privilege.

Machines need credentials too. Secrets management handles API keys, database passwords, and certificates used by applications and pipelines, providing short-lived, rotated, auditable secrets instead of hard-coded values checked into source code.

IAM, Zero Trust, and OT Environments

IAM is the engine of Zero Trust, the model summarized as "never trust, always verify." Zero Trust assumes no implicit trust from network location and re-evaluates each request against identity, device posture, and context. Strong authentication, least privilege, and continuous authorization are precisely the IAM capabilities that make this possible. (Zero-trust networking architecture is covered in depth in a separate article; here we focus on the identity foundations it rests on.)

IAM is markedly harder in Operational Technology (OT) environments such as plants, substations, and control rooms. Legacy industrial systems were designed for availability and physical isolation, not modern identity:

• The shared-account problem — operators frequently share a single generic login at a control console, destroying individual accountability and making deprovisioning impossible.
• Legacy protocols — many devices cannot support MFA, modern directories, or even individual user accounts.
• Jump hosts — a hardened intermediary (a "jump host" or bastion) is placed between corporate IT and the OT network. All administrative access is funneled through it, where MFA, logging, and session control can be enforced even when the end devices cannot.

Common Pitfalls

• Over-privileged accounts — users accumulate permissions over time ("privilege creep") that are never revoked, violating least privilege.
• Orphaned accounts — accounts of departed staff or decommissioned services that remain active and unmonitored, offering attackers a quiet way in.
• Standing privilege — admin rights that exist permanently rather than being granted just in time, leaving a large attack surface around the clock.
• Weak deprovisioning — relying on manual offboarding so access lingers after departure.
• Treating MFA as optional — exempting executives or service accounts undermines the whole control.

Done well, IAM is invisible to legitimate users and an unyielding wall to everyone else. Identification, authentication, authorization, and accounting, governed by least privilege and a disciplined identity lifecycle, form the backbone of modern security engineering.