Identity and Access Management Lifecycle

In this illustrative scenario, a contractor’s engagement ends on a Friday, and the offboarding runs exactly as designed. The end date was in the human resources record, so the identity provider disabled the account that afternoon. The laptop came back on Monday. The ticket closed with every box ticked.

Three weeks later, a pipeline the contractor built still deploys to production through a service account created during a migration. Continued operation is intended, but no team accepted ownership of the account, and the contractor still holds a copy of its non-expiring credential. A nightly warehouse export also uses a separate personal API credential issued to the contractor by the warehouse, outside the central identity provider’s lifecycle integration.

Disabling the central account worked, but the offboarding process did not end the contractor’s access through the other credentials. The service account is a software principal, not another personal identity of its creator. It needs an accountable owner and a decision about continued use. The organization can retain the pipeline while transferring ownership, replacing exposed credentials and invalidating the old ones, and reviewing its grants. The contractor’s personal warehouse access needs its own termination path.

Identity and access management connects subjects, credentials, permissions, and the events that change them. Ask who is requesting access, what that subject may do, for how long, and how a change becomes effective. For service identities, also distinguish who created the account, who owns its business purpose, and who can obtain or use its credentials. Those relationships determine what offboarding must revoke and what the organization should retain under new ownership.

The subject is often not a person

NIST’s digital-identity definition identifies a subject through attributes within a specified context. The same person can have accounts in several systems, while a service account identifies software rather than its human creator. Keep account-to-subject mappings and the separate ownership and credential-access relationships explicit; discovery tools and authoritative records can help maintain them, but their coverage needs verification.

Kubernetes service accounts provide non-human identities for Pods, components, and other clients. Human users are handled differently: Kubernetes normally relies on external authentication and treats user identities as opaque information rather than storing user-account objects in its API. This implementation illustrates why an inventory needs to connect several sources while preserving the distinction between a human subject and a software principal.

Subject type and credential delivery are separate choices. A workload can authenticate as a service account using either a stored credential or one issued at runtime. The table compares those arrangements rather than defining three mutually exclusive kinds of subject.

Arrangement	Who holds authentication material	What sets its lifetime	What ends access
Human account	A person and their authenticator; applications may also hold session or token material	Account eligibility, authenticator validity, sessions, and token policy are separate	Disable the account and address already issued credentials, sessions, and other access paths
Service identity with stored credentials	A workload, credential store, or host; administrators may have copies	The configured credential and grant lifetimes, which can differ	Remove unneeded grants, invalidate old credentials, and handle active sessions. Replacing a credential alone need not invalidate the previous one
Workload using runtime-issued credentials	The process or its agent holds a token or key material according to the mechanism	Issuer policy, renewal eligibility, verifier behavior, and session lifetime	Stop unauthorized issuance and renewal, enforce expiry or revocation at verifiers, and terminate sessions where required

Runtime issuance can reduce dependence on manually distributed, long-lived secrets. SPIFFE provides a standardized workload-identity approach, and Kubernetes recommends short-lived ServiceAccount tokens through TokenRequest or projected volumes. A one-hour token bounds reuse of that token only when expiry is enforced, allowing for defined clock tolerance. It does not bound access if the caller can obtain another token or retain an independently valid session. Verify those paths and remember that expiry cannot undo data already accessed.

Inventory non-human identities alongside human accounts and measure their coverage separately. If service credentials are poorly owned or absent from the offboarding process, prioritize those gaps according to their permissions and exposure. Their importance should follow evidence from the estate rather than an assumed ratio of service accounts to people.

Authentication answers one question, and only for a moment

Authentication establishes confidence in a claimed identity through the configured mechanism. NIST defines phishing resistance more narrowly: protection against an impostor verifier without relying on the claimant’s vigilance. User training is not a substitute for that protocol property. Overall authentication assurance also depends on authenticator protection, enrollment and recovery processes, implementation, and operation; phishing resistance alone does not establish all of it.

Successful authentication does not settle authorization or continuing subscriber presence. Those require separate evidence.

Authorization decides what the subject may do. A valid identity can be granted excessive access or pass a path where the required permission check is missing. Stronger authentication does not repair that authorization policy or its enforcement.

NIST SP 800-63B-4 warns relying parties not to infer subscriber presence from an access token alone: access and refresh tokens may remain valid after the authentication session ends. Its AAL2 guidance recommends (SHOULD) an overall reauthentication timeout of no more than 24 hours and an inactivity timeout of no more than one hour. At AAL3, the overall timeout is required (SHALL) to be no more than 12 hours, while the recommended inactivity timeout is 15 minutes. These are session requirements for the specified assurance levels. They do not independently define an API token’s lifetime or its revocation behavior.

