How do we get started with Wiz onboarding using cloud API connections, and how long until we see full inventory and prioritized risks?

Most teams are surprised by how quickly they can go from “no Wiz” to “full cloud inventory and prioritized risks” using only cloud API connections. You don’t need to roll out agents everywhere or wait weeks for tuning; the onboarding flow is built for fast, low-friction visibility across AWS, Azure, GCP, on‑prem, SaaS, and AI environments.

Quick Answer: You connect Wiz to your cloud accounts via read‑only API permissions, validate data ingestion, and let the Wiz Security Graph automatically map your environment. Most organizations see full inventory within minutes to a few hours, and decision‑grade, prioritized risks within the first hour—often during the initial demo or PoC session.

The Quick Overview

What It Is: Wiz onboarding via cloud API connections is an agentless, API‑driven way to connect your cloud and SaaS environments to the Wiz Security Graph so you can see all assets, risks, and attack paths in one place.
Who It Is For: Security, cloud, and platform teams that need fast, accurate cloud visibility and risk prioritization—without deploying host agents or disrupting workloads.
Core Problem Solved: Traditional onboarding takes weeks of agent rollout, permissions wrangling, and dashboard setup. Wiz uses cloud APIs and a unified security graph to deliver full inventory and prioritized, exploitable risks in minutes to hours, not months.

How It Works

At a high level, Wiz connects directly to your cloud providers’ control planes using read‑only API access. It continuously pulls configuration, identity, vulnerability, data, runtime, and exposure signals into the Wiz Security Graph, which models how attackers could move through your environment. That context lets you see not just “what’s vulnerable,” but what’s actually exploitable—and who owns the fix.

Connect Cloud Accounts via API (Attack Surface Scanning):
You grant Wiz least‑privilege, read‑only access to your AWS, Azure, GCP, and other environments using provider‑native mechanisms (CloudFormation/Terraform templates, ARM/Bicep, Deployment Manager, etc.). Wiz immediately starts mapping externally reachable assets and effective internet exposure.
Ingest & Correlate Context (Deep Internal Analysis):
Wiz collects data on resources, configurations, vulnerabilities, identities and permissions, data locations, secrets, and network paths. The Wiz Security Graph correlates these signals to understand attack paths, lateral movement opportunities, and data access chains.
Surface Prioritized Risks & Owners (From Exposure to Code Fix):
Within the graph, Wiz ranks findings based on exploitability, exposure, identity paths, and blast radius. Ownership mapping ties issues to the right teams, repos, and services. The Wiz Green agent can then generate fixes (including PRs) while Wiz Red and Blue agents validate and investigate threats in runtime.

Step‑by‑Step: Getting Started with Wiz Onboarding via Cloud API Connections

1. Prepare for Onboarding

Before you create any connections, align on:

Scope: Which clouds, subscriptions/accounts, and regions matter for day one? Many teams start with production and internet‑exposed accounts.
Stakeholders: Cloud/platform owners (AWS/Azure/GCP admins), security leads, and someone who can validate findings (DevOps or app owner).
Access Model: Decide whether you’ll connect via:
- Cloud‑native templates from Wiz (recommended for PoC/initial rollout).
- Your own Terraform/infra‑as‑code modules that embed Wiz roles and policies.

This upfront prep keeps the actual onboarding to 30–60 minutes, even in larger orgs.

2. Create the First Cloud API Connection

In the Wiz UI, you’ll add a connector for each cloud provider. The specifics vary by CSP, but the pattern is consistent: Wiz provides a template or script that creates a read‑only role and establishes the secure API connection.

Typical AWS Flow (example pattern):

In Wiz, choose Add Cloud → AWS.
Download or deploy the provided CloudFormation or Terraform template.
The template:
- Creates an IAM role with least‑privilege, read‑only permissions.
- Sets up a trust relationship so Wiz can assume this role.
Paste the generated role ARN (or connection ID) back into Wiz.
Click Validate to confirm the connection.

Typical Azure Flow:

In Wiz, choose Add Cloud → Azure.
Log in with a suitable Azure AD role (e.g., Owner or Security Admin on the subscription/tenant you’re onboarding).
Run the Wiz‑provided ARM/Bicep template or CLI commands to:
- Register an Azure AD app/service principal.
- Assign least‑privilege roles at subscription/management group scope.
Confirm and validate permissions in the Wiz UI.

Typical GCP Flow:

In Wiz, choose Add Cloud → GCP.
Create a service account via the provided Terraform or gcloud commands.
Grant it the recommended read‑only roles on the relevant projects/folders.
Upload the service account key or configure workload identity as per Wiz guidance.
Validate the connection in Wiz.

For all providers, Wiz is primarily agentless and API‑driven—there’s no need to install host agents just to see inventory and core risks.

3. Enable Workload & Configuration Visibility

Once the base connection is live, Wiz starts:

