Security

1. Two deployment models, two data paths

Scanopy runs in one of two ways, and the difference determines where your network data lives.

Self-hosted

You run the full Scanopy stack (server, database, and daemon) inside your own infrastructure. Discovery data is stored in your database and is not transmitted to Scanopy. Self-hosted is available as the free, open-source Community Edition and as the paid Commercial Edition.

Scanopy Cloud

You run only the lightweight daemon on your network. It connects to Scanopy's hosted server, which stores your topology and account data. The daemon transmits the discovery results described in section 2 (host and network metadata). All daemon-to-server and client-to-server communication uses HTTPS/TLS, with certificate validation enabled by default.

Scanopy Cloud is hosted in the United States. The application server runs on Hetzner compute, and the database that holds your topology and account data is a managed Neon Postgres instance, both in the United States.

How the daemon connects

The daemon connects in one of two modes. In DaemonPoll mode (the default) the daemon initiates all connections and polls the server, so it needs no inbound ports open to it, which suits daemons behind NAT or a firewall. In ServerPoll mode the server initiates connections to the daemon, for DMZ deployments where the daemon cannot make outbound connections. Both use HTTPS/TLS. For operational detail, see the architecture reference and daemon deployment planning.

2. What the daemon collects, and what it does not

Without a credential, the daemon tries the listed methods on every host in the subnets you configure, and reads the machine it runs on directly. A host contributes data only through the methods it answers. With a credential, an integration collects only from the devices, controllers, hypervisors and container runtimes that credential reaches.

What the daemon does not do:

• No packet-payload capture. Scanopy discovers devices and services; it does not capture, inspect, or store the contents of network traffic. It is a documentation tool, not a traffic-analysis or monitoring tool.
• No credential exfiltration. The credentials you give the daemon to query devices are used to query those devices. See section 3 for how they are stored.

3. Credential handling

To read from SNMP devices, Docker sockets, and similar sources, the daemon needs credentials. You control how those are stored, and there are two options:

• File-backed on the daemon host. A credential can be a reference to a file on the machine running the daemon. The secret is read from that file at scan time and is never sent to or stored on the Scanopy server. The secret stays where you put it.
• Stored with Scanopy. Alternatively, a credential can be saved through Scanopy so you do not have to manage files on each host. On Scanopy Cloud, those secrets are held in the hosted database; on self-hosted, they are held in your own database.

For SNMPv3, the privacy (encryption) layer uses AES-128 or AES-256, so device queries are encrypted on the wire when the device supports it.

4. Access, authentication, and isolation

Authentication

Scanopy supports email and password with email verification, and single sign-on via OpenID Connect (OIDC). On Scanopy Cloud, Google and Microsoft identity providers are available. On self-hosted and enterprise-managed deployments, any OIDC-compliant provider can be configured, including Authentik, Keycloak, Auth0, and Okta. Bring-your-own OIDC (Custom SSO) is available on every self-hosted edition and on Enterprise, and SAML is coming soon; see pricing for how they are tiered. Anyone can create a Scanopy Cloud account, which creates a new organization. On self-hosted, the free Community edition is limited to a single organization, so the first account becomes its owner and further accounts join by invitation; paid editions raise or remove that limit. Joining an existing organization requires an invitation from an organization administrator.

Tenant isolation

The organization is the top-level tenant boundary. Within an organization, each site holds its own hosts, services, subnets, and topology, and users can be restricted to specific sites. Every API query is scoped to the authenticated user's organization and permitted sites. This is logical multi-tenancy with application-enforced boundaries.

Least privilege

The daemon needs elevated permissions on its host to send raw packets for scanning (root or the CAP_NET_RAW capability on Linux, administrator on macOS and Windows, and optional Docker or Podman socket access for container discovery). The server itself runs as a standard, unprivileged user process.

Logging

Authentication and access activity is recorded in Scanopy's application logs, including sign-in successes and failures, sign-outs, registrations, password and email changes, SSO link and unlink events, and API key authentication failures and key rotation.

Reporting a vulnerability

Report suspected vulnerabilities to [email protected] or through GitHub Security Advisories. Our policy is published at /.well-known/security.txt. Please give us a chance to address an issue before disclosing it publicly.

5. Certifications

Scanopy does not currently hold a formal certification such as SOC 2 or ISO 27001.

7. Subprocessors (Scanopy Cloud)

Scanopy Cloud relies on the following subprocessors. Self-hosted deployments use none of them for your network data.

• Hetzner (United States): application server and compute hosting.
• Neon (United States): managed Postgres database that stores your topology and account data.
• Stripe: payment processing.
• Amazon Web Services (SES): transactional email delivery.
• PostHog: product analytics.

See the Privacy Policy for each vendor's role in more detail.