> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/end-user-guide-for-selfservice/requests/revoke-access.md).

# Giving up access

Hand back access you no longer need, and understand when it actually goes away.

**Revoke Access** is how you hand back access you no longer need. It is the mirror image of requesting: you choose what to give up, say why, and it goes for approval.

Open it from **Requests → Create Request → Revoke Access**.

## Why bother

Handing access back feels like effort with no reward, so it is worth being clear about why it matters:

* **Access you don't use is a risk to you.** If your account is ever misused, everything it can reach is exposed — including the system you last touched two years ago.
* **It shortens access reviews.** Every unnecessary item is something your manager has to look at and decide on, repeatedly.
* **It keeps the picture honest.** Access records are only useful if they reflect what people actually need.

The natural moments to do this: when you finish a project, change team, or notice something in [Your access](/end-user-guide-for-selfservice/your-access.md) that you don't recognise.

## Giving something up

{% stepper %}
{% step %}
**Open the revoke page.**

It lists the roles and groups you currently hold. If you hold none you see *"You currently have no roles or groups to revoke."*
{% endstep %}

{% step %}
**Select what you want to give up.**

You can select several at once. If you submit without choosing anything you are told *"You did not select any access to revoke."*
{% endstep %}

{% step %}
**Give a reason.**

The page asks you to *"provide a reason for revoking the selected access"*. "Project finished" or "moved to a different team" is enough.
{% endstep %}

{% step %}
**Confirm.**

You are asked *"Are you sure you want to revoke access from the selected items?"* — because this reduces what you can do.
{% endstep %}

{% step %}
**Submit.**

Like any request, it goes for approval.
{% endstep %}
{% endstepper %}

## When the access actually goes

This is the part people find surprising. After approval, you see:

> *"Your request to revoke access has been submitted. Once approved, manual tasks will be generated for non-automated applications; access to automated applications will be revoked immediately."*

In other words, removal happens at two speeds:

| Kind of application        | What happens                                                                                          |
| -------------------------- | ----------------------------------------------------------------------------------------------------- |
| **Connected (automated)**  | OpenIAM removes the access itself, immediately after approval                                         |
| **Not connected (manual)** | A task is created for a person to remove it by hand — so there is a delay while someone does the work |

Both are normal. If access lingers in a manual system for a day or two, someone is working through a queue.

{% hint style="warning" %}
Think before revoking access you might still need. Getting it back means a fresh request and a fresh approval — which is quick for a common application, and slow for something with a long approval chain.
{% endhint %}

## Access that goes on its own

You don't always have to do this deliberately. Access can also end when:

* a **time-limited grant** reaches its end date — see [Requesting access](/end-user-guide-for-selfservice/requests/request-access.md)
* your **job changes** and birthright access is recalculated
* an **access review** decides the access is no longer needed — see [Access reviews](/end-user-guide-for-selfservice/access-reviews.md)

Revoking is for everything those don't catch.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.openiam.com/end-user-guide-for-selfservice/requests/revoke-access.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.