Accountable Identities and the Access Lifecycle
Learn why an account must have an owner, a purpose, a lifecycle, and a revocation path before it can be trusted.
In this lesson, you will learn to:
- Map a joiner, mover, leaver, and non-human identity lifecycle with accountable owners and timely deprovisioning controls.
Accountable Identities and the Access Lifecycle
This lesson establishes a practical identity model and follows a workforce or service identity from request through change, offboarding, and evidence retention.
Identity is an accountable relationship, not just a username
An identity system answers a deceptively simple question: which subject is requesting access? The answer needs more than a familiar display name. A useful identity record connects an account to an accountable person, service, or process; a business purpose; an owner; and the information needed to decide whether access is still appropriate.
Keep related terms separate. A subject is the person, workload, device, or service that acts. An identity is the representation used by a system to recognize that subject. An account is a record through which access is granted. A credential or authenticator is evidence used to authenticate. Conflating these terms creates fragile designs: deleting a password does not necessarily remove an account, and a shared administrator account cannot provide person-level accountability.
For each account, record an owner and a purpose that another reviewer can understand. A payroll administrator account may be owned by a named employee and justified by a role. A deployment service identity may be owned by a team, scoped to one pipeline, and prohibited from interactive sign-in. A generic “automation” account with a permanent password and no owner is difficult to review, rotate, or investigate.
Establishment must also be proportionate. A low-impact collaboration space may accept a verified corporate account. An account that can approve payments, change identity policy, or retrieve sensitive records deserves stronger enrollment checks, tighter approval, and a recovery process that cannot be casually exploited. NIST’s digital identity guidance frames these choices as risk-based decisions across identity proofing, Authentication, and federation rather than a one-size-fits-all checklist.
The practical outcome is a small identity inventory that can answer: who or what is this, who owns it, what is it for, how was it enrolled, and how is it retired?
Design for joiners, movers, leavers, and exceptions
Access risk often appears when an organization changes faster than its identity records. A new employee needs a reliable request and approval path. A person who changes team or geography needs access recalculated, not merely added. When employment or a contract ends, the organization needs to disable access across the relevant identity provider, applications, shared devices, and emergency channels without waiting for a manual ticket to be noticed.
Model this as a lifecycle, not a series of unrelated help-desk tasks. An authoritative source—often HR for workforce identities or a controlled inventory for service identities—provides a change signal. That signal should trigger a defined decision: create, modify, suspend, or retire the account. Downstream applications must either receive the change automatically or have an explicit reconciliation process. The correct design varies, but an undocumented manual handoff is a known failure point.
Exceptions require the same discipline. Temporary workers, break-glass accounts, mergers, shared laboratory systems, and vendor support may legitimately need different handling. Give each exception an owner, a narrow scope, an end date where possible, and evidence of approval. “Temporary” access that has no expiry becomes ordinary access without ordinary review.
Test the lifecycle with realistic events. Can a manager’s move remove old finance access while retaining necessary collaboration access? Can a departed contractor’s sessions and recovery methods be invalidated? Can the owner of a service identity be found when a secret must be rotated? A process that works only for the happy-path new hire is incomplete.
Resources
- NIST SP 800-63-4 Digital Identity Guidelines — Use this current NIST overview to understand risk-based identity proofing, authentication, and federation terminology.