An access token is therefore one part of the laptop-compromise assessment alongside authenticators and sessions. Identify the credentials an attacker can actually use, their scopes, expiry and renewal rules, and any proof-of-possession requirements. Possessing a token is not sufficient where the receiving system also requires a protected key the attacker cannot use.

Writing down what may be done

Role-based access control associates permissions with roles assigned to subjects; evaluation can include active roles, inherited permissions, and constraints. Attribute-based access control evaluates policies over subject, object, operation, and environmental attributes. Both make authorization decisions, and hybrid designs are possible: a role can itself be an attribute. NIST’s definitions provide the starting point; the discussion of role-based and attribute-based access control explains the operational tradeoffs and the information each model needs to keep accurate.

Choose the review evidence for the question being asked. Enumerating effective access requires the relevant subjects, role hierarchy or policies, attribute values, and environmental assumptions. Reconstructing one past decision requires its policy version and relevant input evidence. Even without a complete historical snapshot, teams can review policy logic, test allowed and denied cases, and inspect attribute provenance and freshness. State which conclusions remain unsupported instead of treating all review as impossible.

Kubernetes RBAC combines permissions additively and has no deny rules. It can still be narrowed by removing excessive rules or bindings after checking every other grant that permits the same action. Namespace-scoped bindings can limit grants, but creating a namespace does not cancel a cluster-wide permission. Admission policies provide additional checks on supported operations; they cannot block get, list, or watch requests, which bypass admission. Review the combined enforcement paths and manage the rules as policy as code, with tests for both allowed and denied requests.

Authority to change permissions also needs review. Kubernetes enforces escalation restrictions when roles and bindings are created or updated, with explicit privileges such as escalate and bind for authorized exceptions. In any system, inspect what role editors and binding managers can actually grant, including restrictions imposed elsewhere. Broad authority can enable escalation; permission to edit one constrained binding does not necessarily confer every permission in the system.

Least privilege has a second axis

Least privilege limits access to what the assigned function needs. Apply that principle to duration as well as operation and resource scope: a grant needed only during an incident should not automatically remain available between incidents. Standing privilege makes that availability explicit. Decide when access is justified, how elevation is approved, and how expiry is enforced rather than inferring that a concise definition excludes time.

RFC 9700 recommends limiting access-token privileges to the application’s needs and restricting the audience to the intended resource server or a small set of servers. Receiving servers must enforce those restrictions. The same principle applies to credentials as to account grants: the permission actually available depends on both the issued authority and the checks performed when it is used.

Persistent credentials need protected storage and a replacement and invalidation process, which are part of secrets management. Inventory consumers so a planned rotation can update them and verify that the old credential stops working. During compromise, the need to contain exposure can outweigh interruption risk; define that authority and recovery procedure in advance.

Revocation is a propagation problem

NIST SP 800-63B-4 defines authenticator invalidation as removing its binding to a subscriber account. It requires prompt invalidation when the account ceases to exist, the subscriber requests it, compromise occurs, or eligibility ends, with a risk-based check of subscriber requests. The guidance also recommends establishing time limits for handling compromise. This concerns authenticators; the wider access-termination process must address other credentials and sessions too.

NIST notes that leaving a compromised authenticator valid can have more serious consequences than invalidating one in error. Use that risk judgment to define response authority and time limits before an incident. An on-call responder still needs an agreed scope, evidence requirements, and a recovery path for erroneous invalidation.

The identity provider and each relying application can maintain separate sessions. As NIST explains, ending one does not by itself end the other. Account disablement therefore needs an explicit contract for application sessions, including any logout notification, revalidation, or termination mechanism and the delay it introduces.

RFC 7009 distinguishes resource servers that can validate tokens locally from designs that consult revocation state. Immediate revocation of a locally validated token needs additional coordination; short-lived tokens are another way to limit residual validity. That limit assumes unauthorized refresh and new issuance have also stopped and that verifiers enforce expiry. Live checks have propagation and caching delays of their own. Test existing sessions separately and state the actual bound for each path.

Trace revocation along each path that can authorize a request. The following are useful examples, with test practices discussed in access revocation.

