TRINOTIME Cloud
TRINOTIME CLOUD · TRUST CENTER

Security

A plain-language overview of the controls protecting TrinoTime workspaces and the boundaries of current security assurance.

Effective September 7, 2026Version 1.0Contact: Trinoadmin@gmail.com

1. Security architecture

TrinoTime is designed as a multi-tenant SaaS. Public application traffic runs through Cloudflare Workers. Firebase Authentication establishes user identity, while protected TrinoTime API routes re-verify identity and enforce active tenant membership, role/team scope and billing state before returning or changing workspace data.

Server-authorizedProtected mutations do not trust browser role claims.
Tenant-scopedOperational records live below explicit workspace paths.
Fail-closed browser rulesDirect browser Firestore and Storage writes remain blocked for protected application data.
Audited administrationKey member, schedule, leave, payroll, billing and data-control actions produce audit events.

2. Identity and authorization

  • Firebase email/password identity with email verification.
  • JWT verification on the Worker against the configured Firebase project.
  • Role checks for Owner, Admin, Manager, Team Leader and Employee scopes.
  • Recent-authentication checks for sensitive self-service exports and deletion requests.
  • Plan seat limits and billing/trial access are enforced server-side.

3. Workspace and data boundaries

Tenant membership is checked against authoritative server data. Workforce data is stored under tenant-specific paths. Global indexes used for workspace discovery, invitation routing or custom-domain uniqueness contain limited routing metadata and do not replace the tenant authorization boundary.

4. Browser and transport protections

Production responses set HSTS, Content Security Policy, content-type sniffing protection, referrer restrictions, frame restrictions, cross-origin protections and a restrictive Permissions Policy. The application and transactional action links use HTTPS in production.

5. Operational safeguards

  • Request IDs and sanitized diagnostics support incident correlation without exposing Firebase private keys, Resend keys or Lemon Squeezy secrets.
  • JSON request bodies have bounded size limits and bulk onboarding has explicit row limits.
  • Sensitive administrative paths use additional soft rate limiting as defense in depth.
  • Locked payroll snapshots remain immutable from ordinary current-profile edits.
  • Transactional email failures are post-commit and do not roll back authoritative workforce actions.
  • Workspace Owners/Admins can export a bounded recovery snapshot; a managed-backup runbook is maintained separately.

6. Service-provider boundary

TrinoTime uses Cloudflare, Google Firebase, Resend and Lemon Squeezy for specific infrastructure functions. Provider secrets stay server-side and are not intentionally returned to the browser. Customers should still apply their own endpoint, account and employee-access security practices.

7. Reporting a security issue

Send suspected vulnerabilities to Trinoadmin@gmail.com with the subject “TrinoTime Security”. Include reproduction steps, affected URL and impact. Do not include real customer data unless necessary and authorized.

8. Assurance scope

No unsupported certification claims: TrinoTime does not claim SOC 2, ISO 27001, HIPAA, PCI DSS certification or another independent compliance attestation unless a current written statement explicitly says so.

This page describes the product architecture and controls implemented in the current commercial build. Security controls continue to evolve with the service.

Questions about this page?

Contact TrinoTime and include the workspace name if your question concerns an existing account.

Contact TrinoTime