Skip to main content

Security & API Access Overview

Prepared for customer security assessment.

Integration Summary

1. Purpose of This Document

This document is provided to support your organisation’s security assessment of the nOps Azure integration. It lists the Azure API calls nOps makes, the exact RBAC permissions required, the resources in your environment, and what nOps does not access. nOps offers two integration tiers:
  • Savings Analysis: Read-only cost visibility, resource inventory, and optimisation recommendations.
  • Commitment Management: Automated purchasing and lifecycle management of Azure Reservations and Savings Plans. This tier builds on Savings Analysis and requires additional write-level roles scoped to commitment purchasing only.
Supported Agreement TypesnOps supports Enterprise Agreement (EA) and Microsoft Customer Agreement (MCA) only. Cloud Solution Provider (CSP) subscriptions are not supported.

2. Authentication Model

nOps uses a multi-tenant app called nOps.io. Its app registration lives in nOps’s own tenant. During onboarding, a Global Administrator or Privileged Role Administrator grants admin consent through Microsoft’s standard admin-consent flow. This adds the nOps.io enterprise application (a service principal) to your Microsoft Entra ID tenant. No app registration is created in your tenant, and nOps never stores your credentials. Microsoft’s consent screen shows the app nOps.io from publisher nOps Inc (verified publisher) and lists exactly these permissions: The screen also says that if you accept, the app gets access to the specified resources for all users in your organisation, and no one else will be prompted to review these permissions.
  • Consent adds the nOps.io enterprise application to your tenant and approves the permissions above for your whole organisation, so no one else is prompted.
  • Consent by itself gives nOps no access to your subscriptions, billing, or storage. nOps only gets Azure access from the roles you assign during setup (Section 4).
  • nOps never signs in as your users. The consent callback only receives your tenant ID and whether consent was granted.
  • nOps connects using the app’s own identity: app-only tokens from Microsoft Entra ID, with only the roles you assign.
  • For the Azure integration, nOps does not call Microsoft Graph.

3. Azure APIs Called

