> For the complete documentation index, see [llms.txt](https://docs.stepsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stepsecurity.io/azure-devops/overview.md).
# Overview
The Overview page is the All Controls dashboard for an Azure DevOps organization. It lists every security control StepSecurity evaluates against the organization, shows which are failing, and lets you triage them by severity.
#### Summary cards
Four cards at the top of the page summarize the organization's current state:
| Card | What it counts |
| ------------------- | --------------------------------------------------------------------------------------- |
| **Failed Controls** | Controls with at least one failing check |
| **Passing** | Controls where every evaluated item passes |
| **High Open** | Failed controls whose severity is High |
| **Failed Checks** | Individual failing checks across all controls, counted per item rather than per control |
## All Controls
The table below the cards lists each control with its category, current status, severity, and the number of failing tokens out of the number evaluated. Select a control name to open its detail page.
| Control | Category | Severity | What it checks |
| ----------------------------------------------------------------------------------- | -------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Tokens Should Be Rotated Within Max Age](#tokens-should-be-rotated-within-max-age) | PAT Governance | High | Fails for an active token issued for longer than its limit, or already older than it |
| [Tokens Should Have Minimum Scopes](#tokens-should-have-minimum-scopes) | PAT Governance | High | Fails for an active token holding any of the [35 scopes Microsoft rates high privilege](https://learn.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/oauth?view=azure-devops#available-scopes), or granting full access |
| [Tokens Should Be Actively Used](#tokens-should-be-actively-used) | PAT Governance | Medium | Fails for an active token idle past its limit |
| [Tokens Should Belong To Active Users](#tokens-should-belong-to-active-users) | PAT Governance | Medium | Fails for a member deactivated in the directory or removed from the organization while still holding an active token |
{% hint style="info" %}
A control only appears with results if it is enabled under [Settings > Control Evaluation](/azure-devops/settings/control-evaluation.md). Thresholds set there determine what counts as a violation.
{% endhint %}
### Tokens Should Be Rotated Within Max Age
**Severity: High**
This check fails for an active token issued for longer than its limit, or already older than it. High privilege tokens get a stricter limit.
**Why This Matters**
A long-lived token widens the window in which a leaked credential still works. The more a token can do, the more that window is worth to an attacker.
**How to Fix It**
* Re-issue the token with a shorter lifetime, update the automation that uses it, then revoke the old one.
* Azure DevOps can also cap token lifetimes for the whole organization, which prevents new over-long tokens from being created.
* Set **Max age**, **High privilege max age**, and the pre-expiry reminder bands under [Settings > Control Evaluation](/azure-devops/settings/control-evaluation.md).
**Table columns**
| Column | Meaning |
| ---------------------- | --------------------------------------------------------------------------- |
| **Compliance Status** | Passed or Failed for this control |
| **Token** | Token name as set in Azure DevOps |
| **Owner** | Display name and email of the token owner |
| **Issued for / limit** | The lifetime the token was issued for, against the limit that applies to it |
| **Age** | How long ago the token was created |
| **Expires** | The token's expiration date |
| **Remediation** | Revoke action |
### Tokens Should Have Minimum Scopes
**Severity: High**
This check fails for an active token holding any of the [35 scopes Microsoft rates high privilege](https://learn.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/oauth?view=azure-devops#available-scopes), or granting full access.
**Why This Matters**
These scopes can grant standing access, read pipeline secrets, or change what a build runs. That means stolen access can outlive revoking the token, because an attacker with these permissions can establish persistence that revocation alone does not undo.
**How to Fix It**
* Re-issue the token with only the scopes it needs.
* For automation, use a service principal instead of a token owned by a person. Service principals in your organization are listed under [Identities & PATs](/azure-devops/identities-and-pats.md).
**Table columns**
| Column | Meaning |
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| **Compliance Status** | Passed or Failed for this control |
| **Token** | Token name as set in Azure DevOps |
| **Owner** | Display name and email of the token owner |
| **Scope risk** | `High privilege` or `Standard`, based on the scopes the token holds |
| **Scopes** | The scopes granted to the token, shown as chips. Where a token holds more scopes than fit the row, a **+N more** link expands the rest |
| **Remediation** | Revoke action |
This control adds one filter beyond the shared set: **Scope risk**, which narrows the table to high privilege or standard tokens.
### Tokens Should Be Actively Used
**Severity: Medium**
This check fails for an active token idle past its limit, measured from its last audited action or its owner's last access. High privilege tokens get a stricter limit.
**Why This Matters**
A token nobody uses is a credential nobody is watching. Tokens routinely outlive the work, and the person, they were made for.
**How to Fix It**
* Confirm the token is no longer needed, then revoke it.
* For automation that is still running, move it to a service principal rather than leaving a personal token in place.
* Set **Unused for more than** and **High privilege unused for more than** under [Settings > Control Evaluation](https://docs.stepsecurity.io/azure-devops/settings/control-evaluation).
**Table columns**
| Column | Meaning |
| --------------------- | ------------------------------------------------------------------------------------------ |
| **Compliance Status** | Passed or Failed for this control |
| **Token** | Token name as set in Azure DevOps |
| **Owner** | Display name and email of the token owner |
| **Idle for / limit** | How long the token has been idle, against the limit that applies to it |
| **Last used** | The most recent use recorded for the token |
| **Owner last active** | The owner's most recent access to the organization |
| **Last activity** | The token's last audited action. Reads `No recorded activity` where the audit log has none |
| **Remediation** | Revoke action |
{% hint style="info" %}
Idle time is measured from the token's last audited action, or from its owner's last access where the token itself has no recorded activity. A token can therefore show `No recorded activity` under **Last activity** while still being measured against a **Last used** date.
{% endhint %}
### Tokens Should Belong To Active Users
**Severity: Medium**
This check fails for a member who has been deactivated in the directory or removed from the organization while still holding an active token.
**Why This Matters**
Microsoft revokes a token when its owner's account is disabled, and a token belonging to someone removed from the directory stops working within an hour. That leaves a window during offboarding where a token is still live, and it leaves tokens that need cleaning up even after they stop working.
**How to Fix It**
* Revoke the tokens the departed or deactivated member still holds.
* If the work the token was doing is still needed, move it to a service principal rather than reissuing the token under another person's name.
**Table columns**
| Column | Meaning |
| --------------------- | ---------------------------------------------------- |
| **Compliance Status** | Passed or Failed for this control |
| **Token** | Token name as set in Azure DevOps |
| **Owner** | Display name and email of the token owner |
| **Owner status** | Whether the owner is still `Active` in the directory |
| **Owner last active** | The owner's most recent access to the organization |
| **Token** | Whether the token is `Still valid` |
| **Remediation** | Revoke action |
---
# 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 dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.stepsecurity.io/azure-devops/overview.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.
