> 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

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.