Trusted Devices
Recognize approved devices, fingerprints, browser sessions, and mobile app contexts before sensitive work continues.
Device Trust
Control which devices can work, sync, unlock offline mode, and keep sessions trusted.
AWRA Device Trust gives enterprise teams a clear security layer for trusted devices, mobile offline access, session review, revocation, device evidence, and access governance across warehouse, field, finance, vendor, and admin workflows.
Why this page matters
Enterprise buyers care about more than usernames. They care about the device behind the action.
Operational teams work from browsers, shared warehouse phones, scanners, Android field devices, finance laptops, and vendor portals. Device Trust helps AWRA explain who acted, from which device, whether that device was known, whether offline access was allowed, and how admins can review or revoke trust when the risk changes.
Offline Unlock
Limit offline mobile access to devices that previously authenticated and hold a short-lived trusted session.
Revocation
Let admins revoke device trust, terminate suspicious sessions, and contain endpoint risk quickly.
Access Review
Connect device history, user identity, role access, sync status, and audit evidence into one review story.
Trust lifecycle
From login to offline sync, every device should carry trust context.
Device Trust works best when it follows the operational workflow. The same device context that unlocks mobile offline work should also support sync review, suspicious activity detection, session governance, and audit trails.
Authenticate the user
Verify identity through normal login, MFA where required, organization scope, and role-aware access rules.
Recognize the device
Record device fingerprint, browser context, app context, IP pattern, session metadata, and recent trust status.
Allow trusted work
Permit normal work, mobile scanning, offline preparation, or sensitive review only when trust conditions are satisfied.
Review risky changes
Surface unfamiliar devices, stale devices, unusual access, failed MFA, and sensitive actions for admin review.
Revoke, expire, or audit
Terminate sessions, revoke trust, expire offline unlock, and preserve evidence for governance review.
Security dimensions
Device trust connects identity, session, mobile offline work, and audit evidence.
A user account may be legitimate while the device deserves review. AWRA Device Trust gives security-conscious buyers a practical way to govern the endpoint, not only the username.
Device Fingerprint
Preserve device context for access review, scanner sessions, mobile workflows, and audit trails.
Session Governance
Review active sessions, terminate risky access, and keep sensitive actions tied to trusted contexts.
Field Evidence
Pair device trust with GPS, timestamp, scan source, user, and payload evidence when mobile work syncs.
Admin Containment
Contain risk by revoking trust, blocking unknown devices, and requiring fresh authentication for sensitive work.
Governance controls
Device review should be practical enough for real operations teams.
AWRA Device Trust can help admins decide which devices are safe, which need review, which should lose offline privileges, and which sessions should be terminated.
Device control examples
Review the conditions that matter most in enterprise operations.
Trusted mobile deviceCan prepare offline data after successful login and policy checks.
Trusted Offline unlock expiredRequires online re-authentication before continuing offline work.
Refresh Unknown browser sessionRequires MFA and admin-visible review before sensitive workflows.
Verify Revoked warehouse phoneCannot sync new payloads until trust is restored by an authorized admin.
Blocked Visual trust context
Show device trust beside the workflow so teams understand why access is allowed, challenged, or blocked.
Device governance should reduce risk without making warehouse, field, and finance work feel trapped behind vague security prompts.
Policy controls
Sixteen settings, and every one of them names the thing that enforces it.
A security questionnaire is a list of settings, and any vendor can produce the list. What matters is whether each row is wired to something that refuses. These are the controls an administrator configures for the whole organization, each shown with the mechanism that acts on it — and with what happens if you leave it alone.
Sessions
How long a signed-in session survives, whether anybody is using it or not.
Idle timeout Signs out a session left untouched for the period you set — the unattended finance workstation problem. Enforced on every authenticated request
Off by default Absolute session lifetime Ends a session a fixed number of hours after sign-in regardless of activity, so a session cannot be kept alive indefinitely by use. Enforced on every authenticated request
Off by default Passwords
Four controls, all of which can only tighten what AWRA already demands.
Minimum length & complexity Raise the floor above the platform minimum of twelve characters with mixed case, numbers and symbols. Enforced at sign-up and at every reset
Baseline on Expiry Requires a new password after a number of days. A user whose password has aged out is sent to reset it at sign-in rather than blocked. Enforced in the sign-in gate chain
Off by default Reuse history Refuses the last N passwords, so expiry cannot be satisfied by cycling back to the same one. Enforced at reset, against stored history
Off by default Who may sign in
The controls that decide whether an attempt is even eligible.
Identity provider only Turns off password and magic-link sign-in so everyone arrives through your configured provider. Refused outright if no provider is set up — saving it would leave a workspace nobody could enter. Enforced in the sign-in gate chain, all routes
Off by default Allowed email domains New users can only be created on domains you list, so an invitation cannot quietly go to a personal address. Enforced when a user is created
Off by default Failed-login lockout Locks an address after N failures for M minutes. Counted against the address rather than the account, so attempts on addresses that do not exist are counted too — otherwise the lockout itself would reveal which addresses are real. Enforced before credentials are checked
Off by default Where from, and on what
Network and device conditions, now driven by policy rather than only by the presence of a list.
IP allowlist enforcement The master switch over your address list. It exists so an administrator locked out by a changed office address can suspend enforcement instead of deleting every entry to get back in. Enforced in request middleware
On by default Device approval required An unrecognised device is registered and refused until an administrator releases it from the device list already on this page. No new approval queue to learn. Enforced in request middleware
Off by default On the handset
Four controls the Android app collects from the server and applies on the device.
Biometric app-lock & lock timing Requires a fingerprint or face to re-enter the app, and sets how long it may sit idle or backgrounded first. Drives the lock the app already had rather than adding a second one. Applied by the app, on idle and on resume
Off by default Block screen capture Screenshots and screen recording fail, and the app is hidden in the recent-apps switcher. Enforced by Android’s window compositor, not by the app asking. Applied on first frame and every foreground
Off by default Block compromised devices Refuses a handset that reports as rooted and revokes its session. A speed bump against casual misuse rather than a guarantee — see the note below. Enforced server-side when the device reports in
Off by default Two rules about the rules
The design decisions behind the table, which matter more than any single row in it.
Policy tightens, never loosens Every control is combined with the platform baseline by taking the stricter value. A workspace configuring a four-character minimum still cannot weaken sign-up — and neither can anything writing to the settings table directly. Resolved in one place, for every enforcement point
Always Off by default, on purpose Switching session expiry or provider-only sign-in on for a workspace already in use would lock real people out of live work. So new controls arrive inert and you decide. The one exception is IP allowlist enforcement, which defaults on because allowlisting was already active wherever a workspace had entries — shipping it off would have silently removed protection. Applies to every control above
One exception Where MDM meets workspace policy A managed Android profile and the workspace policy are merged by taking the stricter value in each direction, so a fleet can be hardened further than the organization-wide setting but never below it. Merged on the device, before anything is applied
Stricter wins Said plainly
Which of these hold, and which are speed bumps
Screen-capture blocking is enforced by the operating system, so it holds. Compromised-device detection is a heuristic running on a device whose owner — if it genuinely is rooted — already has more privilege than our app process, so anyone determined defeats it. It raises the cost of casual misuse and gives you an honest record of what each device reported, and that is the whole of the claim.
Everything in the first four groups above is enforced on our side, which is why those are the rows to lean on. Where a device claims something, the claim itself is written to the audit trail — and that trail is now sealed so the record of a refused device cannot be tidied away afterwards.
Deploying to a fleet of shared handsets is covered on the Android app page, including the five managed-configuration keys your MDM console can set before a device reaches anybody’s hands.
Enterprise scenarios
Device Trust is where security meets messy real-world operations.
It is built for shared devices, changing network conditions, field work, warehouse scanning, finance review, and vendor access where the endpoint matters as much as the user.
A warehouse phone loses internet but still needs to scan and queue movements.
AWRA can allow a short trusted offline session only because the device authenticated earlier, then validate queued work when the phone reconnects.
A user reports a missing device that had access to inventory and asset workflows.
An administrator can revoke trust, terminate sessions, review recent activity, and keep the evidence trail available for investigation.
Connected AWRA workflows
Device trust supports security, mobile work, scanners, action queues, and enterprise governance.
The value story connects mobile offline controls, scanner sessions, security operations, smart alerts, audit governance, and the broader trust center.
Security Operations
Unify IP controls, MFA enforcement, device governance, and audit intelligence.
Mobile Offline Operations
Use trusted offline sessions, queued actions, GPS evidence, and server-side validation.
Offline Control Center
Monitor stale devices, failed syncs, queued payloads, GPS issues, and reconnect behavior.
Linked Scanner Bridge
Pair scanners through controlled QR sessions with token lifecycle and session closure discipline.
Smart Alerts
Surface unknown devices, stale devices, failed sync, suspicious sessions, and governance exceptions.
Enterprise Governance
Keep roles, permissions, audit events, sensitive actions, and trust decisions reviewable.
Endpoint governance
Trust the right devices, challenge risky sessions, and revoke access when operations change.
AWRA Device Trust gives enterprise teams a practical control layer for mobile work, browser sessions, scanner pairing, offline access, sync validation, and security review.
Help Center
Need a quick answer while you read?
Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.
