No. A device identifier is a value the client sends, and anything the client sends can be copied or faked. Use it, at most, as one signal. Authenticate with revocable tokens, and if you want to bind a login to a device, use a hardware backed key rather than a readable identifier.
Why a device ID is not a credential
A credential proves something. A device ID only claims it. If your API accepts "device 1234 is calling, so it is Alice's phone," anyone who learns or guesses the value can say the same thing. Identifiers show up in logs, analytics, support tickets and crash reports, and on a rooted device or in a test tool they can be set to anything.
The OWASP Mobile Application Security Cheat Sheet is direct: avoid spoofable values like device identifiers for authentication, and use device specific tokens that can be revoked. It also says to assume all client side controls can be bypassed and to perform them server side too.
What a device ID is good for
| Use | Reasonable? |
|---|---|
| Counting installs and sessions | Yes |
| Spotting one account used from many devices | Yes, as a risk signal |
| Rate limiting as one of several keys | Yes |
| Deciding whether to ask for a second factor | Yes, as input |
| Proving who the user is | No |
| Granting access to data | No |
Also check privacy rules. Persistent identifiers can be personal data in some regions, and platforms limit which identifiers an app may read. Collect only what you need and document why.
Better ways to tie a login to a device
- Issue a refresh token at sign in and store it in the platform's secure storage. It is revocable on the server, which a device ID is not.
- Make the token device specific, so a list of "my devices" can be shown to the user and each can be revoked on its own.
- For stronger binding, use a hardware backed key pair. Apple's App Attest generates a key pair that the device keeps in the Secure Enclave, and Apple's documentation says no process can read or modify the private key. Apple recommends one key per user account per device.
- Use sender constrained tokens such as DPoP so a copied token cannot be replayed from elsewhere.
- Require re authentication for sensitive actions, regardless of how trusted the device looks.
A hardware backed key proves a request came from the same device that enrolled, in a way a readable identifier never can. It still does not prove who is holding the phone, so keep user authentication in place.
A sign in flow with device awareness
- User signs in with a password, passkey or single sign on.
- The server issues tokens and records a device entry: token ID, first seen, last seen, and a coarse description such as model and operating system.
- New devices trigger a notification to the user.
- The user can see and remove devices.
- Suspicious changes, such as the same token from two continents, trigger revocation.
Mistakes to avoid
Using the IMEI or advertising identifier as a password. Putting the device ID in a URL. Trusting a device ID that arrives in a header with no other proof. Treating "trusted device" status as permanent.
Safeguard's SBOM and dependency scanning shows which SDKs ship in your app, a starting point for privacy reviews. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a device ID safe if it is long and random?
Randomness stops guessing, but not copying. If the ID is readable by the app or an SDK, it can leak, so it still should not act as a credential.
What replaces it for remembering a trusted device?
A revocable device bound token, ideally paired with a hardware backed key, with a short trust period and re authentication for sensitive actions.
Sources
Last reviewed: 19 October 2026.
