Identity and Access Management (IAM) Architecture
Four questions stand between a person and a resource, and each one needs its own answer
A contractor's directory account is disabled at 17:00 on their last day, while a separately managed account for another online service remains active through the night. A person can have multiple digital identities, so deactivating one account does not establish that every account has been de-provisioned. Disabling the directory account answered who exists for that one identity; nobody asked what other accounts the same person still held. Those four questions are the model this whole domain hangs on: who exists, who is here now, what may they do, and what did they do. Identity and access management (IAM) architecture is the discipline of deciding all four deliberately, and at 25% of the ISSAP exam outline it is the second-largest domain, behind Infrastructure and System Security Architecture at 32%. Its recurring trap is the option that answers one question with a stronger version of another: multifactor authentication offered against a fraudulent enrollment, a tighter sign-in offered against an administrator who can both raise and approve a payment, or a detailed audit trail offered in place of the separation of duties that would have stopped the act.
The four questions are answered in order, one page each: who exists, who is here now, what may they do, what did they do
Read the pages in order, because each one consumes what the page before it produced. Architect the identity lifecycle answers who exists: it establishes and verifies the real-world identity behind an account (identity proofing), assigns the identifiers that carry that decision, and provisions and de-provisions the accounts derived from it, so reach for it when the scenario turns on proofing rigor, an identifier, or someone joining, changing role, or leaving (a joiner, mover, or leaver event). Architect identity authentication answers who is here now: it decides at every later access whether the party presenting evidence controls an authenticator bound to that account, and it covers the assurance target, the factors that meet it, the protocols that carry an authentication or delegated authorization between parties, and the trust relationships that decide whose word about an authentication you accept. Architect identity authorization answers what may they do: the principles that bound every grant, the approach that turns a request into a decision, the plane the decision is enforced on, the process that issues and withdraws the grant, and the tighter treatment privileged access needs. Architect identity accounting answers what did they do: the requirements the record must satisfy, the audit events that satisfy them, the alerts that make selected events actionable, and the log management that keeps the record complete, trustworthy, and lawfully retained.
When two answers both work, let the harm choose the rigor and let the grant run out
The default this domain rewards is the option whose strength is sized by the damage a failure would cause and whose authority ends on its own. Proofing rigor follows the harm of enrolling the wrong person rather than the convenience of the proofing channel, the authentication assurance target follows the impact of the account being taken over rather than what the organization already owns, and a grant is bounded in operations, resources, and time rather than left standing until someone remembers to remove it. On the evidence side the same instinct reads as durability: a record is worth what survives review, so it has to name at least the actor, the target, and the authority under which the action ran, and the people who can erase it must not be the people it covers. Where an option adds strength at a check that already passed while the scenario's failure sits at one of the other three questions, it is the wrong answer however strong it is.
The four questions this domain answers, and which page covers each
| Question | What it settles | Where designs fail | Drill into |
|---|---|---|---|
| Who exists? | Whether an account should exist, whose real-world identity it stands for, and which identifier carries that decision | A role change that only adds access, or a departure where the directory record is deleted first while downstream credentials keep working | Architect the identity lifecycle |
| Who is here now? | Whether the party asking controls an authenticator bound to that account, at the assurance the account warrants | Recovery and authenticator binding left weaker than the daily sign-in they can bypass | Architect identity authentication |
| What may they do? | Which operations, on which resources, for how long, approved by whom, and how the grant is withdrawn | One subject able to complete a critical process alone, or standing privilege that nobody revisits | Architect identity authorization |
| What did they do? | Whether the record reconstructs the event, reaches an owned response path, and survives the people it covers | Logs that capture data reads while the entitlement and policy changes that granted them go unrecorded | Architect identity accounting |