Security FAQ and trust model

This page says plainly what the service can do on your computers, who can trigger it, how the pieces authenticate each other and where your data lives. It is written for the person who has to approve the deployment.

The trust model in one paragraph

The agent runs as SYSTEM on Windows and as root on Linux. Whoever can queue a Run Script, Deploy Software or Deploy Updates action in your organization can run arbitrary code with those rights on every endpoint they target. That is the product: it is how updates get installed. It also means a console account with the Operator role is as sensitive as a domain administrator account, and must be protected accordingly (multi-factor authentication, least-privilege roles, IP allow list, audit review). The same applies to the enrollment key, which lets anyone enroll a computer, and to API credentials.

Who can do what

• Roles: Viewer (read only), Operator (run actions, approve updates), Administrator (everything, including users, roles and settings). Custom roles pick individual permissions (for example "run scripts" without "manage users").
• Platform operators: Idolbe staff designated as platform operators can open every organization for support. Their actions are recorded in your Audit Trail with their email address, like any other user's.
• Audit Trail: sign-ins (including failures and lockouts), every action queued, every setting changed, every API write call, exports, key rotations, account closure. Retention is configurable (Advanced → Data).

Authentication

• Console users: passwords are hashed with scrypt; email-based multi-factor authentication is on by default for password sign-ins, with trusted browsers for 30 days (both configurable). Each user can enrol an authenticator app (TOTP: Microsoft Authenticator, Google Authenticator, 1Password…) with one-time recovery codes; it then replaces the emailed code. Microsoft Entra ID, Google or any OpenID Connect provider (Okta, Duo, Keycloak…) can be required instead of passwords. Sessions are httpOnly, secure cookies with an idle timeout (8 hours by default); changing a password revokes the other sessions.
• Brute force: 5 wrong passwords lock an account progressively; 20 failures from one IP address throttle it; the same limits apply to MFA codes, password resets and API token requests (HTTP 429 with Retry-After).
• IP allow list: restricts the console and the API to your addresses (Advanced → Security). Agents are never restricted.
• Agents: each endpoint holds its own token, issued at enrollment and stored hashed (SHA-256) on the server; it is sent as a bearer header only and compared in constant time. The enrollment key only serves to obtain that token; rotate it from Organizations → Rotate key if it leaks.
• API: OAuth 2.0 client credentials, one-hour tokens, permissions inherited from the credential's role (REST API v1).

What runs on the endpoint, and how it is verified

• Every agent release is signed with an Ed25519 key kept offline by Idolbe. Agents verify that signature before installing a self-update; the Linux installer also checks the SHA-256 the console sends with the binary.
• Windows executables are not yet Authenticode-signed, so SmartScreen may warn on a manual install; silent deployment shows no prompt. Authenticode signing is in progress and will be announced on the status page.
• The agent only executes what the console queues for its own endpoint id; commands are fetched by the agent (outbound HTTPS), never pushed to it. Commands carry timeouts and output limits, and the process tree is killed when they expire.
• Active Directory Deployer credentials are stored encrypted with the server secret, delivered to the deployer once per scan over its authenticated channel and passed to the deployment script through standard input, never through the command line or the environment.

Data: what is stored, where

• Collected from endpoints: hardware and OS inventory, installed software, missing and installed updates, services, shares, local administrators, logged-on user names, IP and MAC addresses, disk usage, agent logs of the commands you run. No file contents, no documents, no browsing history, no keystrokes.
• Derived: vulnerability matches (CVE, CVSS, deadlines), compliance figures, reports.
• About people: user accounts (name, work email, role), audit trail entries, logged-on user names reported by endpoints.
• Where: the console and its PostgreSQL database run on OVHcloud servers in the European Union. Backups are taken nightly and kept 30 days. Vulnerability data is fetched from NIST NVD, CISA and Microsoft; the third-party version catalog from the winget-pkgs repository on GitHub; none of these receives your inventory.
• Transport: HTTPS only (TLS certificates from Let's Encrypt), HSTS and security headers on the console.
• Retention and deletion: Data retention and account closure.

Multi-tenancy

Every record is bound to an organization. Every request re-reads the record with the caller's organization and answers 404 when it belongs to another one; bulk operations intersect the ids you send with the organization's own endpoints. Users who belong to several organizations switch explicitly and see one at a time.

Hardening checklist for customers

1. Keep email MFA on and enrol an authenticator app on every administrator account, or require single sign-on (Advanced → Security → Identity Provider).
2. Give Operator or Administrator only to people who would be trusted with domain administration; use custom roles for helpdesk staff.
3. Put your office and VPN ranges in the IP allow list.
4. Create one API credential per integration with a dedicated role; rotate secrets when staff leave.
5. Rotate the enrollment key after a mass deployment and whenever it was shared outside IT.
6. Review the Audit Trail weekly and configure the "Endpoint offline" alert on pilot machines.
7. Keep Agent Auto-Update on so security fixes in the agent reach every endpoint at the next check-in.

Reporting a vulnerability

Write to the support address shown in the console footer with "security" in the subject. We acknowledge within two business days, keep you informed, and credit you if you wish. Please do not test against other customers' organizations.