Recognizes the phone
The phone creates a cryptographic key that cannot be copied out of the enrolled device.
Access and attendance verification platform
Verify that the enrolled phone is at the correct entry point.
MesaiGo checks the enrolled phone, authorized gateway, whether the request has expired, and BLE or UWB proximity. The server makes the access or attendance decision and records the result.
Explore the security controls
LIVE VERIFICATION
HIGH ASSURANCE · UWB
01
ENROLLED PHONE
Phone key
VERIFIED
02
DISTANCE CHECK
Secure UWB measurement
0.82 m
03
GATEWAY VERIFICATION
Phone-to-gateway connection
VERIFIED
04
SERVER DECISION
User permission and reuse check
ACCEPTED
TRANSACTION RESULT · 7F2A
HIGH ASSURANCE
ACCEPTED
Enrolled device
Phone key
Phone-to-gateway connection
BLE + UWB
Decision maker
Server
If a check is missing
Transaction denied
Outcome
Recorded result
Verify before recording
Location alone is not enough. MesaiGo verifies the transaction live.
GPS coordinates can be altered, QR codes can be shared, and cards can be handed over. MesaiGo checks the enrolled phone, correct gateway, whether the request has expired or was already used, and proximity together.
Recognizes the point
The server verifies that the gateway is enrolled for the correct organization and entry point.
Creates a new request for every attempt
Each attempt receives a new, single-use request, so an old transaction cannot be reused.
Applies the required security level
A Standard or High Assurance result is produced only after the checks required for that level are complete.
Step-by-step verification
See how an access or attendance decision is made.
Choose the security level and outcome. Follow how the phone, gateway, and server check the transaction in sequence.
Standard
The phone and its assigned gateway verify each other over Bluetooth on every attempt.
-
01
Enrolled phone
The phone uses a key created in its secure storage that cannot be copied to another phone. The server matches the key to the correct employee and organization.
-
02
Correct gateway
The app selects the relevant entry point and gateway identity, not simply the strongest signal.
-
03
New verification request
The gateway creates a short-lived, single-use request for every attempt.
-
04
Mobile verification
The phone signs the attempt, entry point, purpose, and single-use request together.
-
05
Gateway verification
The gateway signs the Bluetooth or UWB communication it established with the phone at that moment and submits it to the server.
-
06
Server decision
The server checks identity, request expiry, device assignment, organization rules, and whether the request was already used.
-
07
Result record
The result, security level, and rule version used are written to a transaction history that cannot be altered later.
High Assurance
Local user approval and secure UWB ranging for every transaction.
-
01
Enrolled phone
The phone uses a key created in its secure storage that cannot be copied to another phone. The server matches the key to the correct employee and organization.
-
02
Correct gateway
The app selects the relevant entry point and gateway identity, not simply the strongest signal.
-
03
New verification request
The gateway creates a short-lived, single-use request for every attempt.
-
04
Transaction approval
The user approves every critical attempt locally with the device PIN or biometrics; biometric data never reaches MesaiGo.
-
05
Secure UWB ranging
The measured distance is matched to the corresponding attempt, phone, gateway, and entry point.
-
06
Mobile verification
The phone signs the attempt, entry point, purpose, and single-use request together.
-
07
Gateway verification
The gateway signs the Bluetooth or UWB communication it established with the phone at that moment and submits it to the server.
-
08
Server decision
The server checks identity, request expiry, device assignment, organization rules, and whether the request was already used.
-
09
Result record
The result, security level, and rule version used are written to a transaction history that cannot be altered later.
MESAIGO / TRANSACTION RESULT
7F2A-9C18
Server approval, a single-use unlock command, and an observed passage.
- Security level STANDARD
- Rule Office entry v12
- Decision ALLOW
- Passage OBSERVED
Verified by the server
MESAIGO / TRANSACTION RESULT
7F2A-9C18
A verified arrival or departure becomes the correct shift and attendance record.
- Security level STANDARD
- Rule Shift start v8
- Event CLOCK_IN
- Record SAVED
Verified by the server
Two verification levels
Not every door carries the same risk. Choose the security level that fits the need.
Live BLE verification
Balances speed with strong phone-to-gateway verification for offices, factories, and everyday attendance workflows.
- Enrolled phone key
- New, single-use request
- Phone and gateway checks
- Server decision
Secure UWB + transaction approval
Combines UWB distance measurement and user approval in one decision for vaults, server rooms, and critical spaces.
- Secure UWB ranging
- PIN or biometrics for every attempt
- Denial when a required check is missing
- Field tests against relay and distance-reduction attacks
Compare Standard and High Assurance by hardware, attacks addressed, and required user steps.
Scroll horizontally for the High Assurance column →| Decision criterion | Standard | High Assurance |
|---|---|---|
| Proximity verification | Live BLE communication between phone and gateway | Secure UWB distance measurement |
| What it does not prove on its own | Does not claim to measure exact distance | Does not grant access by itself |
| User verification | Can be required by an organization rule | Mandatory local approval for every attempt |
| Required gateway | Verify, Access Lite, Access, or Access Pro | Access Pro and a supported UWB device |
| When a required check is missing | Standard rules apply | The transaction is denied without the required UWB measurement or user approval |
| Transaction record | Identity, request expiry, gateway verification, rule used, and result | Standard record plus distance measurement and local approval |
One verification, two outcomes
One transaction is verified; access and attendance decisions remain separate.
An access approval does not automatically start attendance, and an attendance record does not automatically unlock a door. MesaiGo evaluates the same verification result under separate access and attendance rules.
MesaiGo Access
See the approval, door command, and sensor result separately.
The enrolled phone, proximity check, server decision, unlock command, and sensor result are recorded separately across doors, turnstiles, private rooms, and controlled spaces.
- Permission based on access rules and the required security level
- Signed, single-use unlock command
- Door contact, tamper, and anti-passback
- Safe denial without the server and an independent emergency circuit
MesaiGo Attendance
Turn verified arrival and departure records into payroll-ready time.
Shifts, breaks, missing departures, leave, corrections, and approvals are managed without rewriting the original verification record.
- Time records from arrival and departure events
- Shifts, overnight work, and overtime
- Employees viewing and disputing their own records
- Payroll/ERP export; the original record is preserved and every correction is recorded separately
How the system works together
Explore the technical flow
The phone, gateway, and server each have a different job.
The phone does not approve itself. The gateway cannot unlock a door by itself. The management panel does not make security decisions. Each component completes only its assigned check.
-
01
Mobile deviceIdentity + local approval
-
02
GatewaySingle-use request + gateway check
-
03
UWB zoneSecure distance measurement
-
04
ServerUser permission + reuse check + security level
-
05
Door controlSingle-use command + sensor result
-
06
Access / AttendanceSeparate product outcomes
-
07
Management and integrationsRole-based access + versioned API
-
08
Transaction historyChecks performed and reason for the result are visible
MesaiGo Gateway
Four deployment-ready gateway models. The same protection rules in every model.
Verify, Access Lite, Access, and Access Pro differ by WiFi, Ethernet, NFC, relay and sensor connections, and secure UWB support. Identity checks, server decisions, signed updates, and transaction records follow the same rules in every model.
VerifyWiFi · BLEAttendance and physical presence
Access LiteWiFi · BLE · 2R/4IDoors and turnstiles
AccessEthernet · WiFi · BLE · NFCEnterprise access
Access ProEthernet · WiFi · BLE · NFC · UWBHigh Assurance
LIVE VERIFICATION
BLESingle-use requestGateway verification
HIGH ASSURANCE
Secure UWBLocal transaction approval
FIELD CONTROL
2 relays4 protected inputsNFC
SAFE OPERATION
Signed updatesDevice statusDeny without verification
Manage from one place
Manage rules, gateways, events, and attendance records from one place.
Security, IT, HR, and operations teams work in views designed for their responsibilities. The values below represent an illustrative business scenario that explains the product flow.
Live transaction stream
Review allowed, denied, and unexpected transactions with the security level and rule used for each decision.
Gateway fleet health
Manage identity, firmware, connectivity, tamper, UWB calibration, and rollout status.
Missing or incorrect attendance records
Resolve missing departures, breaks, overtime, and correction requests without changing the original verification record.
Who can do what
See which actions each user can perform for each organization, facility, entry point, and time window.
Connections to existing systems
Connect identity, HR, payroll, turnstile, and security systems.
Every integration states what data it reads and writes, how it authenticates, how it behaves on failure, and which API version it uses.
MESAIGOVERSIONED APIS
Identity
SAML · OIDC · SCIM
HR and payroll
HRIS · ERP · Payroll
Physical systems
OSDP SC · I/O · Fire
Security
SIEM · Signed webhook
Developer
API · Sandbox · Changelog
Server
Cloud · Isolated installations
No GPS or biometric data collection
Verify presence without tracking people.
MesaiGo does not base access or attendance decisions on GPS coordinates and does not collect face images, fingerprints, or biometric templates. High Assurance user verification remains inside the device operating system.
- No background GPS tracking
- No centralized biometric templates
- Only the required transaction record, only for the required time
- Employees see their own records and every correction
MesaiGo Mobile
Explore the mobile app
Secure verification in a focused, seconds-long experience.
From enrollment to verification, employees do not see the underlying technical complexity. They choose the correct space, approve the transaction on-device when required, and see the server-signed result.
01
VERIFICATION FLOW
Enroll your phone
VERIFIED
02
VERIFICATION FLOW
Open the correct entry point
VERIFIED
03
VERIFICATION FLOW
Verify with Standard or High Assurance
VERIFIED
04
VERIFICATION FLOW
View the result and your own attendance record
VERIFIED
High Assurance · Access Pro
Access verified
RECORDED
Mobile distribution
MesaiGo Mobile follows the same security rules on iPhone and Android.
Store listings clearly identify the published build, privacy disclosure, support link, and compatibility information. Review teams receive a version-bound, time-limited package that is clearly identified as a simulation and requires no physical hardware.
- Key created for the enrolled phone
- BLE Standard + UWB High Assurance
- Hardware-free demo for store review
- Clear data and permission disclosures
App Store
Enabled when the final release link is published
Google Play
Enabled when the final release link is published
Store badges appear only after the App Store and Google Play pages for the published version have been verified.
MESAI GO MOBILE
Verification stays on your enrolled phone.
iPhone · Android
Explore the mobile product and review flow
Trust Center
Instead of saying “trust us,” we show what each decision relies on.
Controls against attacks
Separate controls address sharing, reuse of an old transaction, live relay, fallback to weaker security when verification is missing, key compromise, and physical field risks.
Device enrollment and renewal
Device enrollment, verification, key renewal, revocation, replacement, and reinstallation steps are defined explicitly.
Security updates and incident response
The software component list (SBOM), signed releases, vulnerability-reporting channel, security advisories, service status, and incident-response steps are documented.
Data use and retention
The purpose and retention period of each data item, and the records employees can access, are stated explicitly; every change is recorded.
Product assessment
Let us identify the right MesaiGo solution for your needs.
We will evaluate your entry points, required security level, employee steps, and existing infrastructure to select the right gateway model.