Access

Onboarding and login

How organizations request access and how issued operators authenticate. Onboarding does not silently create production tenants without Access Review.

/onboarding . Access request

Public multi-step form: identity (business email), environment (security stack, use cases, size, timeline), and review. Personal, disposable, reserved, and shared-role mailboxes are rejected. Submission creates an application with a reference id and waits for Access Review.

Successful submit does not hand out console passwords by itself. Credentials are issued when a Super Admin approves the application and mail delivery succeeds (when mail is configured).

/login . Operator sign-in

Supports approved operator credentials when AUTH_CREDENTIALS_ENABLED is not false, and Microsoft Entra ID when Azure AD / Entra env vars are present. Okta and generic SAML may appear in the UI as not configured until wired.

Post-login routing depends on role: Super Admin to Access Review, Admin toward Admin/Workspace or callback, analysts toward Command Center or Incidents. Closing the browser typically requires sign-in again unless AUTH_SESSION_PERSISTENT=true.

Session and API identity

The browser holds a NextAuth session cookie. API calls go through /api/beacons, which attaches identity headers derived from that session. Operators should never paste an API bearer token into frontend code or localStorage. If AUTH_SECRET is missing in production, sign-in fails loudly — that is intentional.

Local AUTH_USERNAME / AUTH_PASSWORD is for development only. Production expects Entra (or another wired IdP) plus Access Review to issued memberships.

Privacy controls

Your visit should be as controlled as your telemetry.

We use necessary cookies to keep the site working. Optional analytics help us understand which product pages are useful. Marketing cookies stay off unless you allow them.