Credentials
Credentials are the logins your scans use: authenticated network checks, web pages behind a login, Active Directory assessments and cloud posture assessments. You manage them under Credentials. Every secret is write-only. It is encrypted when you save it, never shown again, and sent only to the sensor running the scan. Who can manage credentials Who Can do Org owners and admins, and people with the Credential admin role Add, edit and delete credentials People with the Operator or Administrator role See each credential's name, type, scope and when it was last used, and pick credentials for their scans Personal account Manage your own credentials Nobody can read a secret back, not even the person who saved it. Credential types Type (as shown in the console) Used by What you enter Web: HTTP basic auth Web/service scans Username, password Web: bearer token Web/service scans Token Web: HTTP header (e.g. API key) Web/service scans Header name and value Web: session cookie Web/service scans Cookie (name=value; other=value) Network: SSH password Network scans Username, password; optional SSH port (default 22) and privilege escalation user and password (for su/sudo) Network: SSH key Network scans Username, PEM private key, optional passphrase; optional port and privilege escalation Network: Windows (SMB) Network scans Username, password, optional domain Network: SNMP v1/v2c Network scans Community Network: SNMP v3 Network scans Username, authentication password and algorithm (SHA-1 or MD5); optional privacy password and algorithm (AES or DES) Active Directory: domain account Active Directory assessments Username (without the domain), password, the domain's DNS name. A normal domain user is enough. Cloud: AWS account Cloud posture Access key of a read-only IAM user; optional role ARN and external ID Cloud: Azure subscriptions Cloud posture Tenant ID, application (client) ID, client secret Cloud: Google Cloud projects Cloud posture Service account key (JSON) Cloud: Microsoft 365 tenant Cloud posture Tenant ID, application (client) ID, client secret The form lists the read-only permissions each cloud credential needs. See Active Directory and Cloud posture for those assessments. Scope Every credential has a scope: the places it may be used. Keep it as narrow as the hosts you actually scan. A credential can have up to 50 scope entries. Credential Scope entries Rule Web Host names, IP addresses or host:port, one per line The credential is sent only to these hosts. Nothing else ever receives it. Network Host names, IP addresses or CIDR ranges, such as 10.0.0.0/24 Every target of a network scan that uses it must be inside the scope. Otherwise the scan is refused. Active Directory The domain, such as corp.example.com An assessment of any other domain refuses it. AWS / Azure / Google Cloud Account IDs, subscription IDs or project IDs Only these are assessed. Microsoft 365 The tenant itself Nothing else is assessed with it. A scan can use up to 10 credentials. For Network scans, you can use only one credential of each kind (SSH, SMB, SNMP). Adding, editing and deleting Go to Credentials → Add credential. Enter a name, choose the type, and fill in the scope and the secret. Click Save. The secret is now write-only. When you edit a credential, you can change its name and scope, and replace the secret. Leave the secret fields empty to keep the current secret. A new secret applies from the next scan. You can't change a credential's type. When you delete a credential, scans that use it fail until you pick another. Scans already running keep the copy they received. How credentials are protected For the full walkthrough, open Credentials → How we protect them. In short: Stored encrypted with AES-256-GCM. The key is derived separately for each organisation and each credential, from a master key held outside the database. Write-only. Never shown again after you save it, and never returned by the API. Delivered sealed to one sensor. When a scan needs a…
OrbitalCyber documentation