Lessons learned on the digital workspace journey with Workspace ONE

Applications often have secrets that should not be hardcoded in the source code. This poses a challenge for developers, as ProGuard can change classes and method names, it won't help with secrets. Examples of secrets that can be removed from application source code include an API key or a OAuth refresh token. Another capability is for the MDM to dynamically deliver values to the application, such as the current logged in user, device serial number, or organization group. Google has made it more challenging to access non-resettable device identifiers like the serial number in recent years, and this remains a viable solution to provide non-resettable device identifiers (and other values) to applications running on the device. So how do we do it? Workspace ONE UEM can deliver profiles to devices. Profiles can configure a number of settings, in addition to delivering key/value pairs to your applications.  Google refers to these key/value pairs as Managed Configurations, aka application

Recent news from the Google Chrome team reminded me to revisit a previously created tool that allowed enterprises to manage public application updates in their digital workspace. The Chrome team announced that they would temporarily pause upcoming Chrome & Chrome OS releases, and focus exclusively on security updates. It became clear that I needed to update this tool, and tailor it for Google Chrome.  Due to adjusted work schedules, we’re pausing upcoming Chrome & Chrome OS releases. Our goal is to ensure they continue to be stable, secure, & reliable for anyone who depends on them. We’ll prioritize updates related to security, which will be included in Chrome 80. Stay tuned. — Chrome Developers (@ChromiumDev) March 18, 2020 Widespread use of Chrome, combined with the number of CVE's addressed in each release of Chrome requires every enterprise to have the ability to upgrade their endpoints. The solution needs to be tactical, precise, and meet the business

There is a real and immediate need for every organization to be able to quickly react to zero-day vulnerabilities or new application releases with features requiring immediate and precise cut-overs. The threat landscape is wider than ever, while the frequency of new application builds in a world of CI/CD pipelines decreases from days to hours; and everything supporting the business has exacting requirements that need to be met.  Workspace ONE and the EUC product line-up is really well equipped to handle any digital workspace use case on any major platform. When you offer all that with API's to manage identity, access management and secure edge services; you have API's for everything to provide secure remote access to resources.  What has been interesting to watch over the years is the utility, broad-appeal, varied-price points and proven capabilities of the Android OS. As the OS has matured from the era of Jelly Bean, KitKat and Lollipop; the number of use cases supported b

--> Product provisioning in Workspace ONE UEM is an incredibly useful feature. We are often able to deliver resources or manage a device without the use of product provisioning, but there will be use cases that require additional capabilities. Product provisioning allows for actions to be defined in a product manifest, with actions being completed in a sequential order. These actions can be placed in the correct order to achieve the required outcome. If there is a failure in a step, the delivery will stop at the step that failed. The success or failure of each action can be logged for auditing or troubleshooting. Optionally, debug mode can be used to identify root causes remotely. Debug mode level can be turned on by organization group, allowing large groups of devices to have results recorded, or on individual endpoints.  One action that I have become very familiar with is remotely delivering an intent to an activity in my Android application. The abilit