Security at GuestPass Cloud

Version 1.0 — last updated 2026-09-22.

This page describes how GuestPass Cloud is actually built and protected. Where a control is not in place, it says so. Nothing here is aspirational.

What the product does, in one paragraph

GuestPass Cloud manages guest access on networks you own or are authorized to manage. It issues vouchers, private pre-shared keys, RADIUS credentials and MAC bypasses; it runs a captive portal guests sign in on; it can take card payments from guests into the property's own Stripe account; and it records what was issued and who signed in. It does not carry guest traffic, inspect it, or filter it.

Architecture

The whole application is a single Cloudflare Worker.

• Compute: Cloudflare Workers. No servers to patch, no SSH, no long-lived hosts. Code runs in V8 isolates at the Cloudflare edge location nearest the request.
• Database: Cloudflare D1 (SQLite). One database, with every query scoped to the tenant.
• Object storage: Cloudflare R2, for uploaded logos and brand assets.
• Scheduled work: a Cloudflare cron trigger every 15 minutes handles voucher expiry sweeps, scheduled configuration changes and directory sync.
• On-site bridge: an optional small program on a machine at the property. It connects outbound to us over HTTPS and polls for work, authenticated with a per-site token. No inbound port is opened and no firewall rule is needed. Guest portal sign-ins are executed through it against the local controller.
• UniFi cloud path: as an alternative to a bridge, a site can be driven through Ubiquiti's own cloud service with an API key from your ui.com account.

Tenant isolation

The hierarchy is organization, then company, then site. Every read and write is scoped to what the signed-in user is entitled to, and entitlements resolve most-specific-first, so a company's settings override the organization's.

Identity policy is deliberately not inherited wholesale. Under a managed service provider, the MSP's rules for its own technicians do not cascade onto its customers' staff; a company owns its own people's sign-in settings, while the MSP can set a floor those settings must clear.

Isolation is logical, within one database, enforced in the application layer. It is not separate databases or separate deployments per tenant, and we do not describe it as if it were.

Authentication

An organization or a company can require 2FA, require SSO-only sign-in, and set how long a session lasts (default 30 days). Session cookies are HttpOnly, Secure and SameSite=Lax.

If Duo is unavailable, anyone with a passkey or an authenticator app enrolled can still sign in. We recommend every administrator enrols a passkey as a fallback.

Encryption

• In transit: HTTPS everywhere, terminated by Cloudflare. The bridge speaks HTTPS outbound only.
• Connected credentials at rest: UniFi API keys, the property's Stripe secret key for guest payments, identity-provider client secrets, webhook signing secrets, RADIUS passphrases and Umbrella API secrets are encrypted with AES-256-GCM before being written, and decrypted only inside the Worker at the moment of use. They are never returned to a browser, to the API, or to a configuration export.
• The key is a Cloudflare Worker secret. It is write-only from outside the running Worker: it can be set or replaced, and not read back. It is one platform key, not a key per tenant, and we would rather say that than let a diagram imply otherwise.
• Storage at rest: Cloudflare encrypts D1 and R2 at rest underneath us.
• Card data: never touches GuestPass. Guests pay on Stripe's hosted checkout. We store the Stripe identifiers that come back, not card numbers.

Application hardening

Every rendered response carries a Content-Security-Policy that blocks plugins, restricts the document base URL and pins form targets; X-Frame-Options and frame-ancestors, so the console cannot be framed for clickjacking; X-Content-Type-Options to stop content-type guessing on downloads; and a strict-origin-when-cross-origin referrer policy, chosen specifically so that reset, invitation and verification tokens carried in URLs are never leaked to a third-party site a user clicks through to.

Output is escaped at render time. Markdown in documentation and legal pages is escaped before any formatting is applied, so the only HTML that reaches a page is HTML the application wrote.

Logging and audit

Administrative actions are written to an audit log with the actor, their email address, the target organization, company or site, the action, a detail and the source IP address. Tenants can read their own audit log. Errors are logged with route, method, message and stack for diagnosis.

Simple Technologies support staff can reach tenant data through an internal domain console in order to support you. That access is audited like any other.

Backups and rollback

• Database: Cloudflare D1 point-in-time restore ("Time Travel") allows restoring to any moment in the preceding 30 days. We do not currently keep a separate backup outside Cloudflare.
• Application: every deployment is retained as a Cloudflare Worker version, so the platform can be rolled back to an earlier build.
• Your configuration: you can export a company's configuration to a file and restore it. Connected credentials are deliberately never included in that export.

Release channels

Every tenant runs on a channel — alpha, beta or production — and every new feature carries a stage. A tenant sees a feature when its channel is at least as early as the feature's stage.

• alpha: newest work, first to see changes.
• beta: features that have already been through alpha.
• production: settled.

Promotion moves a feature's stage; it is not a separate deployment. A tenant that hits trouble on a newer channel moves to a steadier one and the newer features switch off for it. The on-site bridge is the exception: it is a separate program, so its channels are genuinely separate builds.

What we do not have

We would rather you hear this from us than discover it in a questionnaire.

• No SOC 2 report and no ISO 27001 certification. We have not undergone either audit.
• No third-party penetration test has been performed.
• No 24/7 on-call rota or security operations centre. Support is business hours, United States Central Time.
• No contractual uptime commitment or service credits. GuestPass Cloud is in alpha and we will not quote a number we cannot stand behind.
• No automatic deletion of operational records. Portal sign-in records, voucher history, guest payment records and audit logs are kept until a tenant deletes them or the account is deleted. Scheduled retention is on the roadmap. Ask us and we will delete records for you.
• No bug bounty programme. We will thank you properly, and we will not pursue good-faith research.

Your side of the line

• Keep the bridge machine patched, powered and on a trusted network.
• Rotate API keys and bridge tokens when someone with access leaves, and revoke them immediately if one leaks.
• Enrol passkeys, and require 2FA or SSO for your organization.
• Decide what your captive portal asks guests, and show them honest terms. That content is yours — see the Acceptable Use Policy.
• Whatever filtering, content control or retention your own obligations require is yours to arrange. We do not carry or inspect guest traffic.

Reporting a vulnerability

Email support@simple-technologies.com with "Security" in the subject line. Tell us what you found, where, and how to reproduce it. We aim to acknowledge within two business days and to keep you updated until it is closed.

Please test against your own tenant and your own data. Do not access another customer's data, degrade the service for others, or disclose publicly before we have had a reasonable chance to fix it. Research that follows those rules is welcome and we will not pursue it.

Questions

Security questionnaires, architecture questions and requests for the Data Processing Addendum: support@simple-technologies.com.