**Elevate** is just-in-time privilege escalation for your team: _"Request, approve, and audit just-in-time access."_ Instead of leaving people permanently in a powerful role, they request that role when they need it, for as long as they need it, with a reason attached.

![Elevate](/content/console/elevate.access.png)

The rail has four tabs: **Access**, **Approvals**, **Grants**, and **Policy**.

## Access

**"Request temporary access"** — _"Access expires automatically. Reason is retained in audit history."_

| Field | Details |
|-------|---------|
| **Target type** | What you are elevating into, for example `Environment role`. |
| **Duration** | How long the grant lasts (default: 30 minutes), capped by the environment policy. |
| **Role** | The role to assume. |
| **Reason** | Why this access is needed. Retained in audit history. |
| **Ticket reference** | Optional link to the incident or ticket, for example `INC-1234`. |

Click **"Request access"** to submit. **My requests** below tracks your own submissions with Target, Status, Duration, and Expires.

## Approvals

**"Approval queue"** — the requests waiting on a decision, with Requester, Target, Reason, and Duration.

One rule is enforced by the server, not by convention: _"Requester cannot approve their own request."_ Even an admin who could otherwise approve anything must have someone else sign off on their own escalation.

## Grants

**"Access grants"** — active and past grants, with Grantee, Target, Status, and Window.

The important behaviour is noted on the page: _"Runtime authorization checks expiry synchronously."_ Expiry is not a background sweep — the moment the window closes, the next authorization check fails. There is no gap where a stale grant still works.

## Policy

**"Environment policy"** — the rules the server snapshots onto each request. Because the policy is captured at request time, tightening it later does not retroactively change grants already in flight.

| Setting | Effect |
|---------|--------|
| **Require administrator approval** | An admin must approve requests before they become grants. |
| **Require recent MFA or TOTP activation code** | The requester must prove a recent MFA or TOTP challenge. |
| **Maximum duration (minutes)** | Caps how long any single grant can last. |

Click **"Save policy"** to apply.

> **Tip**
>
> Turn on both **Require administrator approval** and **Require recent MFA** for
> production environments, and keep **Maximum duration** short — 30 to 60
> minutes. A request that needs longer usually wants a permanent role instead.

## Elevate vs impersonation

The two look similar and solve different problems:

| | Elevates | Configured in |
|---|---|---|
| **Elevate** | A *team member's* own privileges within an environment. | This page. |
| **Impersonation** | A team member's ability to act *as an end user*. | [Users > Escalation](/docs/console/users). |

Both are fully audited. Elevate emits the `ELEVATE_ACCESS_*` event family — requested, approved, denied, cancelled, activated, revoked, expired — and impersonation emits `USER_IMPERSONATION_*`. Both appear under the **Administration** category in [Audit > Event Types](/docs/console/audit).

## Related

| Read | To learn how to |
|------|-----------------|
| [Authorization](/docs/console/authorization) | Define the roles Elevate grants |
| [Users](/docs/console/users) | Grant time-boxed impersonation of an end user |
| [Audit](/docs/console/audit) | Review the full escalation trail |
| [Tenants](/docs/console/tenants) | Manage who is on the team in the first place |