Bell2go
Schedule a demo
Security & trust

Safety starts with
controlled access.

Strong identity is only the first boundary. Bell2go separates authentication, school authorization, student relationships, active pickup context, and staff verification.

Review identity controlsDownload datasheet
TRUST MODELMFA
IdentitySchool roleStudent relationshipTrip contextHuman verification
No email address alone authorizes a pickup.
Identity and access

Simple for families. Explicit for schools.

Every sign-in method enters the same mandatory MFA, authorization, audit, and session controls.

01

Public SSO

Support Google and Microsoft personal or organizational identities plus Sign in with Apple, including Apple private email relay.

02

Self-registration

Every parent, guardian, or authorized delegate uses a separate verified email and phone number. Phone-based recovery is non-enumerating and revokes old sessions.

03

Mandatory MFA

Every parent and staff account completes MFA. Provider assurance is validated and Bell2go performs step-up MFA when needed.

04

Independent authorization

Self-registration never grants student access. Roles, guardian and delegate relationships, and school scope come from trusted school approval—not identity claims.

Authorization and tenant isolation

A role grant is only one boundary.

Bell2go evaluates identity, MFA, tenant, school, role, relationship, resource ownership, state, and audit requirements before a protected operation runs.

01

Deny by default

Unknown roles, resources, actions, and ambiguous generic staff identities receive no permission.

02

CRUD by resource

Create, read, update, and delete permissions are explicit. Safety and financial records use state-aware cancellation, void, or retention rules.

03

Tenant partitions

One production platform can serve many school or district tenants while every lookup and mutation remains scoped to verified tenant and school context.

04

Environment separation

Development and production use separate AWS accounts. Deployment names identify releases; they are never treated as a school security boundary.

Application architecture

Portable containers. Managed data. Private connections.

The application backend is built as a Docker image and promoted unchanged through local, pilot, and production environments. Hosted compute connects privately to managed cloud data.

  • Secrets remain outside the image
  • Encryption in transit and at rest
  • Tenant and school isolation on every request
  • Immutable audit events for sensitive actions
CLIENTSParent mobile · Staff tablet · Operations web
HTTPS + short-lived session
APPLICATION SERVICESIdentity · Dismissal · Routing · Notifications
Verified tenant context
CONTROL PLANETenants · Entitlements · Billing · Usage · Cost allocation
Private data + least privilege
MANAGED CLOUD DATAOperational database · Usage ledger · Events · Audit · Backups
Privacy by workflow

Collect less. Retain briefly. Explain clearly.

Trip-scoped location

Location supports active arrival only. The product shows freshness and degrades safely when signals stop.

Student data boundaries

Student records never belong in marketing forms. Application access requires tenant, role, relationship, and active-session checks.

Camera safeguards

Plate recognition is optional corroborating evidence. Staff remain responsible for verification; raw imagery follows short retention.

Human-controlled AI

Prediction can recommend timing, lanes, or staffing. It cannot release a student or silently change the approved traffic plan.

PUBLIC WEBSITE BOUNDARY

The marketing site is intentionally separate.

CloudFront serves the public website from private S3. Only the demo-request path reaches a small serverless API and an expiring business-lead table. It does not connect to student or dismissal records.

Private S3 originCloudFront OACSecurity headersRate-limited demo API180-day lead TTL
Security review

Bring your IT and operations teams together.

Schedule a working session