Securing Mobile Data: A Logic-First Approach
Remote wipe is not enough to protect mobile data. NIST warns that someone could access information before a wipe happens, or switch a device off to stop the command reaching it. Its guidance treats remote wipe as one part of a wider set of protections, not a substitute for securing information already on the device.
For an offline field app, we recommend starting with a specific question: what should this person be able to read or change while the server is unreachable? Write that decision down before choosing storage libraries or management products. Treat the examples below as design and acceptance-test recommendations, rather than claims about controls every mobile platform provides.
Define the data and the permission together
NIST recommends threat modelling before designing and deploying a mobile solution. That means identifying the information worth protecting, plausible threats and the controls needed to address them. Its mobile guidance covers device loss, phishing, malware and data escaping through synchronisation.
We would turn that assessment into a data inventory for the app. For each record type, name the users who need it, the reason they need a local copy and the point at which that copy should be removed. Include attachments and exports in the exercise, rather than reviewing the main database alone.
For example, specify that an inspector may download assigned work but not every customer's history. Decide separately whether they may view a completed inspection, amend it or export it. These are proposed business rules to prove in tests, not permissions to assume a device management product understands.
This also gives a legacy migration a useful starting point. Review each inherited permission against the intended mobile task. Do not declare an old system insecure simply because it is old, or accept a permission simply because the web application already has it.
Check storage protection and key handling
NIST distinguishes encryption from application sandboxing. Sandboxing generally separates apps and their data. Encryption restricts access through cryptographic keys. The guidance also notes that a device's encryption key may be managed by the operating system rather than by the enterprise or app developer.
Ask the implementation team to identify which mechanism protects each local copy. For a field app, our proposed review would include the database, downloaded documents, captured photographs and temporary exports. Record the evidence for each one instead of accepting a single statement that the phone is encrypted.
Hardware support needs the same care. NIST describes dedicated hardware for protecting keys and other sensitive information, but says apps must use the appropriate platform interfaces to benefit from those capabilities.
Our acceptance criteria would therefore ask the builder to demonstrate the chosen key storage and retrieval behaviour on supported devices. Include failed authentication and device restart in that demonstration. Do not infer that a hardware feature is in use from the device specification alone.
Separate local access from server access
NIST describes different authentication controls for unlocking a device and accessing organisational resources. Its management guidance includes idle locking, remote locking and controls on access to enterprise services.
For offline work, we recommend specifying local access separately. Decide whether a user must authenticate again after inactivity, how long an offline session may continue and what the app should do when that period ends. Choose those rules with the operational team rather than inventing a universal expiry time.
Test a role change during a disconnected shift as a separate scenario. State what the app should permit before reconnection, then what the server should accept afterwards. Require the test to cover queued changes as well as fresh requests. This is a proposed test of the application's permission design, not a promise that disabling an account immediately removes a disconnected copy.
Review synchronisation and data sharing
NIST identifies synchronisation and automatic backups as possible routes to storage outside an organisation's control. It gives examples including remote photo backup services and connections between personal and organisation-issued equipment.
Use that finding to widen the review beyond the app's own sync endpoint. Ask where photographs go, which backup services include work data and which sharing actions are permitted. Agree the required behaviour for each supported deployment, including personally owned devices where relevant.
NIST also recommends encrypting stored data and communications. Its network guidance cautions that a VPN may not protect all traffic. Ask for evidence of what is encrypted and how endpoints authenticate, rather than treating the presence of a VPN as the completed check.
Make security review repeatable
NIST's mobile app vetting guidance starts with security requirements defined by the organisation. It separates general requirements from requirements specific to the intended users, data and operating environment.
We recommend making those requirements part of the delivery acceptance criteria. Ask reviewers to inspect the storage and permission design, then exercise the relevant behaviour on a device. Preserve the expected result beside the observed result so that another reviewer can repeat the check.
Do not treat one assessment as permanent approval. NIST recommends establishing conditions that trigger app re-vetting. For this field-app design, we would include changes to local storage, authentication and sharing in that review policy.
Start with one sensitive record type and demonstrate its complete offline behaviour before expanding the scope. Require evidence for who can download it, how its local copy is protected and what happens when access should end.
Update, October 2026
For a later delivery perspective, our engineering article on independent review and verification before merge describes a gated development process. Use it alongside the mobile-specific requirements above, not as a replacement for a security assessment.
Sources
Want this in your team?
Tell us what you're building and where you want to get to, and we'll think it through with you.