Skip to content
Vantage Workforce

Security Overview

Last updated
October 26, 2026
Change history
Contents
  1. 1.Where the Service runs
  2. 2.Signing in and sessions
  3. 3.Keeping workspaces apart
  4. 4.Changes run on our servers
  5. 5.Encryption and secrets
  6. 6.Protecting against abuse
  7. 7.Logging and staff access
  8. 8.If something goes wrong
  9. 9.What we do not have yet

This page describes the security controls actually in place for Vantage Workforce today, in plain terms, including the ones we do not have yet. For a shorter tour, see our Security page.

1.Where the Service runs

Vantage Workforce runs on Google Cloud, in the us-central1 region (Iowa, USA): the website and app on Firebase App Hosting, data in Cloud Firestore and Cloud Storage, live presence in the Firebase Realtime Database, and server code on Cloud Functions. Google runs the data centers, the hardware, and the network, and replicates stored data across zones in the region.

2.Signing in and sessions

  • Sign-in is by email and password through Firebase Authentication.
  • On the Enterprise plan, a workspace can sign its people in through its own identity provider over SAML or OpenID Connect, after proving its email domains with a DNS record. It can require single sign-on, so that a session from anywhere else reads nothing; the workspace owner keeps a password in case the identity provider is down.
  • Passwords are at least eight characters and are never stored where we can read them.
  • A sign-in ends after one hour without activity, with a warning five minutes before, and when the browser closes.
  • Suspending a member disables their account and ends their sessions on every device at once.

3.Keeping workspaces apart

  • Every workspace’s data lives under its own path, and every read is checked against the workspace and role signed into the person’s account, never against a value the browser sends.
  • Database, storage, and presence rules enforce that check on Google’s side, so the app cannot be bypassed by calling the database directly.
  • Roles (owner, admin, manager, employee) decide what each person reads. Pay and bank details are limited to the person and admins.

4.Changes run on our servers

Almost every change, such as approving a timesheet, changing a role, publishing a schedule, or deciding time off, goes through a server function that checks the input against a schema and checks again that this person may make this change. The rules refuse those writes from the browser. The exceptions are tools that edit live together, Sheets and Docs, whose rules check each write themselves.

A manager’s changes are limited to the people and sites they manage, checked on the server.

5.Encryption and secrets

  • Data travels over HTTPS (TLS) between your device, our servers, and Google.
  • Google encrypts stored data at rest.
  • Keys for outside services are kept in Google Secret Manager, never in our code, the app, or logs. Tokens for connected services are stored where no browser can read them, and connector tokens for AI assistants are stored only as hashes.

6.Protecting against abuse

  • AI features are rate limited per person and per workspace, and public forms such as email sign-up are limited per address.
  • Files have size limits by kind, and pictures in Docs and Sheets must be images.
  • When the Service fetches a web address for you, such as a link preview or a data import, it allows only public web addresses and checks every redirect, so it cannot be pointed at internal systems.
  • Messages from outside services, such as webhooks, are verified by their signatures before we act on them.

7.Logging and staff access

Data access audit logging is on for the database and file storage. Every administrative action, and every read or change of customer data by a person through Google’s console or tools rather than through the app, is recorded in a separate log kept for 400 days. Exports of chat history are also recorded in the workspace.

Only a small number of Vantage staff can reach production systems, and only to run and support the Service. Staff access to the app itself uses a separate permission granted from the command line, never from the app.

8.If something goes wrong

If we learn of a security incident that affects customer data, we investigate, contain it, and tell affected customers without undue delay and within seventy-two (72) hours, as our Data Processing Agreement sets out. Report a security issue to [email protected]; our Vulnerability Disclosure Policy explains how.

9.What we do not have yet

We would rather you hear it from us:

  • Two-step sign-in (multi-factor authentication) is not available yet.
  • Single sign-on does not yet include SCIM provisioning or mapping identity provider groups to roles, and the iPhone app does not offer it yet.
  • We have no independent certification such as SOC 2 or ISO 27001. Our hosting provider, Google Cloud, holds those for its own infrastructure.
  • We do not sign HIPAA business associate agreements at this time.
  • We do not run a paid bug bounty.

We will update this page as each of these changes.

Free for 10 peopleEvery tool in all four hubs

Get started