> For the complete documentation index, see [llms.txt](https://docs.sec1.io/user-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sec1.io/user-docs/11-cspm/3-onboarding.md).

# Onboarding & Your First Scan

Step-by-step guide to adding a cloud account to Sec1 CSPM, testing the connection, running your first scan, and reviewing assets, findings, compliance, and attack paths in the Sec1 console.

This guide walks you through connecting your first cloud account and running a scan on the **Sec1 console**. Make sure you have worked through the [Prerequisites](/user-docs/11-cspm/1-prerequisites.md) and created the read-only credential from [Required Permissions](/user-docs/11-cspm/2-permissions.md) first.

{% hint style="info" %}
**The whole flow in five steps:** create the read-only credential → add the account in the console → test the connection → run a scan → review results.
{% endhint %}

***

## Step 1 — Create the read-only credential

Create the scanning identity for the provider you are onboarding, using the roles from [Required Permissions](/user-docs/11-cspm/2-permissions.md):

* **GCP** — create a **service account**, grant it the GCP roles, and create a key (or configure Workload Identity Federation). Have the key JSON / federation details ready.
* **Azure** — create a **service principal** (app registration), grant it the subscription roles, admin-consent the Microsoft Graph permissions, and note the **Tenant ID, Client ID, and Client Secret** (or certificate).
* **AWS** — create the read-only **IAM role** for Sec1 to assume and note the **Role ARN and external ID**.

If you also want Kubernetes scanning, apply the in-cluster read-only RBAC binding to each cluster now (see the [Kubernetes section](/user-docs/11-cspm/2-permissions.md#kubernetes-on-each-cloud-gke--eks--aks)).

***

## Step 2 — Add the cloud account in the console

1. Sign in to the **Sec1 console** (through your SSO provider if configured).
2. Select the **team** that should own this connector — findings will be scoped to it.
3. Go to the **CSPM / Cloud Accounts** area and choose **Add cloud account**.
4. Select the provider (**GCP**, **Azure**, or **AWS** when available).
5. Give the account a recognisable **name** (for example, `prod-gcp-project` or `payments-azure-sub`).
6. Paste in the read-only credential from Step 1:
   * **GCP:** the service-account key JSON (or federation configuration) and target project / folder / org.
   * **Azure:** Tenant ID, Client ID, and Client Secret (or certificate), and the subscription(s) to scan.
   * **AWS:** Role ARN and external ID.
7. (Optional) Enable **Kubernetes scanning** if you granted those roles.

{% hint style="warning" %}
Only paste read-only credentials. Sec1 never needs write access — if a credential grants more than read, scope it down before connecting.
{% endhint %}

***

## Step 3 — Test the connection

Choose **Test connection**. The console validates that the credential authenticates and that the required read permissions resolve. If the test fails, the most common causes are:

| Symptom               | Likely cause                                       | Fix                                                                                    |
| --------------------- | -------------------------------------------------- | -------------------------------------------------------------------------------------- |
| Authentication failed | Wrong key / secret, or expired credential          | Re-issue the credential and re-paste it                                                |
| Missing permissions   | A required read role wasn't granted                | Re-check the role list in [Required Permissions](/user-docs/11-cspm/2-permissions.md)  |
| Cluster unreachable   | Private control plane not reachable by the scanner | Authorise the scanner on the cluster's authorized networks, or use a hybrid deployment |
| Partial results       | Kubernetes roles not granted                       | Add the optional roles, then re-test                                                   |

Once the test passes, **save** the connector.

***

## Step 4 — Run your first scan

1. Open the connector you just saved.
2. Choose **Scan now** (or enable a **schedule** so scans run automatically on a cadence).
3. The platform first builds an **asset inventory**, then evaluates posture, compliance, exposure, identity, and attack-path checks against it.

Scan time depends on the size of the account and whether Kubernetes is enabled — a first scan of a single project or subscription typically completes in minutes, and subsequent scans are incremental.

{% hint style="info" %}
**Point-in-time history:** each scan is retained as a snapshot, so you can track posture and compliance **trends over time** and see what changed between scans.
{% endhint %}

***

## Step 5 — Review results

When the scan finishes, explore the results in the console:

* **Assets** — the full inventory of discovered resources, filterable by type, account, region, and tag.
* **Findings** — misconfigurations and risks, each with severity, contextual remediation guidance, and **AI-assisted remediation**. Use **Ask-AI** to investigate a finding in natural language. Suppress a finding (with justification) when needed — the action is recorded in the audit trail.
* **Compliance** — posture mapped to the supported frameworks, with per-account and per-resource scoring and control-ID mapping. See [Frameworks & Coverage](/user-docs/11-cspm/4-frameworks-and-coverage.md).
* **Attack paths** — chained risks visualised from external exposure to critical assets, with blast radius and the optimal remediation point to break the path.
* **Prioritisation** — a risk-based "top risks to fix now" view that factors in exposure, asset criticality, and exploit/threat context, rather than severity alone.

***

## Step 6 — Report, assign, and ticket

* **Generate reports** — export compliance and findings reports as **PDF** or **CSV** for auditors and stakeholders.
* **Assign owners** — assign findings to team members for remediation.
* **Create Jira tickets** — raise a Jira ticket directly from a finding so remediation is tracked in your existing workflow.
* **Re-scan to verify** — after remediation, run another scan; the finding clears and the change is reflected in your point-in-time trend.

***

## Onboard at organization scope (multiple projects / subscriptions)

The steps above onboard one account at a time. If you granted the read-only roles at a **higher node** — a GCP **organization/folder** or an Azure **management group** (see [Organization-scope permissions](/user-docs/11-cspm/2-permissions.md)) — you can discover and onboard **many projects or subscriptions in one flow**.

1. **Provide the higher-node credential.** In **Add cloud account**, supply the credential scoped at the org/folder (GCP) or management group (Azure) instead of a single project/subscription.
2. **Sec1 discovers everything under the node.** Using the listing permission (`roles/browser` on GCP, the management-group hierarchy on Azure), Sec1 enumerates **all** child projects/subscriptions.
3. **Sec1 probes each for scannability.** Every discovered project/subscription is checked and labelled:
   * **✅ Scannable** — the inherited read-only roles and required APIs resolve.
   * **⚠️ Not scannable** — with the **reason** shown, for example a **missing role** on that child, a **disabled API** (such as Service Usage / Resource Manager), or an access-policy restriction.
4. **Search and multi-select.** Filter the discovered list (by name, ID, folder/management group, or scannable status) and **select the ones you want to onboard**. You can fix a ⚠️ reason and re-probe, or simply skip it.
5. **Deploy & Scan.** Choose **Deploy & Scan**. Each selected project/subscription is onboarded as an **independent account** — with its own scans, findings, compliance, and history — exactly as if you had added it individually.

{% hint style="info" %}
**Inheritance does the heavy lifting.** Because the roles are granted once at the higher node, projects/subscriptions added later inherit them too — re-run discovery to pick up new ones.
{% endhint %}

{% hint style="warning" %}
A ⚠️ **not-scannable** result almost always means a child is missing one of the inherited reads or has a required API disabled. Apply the missing role/API (see [Required Permissions](/user-docs/11-cspm/2-permissions.md)) and re-probe — no need to restart the whole flow.
{% endhint %}

### Organizing the Accounts view

However accounts were onboarded — individually or in bulk — the **Accounts** view lets you make sense of them at scale:

* **Group by Organization** — accounts clustered under their cloud organization/tenant.
* **Group by Folder / Management Group** — accounts clustered under their GCP folder or Azure management group, mirroring your cloud hierarchy.
* **Flat** — a single searchable list of all accounts.

The view is **searchable** in every mode, so you can jump to any project or subscription regardless of how it was onboarded.

***

## Next steps

* Onboard additional accounts, subscriptions, or clusters the same way.
* Set a **scan schedule** so posture stays continuously current.
* Review the [Frameworks, Coverage & FAQ](/user-docs/11-cspm/4-frameworks-and-coverage.md) page for what's covered and how data is handled.