The following tables list the API endpoints nOps calls, grouped by service area. Apart from getting a token (#1) and the optional backfill run (#10), every Savings Analysis call is a read. Calls use the base URL https://management.azure.com unless a full URL is shown.

3.1 Sign-In, Subscriptions & Role Assignments

3.2 Billing Account Discovery

Used to find your billing account structure. All calls are reads.
nOps does not assign billing roles. For EA, you assign EnrollmentReader yourself by running a script in Azure Cloud Shell (a PUT to /providers/Microsoft.Billing/billingAccounts/{id}/billingRoleAssignments/{guid}), because Microsoft only supports assigning EA billing roles to a service principal through the REST API. For MCA, you assign the billing role in the Azure portal.

3.3 FOCUS Export & Export Files

nOps does not create the FOCUS export or change its settings. You create it during setup. nOps reads its settings, its run history, and the files it writes. If you ask nOps to backfill history, nOps also starts a one-off run of the export for each past month.
FOCUS Export Data FlowThe FOCUS export you create writes daily Parquet files to focus-exports/nops-clara inside the dedicated storage account. The nOps data ingestion service reads these files from outside Azure using static IPs 44.246.45.84, 52.11.53.164, and 52.39.155.200. If you enforce storage firewalls, only these three IPs need to be whitelisted, with “Allow Azure services on the trusted services list” enabled.

3.4 Commitment Management Checks During Verify

During Verify, nOps also runs a few read-only checks for Commitment Management roles: a Cost Management query (/subscriptions/{id}/providers/Microsoft.CostManagement/query), a subscription activity log read limited to a 1-hour window and the top 1 event (/subscriptions/{id}/providers/Microsoft.Insights/eventtypes/management/values), effective-permission checks at /providers/Microsoft.Capacity/providers/Microsoft.Authorization/permissions and /providers/Microsoft.BillingBenefits/providers/Microsoft.Authorization/permissions, and a Lighthouse registrationAssignments read. For Savings Analysis customers, these checks are expected to be denied, and they don’t affect the result.

3.5 Storage Account Keys (Commitment Management Setup)

Used only by Commitment Management setup validation, not by Savings Analysis and not in ongoing runtime operations.

3.6 Lighthouse Delegation (Commitment Management Only)

Savings Analysis does not use Azure Lighthouse. For Commitment Management, you deploy a Lighthouse delegation on the dedicated subscription, and nOps checks that it is active.
Lighthouse Visibility & RevocationAll Lighthouse delegations are fully visible in Azure Portal under Service Providers > Service provider offers and can be removed at any time. Removal immediately terminates nOps access.

3.7 Reservations API (Commitment Management Only)

The PUT purchase call (#17) creates a new reservation. No existing resources are modified or deleted.

3.8 Savings Plans API (Commitment Management Only)

The PUT purchase call (#19) creates a new savings plan. No existing resources are modified or deleted.

3.9 APIs nOps Does Not Call

  • Azure Advisor (Microsoft.Advisor) recommendations
  • Creating Cost Management exports or changing their settings (you create the FOCUS export yourself)
  • Assigning billing roles (for EA, you run the EnrollmentReader assignment yourself)
  • Microsoft Graph

4. Required RBAC Permissions (Savings Analysis)

The following roles are assigned during the Savings Analysis onboarding process. This is the complete list. The role at the Management Group scope cascades to all subscriptions underneath. The storage-account role is scoped only to the single dedicated nopsfocus storage account.

4.1 Management Group Scope

4.2 Storage Account Scope (Dedicated Only)

Important: Storage Blob Data Owner scope is strictly limitedThe Storage Blob Data Owner role is granted only on the nopsfocus<first-15-characters-of-tenant-id> storage account that you create for the FOCUS export. It does not grant access to any other storage account or resource in your environment. Savings Analysis does not require the Azure RBAC Owner role on this storage account. Owner is a management-plane role with no blob data permissions, so it cannot replace Storage Blob Data Owner.

4.3 Billing Scope

You assign one of these, depending on your billing account type and how you connect it.
Not assigned for Savings Analysis: Cost Management Contributor, Monitoring Reader, Reservations Reader, Savings Plan Reader, Owner on the storage account, any Azure Lighthouse delegation, and any Azure Policy assignment.

5. Additional Permissions (Commitment Management)

Commitment Management is an optional tier that enables nOps to autonomously purchase and manage Reservations and Savings Plans on your behalf. The following roles are assigned in addition to all Savings Analysis roles.

5.1 Management Group Scope (Additional)

5.2 Tenant Scope (Additional)

5.3 Storage Account Scope (Additional)

Owner is granted in addition to Storage Blob Data Owner, exclusively on the dedicated nopsfocus storage account. It does not grant Owner access to any other storage account or resource.

5.4 Dedicated Subscription Scope (via Lighthouse)

5.5 Billing Scope (Additional)

6. Resources in Your Environment

nOps does not deploy resources into your environment. Admin consent adds the nOps.io enterprise application, and you create everything else yourself during setup.

6.1 nOps.io Enterprise Application

Admin consent adds the nOps.io enterprise application (a service principal) to your Microsoft Entra ID tenant. This is the identity used for all API access described in this document. It is not an App Registration: the nOps app registration lives in nOps’s own tenant.

6.2 FOCUS Export Resources (Created by You)

You create these in the Azure portal during Savings Analysis setup. nOps does not create them.
These resources incur minimal cost: only standard Azure Blob Storage fees for the exported cost data.

6.3 Lighthouse Delegation (Commitment Management Only)

What is a Lighthouse Delegation?Azure Lighthouse allows nOps to access your resources from the nOps tenant without requiring you to create credentials in nOps’s environment. Savings Analysis does not use Lighthouse. For Commitment Management, a delegation on a dedicated subscription lets nOps team members manage commitment purchases in the Azure portal. You can review and revoke any Lighthouse delegation at any time from the Azure portal under Service providers.

6.4 Required Resource Providers

7. What nOps Does Not Access

The following are out of scope for the nOps Savings Analysis integration. nOps does not call the APIs for these items. Where noted, the Savings Analysis roles in Section 4 also block access.

8. Network Requirements

If your organisation enforces firewalls on storage accounts, the following nOps IP addresses must be whitelisted on the FOCUS export storage account. Additionally, ensure Allow Azure services on the trusted services list is enabled on the storage account firewall. If your storage account allows public network access (the default), no firewall configuration is needed.

9. Billing Policy Requirements

The following billing policies apply only to Commitment Management. Savings Analysis has no billing policy dependencies.

10. Security Summary

The table below summarises the key security properties of the nOps Azure integration for Savings Analysis.
For security questions, contact your nOps account team.