Just-in-time admin access closes one of the most common — and most avoidable — gaps in AWS security. Here's what TEAM is, and a full walkthrough of implementing it.
Most AWS environments accumulate standing (always-on) administrative access over time — IAM users and roles with broad, permanent permissions that are used rarely but remain active every day. This is consistently one of the highest-impact findings in security reviews: it expands blast radius, complicates audit, and creates risk that is disproportionate to the actual business need, since genuine admin activity is usually infrequent and time-bound.
AWS TEAM (Temporary Elevated Access Management) is an open-source solution, built by AWS, that replaces standing privileged access with a request-approve-time-bound-revoke workflow, layered directly on top of IAM Identity Center — the AWS-native service most organizations already use for workforce access. Engineers request elevated access to a specific account and permission set, for a specific reason, for a limited time. An approver signs off. Access is granted only for the approved window, then automatically revoked. Every step is logged.
This isn't a new access-control model bolted on top of AWS — it's a workflow layer that uses IAM Identity Center's existing account assignment mechanism, meaning it fits into environments that already use Identity Center for SSO without requiring a parallel identity or permissions system. It's self-hosted (deployed into your own AWS account via CloudFormation/Amplify), free to use, and built on serverless components, so the ongoing cost is typically low.
Every permanent administrative credential is a standing liability, whether or not it's ever misused. It's a target for compromise, a variable in every access review, and a permanent expansion of blast radius that has to be accounted for in every security control you build afterwards — MFA policy, session monitoring, conditional access, the lot.
The uncomfortable truth in most environments is that genuine need for elevated access is infrequent: a production incident, a one-off migration task, a quarterly access review. Yet the access itself is almost always provisioned as permanent, because time-bound access has historically been operationally painful to implement — someone has to remember to grant it, remember to revoke it, and keep a record of why it was needed.
AWS TEAM exists specifically to remove that operational friction, so that the default posture can shift from "always on, just in case" to "granted on request, for a reason, for a limited time."
TEAM is an open-source reference solution published by AWS that layers a request-and-approval workflow on top of IAM Identity Center's native account assignment capability. Rather than provisioning a permanent permission set assignment, TEAM provisions it temporarily — for exactly as long as an approved request is active — and removes it automatically when the window closes or the requester ends the session early.
The solution's full documentation — architecture diagrams, configuration reference, and FAQs — is maintained at aws-samples.github.io/iam-identity-center-team, and is worth keeping bookmarked alongside this guide as the authoritative source when the solution changes.
It's designed around four personas, each with a distinct view of the same system:
| Persona | Role in the workflow |
|---|---|
| Requester | Requests elevated access to a specific account and permission set, with a business justification and a requested duration |
| Approver | Reviews pending requests against eligibility policy and approves or rejects them |
| Auditor | Has read-only visibility into all requests, approvals, and session activity for compliance and review purposes |
| Admin | Configures eligibility policies, approval policies, and manages the TEAM deployment itself |
Key capabilities:
TEAM deploys as a standalone web application (via AWS Amplify) into a dedicated delegated administrator account for IAM Identity Center — deliberately separate from your IAM Identity Center management account, so the TEAM application itself never has standing access to your identity source. It authenticates users via SAML against IAM Identity Center, and drives temporary account assignments through the IAM Identity Center APIs.
At a high level, the day-to-day workflow looks like this:
Before starting deployment, make sure the following are in place:
git-remote-codecommit, Node.js, and jq installed, plus an AWS CLI named profile with administrator access to the delegated admin account.aws-samples GitHub organization), not an official AWS service with SLAs or support. Treat it the way you would any self-hosted open-source security tooling: review the code, test thoroughly in a non-production organization first, and assign clear ownership for keeping it patched and maintained. The official documentation site is the best place to confirm current prerequisites and deployment steps before you start, since this guide reflects a point-in-time snapshot.
The following walks through a first deployment end-to-end, based on the current AWS TEAM deployment process.
In your IAM Identity Center management account, register the dedicated account you've set aside as a delegated administrator for IAM Identity Center. This lets TEAM manage account assignments without needing management-account-level access itself.
# From the management account
aws organizations register-delegated-administrator \
--account-id <TEAM_ACCOUNT_ID> \
--service-principal sso.amazonaws.com
From your development environment, authenticated against the delegated admin account:
git clone https://github.com/aws-samples/iam-identity-center-team.git cd iam-identity-center-team
Edit parameters.sh to set the values for your environment — at minimum, your AWS CLI profile name, target region, IAM Identity Center instance ARN, identity store ID, and the TEAM administrator/auditor group IDs created during prerequisites.
| Parameter | Purpose |
|---|---|
PROFILE | Named AWS CLI profile for the delegated admin account |
REGION | AWS Region for deployment |
IDC_INSTANCE_ARN | ARN of your IAM Identity Center instance |
IDENTITY_STORE_ID | Identity store ID backing IAM Identity Center |
ADMIN_GROUP_ID / AUDITOR_GROUP_ID | Group IDs for the TEAM administrator and auditor groups |
This provisions the foundational resources TEAM needs before the main deployment — including a CodeCommit repository that the Amplify app will build from.
chmod +x init.sh deploy.sh ./init.sh
This is the main deployment step — it provisions the Amplify application, AppSync API, Cognito user pool, DynamoDB tables, and the Lambda functions that drive the workflow engine. Expect this to take around 20 minutes.
./deploy.sh
Once complete, the script outputs the Amplify app URL — this is the web interface your users will access TEAM through.
TEAM authenticates users via a SAML 2.0 connection to IAM Identity Center, configured as a custom SAML application. Run the integration helper script to retrieve the values you'll need:
./integration.sh
This outputs the Application Start URL, ACS URL, and SAML Audience. In the IAM Identity Center console, create a new custom SAML 2.0 application, enter these values, configure attribute mapping (mapping the subject to each user's email or username), download the IdC-provided SAML metadata, and assign the users or groups who should have access to TEAM.
Back in your deployment environment, populate details.json with the SAML metadata URL from the IAM Identity Center application you just created, then run:
./cognito.sh
This wires the Cognito user pool (which fronts the Amplify app) to trust SAML assertions from IAM Identity Center, completing the authentication chain: user → IAM Identity Center → SAML → Cognito → TEAM application.
Sign in to the TEAM application as an Admin (using an account in your TEAM administrators group) and configure:
Start narrow — a small number of well-understood eligibilities (e.g. a specific ops team, a specific account, a capped duration) — and expand coverage once the workflow is proven.
Before rolling out broadly, walk through the full cycle yourself: submit a request as a test Requester, approve it as a test Approver, confirm the account assignment appears in the AWS access portal, use it briefly, end the session, and confirm the assignment is removed and the activity appears in CloudTrail Lake.
TEAM is free and open source — there's no licensing cost — but it provisions billable AWS resources. Since almost everything is serverless (Amplify, AppSync, Lambda, DynamoDB, Cognito), cost scales with usage and is typically modest for most organizations. The main cost variable to plan for is the CloudTrail Lake event data store, since ingestion and storage costs scale with event volume across the accounts in scope — it's worth right-sizing retention and event selectors deliberately rather than capturing everything by default. Run the components through the AWS Pricing Calculator against your expected usage before rolling out broadly.
Standing privileged access is a persistent, quietly compounding risk in most AWS environments — not because anyone decided it should be that way, but because time-bound access has historically been more operationally painful than leaving things permanently open. AWS TEAM removes that friction by layering a proper request-approve-expire workflow directly on IAM Identity Center, so temporary access becomes the easy default rather than the exception that never gets built.
It's not a large lift to deploy — a working first version can be up in well under a day — but the eligibility and approval policy design deserves real thought, since that's what determines whether the workflow actually earns trust from the teams using it. Start with a narrow, well-understood use case, prove the end-to-end flow, and expand from there.