A secure mobile experience combines understandable user actions with controls that remain effective when a device is lost, an account changes, or a client sends an unexpected request. The design must account for who owns the device, which information it holds, and what the person is allowed to do. A company-managed employee phone and a customer’s shared handset should not inherit identical assumptions.
For a security and product leader launching both employee and customer mobile experiences, the decision is which controls belong in the device, the application, the identity service, and the business API. Concentrating everything at sign-in leaves important gaps. Burdening every action with the same friction can make the product difficult to use without addressing the highest-consequence threats.
Start with a task-specific threat model and a control assignment. This article proposes a practical review using a hypothetical parcel-delivery service. It is architecture guidance, not a certification, compliance determination, or substitute for security testing of a particular implementation.
Distinguish employee and customer trust conditions
An organization may control an employee device’s configuration, approved software, and retirement process. On a customer device, it usually has far less control. Ownership arrangements also vary among employees: personally owned phones, shared shift devices, and dedicated corporate devices create different privacy and support considerations.
NIST’s enterprise mobile-device guidance addresses risks, management technologies, ownership arrangements, and lifecycle controls. It supports treating device management as one part of a broader security program rather than assuming application design alone resolves every exposure. NIST SP 800-124 Revision 2, Sections 3–5
List the assumptions the product actually relies on. Is the device screen locked? Can multiple people use the same account? Does the employee hand the device to a colleague at shift end? Could a customer open a notification while another person is watching? These conditions change the sensible defaults for local history, notifications, and reauthentication.
Do not turn employee management controls into an unquestioned requirement for customer participation. A customer may reasonably decline broad device access. Evaluate whether the business task needs that access at all and provide a proportionate alternative where feasible. Privacy and employment implications require review in the relevant organizational and jurisdictional context.
Map threats to concrete business consequences
Begin with a small number of adverse outcomes. For parcel delivery, they might include another person’s address being exposed, a delivery instruction being changed without authority, a driver viewing work outside the assigned route, or an attacker taking over an account through recovery.
For each outcome, identify the entry points and trust boundaries. A lock-screen notification, an API request, a locally cached record, a shared device, and an account-recovery conversation are different paths. A control that protects one path may leave another untouched.
Assign responsibility explicitly. The app can limit what it stores and displays. The identity system establishes authentication. The service must enforce which parcel or route the caller may access. Operations owns assignment and offboarding events. Support owns a recovery procedure that does not bypass the intended protections.
Prioritize by consequence and plausible exposure, not by the visibility of a feature. A polished biometric prompt does not fix an API that accepts an arbitrary parcel identifier. A strong API does not prevent a notification from revealing sensitive delivery details to someone holding a locked phone.
A hypothetical delivery service
Imagine a hypothetical delivery company with a driver app on managed shift devices and a customer app on personally owned phones. Drivers need the parcels and delivery instructions for their assigned route. Customers need information about parcels they are authorized to manage.
A driver finishes a shift and hands the device to another employee. The design should end the prior session, remove or appropriately isolate the previous route’s local data, and establish the new employee’s identity and assignment. Simply changing the displayed name can leave cached records or queued actions associated with the wrong person.
Meanwhile, a customer shares a household tablet. A notification reading “Delivery update available” may be preferable to displaying the full address and access instructions on the lock screen. The appropriate content depends on the task and user choices, but sensitive details should not appear merely because notification delivery is convenient.
Now consider an API request that substitutes a different parcel identifier. The server must evaluate whether the caller is authorized for that parcel and action. Hiding other parcels in the app’s navigation does not enforce that boundary. Test direct requests as well as ordinary screen interactions.
A more consequential action is changing a delivery destination. The product should define who may request the change, which state permits it, whether additional verification is needed, and how the user reviews the exact new destination before committing. The control should reflect the business risk rather than assume that a previous sign-in authorizes every later action.
Finally, a customer loses access to the account. Recovery must establish the appropriate identity and parcel relationship without disclosing unnecessary information to an impostor. A weak support workaround can undermine strong application authentication, so the security review must include the human recovery route.
Use authentication correctly without overclaiming it
Authentication establishes an identity or session under defined conditions. Authorization decides whether that identity may perform a particular action on a particular resource. Keep the two decisions distinct in design, testing, and support explanations.
For native OAuth applications, RFC 8252 requires an external user agent for authorization and PKCE for public clients. It also explains why a secret distributed with an application cannot be treated as a confidential client credential. Evaluate the actual flow and redirect handling, including error and cancellation paths. RFC 8252, Sections 5, 6 and 8.5
Protect session material with appropriate platform facilities and limit its scope and lifetime according to the risk model. Avoid placing credentials or tokens in logs, analytics, screenshots, or error reports. The implementation details should be reviewed for each supported platform rather than assumed equivalent because the interface looks the same.
Additional verification can be appropriate for a consequential action, but it should be tied to that action and understandable to the user. Explain what is being confirmed, preserve a safe draft where possible, and provide a controlled recovery route. Repeated unexplained prompts can encourage workarounds without improving the relevant decision boundary.
Reduce the information exposed by ordinary features
Inventory every place data can appear: local databases, temporary files, photographs, clipboard content, notifications, diagnostic logs, backups, exports, and support tools. The main application screen is only one surface. Decide which locations are necessary and who can access them.
Cache the minimum useful working set. A driver assigned to one route should not automatically receive an entire customer directory. A customer viewing one parcel may not need a permanent local copy of every historical address. Limiting data reduces the consequences of several failure modes even when it cannot eliminate them.
Review application permissions with the same discipline. Request access when the task needs it, explain the purpose, and handle denial without misleading the user. A denied camera permission may justify a manual evidence route; it should not cause the app to fabricate success or ask for unrelated permissions.
Plan data cleanup for sign-out, reassignment, and device retirement. Verify the behavior in the actual storage and backup arrangements. A remote action may not reach an offline device immediately, so do not describe remote wipe or revocation as an instantaneous guarantee.
Make recovery and support part of the product
Users forget credentials, change phones, lose devices, and encounter interrupted verification. Design these journeys before launch. Specify what support can inspect, what it can change, and which changes require stronger checks or an authorized specialist.
Use safe diagnostic references. Support should be able to trace an operation without asking the user to send full addresses, identity documents, or session material through an unsuitable channel. When sensitive evidence is genuinely needed, provide an approved collection and retention process.
Rehearse an employee departure or route reassignment. Confirm that new server requests are evaluated against the current authority and that cached data follows the approved local policy. Preserve appropriate audit evidence without leaving a former user with unnecessary access.
Also rehearse a mistaken security block. A legitimate customer denied access needs a clear route to resolution. Security controls that cannot be explained or corrected can create operational pressure for unsafe bypasses. Track those bypass requests as evidence that the design or support process needs attention.
Verify controls against misuse cases
Acceptance testing should include wrong-resource identifiers, expired sessions, changed assignments, shared-device handover, lost connectivity during a sensitive action, and recovery attempts with incomplete evidence. A successful normal-path demonstration says little about these boundaries.
Separate implementation testing from policy judgment. A test can show that a driver cannot retrieve an unassigned parcel under the tested conditions. It cannot establish that the organization’s assignment policy is appropriate for every role or jurisdiction. The accountable business and security owners must review that policy.
Record residual risks and the conditions under which the application remains supported. A legacy device without needed protection, an unsupported operating-system version, or a required offline access window may change the risk acceptance decision. Avoid claiming that a checklist makes the product universally secure.
The next useful action is a joint review of one employee journey and one customer journey, including loss, handover, denial, and recovery. Assign each control to its enforcing boundary and require evidence that it works there. The result should be an experience that helps legitimate users complete their tasks while preserving clear limits on information and authority.
