Skip to main content

Temporary cloud role access

Request a time-limited Azure or AWS role, follow approval and provider grant separately, and verify that access is removed after the work.

Written for whoever runs IT6 min readUpdated

Temporary cloud role access gives a person or service additional cloud permissions for a defined task and duration. It is useful when a technician needs to repair a resource but should not hold a powerful role every day. The request records the intended identity, role, scope and business reason. A separate approver reviews the request, and the cloud provider must accept the grant before the access becomes usable.

Prepare the provider connection

Open Privileged access → Cloud elevation. Your administrator must configure a cloud credential that can manage the intended assignments. The target identity and role must already exist in the chosen provider. For Azure, the scope determines which resource, resource group or subscription the role covers. For AWS, use the identity and policy references expected by the connection. Copy these references from the provider configuration; similar display names are not a reliable identifier.

  1. Describe the request

    Choose the provider, enter the configured cloud credential reference, target identity and role reference, and set the duration. Supply the Azure scope where required. Write a reason that explains the work and affected resource.

  2. Review the scope

    Check that the selected role has only the permissions needed and that the duration covers the work. The console allows a maximum of eight hours. A shorter duration reduces the period during which the additional permission can be used.

  3. Submit for approval

    Submit the request and follow its status. Approval must come from someone other than the requester. If the approver needs more context, update your work record rather than submitting a succession of broader requests.

  4. Confirm the grant

    Wait for the request to show granted, then verify access at the cloud provider. An approved request still needs its provider operation to succeed. Provider permissions, propagation delays or an incorrect identity reference can prevent usable access.

Read the result carefully

Pending means the request needs a decision. Approved means the approval step succeeded; it does not by itself mean the cloud role was assigned. Granted records a successful provider grant. Denied means the request was refused. Revoked records removal through the revocation workflow. If the operation fails, read the error and check the configured credential, identity, role and scope. Repeated approval clicks cannot fix a provider credential with insufficient permission.

Confirm removal

The access window has an expiry and the platform has a revocation workflow. Check the request after expiry and verify the assignment in the cloud provider for sensitive work. A failed revocation requires attention: expiry in a request record is not proof that the provider removed the role. Use an authorised cloud administrator to investigate unexpected remaining access. Keep the request and provider reference with your change record so the original grant can be distinguished from another assignment.

What this does not replace

This workflow manages a role assignment. It does not provide a cloud console session recording or prove that every permission within a role is safe. Confirm the provider integration in a controlled scope before relying on it for an emergency. For help, include the request reference, state and error time. Do not include the cloud credential secret in a support message.

Was this article wrong?

If a procedure here does not match what you see, or a limit we described has changed, tell us and we will fix the page. Email us about this article, or see how to get help if you need an answer rather than a correction.

Everything in privileged access