SmartX HUB Security and Trust Center
This page exists to make your security review faster. SmartX HUB security architecture, access control, encryption, audit logging, deployment options and data handling are documented here in one place, so your IT and information security teams do not have to assemble the picture from a dozen pages and a sales call.
Where something is not published here, it is because it belongs in a signed agreement or a controlled document rather than on a public page. Ask and we will provide it under the appropriate terms.
How SmartX HUB Security Is Built
Security is enforced at the platform core rather than per module. Because tracking, maintenance, supply chain, sensors and worker safety all resolve to the same record, they also inherit the same identity model, the same permission checks and the same audit trail. There is no module with its own user list, and no side door where one capability family applies weaker rules than another.
Authentication
- Two-factor authentication via time-based one-time codes, email codes or WebAuthn passkeys
- Single sign-on through SAML 2.0, Azure AD, Google Workspace and LDAP or Active Directory
- Just-in-time provisioning, so accounts follow your directory instead of being maintained twice
- Deprovisioning through the same directory, so a leaver loses access where you already manage it
Authorisation
- Twelve role profiles covering the standard separation of duties, extended where needed
- Group-level data filters, so a user sees their site or area rather than the whole estate
- Field-level access control, so sensitive attributes can be hidden without hiding the record
- Multi-tenant isolation, so one organisation's data is never reachable from another's session
Encryption
Traffic between users, devices and the platform is encrypted in transit with TLS 1.3 as the enforced minimum, terminated at the Cloudflare edge. Data at rest sits on Google Cloud Platform, where storage is encrypted by default. Stored credentials and integration secrets are additionally encrypted at application level with AES-256-GCM, an authenticated cipher, so tampering is detectable rather than silent. Outbound webhooks are signed with HMAC-SHA256, which lets your receiving systems verify that a payload genuinely came from the platform and was not altered in transit.
Audit and logging
- Tamper-evident audit logging with a configurable retention policy
- Export to your own security monitoring platform, so logs live where your SOC already looks
- A security report covering account, permission and authentication activity
- Operational history retained alongside the record it belongs to, not in a detached log file
Application and integration surface
Integrations run over a documented REST surface published with OpenAPI, which means your team can review exactly what is exposed before anything is connected. Outbound events are signed, and API credentials are scoped and revocable independently of user accounts — so an integration can be shut off without disabling a person, and a person can leave without breaking an integration.
API token lifetime is set per deployment rather than fixed by us, so it can be aligned with your own credential policy instead of forcing an exception to it.
The wider architecture, including how one record serves every capability family, is described on the enterprise platform page. Where the platform locates people rather than assets, the governance and consent considerations are set out on connected worker RTLS.
Where Your Data Lives Is Your Decision
The same platform runs in three deployment shapes. The choice is usually driven by data residency obligations, network latency to the shop floor, or an internal policy that predates the project. All three run the same code and the same security model — what changes is who operates the infrastructure underneath.
The managed cloud runs on Google Cloud Platform, with Cloudflare in front of it handling edge termination and protection. Both are disclosed as sub-processors, so your legal team reviews a named supply chain rather than an unnamed one.
Hosting regions are available in the United States and the Middle East, and the region is selected per deployment rather than assigned by us. Backups are held in the same region as the data they protect, which means residency survives disaster recovery instead of quietly breaking at the point it matters most. It is worth checking that answer with every vendor you evaluate, because a backup copied to a convenient region undoes the residency commitment made on the main deployment.
The full sub-processor list and the terms covering access to customer data are set out in the data processing agreement, available on request.
Continuity and Response
Backup, recovery objectives, availability commitments and vulnerability handling are governed by the agreement covering your deployment, and they differ between a cloud tenancy we operate and an on-premise installation your own team runs. The sections below must be completed with the commitments your contracts actually make.
Backups run daily and are held in the same region as the data they protect. Recovery objectives, availability commitments and the remedies attached to them are defined in the agreement covering your deployment, because they necessarily differ between a cloud tenancy we operate and an on-premise installation your own team runs.
Customers affected by a security incident involving their data are notified by email from the platform. If you believe you have found a vulnerability, contact us directly rather than disclosing it publicly and we will respond — reach the team here.
Documents Your Team Will Ask For
Everything below is either published or provided on request under the appropriate terms. Nothing here requires a sales conversation first.
What personal data the platform processes, on what basis, and for how long.
Request a copyController and processor responsibilities, sub-processors and transfer terms.
On requestThe commercial and usage terms governing the platform.
Request a copyA completed standard questionnaire, so your team does not have to send its own first.
Request a copyDeployment topology and data flows, for your architecture review board.
On requestIf your review needs a document not listed here, ask and we will tell you whether we can provide it.
Contact usOn certifications, one distinction is worth stating plainly. SmartX HUB runs on Google Cloud Platform, which operates its own audited infrastructure programme. Certification of the underlying cloud is not certification of an application running on it, and we will not present it as though it were. If your review requires a specific framework, tell us which one and we will answer precisely about what we can evidence today rather than implying coverage we do not have.
Send Us Your Security Review
If your team has a standard questionnaire, send it. If your architecture board needs a session with our engineers rather than a document, we will arrange one. Security review is part of the evaluation, not an obstacle to get past.
Security and Trust — Common Questions
The questions information security, IT and procurement teams raise most often during a SmartX HUB security review.
