Lesson 264 · AWS Learning Path

AWS 264: Enterprise identity flow, break-glass access, and delegated administration

Anil Jalela · Published Mar 16, 2026 · 12 min read

Why this matters to an architect

Enterprise access is a chain, not a login page. HR and the identity provider establish the person and lifecycle; provisioning creates the cloud identity; groups/attributes and permission sets grant account access; STS creates a temporary role session; IAM, boundaries, Organizations controls, resource policies, and service state decide each request; logs must preserve accountable attribution.

Central identity also creates shared failure paths. An IdP, DNS, certificate, device policy, SCIM token, Identity Center Region, administrator mistake, or malicious group change can block everyone or grant too much. Normal access, temporary elevation, emergency access, root recovery, workload identity, and delegated service administration therefore need distinct owners and controls.

Outcomes

By the end, you can:

• trace a workforce request from authoritative identity to target API decision and evidence;
• separate authentication, provisioning, assignment, federation, session, and authorization;
• design job-based baseline access and just-in-time production elevation;
• govern joiners, movers, leavers, vendors, privileged admins, and active sessions;
• design emergency access for IdP, Identity Center, network, device, and policy failures;
• distinguish emergency roles/users, alternate SAML federation, and root-only recovery;
• separate trusted access, service-linked roles, delegated administrator, and IAM delegation;
• constrain Identity Center and service delegates by task/account/permission-set tags where supported;
• preserve source identity, session context, CloudTrail, IdP, SCIM, and approval evidence;
• test activation, containment, rotation, recovery, and decommissioning.

The complete human access path

HR/vendor system -> enterprise directory/IdP -> MFA/device/risk policy
-> SAML authentication -> Identity Center identity (SCIM provisioned)
-> group/attribute -> account assignment + permission set
-> provisioned AWSReservedSSO IAM role -> STS temporary session
-> IAM identity policy + boundary/session policy + SCP/RCP/resource policy
-> service action -> CloudTrail/service/IdP/session evidence

Ask a different question at every stage:

One successful portal screenshot proves none of the later stages.

Authentication and provisioning are separate

With an external IdP, SAML authenticates users; SCIM creates/updates/disables users, groups, and memberships in Identity Center. A person can authenticate successfully but be missing/mismatched in Identity Center, or be provisioned but unable to authenticate.

Protect the SCIM endpoint/token as a privileged credential. Rotate it, monitor expiry/use, restrict who can create bearer tokens, and test sync failure. If the external IdP is authoritative, restrict delegated administrators' Identity Store writes; direct group changes can become a privilege path or be overwritten by the next sync.

Define immutable identifier/NameID mapping, display-name changes, duplicate users, nested-group behavior, attribute normalization, deprovision latency, and reconciliation. Never use email/display name alone as durable identity proof.

Permission sets, assignments, and generated roles

A permission set can contain AWS-managed policies, references to customer-managed policies, an inline policy, a permissions-boundary reference, session duration, relay state, and tags. The referenced customer-managed policy and boundary must already exist with the expected name/path/content in every target account; Identity Center does not copy them.

An assignment links user/group, account, and permission set. Identity Center provisions an AWSReservedSSO_... IAM role. Assignment creation and successful role provisioning are separate asynchronous states. Do not manually edit generated roles; update and reprovision the permission set.

If the last assignment for a permission set is removed from an account, the generated role can be deleted and later recreated with a different suffix. Exact role ARNs in KMS, EKS, or resource policies can become stale. Use AWS-documented patterns where supported and maintain an independently created recovery role for critical recovery - never weaken resource policies broadly.

Effective access remains an intersection of the permission-set role, boundary/session policy, SCP/RCP, resource/key/endpoint policy, session context, and service state. AdministratorAccess in a permission set does not bypass Organizations or resource-side denies.

Standard access and temporary elevation

Prefer group-based job functions for ordinary member accounts:

• developer read/write only in owned non-production accounts;
• production read-only troubleshooting;
• security finding investigation without log/key deletion;
• network, backup, billing, audit, and platform roles with bounded scope;
• separate deployment/workload identities, never human credentials in automation.

High privilege uses a distinct permission set, short session, MFA/device/risk conditions at the IdP, justification, approver separate from requester, start/expiry, case/source context, alert, and post-use review. Where native just-in-time workflow is unavailable, automate assignment creation/provision polling/removal/reconciliation rather than leaving permanent admin groups.

Prevent self-escalation: the approver or Identity Center administrator must not be able to alter the IdP group, permission set, boundary, SCP, account scope, logging, and approval record alone. Separate identity administration, cloud entitlement administration, and workload/resource administration.

Management-account access

The Organizations management account is uniquely powerful: its principals are not constrained by SCPs, it controls organization policy/integrations, and it owns consolidated billing. Keep workloads and routine service operation elsewhere.

