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 and created the read-only credential from Required Permissions first.
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.
Step 1 — Create the read-only credential
Create the scanning identity for the provider you are onboarding, using the roles from Required Permissions:
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).
Step 2 — Add the cloud account in the console
Sign in to the Sec1 console (through your SSO provider if configured).
Select the team that should own this connector — findings will be scoped to it.
Go to the CSPM / Cloud Accounts area and choose Add cloud account.
Select the provider (GCP, Azure, or AWS when available).
Give the account a recognisable name (for example,
prod-gcp-projectorpayments-azure-sub).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.
(Optional) Enable Kubernetes scanning if you granted those roles.
Only paste read-only credentials. Sec1 never needs write access — if a credential grants more than read, scope it down before connecting.
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:
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
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
Open the connector you just saved.
Choose Scan now (or enable a schedule so scans run automatically on a cadence).
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.
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.
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.
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) — you can discover and onboard many projects or subscriptions in one flow.
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.
Sec1 discovers everything under the node. Using the listing permission (
roles/browseron GCP, the management-group hierarchy on Azure), Sec1 enumerates all child projects/subscriptions.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.
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.
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.
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.
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) and re-probe — no need to restart the whole flow.
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 page for what's covered and how data is handled.
Last updated