Trust Center
How SignaCast is built and secured.
Your screens are in your lobby, your dining room and your factory floor — in front of customers and staff all day. This page says plainly how the software behind them is built, where your data lives, who else touches it, and what to do if you find a problem.
Last updated September 17, 2026 · Live status · security.txt
CloudflareEvery part of the Service runs on Cloudflare's global network. We operate no servers of our own.
99.9%Monthly uptime target with service credits, in a published SLA.
No AI on your contentYour designs, media and data files are never sent to a machine-learning model. We use no AI subprocessors.
Security practices
Encryption, sign-in, roles, tenant isolation and how a change reaches production.
Player & device security
Outbound-only players, pairing codes that belong to nobody, revocable per-screen credentials.
Subprocessors
Every third party that can touch customer data, named, with what they do and where they are.
Vulnerability disclosure
Scope, how to report, what we promise in return — including safe harbor for good-faith research.
Certifications
Where we stand today
SignaCast does not hold a SOC 2, ISO 27001 or HIPAA attestation, and we're not going to imply otherwise. We're a small engineering team building a young product, and a badge we haven't earned would be worth less than nothing to you.
What we offer instead is specificity. Everything below describes how the product is actually built — the algorithms, the token lifetimes, the isolation model, the deploy path — in enough detail that your security team can judge it on the merits instead of on a logo. If a claim on this page is ever wrong, we'd rather hear about it.
If your procurement process needs a security questionnaire completed, a data processing addendum signed, or a call with the person who wrote the auth service, email [email protected]. That's a real mailbox a human reads.
- Yes Published SLA with uptime credits
- Yes Public status page, 90-day history
- Yes Named subprocessor list
- Yes Vulnerability disclosure with safe harbor
- Not yet SOC 2 Type 1 or Type 2
- Not yet ISO/IEC 27001
- Not yet Third-party penetration test report
- Not yet Regional data-residency commitment
How we protect your data
The parts a security review actually asks about
Written for the person who has to sign off on us, not for a brochure.
Infrastructure and hosting
- One platform, no servers of our own. Compute (Cloudflare Workers), database (D1), file storage (R2), static hosting (Pages), DNS and CDN are all Cloudflare. There is no virtual machine of ours to patch, no SSH port to leave open, and no operating system for us to misconfigure. Application code runs in V8 isolates, not containers we maintain.
- Every public hostname sits behind Cloudflare's edge, which terminates TLS and absorbs network-layer and volumetric attacks before traffic ever reaches application code.
- Each product surface is its own service on its own hostname — sign-in (
id.signacast.co), screens and playlists (app.), the design editor (designer.), billing (billing.), onboarding (signup.), the player (play.) and platform administration (admin.). They share no process. A fault in one does not take the others down with it. - Published screen content is served from a CDN bundle (
cdn.signacast.co), separately from the management apps. A screen that has been configured keeps fetching its content even while the editing tools are unavailable.
Encryption
- In transit: HTTPS for every connection — browser to app, player to content, service to service. Certificates are issued and rotated by Cloudflare.
- At rest: account data lives in Cloudflare D1 and uploaded media in Cloudflare R2, both of which encrypt stored data on Cloudflare's side.
- Passwords are hashed with Argon2id — a memory-hard function chosen specifically to make offline cracking expensive — with a unique random salt per user. We cannot read, recover or email you your password; we can only reset it.
- Second-factor secrets and your identity-provider credentials (an OIDC client secret, a SAML signing certificate) are sealed with AES-GCM envelope encryption under a master key held as a platform secret. The API never returns them once stored — the management screens show only the last four characters.
- API keys and player refresh tokens are stored as hashes, not as the value we issued. An API key is shown exactly once, at creation. A dump of the credential table would not let anyone sign in.
- Card numbers never reach our servers. Card fields render inside Stripe's own iframe on our billing page; we store a plan, a quantity and Stripe's identifier for the card, nothing more.
- Sign-in responses carry
Cache-Control: no-store, so tokens and session material are never cached by a browser or an intermediary.
Sign-in and account security
- Two-factor authentication with a standard authenticator app (TOTP) plus one-time recovery codes, available on every plan.
- Sign in with Google, for organizations that would rather not manage another password.
- Your own identity provider. Enterprise organizations can connect SAML 2.0 or OIDC — Okta, Microsoft Entra ID, Google Workspace, OneLogin and anything else that speaks those protocols — with a setup wizard, a test mode that shows exactly which attributes we derived from a real login, and diagnostics when a connection misbehaves. Email domains are verified by DNS before they can route sign-in, so nobody can claim yours.
- SAML is validated properly. Signature verification runs against the signed references only, with replay, clock-skew and audience checks, XML signature-wrapping defenses and a parser with document type definitions disabled. That validation was built against a purpose-written attack corpus, including two wrapping attacks and refusal of SHA-1 signatures, before it shipped.
- OIDC uses PKCE with state and nonce on every authorization request.
- Short-lived tokens. Applications hold a 15-minute Ed25519-signed access token. Signing keys rotate on a quarterly schedule with an overlap window, published as a JWKS document, so a rotation never signs anyone out.
- Session refresh tokens rotate on every use, with reuse detection. If an old refresh token is ever presented — the signature of a stolen token — the entire token family is revoked immediately rather than the two sessions racing each other. Session lifetime is a per-organization setting.
- Sign-in answers are deliberately uninformative. Asking whether an address should use SSO or a password gives the same shape of answer for an unknown address, so the endpoint can't be used to enumerate your users.
- Session cookies use the
__Host-prefix andSameSite, with a double-submit token on state-changing requests.
Access control and tenant isolation
- Six built-in roles — Owner, Admin, Content editor, Scheduler, Device operator and Read-only — expressed as an explicit list of permission verbs (
designs.write,devices.pair,audit.readand so on) rather than as vague tiers. Access can additionally be scoped to specific locations, so a store manager sees only the screens at their own site. - Every database query is scoped to the caller's organization in a shared middleware layer, and every token carries the organization it was issued for. Cross-organization access isn't prevented by a filter someone remembered to add to a route — the route can't get an unscoped handle in the first place.
- An audit log records administrative actions — who did what, when, and from where — across the apps, with retention set by your plan and export from the admin UI.
- Our own staff access is narrower than you might assume. Platform administration lives in a separate application that requires both membership of the operator organization and the Owner role inside it; an Admin of that same organization is refused. Operator actions such as a billing override or revoking a device are written to the affected customer's audit log, attributed to the operator.
- Machine access uses scoped service keys that can only ever hold a subset of the permissions of the person who created them, are revocable individually, and are exchanged for short-lived tokens rather than being presented to the product APIs directly.
- Partner access is consent-based and visible. When an agency manages your account, its actions are labeled with both the partner organization and the individual, and an Owner can revoke the access from your own settings.
Player and device security
- Players connect outbound only, over HTTPS on port 443. There is no inbound connection to a screen, no port to forward and no firewall rule to open. A player behind ordinary corporate NAT works with no network change.
- A pairing code belongs to nobody until it's claimed. The six-character code on a waiting TV is a platform-level object with no organization attached, and there is deliberately no screen anywhere in the product that lists unclaimed codes to a customer — that list would show one customer every other customer's waiting displays. Only our own operator console can see pending codes, which is exactly why the feature lives there.
- Codes are time-limited and slide. A code expires an hour after the TV stops asking for it, extends while the TV is on, and can never outlive a hard maximum. Polling for a claim requires a secret issued alongside the code, so knowing a code that's on screen isn't enough to hijack the pairing.
- A paired player holds a credential for one screen — a read-only content permission set, not an account — with a four-hour access token refreshed hourly and a refresh token that rotates on every use. Presenting a rotated-out token revokes the credential family.
- Revocation is immediate and reaches the device. Unpairing from the screen manager, revoking the credential in SignaCast ID, or the platform detecting token reuse all push a revocation to the player, which is refused at its next check-in. Re-pairing a screen automatically revokes the previous credential.
- Playback doesn't depend on our availability. A player keeps the last content it successfully loaded and keeps showing it through a network interruption; schedules are evaluated on the screen's own clock, so a lunch menu still ends at 2 p.m. while the link is down.
How code reaches production
- Nothing is pushed straight to production. Every change in every SignaCast repository lands on the default branch through a reviewed pull request; direct pushes to
mainare prohibited by policy across all repositories. Deployment is automatic frommain— which means the pull request is the change-control gate, not a formality on top of one. - Automated tests run on every pull request: unit tests for the pure logic, smoke tests against a real local instance of each Worker, and end-to-end browser tests of the actual sign-in, SSO, SAML, editor and screen-management flows.
- Security-critical shared code is single-source. Token verification and the permission model exist in one place and are copied verbatim into the other services with a recorded source commit, so a fix can't land in three services and get missed in the fourth.
- Secrets live in the deployment platform — Cloudflare Worker secrets and GitHub Actions secrets — never in source control, and never in a client bundle.
Availability, incidents and backups
- A 99.9% monthly uptime target, with service credits when we miss it, defined in our Service Level Agreement.
- Independent monitoring of each surface. Our status page checks every component on a schedule against its real production URL — not a synthetic endpoint that can pass while the product is broken — keeps 90 days of history, and alerts us on the transition into and out of an outage.
- Incident history is curated by a human. A failing check turns a component red automatically, but an incident write-up is written by us, deliberately, rather than generated. We post updates to the status page as we have something to say.
- Account data is held in Cloudflare D1, which supports point-in-time restore, and media in Cloudflare R2. We'll tell you plainly what we don't have: we do not currently publish a tested disaster-recovery runbook or formal RTO and RPO targets.
- Breach notification. If customer personal data is affected by a security incident, we notify affected organizations as described in our Privacy Policy and as required by law.
Your content, privacy, and AI
- Your content is yours. Designs, images, video, fonts and uploaded data files are processed to run the Service and for nothing else, as set out in the Terms of Use.
- No AI anywhere near it. SignaCast has no machine-learning features and no AI subprocessors. Your content is not used to train a model — not ours, and not a vendor's — because there is no model in the product to send it to.
- No advertising or analytics trackers on this website. We set one essential first-party session cookie across
signacast.coand its subdomains so a signed-in visitor stays signed in. That's the whole cookie list. - We don't sell personal information, and we don't buy it from data brokers.
- Access, correction, export and deletion. Most account data is editable in the app; for anything else, email [email protected]. GDPR, UK GDPR and U.S. state privacy rights are honored for the data those laws cover — see the Privacy Policy.
- Data location, stated honestly. Data is stored in Cloudflare's D1 and R2 services and served from Cloudflare's global network. We do not currently offer a contractual EU-only or region-pinned residency commitment. If your organization requires one, tell us before you buy — we'd rather say no than surprise you.
Subprocessors
Who else can touch your data
The complete list. We update it here before adding a subprocessor that handles customer personal data, and the "last updated" date at the top of this page changes when we do.
| Subprocessor | What they do for us | Data they can reach | Location |
|---|---|---|---|
| Cloudflare, Inc. | Compute (Workers), database (D1), object storage (R2), static hosting (Pages), CDN, DNS, DDoS protection, headless rendering for screen snapshots, and delivery of transactional email. | All of it — account data, Your Content, and traffic to the Service. | United States, with a global edge network |
| Stripe, Inc. | Subscriptions, invoicing and card processing. Card details are entered directly into Stripe and never pass through our servers. | Billing contact and payment information. No designs, media or screen configuration. | United States |
| Google LLC | "Sign in with Google," only for users who choose it. Nothing is sent to Google for accounts that use a password or another identity provider. | The name and email address in the sign-in assertion. | United States |
| Your own identity provider | If your organization connects SAML or OIDC, sign-in is delegated to the provider you chose and control. | Whatever your provider sends us at login — typically name, email and group membership. | Wherever you host it |
Mail sent to our published addresses lands on a mail server operated by Triton Agency, LLC — the same company that operates SignaCast, not a third party. Source code and continuous integration live on GitHub, which holds no customer data.
Vulnerability disclosure
Found something? We want to hear it.
How to report
Email [email protected] with enough detail to reproduce the issue — the URL or endpoint, the steps, and what you were able to reach. A proof-of-concept helps. Our machine-readable contact details are at /.well-known/security.txt.
What we promise
- We acknowledge a report within 2 business days.
- We tell you our assessment, and whether we're fixing it, within 10 business days.
- We keep you updated until it's closed, and we'll credit you when it is if you'd like us to.
- We don't run a paid bug bounty. We're a small company and we'd rather be honest about that than dangle a reward we haven't budgeted.
Safe harbor
If you make a good-faith effort to follow this policy while researching a vulnerability, we will not pursue or support legal action against you, and we'll treat your research as authorized under the Computer Fraud and Abuse Act and equivalent laws. If a third party brings action against you for research that followed this policy, we'll make that authorization clear.
Scope and rules
- In scope:
signacast.coand its subdomains, the SignaCast applications, our player software, and our public APIs. - Out of scope: anything hosted by Cloudflare, Stripe or another vendor rather than by us — report those to them; findings from automated scanners with no demonstrated impact; and reports that amount to a missing best-practice header with no exploit behind it.
- Please do: use your own test organization, and stop as soon as you've confirmed access.
- Please don't: access, modify or delete another customer's data; degrade the Service; run denial-of-service or physical attacks; or social-engineer our staff or customers.
- Give us time. Let us fix an issue before you publish it. We'll agree a timeline with you rather than impose one.
Documents
Everything, in writing
Public, with nothing behind a request form.
Privacy PolicyWhat we collect, why, who we share it with, how long we keep it, and your rights.
Terms of UseThe contract, including ownership of Your Content.
Service Level Agreement99.9% uptime target, service credits, support response targets, exclusions.
security.txtRFC 9116 machine-readable security contact and disclosure policy.
Status pageLive component status, 90-day uptime history and incident record.
Data Processing AddendumNeed a DPA signed, or a security questionnaire completed? Ask and we'll turn it around.
Still have questions?
Security questions go to a person, not a queue. Ask anything on this page and you'll get a specific answer — including "we don't do that yet."