Secure your account
Protect your account and keep portal, API, and service credentials separate.
Keep portal identity separate from workload credentials
Portal login controls account access, billing actions, and settings. Service consoles, API keys, SSH access, and workload credentials are separate and should be handled separately.
Important boundary
Changing your portal password does not replace API keys or service credentials. Each access type exists for a different job and should be managed separately.
Security settings and service access
After your first sign-in, decide how the account should be protected and how your team should access services without mixing portal login with workload credentials.
Important boundary
- portal login controls account access, billing actions, and account settings
- API keys are for automation and should be managed like integration secrets
- service consoles, SSH access, and workload credentials belong to the individual service they operate
- rotating one access type does not automatically replace the others
Recommended security order
- keep one strong owner account for the organization
- add passkeys for frequent portal users on supported devices
- enable TOTP for accounts with billing or production impact
- store recovery codes somewhere secure and reachable during incidents
- keep API secrets and service credentials in separate secrets storage
Security features available in account settings
Account settings currently support these security controls:
- set or change a password
- enable passkeys and manage saved passkeys
- link or unlink supported OAuth accounts such as Google and GitHub
- enable or disable TOTP-based two-factor authentication
- download and retain recovery codes when TOTP is enabled
What recovery codes are for
When you enable TOTP, the setup flow provides one-time recovery codes. Save them somewhere safe. They are meant for the moment when you lose access to the authenticator app, not for everyday login.
Service access is different from portal login
Some services expose their own actions, consoles, or credentials after provisioning. That access is about operating the service itself. Your portal account is still the customer identity that owns the invoices, settings, and account-level permissions.
That separation is useful because it lets you:
- keep ownership tied to the customer account
- limit who can operate a workload directly
- rotate service access without changing the core customer identity
A simple rule to follow
Use the portal account for customer administration. Use service-specific access only for the service it belongs to.