Use dedicated management-account permission sets. AWS recommends direct user assignment rather than ordinary group assignment because anyone who can modify a privileged IdP group could grant management-account access. If groups are exceptionally used, tightly govern and independently alert on membership. Identity Center's delegated administrator cannot modify permission sets provisioned to the management account or enable/disable access there; those remain management-account operations.

Keep access rare, temporary where possible, and monitored. Preserve at least two independently recoverable authorized operators and prevent the only rollback path from depending on the control it must repair.

Joiner, mover, leaver, and vendor lifecycle

Joiner

Verify HR/vendor sponsor, identity proof, MFA/device enrollment, groups/attributes, SCIM result, assignment/provisioning, least-privilege test, prohibited-path denial, training, and expiry for temporary roles.

Mover

Remove old access before or together with new access. Reconcile direct assignments, nested groups, ABAC attributes, applications, CLI profiles, active elevation, service accounts mistakenly owned by the person, and resource-policy grants. Test old denied/new allowed paths.

Leaver or compromise

Disable at the authoritative source and IdP; remove group/direct assignments and active elevation; disable supported portal/application sessions; investigate active role credentials, API keys, SSH/certificates/tokens, code signing, secrets, delegated approvals, and changed resources. Existing STS role sessions can remain valid until expiry unless the relevant revoke mechanism/policy containment applies. Short privileged session duration reduces exposure.

Vendors require sponsor, contract/end date, named identities, phishing-resistant MFA, managed device/network conditions where appropriate, narrow accounts/roles, no shared login, monitored sessions, and automatic expiry with sponsor review.

Session clocks and revocation reality

Different sessions expire independently: IdP browser session, Identity Center portal session, application session, and AWS account role session (permission-set duration, commonly 1–12 hours). Ending a portal/IdP session does not necessarily terminate credentials already issued for an IAM role session.

Incident containment options include removing future assignment, disabling the source user, revoking supported Identity Center sessions, applying a targeted explicit deny/SCP where safe, changing a role/policy trust path, revoking permissions issued before a time where supported, disabling keys, and isolating resources. Choose based on actual credential type and blast radius. Validate from CloudTrail/session evidence rather than assuming “user disabled” equals “all access ended.”

Emergency access is not root access

Emergency/break-glass access is a deliberately independent administrative path for defined failure/incident scenarios. Root is the account's ultimate identity for root-only tasks and account recovery. Root is not the normal emergency administrator.

Threat-model failures:

One design does not survive every failure. For a third-party IdP, AWS documents alternate direct SAML federation to emergency IAM roles as one pattern when IAM data plane and IdP remain available but Identity Center is unavailable. If the IdP itself fails, use a small independently authenticated IAM recovery path where justified. Protect with unique vaulted credentials, phishing-resistant hardware MFA, no access keys unless a separately justified CLI recovery need exists, dual custody/approval, out-of-band contacts, and immediate alarms.

Root credentials use unique email/phone recovery, strong unique password where retained, multiple independently held MFA devices, no access keys, account alternate contacts, tested recovery, and sealed custody. Centralized root access capabilities for member accounts must be governed separately; management-account root remains especially protected.

Break-glass activation and closure

1. Declare an allowed emergency and incident commander.
2. Verify normal path is unavailable/unsafe and choose the least-powerful independent route.
3. Obtain dual authorization when time/risk permits; record case and intended actions.
4. Retrieve credential/MFA components from separate custodians; verify account/role.
5. Alert security automatically on authentication and every action.
6. Use a dedicated short session; capture CloudTrail/source IP/device/time and command/change record.
7. Repair/contain, test normal access and rollback, then stop emergency use.
8. Remove temporary grants, sign out/revoke what is revocable, rotate password/keys/token, reseal MFA/custody.
9. Reconcile actions/resources, conduct independent review, update runbook, and retain evidence.

Test quarterly and after identity/policy architecture changes. A test must authenticate, reach a harmless approved action, prove forbidden actions, generate alarms, measure time, and rotate/reseal - not merely confirm a password exists.

Delegated administration is service-specific

Do not confuse:

• trusted access: permits an AWS service to work with Organizations and create/use service-linked roles;
• service-linked role: IAM role owned by a service for defined actions;
• delegated administrator: member account registered to administer supported organization-wide service capabilities;
• IAM role delegation: ordinary principal permissions/trust within or across accounts;
• RAM sharing: resource access, not service administration.

Each service defines number of delegates, Regions, operations, auto-enrollment, member behavior, and management-account-only tasks. Inventory the service principal, delegate account, registration Region, service-linked roles, member/coverage state, data access, billing, logging, and deregistration effects. Never infer GuardDuty behavior from CloudTrail, Backup, License Manager, Security Hub, or Identity Center.

Place delegates by function in Security Tooling, Network, Identity, Backup, or other dedicated accounts when separation adds value. Too many delegate accounts increase privileged paths; one universal security account concentrates compromise. Use a RACI and threat model.

Identity Center delegated administration

