AWS IAM Identity Center: SSO and Permission Sets Guide

AWS IAM Identity Center is the AWS service for giving your workforce single sign-on access to AWS accounts and applications using temporary credentials, and AWS recommends it for centralized access management instead of creating IAM users for people. If you manage more than one AWS account, it is the first service you should learn to configure well.

This guide explains what IAM Identity Center does, how permission sets work, how it compares to IAM users, and how to roll it out safely. It is written for beginners, sysadmins, and IT pros moving into cloud security.

What is AWS IAM Identity Center?

IAM Identity Center connects workforce users to AWS accounts and AWS managed applications. It was renamed from AWS Single Sign-On in July 2022, so you will still see "AWS SSO" in older tutorials and job postings.

Instead of creating a separate IAM user in every account, you:

1. Connect an identity source, such as your existing identity provider over SAML 2.0, or create users directly in IAM Identity Center.
2. Organize people into groups.
3. Assign those groups to AWS accounts with permission sets.
4. Let people sign in once through the AWS access portal and pick the account and role they need.

Behind the scenes, IAM Identity Center creates IAM roles in each assigned account. Users receive short-lived credentials when they sign in, not permanent passwords or access keys stored in each account.

Why AWS recommends it over IAM users for people

AWS best practices say human users should use federation with an identity provider and temporary credentials. For centralized access management, AWS recommends IAM Identity Center. You can read the full guidance in the AWS IAM security best practices documentation.

The security benefits are practical:

• No long-term keys for people. Access keys that live on laptops and in scripts are a common source of leaks. Temporary credentials expire on their own.
• One place to remove access. When someone leaves, you disable one identity instead of hunting through every account.
• Consistent MFA. You enforce strong sign-in once, at the identity source or in Identity Center, rather than per account.
• Less sprawl. Hundreds of IAM users across many accounts become a handful of groups and permission sets.

Organization instance vs account instance

IAM Identity Center can be deployed in two ways.

Feature	Organization instance	Account instance
Where it lives	Management account of AWS Organizations	A single AWS account
Manages access to AWS accounts	Yes	No
Permission sets	Available	Not available
Intended use	Production, workforce access across accounts	Isolated deployments of select AWS managed applications
AWS recommendation	The best practice for production use	Only for narrow, isolated cases

For anyone building a multi-account AWS environment, the organization instance is the one you want. If you are new to multi-account design, pair this with our guide on AWS SCPs vs RCPs for multi-account guardrails.

How permission sets work

A permission set is a template of permissions for a job function, such as read-only auditor, security analyst, or administrator. When you assign a permission set to a group in a given account, Identity Center creates a matching IAM role in that account.

A permission set can include:

• AWS managed policies, such as job function policies
• Customer managed policies that already exist in the target account
• Inline policies you write yourself
• A permissions boundary to cap the maximum permissions

Session duration

When you create a permission set, the session duration defaults to 1 hour. You can set it between 1 hour and 12 hours. Shorter sessions limit how long stolen credentials stay useful, so use longer sessions only where the work truly needs them.

Design permission sets around jobs, not people

A simple starting model looks like this:

Group	Permission set	Typical scope
CloudAdmins	Administrator access	Break-glass and platform team, few accounts
SecurityAnalysts	Security audit, read-only	All accounts, read access to logs and findings
Developers	Power user without IAM changes	Dev and test accounts only
Auditors	View-only access	Production, read only

This is least privilege in practice. If you want to go deeper on the concept, read Least Privilege in the Cloud: A Practical Guide and AWS IAM Security Best Practices.

A safe rollout plan

You do not need to migrate everything in one weekend. A controlled rollout works better.

1. Inventory current access. List IAM users, access keys, and roles across accounts. Note who actually uses them.
2. Enable the organization instance. Do this from the AWS Organizations management account, and keep that account's day-to-day use minimal.
3. Pick the identity source. If your company already has a directory or identity provider, connect it and sync users and groups. If not, create users directly in Identity Center.
4. Require MFA. AWS recommends phishing-resistant MFA such as passkeys and security keys wherever possible.
5. Create groups and permission sets. Start with three or four job-based sets, not twenty.
6. Assign to one pilot account first. Test sign-in, CLI access, and break-glass procedures before expanding.
7. Move people over, then remove old IAM users. Use IAM access last used information to confirm an old key or user is truly unused before deleting it.
8. Monitor. Send sign-in and API activity to your logging pipeline. Our overview of cloud logging and monitoring fundamentals covers what to capture.

Common mistakes to avoid

• Giving everyone administrator access because it is easy. Build real permission sets instead.
• Forgetting the root user. Identity Center does not remove the need to protect each account's root user with strong controls and MFA.
• Leaving long-lived access keys in place after migrating people to Identity Center. Old keys keep working until you remove them.
• Using an account instance for multi-account access. It cannot manage access to AWS accounts.
• Skipping break-glass planning. Decide in advance how you regain access if your identity provider is down.
• Assigning permissions to individual users instead of groups. Group-based assignment is easier to audit.

Why this matters for your cloud security career

Identity is the control plane of cloud security. Interviewers for cloud security roles regularly ask how you would design workforce access across many accounts, how you would remove standing credentials, and how you would audit who can reach production. Being able to explain IAM Identity Center, permission sets, and temporary credentials clearly is a real differentiator. It also appears throughout the identity and access domain of the AWS Certified Security - Specialty exam, so see our AWS Security Specialty exam guide when you plan your study.

At PrimeSec Academy, students build this exact pattern in a hands-on lab, document it, and defend it in their capstone. You can see how it fits the program on the curriculum page.

Frequently asked questions

Is AWS IAM Identity Center the same as AWS SSO?

Yes. AWS Single Sign-On was renamed AWS IAM Identity Center in July 2022. The service is the same lineage, so older articles using the AWS SSO name still describe the core idea.

Should I use IAM users or IAM Identity Center for employees?

AWS recommends that human users access AWS with temporary credentials through federation, and recommends IAM Identity Center for centralized access management. IAM users are best kept for rare cases that truly need them, and those should require MFA.

Does IAM Identity Center cost extra?

Check the current AWS pricing page for the latest details, since pricing and feature packaging can change. Do not assume costs from older blog posts.

What is a permission set?

A permission set is a reusable template of permissions for a job function. When you assign it to a user or group in an AWS account, IAM Identity Center creates a corresponding IAM role in that account.

How long do IAM Identity Center sessions last?

A new permission set defaults to a 1 hour session duration, and you can configure it from 1 hour up to 12 hours. Shorter sessions reduce the risk window if credentials are stolen.

Do I still need to secure the root user if I use IAM Identity Center?

Yes. Each AWS account still has a root user. Protect it with a strong unique password, MFA, and limited use, and follow the AWS root user best practices.

Ready to build this skill for real?

Reading about identity is useful, but employers hire people who have configured it. Explore the PrimeSec curriculum to see the labs and projects, or enroll today to start your 20-week path into cloud and AI platform security.