Edited (after comments)
First of all
Save sensitive data on the client is a matter of agreement between the user and the owner of the data. You should get into the details of the software license, and the privacy policy that claims to offer.
Deciding to save data to the client application, without a robust synchronization policy, can create problems of data consistency (apart from safety).
Deciding to save data to the client application, can result in a complex system of synchronization increasing database workload (a hell).
I personally believe that the device should only be used as terminals, not as part of the architecture.
For those reasons, save data locally is not a good option, and +1 to Nikolay for
Caching sensitive data: Don't.
The customer is right, and not listen to reason
Having said that, if the request is mandatory, and there is no way to convince the customer/owner to move towards an on-demand architecture, you must find all the tricks to increase security within the client, protecting the rights, privacy and in general the access and use of data.
The proposal (which is one of opportunity), consider the following key points:
- The user must log into the system at least once;
- After login, we will carry out the synchronization of local data with the server;
- After synchronization, a new encryption key will be generated (see details below) and used throughout the session (including after you disconnect from the server and network);
- All information processed by the customer, even after disconnection, will be saved in the device, using an algorithm that considers the "encryption key currently available";
Two-Factor Auth
The keys to encrypt data during sessions will be generated after the log in process. The 2nd factor is a key element to maximize the safety of a product that can be defined as "unsafe".
This mechanism ensures that if the device is stolen (for example), the data available locally, will be limited to one session, but most important, the remote system will not be accessible using the device.
What about VPN or ...
A product developed specifically to be used within an intranet, where the device does not have ability to connect to other networks, it does not need high security mechanisms, indeed, that kind of products only need to identify the user (you would use identity certificates, LDAP or similar devilry).
If the application must save data locally and can be distributed in any type of device (which has the minimum requirements), the VPN is no longer a security element within the design.