The page your security team asked for
Single sign-on with your own provider. Two-factor authentication you can require of everyone. Roles built from individual permissions and granted per location. Designs whose locks are enforced on our servers, not drawn in the interface. Emergency takeover that tells you which screens received it. An audit log nobody can edit.
How to read this page. Everything below is a capability you can turn on and check yourself, in the product, on your own workspace. If your review asks something this page does not cover, send it to [email protected] and we will answer it line by line.
Your identity provider, your rules
Set up in the product, by you, on any plan. There is no enterprise upgrade gate on single sign-on and no professional-services fee to switch it on.
Single sign-on (OIDC)
Route one or more of your email domains to your own identity provider. Microsoft Entra ID, Google Workspace, Okta, Auth0 and any other OpenID Connect provider. You set it up yourself in Settings → Security; you do not raise a ticket and you do not pay a platform fee for it.
Domain verification before a connection goes live
A connection only appears at sign-in after Brix has verified by DNS that you control the email domains listed on it. This is what stops somebody else claiming your domain and provisioning themselves an account inside your workspace.
Just-in-time provisioning, with a role you choose
A person who signs in through your provider for the first time becomes a member with the role you nominated. You can turn this off and invite people explicitly instead.
Two-factor authentication, enforceable workspace-wide
Time-based codes from any authenticator app, plus ten one-time recovery codes. An administrator turns it on for every member in Settings → Security: a person without it is blocked at sign-in and sent to set it up. The requirement is enforced on the single sign-on path as well as the password path.
Require single sign-on for everyone
A workspace policy: anybody whose email domain one of your connections covers can only sign in through it, and a Brix password stops working for them. Somebody on a domain no connection covers keeps their password, because they would otherwise have no way in. Brix refuses to turn the policy on until you have a verified connection that could serve it.
Passkeys
Sign in with a fingerprint, a face or a hardware security key. One passkey per device, named by you, removable at any time.
Password-free accounts
Once a person has a passkey or a connected provider, they can remove their password entirely. Brix always keeps one working way in, so no action on the security page can lock a person out.
Who can do what, where
Eight roles come built in — Owner, Admin, Finance, Content Manager, Approver, Local Manager, Installer and Viewer. Every one of them is a starting point you can copy and change, and you can build a role from scratch out of individual permissions.
Every action is written to an audit log
Who did it, what they did, what they did it to, and when. The log is append-only — no role can edit or delete an entry — and it is never purged. Export the current view to CSV for your own records or for an auditor.
Permissions are per-action, not per-plan
Twenty-four kinds of thing (screens, playlists, schedules, designs, media, users, roles, billing, the audit log, emergency takeover and more) each carry their own verbs: view, create, edit, delete, approve, publish, share, export, cast, manage permissions. A role is any combination you choose.
Access is scoped to places, not just to the account
Your organization is a tree you name yourself — the tiers are yours to label. A role is granted at a place in that tree and covers everything beneath it, so a person who runs two libraries sees two libraries.
Content can require approval before it airs
Approval is set per place and inherited down the tree. It can escalate: a site signs off, then the district signs off. The chain is fixed at the moment the request is made, so moving the content afterwards cannot dodge a step.
A shared design stays the author’s
Our servers enforce the lock — the interface only draws it. A recipient never writes to your design. Brix holds their changes separately and merges them when a screen asks for its content. So your later edits still flow down, and a lock you add tomorrow applies immediately.
One workspace cannot read another
Every query is scoped to the workspace that made it. A request for another workspace’s content answers "not found" rather than "not allowed", so the existence of another customer is never disclosed.
Nothing is deleted the moment you delete it
Deleting marks the item and moves it to a recycle bin for 30 days. This is the mechanism, not a courtesy — the row is still there, and a mistaken deletion is recoverable by you, without contacting us.
Integrations get their own credentials
API keys are separate from people, carry their own permissions, and are listed and revocable. A person leaving does not take an integration down with them, and an integration cannot inherit a person’s access.
The message that has to get through
Prepare your messages before you need them — an evacuation, a lockdown, a severe weather warning, an all-clear. When one is triggered, every screen in scope switches to it.
It layers over, it does not replace
A takeover occupies a separate slot on each screen. Clear the takeover and every screen returns to its normal content. You have no re-assignment to undo afterwards, and nothing to remember.
Pre-staged content survives an outage
Mark a message as pre-staged, and every screen in scope caches its content in advance. The trigger then does not depend on the venue’s internet connection at the moment you need it.
You are told which screens received it
Brix confirms per screen that the message is on the glass, not merely sent. Brix names a screen that is off, or stuck on old content, as not reached — it never counts it as delivered.
Scoped like everything else
Trigger across every screen, one part of your organization, or a hand-picked set. Only people you grant the emergency permission to can do it.
Set it to clear itself
Choose an automatic clear — 30 minutes, an hour, four hours — or leave it in place until somebody clears it deliberately.
Every incident is on the record
Who triggered the takeover, what it said, how many screens it reached, who cleared it and when. The page reads as a history, because that is what you need after an incident.
The parts you cannot see
- Where it runs
- Cloudflare’s network. There is no server of ours for an attacker to reach, and no operating system of ours to patch.
- In transit
- TLS on every connection — the browser to Brix, Brix to your screens, and your screens to Brix. No plain-text path exists.
- At rest
- Your media sits in object storage that is not publicly listable and is served only through short-lived signed links. Credentials you give us for a connected account are encrypted before they are stored, and are never returned to the browser.
- Sessions
- The session credential is an HttpOnly cookie, so no script on the page can read it, with a server-side check that the request came from Brix.
- Data residency
- Choose United States or European Union at sign-up. The European option places your media physically inside Cloudflare’s EU jurisdiction. Media never crosses between the two.
- Recovery
- The database is continuously captured and can be restored to any second within the last 30 days. Our recovery objective is one minute of data and thirty minutes of downtime. Media is protected by preventing deletion rather than by versioning — see the note below.
- If your internet drops
- Screens keep playing. Content is cached on the device, so a venue that loses its connection carries on showing what it was told to show, and catches up when the connection returns.
Asked by security teams
Can we bring our own identity provider?
Yes. Add a connection in Settings → Security with your issuer URL and client credentials, list your email domains, and paste the redirect URL Brix gives you into your provider. A Test button reads your provider’s discovery document first, so a wrong tenant is caught before you finish. Microsoft Entra ID, Google Workspace, Okta, Auth0 and any other OpenID Connect provider are supported.
Can we require two-factor authentication for everybody?
Yes. Turn it on in Settings → Security and every member of the workspace must have an authenticator set up. A person without one is blocked at sign-in and steered to set it up, on the single sign-on path as well as the password path.
Can a team edit the words on a design without touching the design?
Yes, and you choose per layer how far that goes. Each layer on a design is set to one of five levels: they can change nothing, the wording only, the wording and whether it shows, the wording and how it looks, or anything. The rule is enforced when their change is submitted, so an interface that has been tampered with cannot get around it.
Who can trigger an emergency message, and what happens to the screens?
Anybody you give the emergency permission to, scoped to the places you choose. A takeover sits over each screen’s normal content rather than replacing it, so clearing the takeover returns every screen to what it was showing. Brix then reports, per screen, whether the message actually arrived — a screen that is off or stuck is named rather than counted as reached.
Does an emergency message still work if the building loses its internet?
If you mark the message as pre-staged, yes. Its content is cached on every screen in scope before anything happens, so triggering it does not depend on the network at the moment you need it.
Can somebody see billing without seeing our screens?
Yes. The built-in Finance role has invoices and billing settings and no access to screens or content at all. Roles are combinations of individual permissions, so any separation you need can be expressed.
Where is our data held?
Choose United States or European Union when you sign up. The European option places your media physically inside Cloudflare’s EU jurisdiction, and media never crosses between regions. If you need another region, ask — we will tell you honestly what we can and cannot guarantee for it.
How do we report a security problem?
Email [email protected]. We will acknowledge within one business day and tell you what we found and when it will be fixed.
We checked every statement on this page against the running product on 17 August 2026. Tell us at [email protected] if you find one that is wrong, and we will correct it here.
Send us your security questionnaire
We would rather answer it properly than have you guess from a feature list. Send it over, or book half an hour and we will go through your acceptance criteria line by line.