The organization instance remains in the management account, but one member account can be registered as Identity Center delegate. It can perform most identity/application/permission-set/assignment administration, but cannot enable/delete Identity Center, register a delegate, manage permission sets provisioned in the management account, or enable/disable management-account access.

Constrain delegated administrators with distinct admin permission sets:

• identity-source/MFA/SCIM token administration;
• permission-set authoring by approved resource tags;
• account assignment for an approved account list and permission-set tags;
• application administration;
• read/audit;
• emergency disable without broad grant authority.

Protect the delegated-admin account itself from self-assignment. Restrict CreateBearerToken except approved rotation windows. Reconcile permission-set tags and account lists; ARNs are case-sensitive.

Evidence and attribution

Create a UTC timeline from HR/vendor, IdP sign-in/risk/MFA, SCIM provisioning, Identity Center/Identity Store admin events, assignment/provision status, STS/role session, CloudTrail target actions, service data events, approval system, and emergency vault alarms.

CloudTrail target events show assumed-role session issuer/access-key context; the original AssumeRole/federation event and IdP evidence establish the human. Session names may be caller-controlled. Use source identity/session tags where the path supports and protects them, but do not claim CloudTrail proves MFA unless the exact event/path carries reliable MFA evidence.

Monitor privileged group/attribute changes, direct assignments, permission-set/policy/boundary edits, reprovision failures, SCIM tokens/sync failures, identity-source/MFA/session changes, delegated-admin/trusted-access changes, management-account/root/emergency sign-in, logging changes, and emergency actions. Reconcile periodically because event alerts are not a complete state inventory.

Read-only evidence audit

Redact identity-store IDs, names/emails, account/role/permission-set ARNs, group membership, source IP/device, service delegates, and event details:

aws sso-admin list-instances
aws sso-admin list-permission-sets --instance-arn replace-with-instance-arn
aws sso-admin list-account-assignments --instance-arn replace-with-instance \
  --account-id replace-with-account --permission-set-arn replace-with-permission-set
aws organizations list-delegated-administrators
aws organizations list-delegated-services-for-account \
  --account-id replace-with-delegated-account
aws organizations list-aws-service-access-for-organization
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole --max-results 20

Follow pagination and inspect provisioning status, target IAM role/policies, IdP/SCIM logs, and target service events securely. These commands alone do not prove effective access or emergency readiness.

Troubleshooting matrix

Cost, quotas, and lifecycle

Identity Center itself may have no separate workforce-access charge, but IdP/directory licensing, MFA hardware, privileged-access workflow, CloudTrail/data events, SIEM, Config, support, staff, and emergency testing cost money. Delegated services retain their own charges. Track assignment/permission-set/API quotas and provisioning throughput.

Before changing identity source, SCIM, delegate account, permission sets, emergency roles, directory, or management access, inventory dependencies and active sessions; canary; preserve independent rollback; and test allowed/denied/recovery paths. Decommission only after assignments, generated-role resource policies, application access, vendors, credentials/tokens, emergency copies, service delegation, logs, and retention are reconciled.

Practical lab

Download the AWS264 enterprise identity and emergency access pack. It contains an identity/session matrix, delegated-administration register, break-glass runbook/game day, lifecycle reconciliation, eight failure cases, and answer directions.

Design access for administrator, security analyst, developer, vendor, automation, and emergency operator. Submit normal/elevated/emergency flows; management-account treatment; Identity Center delegate controls; five service delegates; session/revocation evidence; joiner/mover/leaver; root recovery; monitoring/cost; and game-day results.

Knowledge check

1. Which stages separate authentication from an authorized API request?
2. Why can SAML succeed while SCIM/portal access fails?
3. What must exist before referenced customer-managed policies/boundaries provision?
4. Why can generated-role suffixes break recovery policies?
5. How do baseline access and temporary elevation differ?
6. Why are management-account group assignments unusually risky?
7. Why can a leaver retain an active role session?
8. How do emergency access and root differ?
9. Which failed dependencies must each emergency path avoid?
10. What makes a break-glass test complete?
11. How do trusted access, service-linked roles, delegates, and IAM roles differ?
12. What remains management-account-only for Identity Center?
13. Why must session attribution combine IdP, federation, and target evidence?
14. What must be reconciled before changing identity source or delegate?

Lesson acceptance

Pass requires complete identity-to-API flow; protocol/session/policy boundaries; role provisioning/suffix handling; baseline/elevation separation; management-account controls; joiner/mover/leaver/vendor lifecycle; threat-matched independent emergency and root recovery; activation/rotation game day; service-specific delegation RACI; constrained Identity Center delegate; attribution/monitoring; eight diagnoses; cost/quotas; and reversible lifecycle plan.

Official sources

• IAM Identity Center workforce architecture
• SAML and SCIM federation
• Permission sets
• Identity Center delegated administration
• Delegate permission-set administration
• Configure AWS account access
• Organizations trusted access
• Organizations delegated administrators
• Root user best practices
• IAM federation