Access has a habit of outliving the reason it was granted. Someone changes roles but keeps an old permission. A temporary integration becomes permanent. A service account created for one deployment quietly acquires the keys to half the cloud estate.

Identity and Access Management (IAM) is how we stop that drift. It answers three practical questions: who or what is making a request, what is it allowed to do, and how can that access be changed or removed?

The answer must cover more than employees and customers. Service accounts, cloud workloads, devices, APIs, automation, and third parties all have identities too. A forgotten machine identity can be every bit as powerful as a forgotten administrator account.

Identity Lifecycle

Access should follow a managed lifecycle:

  1. Establish: verify the identity to the level required by the risk.
  2. Provision: create accounts and assign initial access from an approved role or request.
  3. Use: authenticate requests and enforce authorization at every relevant resource.
  4. Review: confirm that access still matches the person’s or workload’s responsibilities.
  5. Change: update access promptly after a role, contract, device, or application change.
  6. Remove: disable sessions, credentials, tokens, and entitlements when access ends.

The joiner–mover–leaver process is often where IAM succeeds or fails. Removing a directory account is not enough if API keys, shared passwords, cloud roles, and active sessions remain usable.

Authentication and Authorization

Authentication establishes which identity is present. Authorization decides whether that identity may perform a specific action on a specific resource. Logging and review provide accountability.

A valid login should not imply access to every object. Applications must enforce authorization on the server for each request; hiding a button in the interface is not an access-control decision.

Authorization models

  • Role-based access control (RBAC): permissions are grouped into roles.
  • Attribute-based access control (ABAC): policy considers attributes of the subject, resource, action, and context.
  • Relationship-based access control (ReBAC): decisions use relationships such as owner, member, or manager.

Many systems combine them. Whatever the model, default-deny and least privilege are easier to reason about than a long list of exceptions.

Passwords

Current NIST guidance does not support arbitrary composition rules such as “one uppercase, one number, and one symbol,” and it does not recommend periodic password changes without evidence of compromise. Those rules often encourage predictable variants.

A better password policy:

  • permits long passwords and passphrases;
  • blocks commonly used and known-compromised values;
  • supports password managers and paste;
  • rate-limits failed attempts;
  • stores passwords with a salted, adaptive password hash;
  • forces a change when compromise is known or suspected.

Knowledge-based authentication questions are weak. Answers are often public, guessable, or forgotten, and current NIST guidance says not to use them as an authenticator.

Multi-Factor Authentication and Passkeys

MFA combines factors from different categories: something known, possessed, or inherent. Two passwords are not two factors.

Phishing-resistant options such as FIDO2 security keys and passkeys are preferable for high-value access because the credential is bound to the legitimate site. SMS and one-time codes can still reduce risk compared with a password alone, but they remain vulnerable to phishing, interception, and account-recovery attacks.

Recovery must be designed as carefully as login. An attacker will use a weak help-desk or email-reset path to bypass strong MFA.

Federation: SAML, OAuth, and OpenID Connect

These technologies solve related but different problems:

  • SAML 2.0 commonly carries authentication and attribute assertions for browser-based enterprise federation.
  • OAuth 2.0 lets a client obtain limited authorization to call an API. It is not an authentication protocol by itself.
  • OpenID Connect (OIDC) adds an identity layer to OAuth 2.0 and returns an ID token describing an authentication event.

An OAuth access token is for the resource server. An OIDC ID token is for the client that requested authentication. Sending an ID token to an API as if it were an access token mixes those roles and can create validation mistakes.

Validate issuer, audience, signature, time claims, nonce or state where required, redirect URIs, and the exact flow used. “Uses SSO” is not a security review.

Privileged Access

Administrator access deserves additional controls:

  • separate administrative and everyday accounts;
  • phishing-resistant MFA;
  • just-in-time and time-limited elevation;
  • approval for particularly sensitive actions;
  • managed workstations or privileged access stations;
  • session and command logging with privacy safeguards;
  • rapid revocation and tested emergency access.

Privileged Access Management (PAM) tools can broker and record access, but they do not make a permanently overpowered role safe.

Workload and Machine Identities

Applications should not share a long-lived secret copied into configuration files. Prefer short-lived, automatically issued credentials tied to a workload identity. Cloud instance identities, Kubernetes service accounts with bounded tokens, mutual TLS, and workload identity frameworks can remove the need to distribute static keys.

When static secrets remain necessary:

  • store them in a secret manager;
  • scope them narrowly;
  • rotate them automatically;
  • prevent them from entering source control, images, logs, and crash reports;
  • record where each secret is used before revoking it.

Provisioning and Access Reviews

SCIM can automate identity provisioning between systems, but automation needs a reliable source of truth and failure monitoring. A failed deprovisioning event should create an alert, not a silent former-employee account.

Access reviews should focus on meaningful entitlements and owners. Asking a manager to approve hundreds of unreadable permission names once a year produces little assurance. Review high-risk access more frequently and remove permissions that have no clear owner or use.

Conclusion

IAM is not a login screen. It is the full life of an identity and every credential, session, role, and policy attached to it. Strong authentication matters, but the larger goal is precise authorization, short-lived access, dependable removal, and evidence that the process works.

References