IAM Identity Center architecture for SOC 2 is the human-access half of a SOC 2-ready AWS org. Identity Center (successor to AWS SSO) federates your IdP, issues short-lived roles via permission sets, and gives you one assignment API to review. Standing IAM users for engineers are the anti-pattern.
This is infrastructure with a compliance audience — the same bridge as SOC 2-ready AWS architecture. We do not claim a SOC 2 attestation. We claim an access path auditors can understand.
Default Design We Deploy
- IdP as source of truth (Okta / Entra / Google Workspace — whoever you already run). SCIM provisions users/groups into Identity Center.
- No IAM users for humans except a documented break-glass, hardware MFA, offline password.
- Permission sets named by job, not by person.
prod-readonly,prod-poweruser,billing,break-glass-org. - Account assignments via groups, not 200 direct user assignments.
- Session duration short on prod write; longer on read-only sandbox if you must.
- Permission boundaries on poweruser sets so a policy edit cannot grant
iam:*.
AWS documents Identity Center in the IAM Identity Center user guide. The SOC 2 translation is CC6: unique IDs, authorized access, removal via SCIM when HRIS disables the IdP user.
JML still needs custom fan-out for systems outside SCIM — deprovisioning automation. Identity Center only covers AWS human access.
SCPs That Make the Architecture Hold
Identity Center without SCPs is a suggestion. We add:
- Deny
iam:CreateUser/CreateAccessKeyin member accounts except break-glass - Deny disabling CloudTrail / Identity Center in member accounts
- Region allowlists if your system description named regions
Same family as Organizations SCP least privilege.
Break-Glass Without Lying
Break-glass is a permission set with:
- Dual control (ticket + second approver) or a monitored assume
- CloudTrail alarm on use
- Recertification monthly (Identity Center access reviews)
A break-glass IAM user with a password in a wiki is not an architecture. It is the finding.
Discuss SOC 2-oriented AWS access architecture → rutagon.com/contact · 907-841-8407 · contact@rutagon.com.
Permission Set Catalog We Refuse to Skip
A landing zone that ships AdministratorAccess as the only permission set is not SOC 2 architecture. We require a written catalog: name, managed vs customer policy, boundary, session duration, and which accounts may receive it. prod-poweruser is not allowed in the log-archive account. break-glass-org is not assigned via a 200-person IdP group.
SCIM group names should match the catalog (aws-prod-readonly), not Everyone. When HRIS adds a contractor to Everyone, Identity Center should not grant prod write. That mapping is an engineering artifact in Terraform or the Identity Center API — not a wiki.
CLI and Console Are the Same Control
Engineers using aws sso login still assume the same permission sets as the console. We do not allow a parallel IAM user "for CLI." Session tags (Department, Jira) help incident review. Long CLI sessions on prod write get the same monthly recertification as console admins.
Control Tower Account Factory can create accounts faster than the catalog updates. A new sandbox that inherits an org-wide Admin assignment is a regression. We test: create a throwaway account, confirm it receives only sandbox sets, then delete. That test is evidence.
Remote delivery from Alaska does not change IAM. It does mean the IdP and Identity Center must be operable without a DC-based IAM team: documented break-glass, documented SCIM owner, documented review campaign.
IAM Identity Center architecture choices that survive CC6 sampling
IAM Identity Center architecture is only as strong as the permission-set catalog. We keep that catalog in git: name, AWS managed vs customer policy, permissions boundary, session duration, and the account OU that may receive it. AdministratorAccess is not a permission set we assign to a 40-person engineering IdP group. It is break-glass, recertified monthly, with a ticket on every use.
AWS documents the service in the IAM Identity Center user guide. The SOC 2 translation is unique identification, authorized access, and removal when the IdP user is disabled. SCIM lag is a measured SLO (we alarm if disable in Okta has not removed the Identity Center user within N minutes). “SCIM is on” is not evidence. The timestamp join is.
Account Factory / Control Tower can vend accounts faster than the catalog. We test with a throwaway account: it must receive only sandbox permission sets. If it inherits org-wide admin, that is a pipeline bug, not a training issue. CLI aws sso login uses the same permission sets as the console. A leftover IAM user “for the CLI” is a parallel access path we inventory and kill.
Session duration on prod-write sets is short (1–4 hours). Long sessions are how a laptop theft becomes a quiet admin window. We would rather engineers re-auth than pretend an 12-hour session is “usability.”
Frequently Asked Questions
Is Identity Center required for SOC 2?
No specific AWS product is required. Unique, authorized, removable access is. Identity Center is the AWS-native way to get there without IAM users.
Can we keep IAM users for CI?
CI should be OIDC roles, not users. See replace access keys with OIDC. Identity Center is for humans.
What if our IdP cannot SCIM to Identity Center?
Manual user sync is a control gap. Either enable SCIM, or accept a documented reconciliation job with timestamps. Do not pretend a quarterly CSV is SCIM.
Does this replace Privileged Access Management products?
For AWS console/CLI human access, permission sets + short sessions + review often suffice at 50–500 employees. If you need JIT for everything including SaaS, that is a broader program. We still build the AWS piece.
How does this relate to Control Tower?
Control Tower can deploy Identity Center in the landing zone. Guardrails must still match your permission-set model. Default landing zones are a start, not a SOC 2 narrative.