• A fresh login attempt, including alternate authentication routes.
• A live session already established at each application, which ends on its own clock.
• Direct calls with issued tokens, testing expiry or revocation enforcement and whether refresh or new issuance remains possible.
• Background jobs and pipelines, separating personal credentials to retire from service identities to retain under accountable ownership and reviewed grants.
• Cached authorization decisions and replicated permission data, whose staleness window is a configuration value somebody chose.
• Managed sharing links, whose future access may be removable through the sharing service. Microsoft Graph, for example, can delete non-inherited sharing permissions. Check other grants and cached responses too. Already downloaded copies and information a recipient has learned cannot be recalled merely by revoking the link.

Define an intended revocation window per path and compare it with observed denial after revocation, allowing for test coverage and timing uncertainty. Account status alone cannot establish that window. Where a path has not been measured, record the design assumptions and the missing evidence instead of reporting a verified bound.

The lifecycle, and who owns each trigger

Everything above is a stage in one sequence: identities are created, what they may do changes, credentials are maintained, and eventually all of it should end. The stages and their failure points are laid out in identity lifecycle; the architectural point here is where the triggers come from.

Lifecycle decisions draw on hiring records, team changes, contract dates, deployment definitions, and service-retirement events. RFC 7642 separates SCIM provisioning from authentication as functions; it does not require different products to perform them. Identify the authoritative source for each decision even when provisioning and authentication share a platform.

For each stage, record the event source, responsible owner, consumer, and evidence that the intended change was applied. Monitor failures and queue age, retry safely, and reconcile desired eligibility with actual accounts and grants so a missed event can be detected. Team changes need explicit removal decisions as well as additions; neither should depend only on someone remembering the old access.

A service identity can outlive the migration or person that created it. Record its accountable owner, purpose, review or expiry policy, and credential-access relationships. When the purpose ends, retire it; when the purpose continues, transfer ownership and reassess access. Missing ownership is a governance gap even if the current credential has expired, because issuance or reactivation may remain possible.

What tells you it works

Technology inventories show available mechanisms, not their effective coverage. Use evidence that connects subjects and permissions to operating behavior. The following questions provide a starting point; their answers depend on the completeness of the underlying records.

• For a named leaver, identify personal accounts, tokens, sessions, and access to service credentials. Separately identify service identities they created or owned, then record retirement or transfer decisions. Interviews can supplement system records; document gaps and verify that the leaver can no longer use retained identities.
• For one named sensitive resource, every subject that may modify it and why. The second half is what makes the first half reviewable.
• The measured revocation window per path, obtained by trying access after a revocation.
• Measure standing grants for human and non-human subjects and use inactivity as a review signal. Before removing a grant, check observation coverage, business cycles, ownership, recovery needs, and emergency use. AWS IAM’s last-access reports illustrate why the evidence needs interpretation: supported actions, tracking periods, reporting delay, and failed attempts affect what the report means. Remove unnecessary access or move it to controlled elevation once those conditions are understood.
• Whether the record supports reconstruction: for a given request, which identity, which grant, and which decision inputs. That is a property of the audit log being designed for the question, not of logging being enabled.

Each of these is also a reasonable exercise to run deliberately. Pick a leaver from three months ago and try to find everything that still authenticates as them. Pick your most sensitive table and produce the list of writers. The results tend to be more informative than a control inventory, because they are answers about reachability rather than about presence, which is the distinction that a threat model built around paths exists to keep visible.

The order that produces decisions

Identify the requesting subject in its context, then make its permitted actions reviewable and limit how long unused permission remains available. When identity, scope or eligibility changes, trace the update through every authorization path and verify the time within which it takes effect. Each decision needs evidence that the preceding one cannot supply.

In the opening scenario, the unresolved issue is the former contractor’s continuing ability to use credentials, not the mere fact that a useful pipeline still runs. Correcting it requires revoking personal access, ending access to old service credentials, and establishing ownership and reviewed permissions for the retained workload. Authentication, authorization, and lifecycle integration each contribute evidence; none substitutes for the others.

References

• NIST CSRC Glossary — identity
• NIST CSRC Glossary — least privilege
• NIST CSRC Glossary — role based access control
• NIST CSRC Glossary — attribute based access control
• NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (2025), Sections 2.2.3, 2.3.3, 3.2.5, 4.3, 4.5, and 5.
• RFC 7009, OAuth 2.0 Token Revocation (2013), Section 3.
• RFC 9700, Best Current Practice for OAuth 2.0 Security (2025), Section 2.3.
• RFC 7642, System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements (2015), Section 1.
• Kubernetes — Service Accounts
• Kubernetes — Using RBAC Authorization
• NIST — Role Based Access Control FAQs
• NIST SP 800-162 — Guide to ABAC
• Kubernetes — Admission Control
• AWS IAM — Last accessed information
• Microsoft Graph — Delete a sharing permission