> ## Documentation Index > Fetch the complete documentation index at: https://docs.amnify.ai/llms.txt > Use this file to discover all available pages before exploring further. # Azure Permissions > How Amnify authenticates to Azure and the read-only access it requests. ## How Amnify authenticates Amnify is a single multi-tenant Microsoft Entra application. When you connect Azure, you authorize it once, which provisions a service principal (an "enterprise application") in your tenant. Amnify then authenticates as the application, using its own confidential client secret, to read posture data. It stores no user passwords and no customer secrets. The authorization request asks only for the minimal OpenID Connect scopes: `openid`, `profile`, and `email`. These low-impact, user-consentable permissions identify the tenant and establish the application in the directory. On their own they grant no access to resources or directory data. Where an organization restricts application consent, Microsoft routes the request to that organization's own administrator, who approves it in the Azure portal without needing an Amnify account. Resource access is granted separately, as an Azure role assignment, not through OAuth consent. Sign in and consent to the minimal `openid`, `profile`, and `email` scopes only. This establishes the Amnify application in your tenant **without any optional directory permissions** and can be completed by a standard user. ## Steps to connect Sign in and consent using the card above. This provisions the Amnify service principal (enterprise application) in your tenant and requests only `openid`, `profile`, and `email`. A standard user can complete it; where your tenant restricts consent, an administrator approves it. In the Azure portal, assign the built-in **Reader** role to the Amnify application at each **subscription** you want assessed, or at a **management group** to cover many at once — plus the small **custom role** for the two app-service read actions. See [Tier 1](#tier-1-subscription-read-access-required). To assess the identity layer, a **tenant administrator** grants admin consent for the three read-only Microsoft Graph permissions using the card in [Tier 2](#tier-2-microsoft-entra-id-directory-access-optional). You can add this later without disrupting existing scans. ## Tier 1: Subscription read access (required) **What:** the subscription permission is the built-in [**Reader** role (Azure RBAC)](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles/general#reader), assigned to the Amnify application at either: * each **subscription** you want assessed, or * a **management group**, to cover many subscriptions at once. Plus a small **custom role** for two read actions that Reader omits: * `Microsoft.Web/sites/host/listkeys/action` * `Microsoft.Web/sites/config/list/Action` **Why:** Posture assessment inspects how your resources are configured (networking, storage, compute, databases, key vaults, and resource-level identity assignments) to flag insecure settings. Reader grants read-only visibility into that configuration and nothing more. It cannot change, create, or delete resources, and it cannot read the data inside them, such as blob contents, database rows, or secret values. The two extra read actions serve a handful of app-service checks that must read app-service configuration and host-key metadata to confirm secure settings. Reader excludes those reads, so a minimal custom role adds them at the same scope as Reader. This tier alone enables the full set of subscription and resource posture checks. It is purely an Azure role assignment on your side, and it needs no Microsoft Graph permission and no directory-wide consent. ## Tier 2: Microsoft Entra ID directory access (optional) **What:** three admin-consented Microsoft Graph **application** permissions: * `Directory.Read.All`: read directory objects (users, groups, roles, service principals, and organization settings). * `Policy.Read.All`: read directory policies (Conditional Access, authorization, consent, and security-defaults). * `UserAuthenticationMethod.Read.All`: read which authentication methods users have registered. Used only for multi-factor-authentication posture. **Why:** This tier assesses the identity layer itself: privileged role assignments, Conditional Access coverage, legacy-auth exposure, and MFA registration. It reads identity configuration only. It cannot read mailbox or file content, and it cannot reset credentials or change anything. **Why it is optional and separate:** None of this is needed to assess subscription resources. This step goes through **admin consent** because most organizations require a **Global Administrator** or **Application Administrator** to approve any consent an enterprise application is granted — so Microsoft routes the request to your tenant's administrator, who approves it in the Azure portal without needing an Amnify account. These are also application permissions, which additionally require administrator consent under Microsoft's rules, but the organization's consent policy is the primary reason an administrator — rather than a standard user — completes this step. You can add them later, after Tier 1 is working, without disrupting existing scans. A tenant administrator grants tenant-wide admin consent for the optional Microsoft Graph application permissions listed above. **Requires an administrator** — a standard user cannot complete this flow. **Least-privilege notes:** * All three are read-only. * Amnify requests `Directory.Read.All` rather than narrower per-object permissions because the identity checks span users, groups, roles, and service principals together. It deliberately does not request the broader "read all users' full profiles" permission (`User.Read.All`), which is unnecessary and redundant with `Directory.Read.All`. **What Amnify never asks for on Azure** * No write or modify Azure RBAC permissions, only `Reader` plus the two read actions above. * No Microsoft Graph write permissions. * No access to mailboxes, files, Teams, or any message or content data. * No long-lived customer secrets. You grant a role assignment (Tier 1) and, optionally, admin consent (Tier 2). You never paste credentials into Amnify.