One-time passcode sign-in
Users sign in with a one-time passcode sent by SMS to their registered mobile number.
Security
Security you can put in front of a reviewer
The controls running in X2 today: how people sign in, how customers are kept apart, how a punch is verified and how the platform is watched in production. Nothing on this page is a plan.
Verified, not assumed
Before a punch counts, the phone checks it and the server validates it. Anomalies go to a supervisor instead of being quietly accepted.
Need-to-know by default
Each customer's records are isolated in the database, and managers see their own teams unless wider access is explicitly granted.
Stated plainly
We describe controls that run in production, not intentions. What this page does not answer, we answer in writing during procurement.
01Identity & access
The right person, on the right phone
Sign-in, device binding and roles decide who can do what, and over which employees.
Device binding
Each employee is bound to one registered phone, so their attendance is recorded from their own device.
Role-based access
Access is granted through four roles (employee, supervisor, admin and super admin), each with a defined set of permissions.
Department-scoped visibility
Managers see only their own teams. Wider visibility has to be granted explicitly and is never the default.
02Tenant isolation & data protection
Your records, walled off from everyone else's
X2 is multi-tenant. Separation between customers is enforced in two layers, and data is encrypted in transit.
Row-level security in the database
Every customer's records are isolated at the database layer with row-level security, so a query made for one customer does not return another customer's rows.
Tenant scoping in the application
The application also scopes requests to the signed-in customer, so isolation does not rest on a single mechanism.
Encrypted in transit
All traffic between the mobile app, the web dashboard and our servers travels over HTTPS with TLS.
03Punch integrity
A punch is evidence, so it is checked
Attendance becomes payroll and, sometimes, a disciplinary record. X2 checks each punch before accepting it.
Four checks before acceptance
Before a punch is accepted, the app checks GPS location and device integrity, compares the time against a network clock, and confirms identity by face verification.
Geofences validated on the server
Each site has a circle, polygon or rectangle boundary, and the punch location is validated against it on the server.
Exceptions go to review
Clean punches approve automatically. Punches outside the geofence or with integrity problems go to a supervisor's review queue instead of being silently accepted.
X2-Beacon where GPS is weak
X2-Beacon Bluetooth beacons anchor presence on sites where GPS alone is unreliable.
04Application & API security
Protected where it meets the internet
The mobile app, the API and the website each carry controls against interception, abuse and common browser-based attacks.
Certificate pinning
The mobile app pins the certificates it expects from our servers, which makes its traffic much harder to intercept on an untrusted network.
Rate limiting
Sign-in and API endpoints are rate-limited, which slows passcode guessing and automated abuse.
Security response headers
The website sends security response headers that instruct browsers to apply stricter protections.
05Operations & monitoring
Monitored in production, traceable afterwards
We run X2 as a service. That means knowing when something fails, and being able to show who approved, overrode or corrected a record.
Audit trail
Approvals, overrides and corrections made in X2 are recorded with who made them, what changed and when.
Error monitoring without personal data
Errors are captured by monitoring configured to scrub personal data (GPS coordinates, phone numbers and tokens) from the reports.
Health checks
Health checks report the status of the database, cache, file storage and job queues.
Where X2 is hosted
X2 runs on Amazon Web Services. The hosting region and the list of sub-processors are documented in the customer agreement and provided during procurement.
Reporting a vulnerability
If you believe you have found a security issue in X2 or this website, tell us through the contact page with enough detail to reproduce it. Reports are acknowledged and handled confidentially. Please do not access or alter data that is not yours while investigating.
FAQ
Questions security reviewers ask
Where is our data hosted?
On Amazon Web Services. The hosting region and the sub-processor list are set out in the customer agreement, and we provide them during procurement.
How is our data separated from other customers?
In two layers: row-level security in the database, and tenant scoping in the application. Isolation does not depend on a single mechanism.
Can a manager see employees outside their department?
Not by default. A manager's visibility is limited to their own teams, and wider access has to be granted explicitly.
What does face verification do?
It confirms who is punching: that the person using the phone is the employee the account belongs to. It works alongside the GPS, device integrity and network clock checks, not in place of them.
Are approvals and corrections audited?
Yes. Approvals, overrides and corrections made in the application are recorded with who made the change, what changed and when.
Will you complete our security questionnaire?
Yes. Send it through the contact page and we will complete it, alongside the hosting and sub-processor details in the customer agreement.
Send us your security questionnaire
We will complete it, and include the hosting and sub-processor details from the customer agreement.