Enumerating cloud resources (VMs, containers, serverless functions, databases, storage, Kubernetes, managed services).
Collecting configuration and posture data (CSPM‑style checks).
Gathering identity/permissions (IAM roles, service principals, groups, policies).
Discovering public exposure (security groups, load balancers, public buckets, DNS).

This “attack surface scanning” layer is usually visible in the UI within minutes of the connection going green.

4. Attach Additional Signals (Optional but Recommended Early)

To deepen context and speed, teams often quickly layer in:

Container / Kubernetes metadata: Connect managed Kubernetes services (EKS/AKS/GKE) and cluster configs.
Data & secrets insight: Allow Wiz to identify where sensitive data, secrets, and keys live, and who/what can access them.
Cloud & SaaS logs: Integrate relevant logs and SaaS sources so runtime behaviors can be tied back to the graph.
eBPF Runtime Sensor (for DETECT AND BLOCK): For workloads where you want live threat detection and blocking, deploy Wiz’s runtime sensor. This is optional for onboarding; you’ll still get full inventory and prioritized risks from API‑only integration.

You can phase these in by environment (e.g., start with prod Kubernetes, then expand to dev/test).

5. Watch the Wiz Security Graph Populate

As data lands, the Wiz Security Graph begins to map:

Relationships between resources (VMs, containers, functions, databases, storage).
Network paths and effective internet exposure.
Identity relationships (who can assume what, privilege escalation paths).
Where vulnerabilities intersect with reachable assets and sensitive data.
Cross‑environment chains (e.g., SaaS app → cloud identity → database).

Within the first 30–60 minutes, most teams can:

Navigate full inventory views for the onboarded accounts.
See attack surface maps of what is actually reachable from the internet.
Use initial risk views (sorted by exploitability and blast radius) instead of CVSS‑only lists.

6. Review Prioritized Risks & Attack Paths

Once the graph has enough data, Wiz automatically surfaces:

Critical attack paths that reflect how an attacker could gain initial access, pivot via identity paths, escalate privileges, and reach sensitive data.
Contextual risk scores based on:
- Internet exposure.
- Identity paths and permissions abuse.
- Vulnerability exploitability.
- Misconfigurations that remove defense‑in‑depth.
- Data sensitivity and blast radius.

Early in onboarding, you’ll typically see examples like:

An externally reachable VM with a critical vulnerability and a path to a high‑value database.
A misconfigured IAM role with broad permissions that can be assumed by a compromised workload.
A public storage bucket containing sensitive data and weak access controls.

These aren’t just “findings”; they are end‑to‑end chains you can walk through—precisely what makes prioritization and executive communication straightforward.

7. Map Ownership and Route Fixes

To move from visibility to action, you’ll:

Configure ownership mapping:
- Connect repositories, CI/CD, or service catalogs where applicable.
- Tag services by team (e.g., with labels, tags, or naming conventions).
- Let Wiz associate cloud resources with repos, services, and owners.
Integrate with ticketing and workflows:
- Jira, ServiceNow, or your preferred system.
- Define routing rules (e.g., “Kubernetes namespace X → Team A,” “Account Y → Platform Team”).
Enable the Wiz Green agent for fixes:
- Generate code‑level and IaC‑level fixes for prioritized risks.
- Auto‑open PRs to the right repositories with proposed remediations.
- Let engineering teams review and merge instead of copying from spreadsheets.

From here, you have a repeatable flow: Exposure → Attack Path → Owner → Code Fix → Runtime Validation.

How Long Until You See Full Inventory and Prioritized Risks?

Timelines always depend on environment size and API limits, but real‑world patterns are consistent:

Initial Connection Validation:
5–15 minutes per major cloud provider once your IAM team is aligned.
First Inventory & Posture Views:
Typically within minutes after connection for most accounts. You’ll see:
- Resource inventory.
- Basic posture/misconfigurations.
- Internet‑exposed assets.
Full Inventory Across Large Multi‑Account Environments:
For enterprises with hundreds of accounts/subscriptions:
- Meaningful coverage in under an hour.
- Full initial inventory often within a few hours, depending on CSP API throttling and account count.
Prioritized, Contextual Risks (Attack Paths, Exploitability):
Generally within the first hour of data ingestion:
- Wiz correlates vulnerabilities, misconfigs, identities, and data into attack chains.
- You can immediately focus on a short list of high‑impact issues instead of thousands of raw findings.
Operationalized Remediation (Tickets, PRs, SLAs):
- Basic ticket routing can be set up in under a day for a PoC.
- Mature orgs map ownership and start running on remediation SLAs within the first few weeks.

