Skip to content
Log inGet started

Trust & security

Security at WeDisplay

Last reviewed 30 July 2026. This page describes the service as it is deployed today.

This page sets out, in concrete terms, who runs WeDisplay, where it runs, and what protects the data you put into it. It is written for the person who has to sign off on a new vendor — so it also says plainly what we do not have.

Everything below is a factual description of the running system, not a contractual commitment. The binding terms live in our Terms of Service, Privacy Policy and Data Processing Addendum.

1. Who runs WeDisplay

WeDisplay is operated by EN6IA, a company registered in Québec, Canada under Québec enterprise number (NEQ) 2266497173, doing business as WeDisplay. That is the legal entity named in our Terms of Service, Privacy Policy and Data Processing Addendum, and the party you contract with. The company name and the NEQ appear in all three of those documents, so you can check them for yourself — they are collected, with every other policy, in the Legal Center.

2. Data in transit

  • HTTPS everywhere. The marketing site, the dashboard, the APIs and the player all run over TLS. Plain HTTP is permanently redirected to HTTPS.
  • HSTS. Production responses carry Strict-Transport-Security: max-age=31536000; includeSubDomains, so a browser that has seen the site once refuses to talk to it unencrypted for a year, on every subdomain.
  • Hardened response headers. Every response also sets X-Frame-Options: SAMEORIGIN, X-Content-Type-Options: nosniff and Referrer-Policy: strict-origin-when-cross-origin, plus a Permissions-Policy that switches off geolocation, USB, serial, Bluetooth and MIDI.
  • The Android player refuses cleartext. Our Android TV application ships with usesCleartextTraffic=false, so the operating system itself blocks any unencrypted connection the app could attempt — even a misconfigured one.
  • Live streaming. Screen sharing and live sources use WebRTC, which the protocol encrypts in transit. The relay it falls back to when a direct path is impossible is our own server rather than a third party service, and its credentials are time-limited and issued on demand instead of being hardcoded into the player.

3. Tenant isolation and access control

  • Every query is organization-scoped. API routes resolve the caller's organization on the server and constrain the query to it, so one customer's screens, media, playlists and reports are not reachable from another customer's session — regardless of which identifiers the client sends.
  • 24 granular permissions across 10 categories. Access inside an organization is governed by individually assignable permissions grouped into screens, media, playlists, layouts, sources, team, settings, conference, reports and AI assistant — not a handful of coarse roles. A team member gets exactly what their security group grants, and platform-administration routes are checked separately again.
  • The realtime plane is authenticated too. The WebSocket connection that pushes content to screens decodes the signed session cookie during the handshake and joins the socket to an organization-scoped room. Every control and signalling message is then authorized against the specific screen or source it targets, using the identity registered at connect time rather than any identifier in the message body.
  • Audit log. Sensitive account and administrative actions are recorded in a per-organization audit log.

4. Authentication

  • Sessions. Sign-in is built on Auth.js v5 with signed JWT session cookies that expire after 7 days. The cookies are HttpOnly, Secure and SameSite=Lax, and use the __Secure- and __Host- cookie prefixes over HTTPS.
  • Passwords. Passwords are hashed with bcrypt at cost factor 12 and are never stored or logged in the clear. Repeated failed sign-ins against the same account are throttled.
  • Single sign-on, on request. WeDisplay ships OIDC (Microsoft Entra ID and Google Workspace), SAML 2.0 with per-domain connections bound to a domain you have verified, and SCIM 2.0 user and group provisioning so joiners and leavers are handled by your identity provider. All three are built and shipped, and are activated per customer rather than being on by default.
  • Production refuses to start with a weak secret. The server checks its session-signing secret at boot and aborts if it is missing, a known default, or shorter than 32 characters. A forgeable signing key is the one failure that would defeat everything else on this page, so it is enforced by the process, not by a checklist.

5. Backups and recovery

  • Every six hours, off the instance. A dedicated sidecar container dumps the production PostgreSQL database every six hours and uploads it to Cloudflare R2 object storage — deliberately a different provider from the one hosting the application, so one provider's bad day cannot take out both the system and its backups.
  • Tiered retention. Six-hourly dumps are kept for 2 days, daily dumps for 30 days and weekly dumps for 90 days; anything older is pruned automatically.
  • Media as well as rows. Uploaded media files are synced to the same off-site storage, so the files survive the loss of the instance and not merely the database rows that describe them.
  • Monitored. Each completed backup cycle pings an external heartbeat monitor, so a silently failing backup raises an alert instead of being discovered during a restore.
  • The restore has actually been performed. On 30 July 2026 we pulled the latest backup from off-site storage, replayed it into a scratch database and compared it against live production: 54 tables, 68 schema migrations and 88 foreign-key constraints present, and identical row counts on both sides for users, organizations, screens, media, playlists and play logs. The scratch database was dropped afterwards and production stayed healthy throughout. An untested backup is a hypothesis; this one has been tested.

What that does not mean. It is not a recovery-time or recovery-point guarantee, and we do not offer a contractual uptime SLA today. WeDisplay currently runs as a single instance in one region: losing that host would mean rebuilding from a dump that could be up to six hours old, with downtime while that happens. Replicated database hosting with point-in-time recovery is on our roadmap and is not in place yet. Current availability is published on our status page.

