---
{
  "title": "Identity and access management",
  "summary": "Coordinate human and workload identities through creation, authentication, permission review, role changes, and complete removal of obsolete access.",
  "topic": "networking",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    3
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Zero Trust Architecture",
      "url": "https://csrc.nist.gov/pubs/sp/800/207/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---
## The idea

Identity and access management coordinates account creation, authentication, authorization, review, and removal. It includes people and nonhuman identities. Joiner, mover, and leaver processes ensure access matches current responsibilities. Central directories, federation, and privileged-access controls can improve consistency, but they also become critical dependencies. Maintain clear ownership and review actual permissions rather than assuming an old approval remains valid forever.

## In practice

An employee changes department. Their old access is removed, new access is approved, and active sessions or delegated applications are reviewed where relevant.

## A common misunderstanding

Disabling a visible user account may not remove every token, service credential, or delegated access path.

## Check your understanding

Why include nonhuman identities in reviews?

**Think it through:** Service accounts and applications may retain powerful access even when the original human owner leaves.

## Treat access as a changing relationship

Imagine a fictional academy hires an instructor, moves them into curriculum design, and later ends the contract. Each transition changes the work they need to perform. An account that was appropriate on the first day can become overprivileged if access only accumulates.

The joiner process establishes an approved identity and initial permissions. The mover process removes obsolete access as well as adding new rights. The leaver process addresses sessions, credentials, delegated applications, and resource ownership instead of merely hiding the account from a directory view.

## Nonhuman identities have owners too

Suppose the instructor created an integration that imports course schedules. The integration may use its own service identity and continue operating after the instructor leaves. Removing the human account does not necessarily remove or safely transfer that automation.

Record each workload identity's purpose, owner, effective permissions, credential lifecycle, and recovery dependency. A team should understand which integrations are still required and how access is replaced without creating unexplained outages.

## Review effective access rather than labels

A role name can sound harmless while its permissions or group relationships grant broad authority. Review what the identity can actually do, including permission-changing actions and inherited access. An approval from a year ago is evidence of a past decision, not proof that the current access remains necessary.

For the academy, access reviews should use resource owners and concrete tasks. Asking whether an account is “still okay” is less useful than asking whether it still needs to read learner records or change publication settings.

For a paper exercise, create an instructor and a schedule-import service identity. Follow them through a role change and departure. List the required removals, transfers, and verification evidence. Explain which active sessions or delegated access paths need independent attention. This makes identity management an operational lifecycle with clear accountability rather than a one-time account creation task.

## Keep exploring

- [[authentication]]
- [[authorization]]
- [[identity-federation]]
- [[privileged-access]]