Security model

Helios holds credentials for your clients' most sensitive systems, so the security model is documented plainly here: how tenants are isolated, how accounts are protected, and how secrets are stored.

Tenant isolation

Every MSP on Helios is a separate tenant. Every query that touches clients, devices, tickets or settings is scoped to the requesting tenant on the server side; there is no client-side filtering to bypass. The same boundary applies to automation: a tenant's alert rules and healing scripts can only ever run against that tenant's own devices. API keys carry the same hard scoping.

Account security

• 2FA is mandatory for admins. Admin and platform accounts must enrol TOTP two-factor on first login; it is not optional. Trusted devices can skip the prompt for 30 days.
• Passkeys: any user can register WebAuthn passkeys and sign in with them.
• Intermediate login tokens (for example, the token issued between password and 2FA) cannot be replayed as session tokens.
• Client portal users are viewers: they can see and request, never change.
• Per-engineer client access. Under Users → Client access, limit any engineer to the clients they should see. The restriction is applied on the server to every list, search, report and device page, so a client outside the list does not appear at all.

The credential vault

Per-client credentials live in an encrypted vault (Fernet symmetric encryption with a key held in server configuration, not in the database). Vault access is logged. The same encryption protects per-tenant integration secrets such as SMTP, IMAP and API credentials. The rule the product follows internally: prose lives in IT documentation, secrets live in the vault.

Agents and remote access

Each device agent authenticates with its own secret enrolment token; one compromised device does not impersonate another. Agents are CI-built, and remote access sessions are initiated from within Helios, so they inherit your account security including 2FA.

Install links cannot be guessed. The link that installs the agent for a client carries a random key, not the client's name, and a link for a closed account or the public demo hands out nothing. You can regenerate a client's link at any time, which invalidates every copy of the old one without touching enrolled machines. Each enrolment is recorded in the audit log with the address it came from and announced to your admins. The key is still a secret: anyone you send the link to can install until you regenerate it, so send it to the person doing the install rather than posting it somewhere shared.

Every script is checked before it runs. The script engine is powerful, so each script is scanned after its parameters are filled in and before it reaches a device. One that fetches a known remote-access tool, or downloads and executes an arbitrary payload from the internet, is high risk: a trial account cannot run it, and a paying tenant is warned and the run is logged. Domains you trust go under Settings → Notifications → Trusted script domains, and scripts that only touch those pass without comment.

Offboarding removes the agent. When a tenant is switched off, every one of its agents is told to uninstall itself at its next check-in. A machine that was offline that day still cleans up when it reconnects, so nothing of Helios is left behind on estates you no longer manage.

Ongoing practice

The platform undergoes recurring internal security audits covering tenant isolation, authorisation and injection surfaces, and findings are fixed before feature work continues. Billing is handled by Stripe; card details never touch Helios servers.

Questions a security review needs answered? Email support@heliosmsp.io and you will get specifics, not marketing.