6. Application hardening

  • Rate limiting. Account registration, password reset and change, device and source pairing, player content polling, conference joining, invite verification, lead submission and the public QR and widget-data endpoints are all rate-limited.
  • Uploads are checked by content, not by name. Every upload is validated against an extension and MIME allowlist and against its actual file signature (magic bytes), so an executable renamed to .png is rejected. Office documents have to carry a genuine OOXML manifest, not merely a ZIP header.
  • Media is served only for registered files. The media endpoint looks the requested path up as a database-registered media record before it reads anything from disk, and rejects path-traversal segments outright. No route serves an arbitrary filesystem path.
  • SSRF guard on outbound fetches. When the platform fetches a URL on your behalf — data widgets, integrations, webhooks — the hostname is resolved first and rejected if any resolved address is loopback, private, link-local, carrier-grade NAT or multicast. The connection is then pinned to the exact addresses that were validated, so DNS rebinding cannot swing it to an internal host mid-request; redirects are never followed, and the response body is capped as it streams.
  • Secrets encrypted at rest. Credentials the platform holds on your behalf — connected-calendar tokens, provider API keys, billing keys — are encrypted with AES-256-GCM before they are written to the database.
  • Dependencies. We monitor security advisories against our dependencies and patch what is reachable at runtime as routine maintenance; the most recent full security and dependency pass shipped in July 2026.

7. Where your data lives

The WeDisplay application and its PostgreSQL database run on infrastructure operated by OVH in Canada. Our WebRTC relay runs on the same infrastructure, so live-stream relay traffic is never handed to a third-party streaming provider. Cloudflare sits in front of the application as CDN and web application firewall, and also holds the off-site backups described above.

Some sub-processors we rely on for specific functions — payments, transactional email, identity providers, the optional AI assistant — process data on servers outside Québec, including in the United States and the European Union. Each of them is named individually in Section 5 of our Privacy Policy, and before relying on such a transfer we assess whether the recipient offers protection equivalent to what Québec law requires. If you need a specific residency arrangement, raise it with us before you sign rather than after.

8. Privacy, and what runs on your screens

  • Québec Law 25 and PIPEDA. Our privacy program is written to comply with Québec's private-sector privacy act (Law 25) and Canada's PIPEDA, and we honour GDPR, UK GDPR and CCPA/CPRA rights where they apply. We have a designated Privacy Officer, an internal register of confidentiality incidents, and a breach-notification process that includes the Commission d'accès à l'information du Québec where the law requires it.
  • We do not sell or share personal information as those terms are defined under the CCPA/CPRA, and we do not disclose personal information to third parties for their own marketing.
  • No third-party trackers. Every cookie WeDisplay sets is first-party and functional: your sign-in session, the sign-in plumbing that protects it (an Auth.js CSRF token and callback URL, which our authentication layer sets on any visit, signed in or not), your cookie-consent choices, your language and interface preferences, the display currency you pick on our pricing page if you change it (a display preference only — every plan is billed in US dollars), and — only if you grant functional consent — a referral code. There is no analytics suite, no advertising pixel and no third-party tracking script anywhere in the product. Our Cookie Policy explains what they do and how to change your choices.
  • No ad networks on your screens. The player embeds no advertising network and no audience-measurement SDK. Free-plan screens carry a WeDisplay watermark and occasional WeDisplay promotional spots — our own content, served by us, with no third party involved and no viewer data collected — and paid packages can be set ad-free. Content you choose to display is of course yours: a web page or widget you embed runs whatever its own publisher put there.

9. What we do not have yet

A trust page is only useful if it also lists what is missing, so here it is, plainly.

  • No SOC 2 report and no ISO 27001 certificate. WeDisplay holds no third-party security certification or attestation today — not SOC 2, not ISO 27001, not PCI DSS, not a HIPAA attestation. Our Data Processing Addendum says so in the same words. If a certification is a hard requirement for your organization, we are not the right fit yet, and we would rather you learn that here than three months into a procurement cycle.
  • No published third-party penetration test. We run internal security audits and remediate what they find, but we have not commissioned an external penetration test whose report we could hand you.
  • No contractual uptime SLA. The service is provided as-is under our Terms of Service. Live availability is published on our status page.
  • Single region, single instance. As set out in Section 5, backups are off-site and their restore has been tested, but the application itself has no automatic failover today.

We would rather publish this list than be found out on it. If any item here is a blocker for you, tell us — it helps us sequence the work.

10. Reporting a problem, or asking us anything

If you have found a security issue in WeDisplay, email [email protected] with enough detail for us to reproduce it. We will confirm receipt and keep you informed while we investigate, and we will not pursue anyone who reports a genuine issue in good faith and does not access, alter or destroy other people's data in the process.

For a vendor security review or a security questionnaire, write to the same address and tell us what you need — we would rather answer honestly, including where the answer is no, than leave a blank. Privacy requests go to our Privacy Officer at [email protected], and a countersigned Data Processing Addendum can be requested at [email protected].

Questions about anything on this page? Write to [email protected]. Every policy is collected in the Legal Center.