7 Best Practices for Employee Mobile Device Rollout

Banks are deploying mobile devices for employees at the highest rate of any industry, but must address issues like security and cost in managing those devices.

Only a few years ago, financial institutions were looking at the bring-your-own-device (BYOD) movement with trepidation because of concerns that their carefully constructed information security infrastructure would come tumbling down as loan officers and other employees tapped their way to needed data. Today, many banking organizations are not only tolerating employee use of smartphones and tablets but embracing it.

The shift in attitudes spans institutions of every size. Examples of adoptees include the National Banks of Central Texas, which has rolled out a mix of iPhones, iPads and Android devices to its 10 branch offices, and UK-based banking giant Barclays, which last November purchased 8,500 iPads to facilitate face-to-face customer interaction beginning with a new app enabling fast market-wide searches for mortgage loans.

The challenge is to manage both bank-owned and employee-owned mobile devices with the robust device, data and application security controls required to address the stringent governance, compliance and asset protection needs of the banking environment. Also critical is the ability to save money on recurring mobile expenses by monitoring device usage for voice, data or text overages.

Achieving these objectives requires admins to set mobile device policies as well as utilize tools like mobile device management (MDM) services to enforce them. Here are seven building blocks that banks can use as a foundation of a secure and cost-effective mobile program.

1. Determine which apps will be allowed and banned.

Core business apps like mortgage loan, business loan and wealth management programs clearly need to be accessible to mobile users, but some public apps should be off-limits on employee devices to avoid compromising security, productivity and/or legal or regulatory compliance as well as to reduce the risk of device infection by malware or other malicious code. Admins can dictate what’s allowed – and what’s not – by utilizing the whitelist and blacklist functions of the bank’s preferred MDM solution.

Whitelists should include all private in-house apps, which will be pushed to smartphones and tablets by IT staff; customer service apps like Salesforce CRM that are used by the bank; email and other applications from office suites like Microsoft Office and Google Enterprise; and other tools and databases that should be installed on the device for business use.

Blacklists might include social networks, gaming and movie/TV streaming services, apps with sexually suggestive or other objectionable content that might expose the bank to legal action, and unauthorized cloud storage apps that can cause data leakage. Admins may also want to restrict the use of some apps that come pre-installed on the mobile device. Blocking Apple’s iCloud storage service, for example, will prevent bank employees from backing up bank information to their personal cloud.

Blacklists can typically be configured in MDM software simply by checking boxes with unwanted categories and specifying additional undesirable apps by URL or keyword. While the ability to stop users from downloading blacklisted apps varies depending on the mobile OS, the MDM solution can issue a warning, lock the user’s email access or even selectively or completely wipe the affected device if it detects installation of an unwanted program.

2. Control app access by location.

Access control can also be enhanced – particularly in the case of employee-owned devices where admins have limited control over users’ app habits – by preventing employees from using certain apps on bank premises. Admins might want to disable device cameras inside the bank to eliminate the risk of mobile users taking a screenshot of a customer’s account; bar the use of game apps or media streaming at bank locations; and so on.

This can be accomplished by using the MDM solution’s geofencing capabilities to activate or deactivate mobile features and apps within specific geographic boundaries. The same geofencing functionality can also be used to automatically switch the mobile device from the carrier network to the bank’s WiFi connection as users enter the bank zone, helping reduce data bandwidth costs.

3. Establish device locking and user access control policies.

Whether the device is bank-issued or employee-owned, an important but often overlooked step is to establish user authentication controls via strong password policies. How frequently should they be changed? How many invalid logins should be permitted, and how long a period of inactivity, before the device is locked? And who can access what data using what mobile apps from what kinds of devices? Banks may want to limit mobile access to critical banking applications because of the higher risk of a data breach over unsecured mobile communication channels and potential infection by malware or rogue apps.

Once established, device locking policies should be deployed over-the-air (OTA) for easy mass distribution, and for easy on-the-fly changes of details such as password length, strength, complexity and reuse. (Policies that are stricter than those provided with the mobile OS will supersede the OS rules.) Admins should also be able to remotely reset forgotten passwords, and override passwords for lost or stolen devices in order to erase sensitive information.

Banning social app access for employees is common in financial services, but the tide is shifting. Social business is becoming more and more a part of corporate life. I think we will see social bands altered over the next few years.

For a frame of reference, banks initially banned access to the internet for most employees, but that has changed as employees obviously use the internet for work and personal use all the time.

Does BYOD come with headaches? Of course it does. However, security issues and IT management headaches (how do I support all those devices?) can be addressed by using new HTML5 technologies that enable users to connect to applications and systems without requiring IT staff to install anything on user devices. For example, Ericom AccessNow is an HTML5 RDP client that enables remote users to securely connect from iPads, iPhones and Android devices to any RDP host, including Terminal Server and VDI virtual desktops, and run their applications and desktops in a browser. This enhances security by keeping the organization's applications and data separate from the employee's personal device.

Since AccessNow doesn't require any software installation on the end user device Gă˘ just an HTML5 browser, network connection, URL address and login details - IT staff end up with less support hassles. An employee that brings in their own device merely opens their HTML5-compatible browser and connects to the URL given them by the IT admin.

Instead of outright banning some social networking and gaming apps, would there ever be a scenario where these apps might be useful to business goals that would warrant only restrictions? Or would these be reserved for limited employees who might have interaction with customers?