Customers routinely report “visibility in a short time” and “deployed across hundreds of accounts within hours,” which mirrors what I’ve seen in large, multi‑cloud environments replacing 10+ legacy tools.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Agentless Cloud API Connections	Connects to AWS, Azure, GCP, on‑prem, SaaS, and AI environments via read‑only cloud APIs and templates.	Rapid onboarding with minimal overhead—visibility without widescale agent deployment.
Wiz Security Graph	Correlates resources, configs, vulnerabilities, identities, data, secrets, and exposure into attack paths.	Prioritization based on exploitability, identity paths, and blast radius—not just CVSS.
Attack Surface Scanning	Maps externally reachable assets and effective internet exposure across environments.	Immediately highlights “front door” risks attackers would target first.
Deep Internal Analysis	Models lateral movement, privilege escalation, and data access chains using identity and network context.	Shows how small misconfigs become end‑to‑end attack chains so you can fix root causes.
Ownership Mapping & PR Fixes	Associates findings with teams/repos and generates code/IaC fixes via the Wiz Green agent.	Turns security findings into actionable PRs and tickets that engineering can self‑remediate.
Runtime Detection & Blocking	Uses an eBPF Runtime Sensor plus cloud/SaaS logs to detect and block exploitation attempts.	Validates that critical issues are fixed and stops active attacks—closing the loop from code to runtime.

Ideal Use Cases

Best for Fast, Low‑Friction Cloud Onboarding:
Because Wiz uses cloud API connections and a primarily agentless architecture, you can connect multiple clouds, see full inventory, and get prioritized risks within hours—ideal for M&A, audits, or leadership “show me now” moments.
Best for Replacing Fragmented Tooling with a Single Operating Model:
Because the Wiz Security Graph connects code, cloud, identities, network, data, and runtime into one context, it replaces siloed CSPM, vulnerability, and identity tools and provides a shared language for security and engineering.

Limitations & Considerations

API Permission Design:
You’ll need to work with your cloud/IAM teams to approve and deploy read‑only roles and service principals. Wiz provides least‑privilege templates, but internal governance processes can affect timelines. Align early to avoid delays.
Depth of Visibility Without Optional Signals:
Core inventory and prioritization work with API‑only connections, but to unlock the full value (especially runtime detections and certain data/secret insights), you’ll want to add logs and optional runtime sensors. Plan a phased rollout.

Pricing & Plans

Wiz is a cloud security platform (CNAPP) rather than a point tool, so pricing typically reflects:

Scope: Number of cloud accounts/subscriptions, workloads, and environments (prod vs. non‑prod).
Capabilities: Code scanning, cloud posture, vulnerability management, runtime protection, and security agents (Green/Red/Blue).
Support & Services: Enterprise features, support SLAs, and any onboarding assistance you opt into.

Common patterns:

Growth / Mid‑Market Plan:
Best for teams needing full‑stack visibility (code to cloud) for a smaller number of accounts and workloads, with agentless onboarding and core risk prioritization.
Enterprise / Global Plan:
Best for large, multi‑cloud organizations needing broad coverage across hundreds of accounts, full Wiz agent capabilities (Green/Red/Blue), and deep integrations with ticketing, SIEM, and existing security workflows.

For an exact quote and scoping, it’s best to walk through your environment and requirements with Wiz.

Frequently Asked Questions

How many cloud accounts should we connect in the first phase?

Short Answer: Start with a representative but manageable slice—typically your most critical production accounts and any internet‑exposed environments.

Details:
For onboarding, you don’t have to start “big bang.” A good pattern is:

Phase 1: A few high‑value prod accounts/subscriptions, including those hosting customer data and public‑facing apps.
Phase 2: Expand to all prod, then business‑critical non‑prod.
Phase 3: Cover the remaining long tail (lab, sandbox, legacy).

Even in Phase 1, you’ll see real attack paths and prioritized risks within an hour, which makes it easy to justify expanding coverage quickly.

Can we see prioritized risks during a PoC, or do we need a full deployment?

Short Answer: You can see full inventory and prioritized, contextual risks during a PoC, often within the first hour of connecting cloud APIs.

Details:
Because Wiz relies on agentless cloud API connections, a PoC isn’t a “fake” or limited dataset—it’s your real environment. As soon as:

Your cloud accounts are connected with read‑only roles.
Wiz starts ingesting configs, identities, vulnerabilities, and exposure data.

…the Wiz Security Graph will surface true attack paths and exploitable risks. Many teams use PoC findings to drive immediate remediation, retire legacy tools, and validate that Wiz’s prioritization aligns with how they think about exploitability and blast radius.

Summary

Onboarding Wiz via cloud API connections is designed to match the speed of modern cloud teams: connect environments with read‑only roles, let the Wiz Security Graph map your resources, identities, and data, and start working from a prioritized list of exploitable risks—often within the first hour.

Instead of wrestling with agents and spreadsheets, you get:

Full inventory across clouds in minutes to hours.
Risks ranked by exposure, identity paths, and blast radius.
Clear ownership mapping and code‑level fixes via Wiz Green.
Optional runtime validation and blocking via Wiz’s eBPF Runtime Sensor and Wiz Blue.

If your current onboarding experience with other tools is measured in months, the shift to an API‑driven, graph‑powered model is dramatic.

Next Step

Get Started