How do we connect Wiz to AWS Organizations and multiple Azure subscriptions with least-privilege access (what roles/permissions are needed)?

Most teams I’ve worked with want two things on day one with Wiz: connect all their cloud accounts fast, and do it with clean, least‑privilege access their auditors won’t fight. The good news is you can integrate AWS Organizations and multiple Azure subscriptions without handing Wiz broad admin rights, and still get full security graph coverage across code, cloud, identities, and runtime.

Quick Answer: You connect Wiz to AWS via an AWS Organizations integration that uses a dedicated Wiz master role and per‑account read‑only member roles, and to Azure via a multi‑subscription onboarding that uses a custom Reader‑level role plus a lightweight app registration. Both follow least‑privilege principles: Wiz only gets the permissions required to discover resources, entitlements, and risks—no write or control-plane changes in your environment.

The Quick Overview

What It Is: A least‑privilege connection model for onboarding Wiz to AWS Organizations and multiple Azure subscriptions using scoped, read‑only roles and service principals.
Who It Is For: Cloud security, platform, and identity teams that need to standardize Wiz access across large, multi‑account/multi‑subscription environments and prove least privilege to internal and external auditors.
Core Problem Solved: Eliminates the need for ad‑hoc, over‑privileged admin roles on every account/subscription while still giving Wiz enough access to build a complete security graph and surface exploitable attack paths.

How It Works

At a high level, you:

Establish a trust anchor in each cloud:
- In AWS, a management‑account role connected to AWS Organizations.
- In Azure, a tenant‑level app registration (service principal).
Grant scoped, read‑only permissions across accounts/subscriptions:
- In AWS, a member role in each account with only the APIs Wiz needs.
- In Azure, a custom Reader‑like role on each subscription (and management group if you use them).
Let Wiz enumerate and analyze via the security graph:
- Wiz uses these roles/service principals to read resource configs, identity relationships, network exposure, and runtime signals—without modifying anything in your environment.

AWS: Connecting Wiz to AWS Organizations with Least‑Privilege Access

Attack surface scanning (cross‑account discovery):
From your AWS Organizations management account, you create a Wiz “master” role that lets Wiz:
- Read your AWS Organizations structure (accounts, OUs).
- Discover which accounts exist and whether they’re in scope for Wiz.
- Assume a dedicated member role in each account.
Deep internal analysis (per‑account read‑only roles):
In each AWS account, you deploy a minimal Wiz member role that:
- Allows sts:AssumeRole from Wiz’s AWS account only.
- Includes a least‑privilege, read‑only policy that covers:
  - Resource configuration: Describe*, Get*, List* for EC2, RDS, EKS, Lambda, S3, IAM, KMS, Security Hub, CloudFormation, etc.
  - Identity & access: read IAM roles, users, policies, SSO identities, and permission sets to construct effective permissions and privilege paths.
  - Networking: read VPCs, subnets, security groups, NACLs, route tables, load balancers, gateways to build network attack paths and external exposure.
  - Data services: metadata on S3 buckets, RDS/Aurora, DynamoDB and other data services (no data-plane read of your business data).
- Explicitly excludes *:* style wildcards, resource changes (Put*, Delete*, Update*), and any action that can modify state.
FIX AT SCALE IN CODE (ownership mapping & PRs):
Once connected, Wiz:
- Maps AWS resources to owning teams via tags, naming, and metadata.
- Uses Wiz Green agent to generate IaC and configuration fixes (e.g., security group and S3 policy changes) as PRs in the right repo.
- Routes issues into Jira/ServiceNow for engineering self‑remediation, without needing write permissions in your AWS accounts.

Azure: Connecting Wiz to Multiple Azure Subscriptions with Least‑Privilege Access

