Identity Management
Hardware-Bound Identity.
Checked Against Location.
NonaShield manages device identity by binding each customer to a key generated inside the phone's secure hardware, which cannot be exported or cloned, then testing every session against location signals: impossible-travel velocity, GPS versus IP geolocation, and a learned home zone. Identity proves which phone is calling; location tests whether the session makes sense.
The identity is the chip, not a file.
Key created in hardware
The identity key is generated inside the TEE or Secure Enclave (StrongBox first on Android). The private key never exists in OS memory and the hardware blocks every read request for it.
Stable device ID from the key
The device ID is the SHA-256 hash of the device's own hardware-backed public key. It changes only if the key material itself changes.
Every request is signed
Each request carries a hardware-signed proof. A copied token or cloned app on another device cannot produce the signature.
Not backed up, not synced
Because the key cannot leave the chip, it is not included in cloud backups and cannot be moved to a different phone.
Software identities such as device IDs and app tokens sit in the ordinary file system, get copied into cloud backups, and can be moved by malware with root access. A hardware key removes that route. Read the full hardware-backed possession explainer →
Three independent location checks.
A device can claim to be anywhere. It cannot claim to have travelled faster than physically possible between two real sessions, and a mock-GPS app cannot change where the network traffic comes from.
| Signal | Thresholds |
|---|---|
| Geo-velocity (Haversine distance ÷ elapsed time) | ≥ 900 km/h impossible travel · ≥ 500 km/h high velocity · ≥ 200 km/h cross-region |
| GPS versus IP geolocation | Mismatch ≥ 300 km low severity · ≥ 1,500 km high severity |
| Home-zone deviation (learned per customer) | ≤ 100 km clean · 100–300 km warning, step-up · 300 km+ high risk, step-up only |
Each check covers the other's gap.
A cloned identity used from another place fails the location checks. A spoofed GPS fails the IP cross-check. A genuine phone in an unusual place is stepped up rather than blocked. Together they give one identity decision with evidence behind it, recorded in a signed, hash-chained evidence chain and combined with device fingerprinting in the unified platform.
Anonymous-IP databases that flag VPN and Tor exits are incomplete across every vendor. NonaShield therefore combines ASN heuristics and a maintained hostile-ASN list with behavioural and velocity signals, so no single missed database entry becomes a single point of failure.
Hardware-bound identity, answered.
What is hardware-bound identity management?
It means each customer's device identity is a key generated inside the phone's secure hardware (StrongBox, TEE or Secure Enclave) that cannot be exported, backed up or cloned. Every request is signed by that key, so the server knows it came from that specific chip.
How does location improve device identity?
Identity proves which phone is calling; location tests whether the session makes sense. NonaShield scores geo-velocity between sessions, cross-checks device GPS against IP geolocation, and compares each session with a learned home zone.
Can a GPS-spoofing app defeat the location check?
A mock-GPS app can fake the phone's own location, but not where the network traffic originates. NonaShield cross-references device-reported GPS with edge-derived IP geolocation on every request and flags large mismatches.
Does a location mismatch block the customer?
Not automatically. A deviation from the learned home zone triggers step-up authentication, never an automatic block. Impossible-travel velocity and large GPS-versus-IP mismatches carry higher severity.
See it on your app.
Book a free 30-day shadow pilot, or get the platform brochure.