Security

Authentication

Dashboard and mobile access use different paths, and both are designed so that a database copy on its own does not yield working credentials.

• Dashboard passwords are hashed with bcrypt and a per-user salt. They are never stored or recoverable in plain text.
• Access tokens are JSON Web Tokens with a 15 minute lifetime, so a leaked token has a short useful life.
• Refresh tokens last 14 days and are stored as hashes, not as the token itself.
• Multi-factor authentication is supported for dashboard accounts.
• Mobile sign-in uses a one-time code issued by HR. The code is stored hashed, expires, and is limited to a fixed number of attempts.
• One-time code requests are rate limited per employee, per device and per IP address, with a lockout after repeated failures.
• Session tokens on mobile are held in the operating system secure store rather than in general app storage.

Access control

The platform is multi-tenant. Every record is scoped to a company, and queries are constrained by that scope so one customer cannot read another customer data.

Within a company, access is role based. Roles carry explicit permissions, and what an HR administrator, a line manager, a branch manager and an employee can see are different. Customers assign roles themselves.

Access to production data by our own staff is limited to the people who need it to operate the service.

Encryption

• All traffic between the apps and our servers runs over TLS.
• Bank account numbers and SWIFT or routing values are encrypted at field level before they are written to the database, using a key held outside the database. A database copy alone does not expose them.
• Storage and backups are encrypted at rest by our infrastructure providers.

Attendance integrity

Attendance data is only useful if it can be trusted, so several checks run at the moment of a punch. Each is optional and is enabled per branch by the customer.

• Geofence verification compares the reported coordinates against the branch boundary, and records the accuracy the device reported.
• Wi-Fi verification compares the BSSID of the connected network against the networks registered for that branch. BSSID is used rather than network name because a network name is trivial to spoof.
• Device binding ties an employee to a known device, so a punch from an unrecognised device can be flagged.
• Both the time reported by the phone and the time the server received the event are stored, along with the client time offset, so clock tampering is visible.
• Punches made offline are queued and marked as offline when they sync, rather than being presented as live punches.
• Events that fail a check are flagged for review rather than silently dropped or silently accepted.

Audit logging

Dashboard actions are written to an audit log that records who acted, the role they acted in, what changed before and after, the IP address, the user agent, and a correlation identifier that ties related changes to a single request.

Manual attendance entries and adjustments are recorded with the actor and a reason, so a corrected record is distinguishable from an original one.

Infrastructure

Production runs on Amazon Web Services. Uploaded files are stored in Amazon S3 in the US East (N. Virginia) region. Caching runs on Upstash. Our sub-processors page lists each provider, its purpose and its region.

Environments are separated. Development, staging and production use distinct databases and distinct cache namespaces, so a staging fault cannot reach production data.

API requests are rate limited, and cross-origin access is restricted to an allowlist of known front ends.

The cache layer has a circuit breaker. If the cache backend becomes unreachable it is bypassed rather than being allowed to slow every request.

What we have not done yet

We do not hold SOC 2, ISO 27001 or any equivalent certification, and we do not claim to.

We have not commissioned an independent third-party penetration test.

We do not run an automated data retention or purge schedule. Deletion is carried out on request.

We do not offer a contractual uptime commitment.

If any of these is a requirement for your organisation, raise it before you roll out rather than after, so we can tell you honestly whether we can meet it and by when.

Reporting a vulnerability

If you believe you have found a security issue, email hello@timegate.me with enough detail to reproduce it. We will acknowledge receipt and keep you updated while we investigate.

Please do not test against a live customer tenant, do not access or modify data that is not yours, and give us a reasonable window to fix the issue before disclosing it publicly. We will not pursue action against researchers who follow that.