Answer: Use federated identities and temporary credentials, but also remove the permanent entitlement to administrative roles. Grant a task-specific permission set only after approval, remove the assignment when the approved window ends, and separately control any role sessions already issued. Short-lived credentials alone do not eliminate standing admin access. AWS supports temporary elevated-access integrations alongside IAM Identity Center permission sets and MFA. (docs.aws.amazon.com)
This guide covers human maintenance access through an AWS IAM Identity Center organization instance and permission sets. It does not cover workload identities or every alternative AWS access model. Permission sets require an organization instance; account instances are not interchangeable for this workflow. (docs.aws.amazon.com)
The workflow and commands below are illustrative, not a tested deployment. Validate them in a sandbox before changing production access.
1. Separate temporary credentials from temporary entitlement
Two different controls are needed:
| Control | Question it answers | Operational check |
|---|---|---|
| Temporary credentials | How long can this issued session operate? | Check the permission-set session duration and test expiry. |
| Temporary entitlement | When may this person obtain an administrative session? | Check assignment creation, removal and renewal prevention. |
AWS recommends federation and temporary credentials for human users. However, an operator who remains assigned to an administrative permission set can continue obtaining sessions. The AWS CLI can automatically refresh temporary credentials while the relevant access and sign-in session remain available. (docs.aws.amazon.com)
Therefore, replace permanent broad assignments—not merely permanent access keys.
Keep everyday diagnostic access separate from maintenance access. Make elevation a deliberate transition with a named task, accountable approver and recorded end condition. AWS describes temporary elevated access as requesting, approving and tracking permission for a specific task during a specified time. (docs.aws.amazon.com)
Before implementation, choose your intended guarantee:
- Bounded residual access: assignments end on schedule, but existing role sessions may remain usable until expiry.
- Hard maintenance cutoff: the workflow also denies actions from already-issued sessions.
Do not describe the first model as the second.
2. Establish federation and protect the access-control path
Use a named workforce identity rather than a shared administrative login. AWS recommends IAM Identity Center for centralized human access management and supports identities managed there or through an external identity provider. (docs.aws.amazon.com)
For this design, require MFA at the appropriate authentication layer. Verify that the policy actually applies to maintenance operators; a documented MFA requirement is not evidence that the relevant sign-in path enforces it.
Separate responsibilities:
- Operators request access and perform approved maintenance.
- Approvers assess necessity, scope and timing.
- Access administrators or automation apply and remove assignments.
- Security responders use the prepared revocation procedure.
Do not let a maintenance permission set manage its own assignments, alter its own permissions or modify the approval system.
As a readiness check, ask an operator to demonstrate the complete path from sign-in to the target account. Record the intended identity, account, permission set and authentication requirement without collecting passwords, tokens or MFA recovery material.
3. Build roles around maintenance tasks, not job titles
Start with an operational verb and target: “reboot the approved EC2 instance,” not “perform cloud administration.”
AWS recommends choosing the least-privileged permission set capable of completing the task and testing it before granting access. Permission sets define account permissions and produce corresponding IAM roles. (docs.aws.amazon.com)
For each maintenance permission set, document:
- Allowed actions and resources.
- Necessary read operations.
- Explicitly excluded activities.
- Session duration.
- Required validation and recovery steps.
An illustrative MaintenanceReboot permission set should not automatically include instance termination, IAM administration or unrestricted role assumption. Review the actual policy rather than assuming its name proves its scope.
IAM Identity Center permission-set sessions have a one-hour minimum and a twelve-hour maximum. Choose the shortest supported duration that fits the task, and check successful provisioning to the affected accounts after changes. (docs.aws.amazon.com)
Also inspect resource policies before adopting assignment-based elevation. Removing every assignment for a permission set in an account deletes its generated role. A later assignment creates a role with a different suffix and ARN, potentially breaking references such as KMS key policies or legacy EKS access mappings. (docs.aws.amazon.com)
Resolve those dependencies deliberately; do not leave ordinary operators permanently elevated simply to preserve an ARN.
4. Make approval expiry enforceable
Treat the approval workflow as a system with failure handling, not a ticket reminder.
AWS documents temporary elevated-access integrations, but a permission set and its session-duration setting are not, by themselves, a complete approval-and-expiry workflow. (docs.aws.amazon.com)
Use this implementation sequence:
- Request: capture the task, target account, resources, permission set, requested window and recovery plan.
- Approve: require a separate authorized approver for sensitive maintenance.
- Grant: apply the approved assignment and verify that provisioning completed.
- Validate: confirm identity and permissions before any change.
- Expire: remove the assignment or temporary group membership automatically.
- Reconcile: independently check for grants that survived their deadline.
- Close: record cleanup status, session handling and maintenance results.
Keep the approval record separate from the effective-access record. An approved request can fail to provision; an expired request can fail to clean up.
Illustrative timing example: a thirty-minute approval combined with a one-hour permission-set session does not imply a thirty-minute access limit. A session obtained near the end of the approval window can outlast it. Assignment removal prevents new sessions, but existing role sessions operate independently until expiry unless separately denied. (docs.aws.amazon.com)
If the deadline must stop all maintenance actions, design and test active-session denial as part of expiry.
5. Test an illustrative EC2 maintenance grant
Assume an authorized sandbox operator needs to reboot one designated EC2 instance. The access administrator has prepared the scoped permission set, and the operator has AWS CLI v2 installed.
Configure and sign in to a dedicated profile:
aws configure sso --profile maintenance
aws sso login --profile maintenance
aws sts get-caller-identity --profile maintenance
The AWS CLI supports IAM Identity Center profile configuration and browser-based sign-in. get-caller-identity returns the identity behind the credentials used for the request. (docs.aws.amazon.com)
Check the returned account and role against the approval. Keep those identifiers in restricted operational records rather than public examples.
Then test the approved reboot permission without rebooting anything. Replace the placeholders with an authorized sandbox instance and its Region:
aws ec2 reboot-instances \
--profile maintenance \
--region "<approved-region>" \
--instance-ids "<approved-instance-id>" \
--dry-run
Interpret the response:
DryRunOperation: AWS reports that the required permission is present.UnauthorizedOperation: AWS reports that the required permission is absent.- Other errors: investigate credentials, parameters or connectivity; do not count them as successful authorization tests.
These are documented EC2 dry-run responses. The test does not request the actual reboot. (docs.aws.amazon.com)
Run the same dry-run against a second, explicitly authorized sandbox instance outside the grant’s resource scope. Expect UnauthorizedOperation. If it returns DryRunOperation, stop and review the policy.
Only proceed with the approved maintenance after both checks pass. A real reboot request is asynchronous and can result in a hard reboot if the instance does not shut down cleanly; authorization testing is not a substitute for workload readiness or recovery planning. (docs.aws.amazon.com)
6. Test expiry and prepare active-session revocation
Test assignment expiry and credential expiry separately.
After the grant ends, attempt to obtain a fresh maintenance session. Confirm that no overlapping direct assignment or group membership still provides access. For externally managed groups, account for synchronization: AWS states that changes take effect after the identity provider’s update reaches IAM Identity Center. (docs.aws.amazon.com)
For credential expiry, use a controlled sandbox test with a fixed credential set that cannot automatically refresh. Keep credentials local and protected. After its recorded expiration, repeat the authorization probe. A refreshing CLI profile is not proof that the original credentials remained valid. (docs.aws.amazon.com)
For emergency revocation, prepare AWS’s user-specific deny mechanism in advance. Its documented approach matches identitystore:userId, commonly through an SCP attached to relevant member accounts. AWS also documents permission-set policy alternatives. (docs.aws.amazon.com)
Important boundaries:
- SCPs do not restrict the organization management account. Prepare a separate applicable control there. (docs.aws.amazon.com)
- Do not directly edit permission-set-generated roles in IAM. AWS directs their revocation through the IAM Identity Center procedure. Ordinary IAM role revocation is a different mechanism and affects all qualifying sessions of that role. (docs.aws.amazon.com)
- Follow the full containment sequence. AWS’s procedure includes denying actions, removing assignments, handling identity-source access and ending portal sessions. It requires keeping the deny in place for at least twelve hours. (docs.aws.amazon.com)
Validate denial with a permission-dependent operation such as the EC2 dry-run. get-caller-identity is unsuitable as a denial test: AWS says it requires no permissions and can still return identity information despite an explicit deny. (docs.aws.amazon.com)
7. Connect approvals to audit evidence and common failure checks
Keep a restricted evidence record containing the requester, approver, task, target scope, grant deadline, assignment events, permission-test results and cleanup outcome.
CloudTrail can support investigation of IAM Identity Center access and configuration activity. For Identity Center-emitted user events, AWS recommends identifying users with userId and identityStoreArn; these can appear under userIdentity.onBehalfOf. (docs.aws.amazon.com)
Do not assume every service event has an identical identity structure. Validate correlation using representative sign-in, assignment and target-service records before relying on an audit query.
Use these review checks:
| Common mistake | Practical check |
|---|---|
| A short session masks permanent admin entitlement | Inventory direct assignments and group-derived access. |
| Signing out is treated as revocation | Repeat a permission-dependent probe from an existing role session; sign-out does not end it immediately. |
| Every task uses a broad administrator role | Require task-specific positive and negative permission tests. |
| Cleanup failure is silently ignored | Alert on overdue grants and reconcile them independently. |
| Evidence contains credentials | Retain necessary identifiers and outcomes, never credential values. |
AWS documents that signing out ends the portal session but existing IAM role sessions continue until their configured expiry. (docs.aws.amazon.com)
8. Drill break-glass access before removing standing administration
Emergency access must survive the failure it is intended to address.
AWS’s direct-federation emergency configuration can bypass an unavailable IAM Identity Center, but it still depends on the external identity provider and IAM data plane. An identity-provider outage therefore needs a different break-glass design. AWS recommends preparing and periodically testing emergency access before disruption. (docs.aws.amazon.com)
Protect emergency identities with appropriate controls, including hardware-based MFA where applicable, and alert on their use. AWS’s break-glass guidance calls for tightly controlled, auditable emergency access tied to incident response. (docs.aws.amazon.com)
Run a sandbox drill:
- Simulate normal access being unavailable without disabling production federation.
- Obtain emergency authorization through a separately documented path.
- Authenticate using the prepared emergency mechanism.
- Perform a harmless permitted operation and verify the alert.
- Confirm access to the resources needed for recovery.
- End access, review the logs and complete credential cleanup required by the design.
Finally, rehearse maintenance cancellation before elevation and revocation during an active session.
Remove standing broad access only after normal elevation, automatic cleanup, active-session containment and emergency recovery have all been demonstrated. Keep any unavoidable exception explicit, owned and regularly reviewed.
