# Security and access


> The controls an IT or security review asks about, and where each one is documented: device hardening, certificates, private network access, sign-in, roles, and audit.

A review usually arrives as a list of questions. This page answers the first round and points at the page that answers the rest.

## Screens

Every screen connects outbound only, over TLS, and nothing connects in. [What the network needs](/docs/it-requirements/overview/what-the-network-needs/) has the detail, and [Hostnames and ports to allow](/docs/it-requirements/reference/hostnames-and-ports/) the allowlist.

A ScreenlyOS player runs nothing but Screenly. It is built on Ubuntu Core, updates the operating system and the player together over the air with signed, transactional updates that roll back if they fail, has no remote login and no open ports, and encrypts storage where the hardware supports it. On a Screenly Player Max, credentials for protected dashboards live in the TPM. [What ScreenlyOS is](/docs/screenlyos/overview/what-is-screenlyos/) covers the design, and [ScreenlyOS or Screenly Anywhere](/docs/screens/overview/screenlyos-or-screenly-anywhere/) has the section written for security teams, including what is and is not true of a Screenly Anywhere screen running inside another vendor's system.

Each screen has its own device certificate, signed by the Screenly certificate authority, and a service on your network can require it before serving a page. [Device certificates](/docs/screens/managing/certificates/) explains how to download them, and [Authenticated pages](/docs/content/web-pages/authenticated-pages/) how to verify a screen rather than the whole fleet.

Screens that need to show something on a private network can join your Tailscale network, configured once for the workspace, on ScreenlyOS only. See [Reaching your private network](/docs/integrations/network/private-network-access/).

Remote screenshots can be turned off per screen with Privacy Mode, for displays showing sensitive information. See [Screenshots](/docs/screens/monitoring/screenshots/).

## People

There are no passwords. People sign in with a one-time email code, a passkey, or an existing Google, GitHub, or Microsoft account, and can add two-factor authentication. Enterprise workspaces can require SAML single sign-on. See [Ways to sign in](/docs/account/signing-in/ways-to-sign-in/), [Securing your account](/docs/account/securing/), and [Single sign-on](/docs/workspaces/settings/single-sign-on/).

Four roles decide who can change what inside a workspace; every role sees every screen, and separation of screens between groups of people is done with separate workspaces, which are isolated from each other. See [Roles and permissions](/docs/workspaces/people/roles-and-permissions/) and [What a workspace is](/docs/workspaces/overview/what-a-workspace-is/). Access that should expire on its own is covered in [Temporary access](/docs/workspaces/people/temporary-access/).

API tokens carry the permissions of the person who created them and are managed per workspace. See [API tokens](/docs/developers/overview/api-tokens/).

## Audit and billing controls

Audit logs, linked workspaces with consolidated billing, and a support SLA are Enterprise features. The workspace [Security](/docs/workspaces/settings/security/) settings page is where SAML, API tokens, and Tailscale live, and [Plans for Screenly](/docs/get-started/plans/plans-for-screenly/) lists what each tier includes.