The rules, pillar by pillar

Each pillar comes down to a few plain rules you can test your program against.

Every rule is quoted from the book, with the chapter where the reasoning behind it lives. Where a rule is specific to one kind of identity, it is marked Human, Nonhuman, or AI.

Governance

Who decides, who owns what, and whether the rules are written down.

  • Every exception needs a named owner and a closure condition. Chapter 6
  • A type that can hold standing privileged access should never be creatable with a blank owner and no expiration. Chapter 12
  • If a standard cannot be tested, it is not mature enough. Chapter 12
  • A service account should have an owner, justification, and credential management expectation. Chapter 12 Nonhuman
  • An AI agent should have a sponsor, delegated boundary, review cadence, and shutdown path. Chapter 12 AI

What lives here: Policy, ownership, decision rights, standards, exceptions, and AI governance rules.

Lifecycle

Whether identities begin, change, and end the way they should.

  • Every identity needs a beginning, a middle, and an end. Chapter 7
  • Removal must be built. Chapter 7
  • An identity you can only stop on a schedule is one you do not fully control. Chapter 7
  • Creating the record early is fine; switching on access before the person is actively employed is exposure without a purpose. Chapter 13 Human
  • If an AI agent can still act after its purpose has ended, its lifecycle was never fully designed. Chapter 13 AI

What lives here: Source of truth, HRIS integration, joiner-mover-leaver, and the lifecycle of nonhuman and AI identities.

Access

Whether access means what you think, and is no larger than it needs to be.

  • An identity should hold only the access a task requires. Chapter 8
  • Role-obvious access should be automatic. Chapter 14 Human
  • Sensitive or privileged access should be requested. Chapter 14 Human
  • Service accounts should have only the capabilities they need for the system they support. Chapter 8 Nonhuman
  • An agent acting for a person can never do more than that person could. Chapter 15 AI

What lives here: Entitlements, access roles, application authorization, privileged access, certifications, and access reviews.

Technology

Whether your tools serve a model you defined, or quietly define how you work.

  • Technology selection should begin with capability. Chapter 16
  • The strength of the proof should match what the access can reach. Chapter 9
  • If you cannot enable everything the operating model could use, do not half-enable many things. Chapter 16
  • Technical debt should be managed as a structural risk category, not just a technical backlog. Chapter 16

What lives here: Directories, the IGA platform, provisioning, cloud IAM, and authentication, from SSO and MFA to passwordless, federation, and conditional access.

People & Change

Whether ownership is real and the work is shared.

  • An approval path is not governance if the approver cannot interpret the decision. Chapter 10
  • Managers should know what they are expected to approve. Chapter 10 Human
  • Communication should not begin the week before rollout. It should begin when the change is first being shaped. Chapter 17
  • AI sponsors should know they are accountable for the behavior of the agents they introduce. Chapter 10 AI

What lives here: Ownership clarity, communication, training, adoption, and the human side that decides whether the rest holds.

Want to test yourself against them? The five-minute assessment checks all five pillars, and the checklists at the end of each chapter turn them into questions. Each rule comes straight from the chapter named beside it, and Appendix B of the book, the Artifact Pack, turns them into working templates.

The Modern Identity Operating Model cover

Go deeper in the book

Appendix B, The Rules at a Glance, collects the core rules, and the chapter named on each rule explains the reasoning behind it.

Coming soon: get notified