Global Admin separation

Fanzava maintains a strict architectural separation between two distinct authentication systems: the customer-facing system that participants and hub admins use, and the platform-facing system used exclusively by Fanzava staff. The two are isolated such that compromising one cannot grant access to the other.

Why this matters

In many SaaS platforms, “global admin” or “support staff” access is implemented as a special role within the same authentication system that customers use. Compromising any privileged customer account can therefore escalate to global access.

Fanzava’s architecture eliminates that risk by keeping the two systems on separate infrastructure with separate credentials. A compromised hub admin account can only access that hub. A compromised Fanzava staff account is constrained by the controls below — and in either case, the boundary between systems is enforced architecturally, not by application code.

Two-system architecture

System	Auth provider	Audience	Surface
Customer-facing	Better Auth (default) / WorkOS (Enterprise SSO)	Hub admins, participants	your-hub.fanzava.com or your custom domain
Platform-facing	Cloudflare Access	Fanzava platform staff	admin.fanzava.com

The two systems do not share user records, sessions, tokens, or signing keys. They run on separate authentication infrastructure with separate audit logs.

Customer-facing authentication

Participants and hub admins authenticate through the customer-facing system using whatever methods their hub has enabled — email + password, magic link, Google OAuth, or Enterprise SSO. See SSO and MFA for detail.

The customer-facing system has no concept of a global admin role. The maximum privilege available through this system is hub admin within a specific hub. No customer-facing credential, regardless of role, can access another hub’s data or any platform administrative interface.

Platform-facing authentication

Fanzava staff access the platform administrative interface (admin.fanzava.com) exclusively through Cloudflare Access. This is a separate identity provider gating a separate origin:

• Staff sign in to Cloudflare Access using a corporate identity provider with mandatory MFA
• Cloudflare Access issues a short-lived signed JWT
• The Worker validates the JWT against Cloudflare’s public keys on every request
• Staff identity, role, and session are all derived from this token — not from any customer-facing system

Compromising a customer-facing account — even a hub admin account — provides no path to admin.fanzava.com. The Worker that serves admin.fanzava.com does not accept Better Auth or WorkOS tokens. It only accepts Cloudflare Access JWTs.

What platform staff can do

Even with valid Cloudflare Access credentials, Fanzava staff are constrained:

• Access is role-scoped within the platform admin system — engineering does not implicitly have support access, support does not have billing access, and so on
• Access to customer data is logged and reviewed — see Impersonation for the operational guardrails
• Production database access requires Cloudflare Access plus a separate just-in-time access request, recorded in the audit trail
• Production database access is time-bound (default 1 hour, max 4 hours) and read-only by default — write access requires a separate elevation step

Compromise scenarios

Scenario	Outcome
Hub admin credentials phished	Attacker accesses that hub only; no path to other hubs or platform admin
Fanzava engineering laptop stolen	No persistent credentials — Cloudflare Access session expires; attacker has no path to re-authenticate without corporate MFA
WorkOS or Better Auth provider compromised	Platform admin remains unaffected (different system); incident response triggered for customer-facing system
Cloudflare Access compromised	Customer-facing system remains unaffected; incident response triggered for platform system
Internal Fanzava role escalation attempt	Cloudflare Access roles enforced by the IdP, not by application code; cannot self-elevate

i

Note

The separation is architectural, not policy. Two different identity providers, two different Workers serving two different origins, two different audit log streams. Application code cannot bridge them.