Identity, Access, and User Lifecycle

Identity and access are among the clearest customer-owned parts of the shared responsibility model. Providers supply IAM systems, sign-in services, policy engines, and role primitives. Customers decide who gets accounts, which roles exist, when multi-factor authentication is required, how privileged access is limited, and when access should be removed. The tooling may be provider-native. The governance is still customer-owned.

This is where many teams make a category mistake. They see that the provider offers an authentication platform and conclude that identity security has largely shifted outward. In reality, the most consequential identity decisions remain local to the customer:

• which identities exist
• which permissions they receive
• which administrators are highly privileged
• which exceptions are allowed
• which accounts are stale and should be removed

The identity lifecycle is almost entirely customer-directed:

    flowchart LR
	    A["Customer joins or changes role"] --> B["Customer provisions account and assigns role"]
	    B --> C["Provider IAM system enforces configured policy"]
	    C --> D["Customer reviews, updates, or removes access later"]

What to notice:

• the provider enforces the policy engine
• the customer decides the policy content and lifecycle actions
• stale or excessive access is usually a customer governance failure, not a provider platform failure

What Customer IAM Responsibility Covers

In practice, customer IAM responsibility often includes:

• account provisioning and deprovisioning
• group and role design
• privileged access scope
• MFA and sign-in policy
• access review cadence
• service identity and workload permission design

These responsibilities stay with the customer across IaaS, PaaS, SaaS, and serverless. The exact control surface changes, but the underlying governance work does not.

A Practical IAM Map

 1control_family: admin-access-governance
 2
 3customer_owned:
 4  - onboarding-and-offboarding
 5  - role-design
 6  - mfa-required-for-admins
 7  - quarterly-access-reviews
 8  - break-glass-account-policy
 9
10provider_owned:
11  - iam-service-availability
12  - policy-engine-runtime
13  - sign-in-platform-operations

What this demonstrates:

• the provider operates the IAM mechanism
• the customer governs how that mechanism is used
• access failures usually emerge from customer policy and review gaps

Why Provider IAM Tooling Can Be Misleading

Provider IAM tooling is often polished and powerful. That is helpful, but it can create a false impression that identity governance is “built in.” Tooling cannot decide your organization’s role model, review cadence, separation of duties, or deprovisioning discipline. If those are weak, the identity platform will faithfully enforce weak policy.

Common Mistakes

• assuming provider IAM features remove the need for role engineering
• letting privileged access grow through exceptions without review
• focusing on authentication strength while underinvesting in authorization hygiene
• forgetting that non-human identities also need lifecycle governance

Design Review Question

A company uses provider-native single sign-on and MFA and says identity responsibility is now mostly with the provider. The company still defines admin roles, approves exceptions, provisions service identities, and decides when access is removed. Is that a strong interpretation?

No. The stronger answer is that the provider operates the identity platform, but the customer still owns the core governance decisions that determine whether the identity system is safe or dangerous in practice.

Check Your Understanding