Tenant‑level setup (service principal):
In your Azure AD (Entra ID) tenant, you:
- Create an app registration for Wiz.
- Grant it appropriate API permissions (primarily Azure Resource Manager and Graph read scopes).
- Use a client secret or certificate for Wiz to authenticate.
Subscription‑level access (custom Reader role):
For each subscription you want Wiz to monitor, you:
- Assign the Wiz service principal a custom role that is:
  - Based on the built‑in Reader role.
  - Extended with specific read actions Wiz needs for:
    - Resources: Microsoft.*/*/read for compute, storage, databases, and PaaS services.
    - Networking: network interfaces, NSGs, route tables, load balancers, public IPs.
    - Identities: managed identities, role assignments/definitions, Key Vault metadata.
  - Scoped at the subscription (or management group) level only, not tenant‑wide ownership.
- Avoid giving Owner or Contributor at subscription scope; that’s not required for Wiz to operate.
Deep internal analysis (subscriptions and tenants):
Wiz then:
- Enumerates all resources in each subscription with read‑only calls.
- Resolves RBAC assignments, managed identities, and service principals to model identity paths and privilege escalation routes.
- Connects network exposure to data access chains—for example, an externally reachable VM with a managed identity that can read a Key Vault that protects a production database.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Agentless, least‑privilege onboarding	Connects to AWS Organizations and Azure subscriptions using read‑only roles and service principals.	Fast, low‑risk deployment that passes security and audit review.
Unified Security Graph	Correlates code, cloud resources, identities, network, data, and runtime signals across all accounts/subscriptions.	Shows real attack paths instead of isolated misconfigurations.
Ownership mapping & PR‑based fixes	Maps findings to teams/repos and uses Wiz Green agent to generate code and config fixes.	Turns cross‑cloud risk into actionable work engineering can own.

Ideal Use Cases

Best for centralized cloud security teams: Because it gives you a single, governed way to onboard hundreds of AWS accounts and Azure subscriptions with consistent, least‑privilege access policies.
Best for compliance‑sensitive environments: Because the roles are read‑only and auditable, letting you demonstrate that Wiz cannot change workloads while still providing complete visibility and attack path analysis.

Limitations & Considerations

Role design is security‑critical: You should review Wiz’s latest IAM and Azure RBAC templates rather than improvising policies. Keeping to the documented actions ensures both least privilege and full feature coverage.
Org/tenant structure matters: If your AWS Organizations or Azure management group hierarchy is fragmented, you may need more than one integration or additional scoping decisions to avoid gaps.

Pricing & Plans

Wiz pricing is based on your environment footprint and the modules you enable (e.g., core CNAPP, container security, runtime protection). Connecting via AWS Organizations and multiple Azure subscriptions does not incur separate connector fees; it’s how you operationalize Wiz at scale.

Wiz Cloud (Core CNAPP): Best for security and platform teams needing unified visibility, attack path analysis, and code‑to‑cloud risk reduction across AWS and Azure.
Wiz Cloud + Runtime Protection: Best for organizations needing not just exposure management but also runtime detection, lateral movement blocking, and full SecOps automation on top of the same least‑privilege connectors.

Frequently Asked Questions

What exact permissions does Wiz need in AWS Organizations to stay least‑privilege?

Short Answer: A management‑account role that can read AWS Organizations metadata and assume a per‑account Wiz member role, plus a read‑only, least‑privilege policy on that member role covering discovery of resources, identities, networking, and security posture.

Details:
In AWS, you’ll typically create:

Wiz Organization Role (in the management account):
- Trusts Wiz’s AWS account via sts:AssumeRole.
- Grants:
  - organizations:ListAccounts, organizations:DescribeOrganization, organizations:ListOrganizationalUnitsForParent, etc.
  - sts:AssumeRole into the Wiz member role in each account.
- No permissions to modify organizations or accounts.
Wiz Member Role (in each account):
- Trust policy allows only the Org Role (and implicitly Wiz via that chain) to assume it.
- Permissions include:
  - ec2:Describe*, rds:Describe*, eks:Describe*, lambda:List*/Get*/Describe*, s3:ListAllMyBuckets, s3:GetBucket* (config‑level), and similar read‑only actions across services.
  - iam:Get*/List* for roles, users, groups, policies, and instance profiles.
  - Read‑only for CloudTrail, Config, and Security Hub where present.
- Explicitly avoids mutation actions like RunInstances, Put*, Delete*, and Update*.

This design lets Wiz build a full attack surface map and security graph without any control‑plane write capability in your AWS environment.

What roles and permissions does Wiz need for multiple Azure subscriptions?

Short Answer: An Azure AD app registration (service principal) with read scopes and a custom role assignment per subscription (or management group) based on Reader plus a small set of extra read actions.

Details:
In Azure, you’ll generally:

Create an app registration in Azure AD:
- This is the Wiz service principal.
- Assign API permissions so it can call Azure Resource Manager and read directory objects where necessary.
Create a custom “Wiz Reader” role:
- Start from the built‑in Reader role definition.
- Add any additional Microsoft.*/*/read actions that Wiz requires but Reader does not include by default (often around identities, security data, or specific PaaS services).
- Do not include */write, */delete, or */action that perform state changes.
Assign the “Wiz Reader” role:
- At the subscription scope for each subscription you want Wiz to monitor.
- Optionally at management group scope to cover many subscriptions consistently.
- Avoid granting Owner or Contributor unless you have a very specific, documented reason.

With this model, Wiz can inventory all resources, understand RBAC, and model attack paths across subscriptions without having the ability to modify Azure resources.

Summary

Connecting Wiz to AWS Organizations and multiple Azure subscriptions with least‑privilege access is straightforward: establish a trusted, read‑only role in each cloud, scope it at the right organizational level, and let Wiz’s security graph do the heavy lifting. You avoid over‑privileged admin access, you satisfy audit requirements, and you still get full‑fidelity attack path modeling—from exposed internet assets and misconfigured identities to the data they can actually reach.

Once that foundation is in place, you can push the value further: map ownership, route findings to the right teams, and use Wiz’s AI‑driven agents to turn cross‑cloud exposures into concrete code and config fixes, all without expanding Wiz’s permissions in your cloud.

Next Step

Get Started