[Feature Focus] Managed Google Domains & Insider Opportunity
Hi everyone, Welcome to our new video series, Feature Focus! This is our new series where we will focus on a specific feature from Android with an enterprise lens. Our aim is to provide you with all the information you need to understand a feature and equip you with the tools you need to implement it. In this episode we’ll be focusing on identity and managed Google domains with Gene Trinks, a technical account manager within the Android Enterprise team. You can find the first episode below: Useful resources to implement this feature: Overview of - Managed Google domains How to - Upgrade your domain Sync your directory Verify your domain Set up SSO While this is a publicly available feature, we are also excited to announce that managed Google domains will also be our first Android Enterprise Insiders’ project. This creates a dedicated area to navigate implementing this feature, ask any questions and get ready for future possibilities that this feature enables, launching 11th September. To find out more about Insiders and to register your interest, click here now! Thanks, Jordan Updated Sept 2025: To better protect your Google domain from unauthorized access, we will soon begin requiring 2-Step Verification (2SV) for administrative Managed Google Accounts. Learn more here.Securing your Business: Checklist for Android device offboarding
Modern workplaces are full of digital footprints. From day one, employees leave a digital trail, from corporate email accounts to VPN access and social media updates. So, to ensure a secure exit, it's vital to have an offboarding process in place. Companies must carefully decouple an employee's digital footprint to mitigate risks like data breaches and unauthorized access. To help you with this, we've created a checklist of things to consider when offboarding an employee. While the exact process will vary from organization to organization, read on for some handy tips. IT Admins: Checklist for a Secure Exit Once the employee offboarding process has been initiated, you’ll need to consider the level of remote access the employee should retain. It may be a good idea to reduce this in stages, affording the employee enough time to backup personal and corporate data appropriately. Or depending on the level of sensitivity, more immediate restrictions may be appropriate. Identify the user’s device(s): Use your MDM solution to locate the employee’s device. Limit access: If your company leverages SSO, you can immediately revoke a user's access to all apps by revoking their SSO tokens. Otherwise, you will need to consider the following: Email: Disable the user's email account. Redirect incoming emails to an appropriate recipient or archive them. Company Apps: Remove the user's access to company-specific apps, or third party apps that were previously authorized. Revoke app licenses, if applicable. Cloud Storage: Revoke the user's access to cloud storage services (e.g., Google Drive, Dropbox). Remove the user from shared folders and documents. Collaboration Tools: Remove the user from collaboration tools (e.g. Google Workspace, Microsoft Teams). Revoke access to shared documents and projects. VPN and Remote Access: Disable the user's VPN and remote access privileges. Revoke any VPN certificates or keys. Data Retention and Archiving: Determine the appropriate retention period for the employee's data and implement necessary archiving procedures. Ensure compliance with data privacy regulations. Deactivate User Account: Deactivate the user's account to prevent future access, while allowing other employees to still access any documents associated with the deactivated account. Configure Factory Reset Protection policies: To ensure a seamless offboarding process for company-owned Android devices, it's crucial to properly configure Factory Reset Protection (FRP). If you've already configured your FRP policies, you can skip to step 4. Otherwise, let's dive into the details. Factory Reset Protection (FRP) is a security feature designed to protect Android devices from unauthorized access after a factory reset. It requires authentication with the Google account last used on the device. While this is a valuable security measure, it can complicate device management, especially during employee offboarding. To ensure a smooth offboarding process, consider these two approaches: Enable Enterprise Factory Reset Protection (EFRP): Designed for Enterprise, EFRP allows you to specify which Google Accounts can activate a device that has been factory reset and locked by FRP. These approved users can unlock company-owned devices that have been factory reset, without the need for the previous user’s Google account details. This approach provides a balance between security and manageability. Disable FRP: Disabling FRP allows you to factory reset devices without requiring the previous user's Google account credentials. This can simplify the offboarding process, but it also reduces the device's security. Use with caution, particularly for devices that are at risk of loss or theft. Important Note: Resetting a device through the Settings app typically doesn't trigger FRP, except in specific scenarios involving company-owned devices with Work Profiles and EFRP enabled. Therefore, it's crucial to disable FRP or enable EFRP before initiating a factory reset to prevent potential lockouts. Remote wipe: After allowing the user a brief period to back up personal data on company-owned devices, or transfer ownership to work files, remotely wipe the device. Depending on the device’s enrollment method either: Factory Reset: For company-owned devices, instigate a factory reset to erase all work apps and data from the device without physical access. Remove Work Profile: For BYOD devices, use your MDM solution to remove the user's Work Profile from the device. This will eliminate company apps, data, and settings from the device. Note, personal data is unaffected by the removal of the Work Profile so does not require backup. Revoke device access: Deactivate the device from your MDM solution. This will prevent the device from receiving updates, policies, and security patches. Asset retrieval: Create a comprehensive inventory of all physical assets assigned to the employee (e.g., laptops, phones, keys, badges). Ensure all physical assets are returned or disposed of securely. Update device inventory: Update your device inventory to reflect the device's status (e.g. retired, reassigned). Employees: Your Role in a Secure Exit Data Backup: Use a personal cloud storage service or external storage to back up any personal data that you want to keep before the device is wiped or reset. Following your company's guidelines for data backup, ensure that all company data is backed up to the appropriate location or cloud storage. App Removal Clear the data and cache for these apps to remove any sensitive information. Uninstall any company-owned or work-related apps that you no longer need. This may include email, calendar, and productivity apps. Network Access: Disconnect from any company VPN connections. Remove any VPN profiles or certificates. Forget any saved company Wi-Fi networks. Personal Cloud Storage: Download and save any personal files from company-provided cloud storage. Revoke access to personal accounts linked to company devices. Assets: Depending on company policy, return all corporate devices and accessories to the IT department or designated location. Ensure that the device is in good condition and free of any damage. Social Media Accounts: Review and remove any company-related content from personal social media accounts. Update privacy settings to limit public visibility. Best Practices From the off, it’s good to keep handover in mind. After all, the more structure in place when setting up, the easier handover will be. With this in mind we've put together some tips and best practices to consider when starting out, or even implementing further along. Setting Up Devices and Profiles Separate Profiles: Create separate profiles for work and personal data to improve security and privacy. Use work profiles to enforce company policies and manage company-owned apps. Corporate email accounts: The improved Android sign-up process makes it easier for IT admins to sign-up and access Google services using their corporate email addresses. This eliminates the need for personal Gmail accounts, leading to cleaner handovers when an employee leaves. Plus, certain setup tasks can be managed centrally through the Google Admin console, again making it much easier to keep track, document and handover tasks. Centralized Management Avoid the hassle of being locked out of corporate Google accounts when the time comes for the admin that set up the account to embrace a new opportunity. Maintaining a centralized approach avoids having a sole owner of any Google accounts, making it easier to manage and maintain control and access to business Google accounts in the event of a handover. IT admins can also easily track, document, and hand over administrative tasks in this way. Default Settings: Configure default settings for devices and profiles to streamline the onboarding process and ensure consistency. Consider using templates or scripts to automate device setup. App Management: Use Google Managed Play to create a customized and secure app store for different business needs and user roles and have more control over which apps employees can install and use. Policy Enforcement: Implement policies to enforce security measures such as password complexity, screen lock timeout, and data encryption. Use conditional access policies to restrict access to company resources based on device compliance. Employee Training Remember, documented procedures and workflows are vital for mitigating risks associated with employee turnover. Proactive documentation ensures business continuity and minimizes disruptions during employee transitions. Provide employees with clear guidelines and training on their responsibilities during the offboarding process. Educate employees on data security best practices and the importance of returning company assets. Regular Reviews Review and update your offboarding procedures regularly to ensure they remain effective and aligned with evolving security threats. Conduct periodic security audits to identify and address any potential gaps. A well-executed offboarding process is crucial for safeguarding your organization's sensitive data and maintaining security. By following the checklist provided, you can effectively mitigate risks, minimize disruptions, and ensure a seamless transition for both the departing employee and your organization. Like and share this post to help others secure their organization's digital footprint! Let us know your thoughts and experiences in the comments below. Do you have any additional tips for a smooth offboarding process?Benefits of an EMM
What are the benefits of using a device management tool? Device management tools have had many different terms of the years… Mobile Device Management (MDM), Enterprise Mobility Management (EMM), Unified Endpoint Management (UEM). Whatever you prefer, they are undoubtedly the cornerstone of any successful IT project that involves hardware assets. Boiling down the core functionality of these tools, they allow IT admins the ability to use a single tool to view all of the hardware assets within their organisation, distribute applications and apply configurations based on their needs. Let’s start with the basics: Why do you need an EMM? As you have probably been able to discern from the different terms for device management tools, there’s quite a few benefits that are offered by introducing an EMM to your organisation. We can boil them down into three key buckets: Asset enablement and management I love a good spreadsheet as much as the next person, but monitoring what devices are within your organisation and have access to your corporate data simply cannot be done by a static tool. EMMs provide you a great platform to see all the assets within your organisation, who is using them and if they are compliant with your organisation's security policies. IT helpdesks are overwhelmed with inbound tickets and an EMM’s asset management capabilities can really help streamline this process. An EMM, integrated into your LDAP, can help shave minutes off every inbound request. Let’s run through a quick scenario that you may have faced: An end user can’t connect their phone to the WiFi in the office, they’ve followed your guidance and dropped an email into your IT team's support distribution list saying “I’ve come into the office and my phone can’t connect to the WiFi, it worked yesterday!”. Normally the first response will be to ask the user for details about their impacted device such as the device’s serial number, phone number and version of OS. But by simply copying their LDAP and pasting it into your EMM, you’re able to view all of the devices assigned to that user, as well as all of the details you’d usually have to ask for. Your EMM will likely present you with the initial steps to resolve the issue too. In this instance the user’s device is no longer compliant with the security policies, allowing you to respond with actionable information for your end user; update your device! Securing corporate assets and data Let’s start with the big one, is the Android platform secure? Our answer is, absolutely! The 2024 security paper should be able to answer any question you have if this is something you’d like to explore further. Now we’ve established the platform is secure, let’s get into why you need an EMM to secure your assets and data. Android Enterprise is designed to be flexible enough to meet your organisations security needs and EMM’s are the key to unlocking that functionality. In some instances simply enrolling devices into an EMM is enough thanks to Android Work Profile. But we can’t forget those working in regulated industries where data retention and handling is critical. My rule of thumb is, how can we keep devices secure without providing too much friction for end users? EMMs give you all the ingredients you need as an IT decision maker to create policies that meet your organisations requirements while also being considerate to end users. It goes without saying that all organisations should have a password policy applied, and for a lot of folks this may be sufficient. But depending on the type of work your users do there may be a requirement to add additional controls, such as preventing cross profile data sharing in Work Profile. As you go deeper into the realms of keeping your corporate data secure, data loss prevention becomes a real concern and you may need to further understand exactly what is happening on your devices. AI is a real inflection point for IT admins and a great point of reference for this topic. While AI is bringing game changing tools to users, the rapid rate of development and rollout is putting strain on security teams trying to evaluate the functionality to understand what data is being processed on device or in the cloud. Android Enterprise has already rolled out controls for IT admins to control what device features are available in Work Profile or on managed devices, but there are certain OEM native features, such as keyboards, where a global control may not be an option. This is where Android Enterprise’s flexibility really shines, allowing you to use various EMM controls to limit functionality through app configurations or, in this example, setting a different default keyboard. Keep an eye out for future discussions about how to determine if an AI process is being handled on device or in the cloud. Unlock hidden savings Downtime caused by device issues directly impacts workforce productivity. When a user's device fails, productivity grinds to a halt. Not only because they can’t perform their work, but they also need to wait for IT to resolve the issue. By enrolling your devices into an EMM you can transform existing IT support processes and enable the team to resolve more issues remotely. EMMs provide automation capabilities that create reports and alerts. This automation can proactively inform end-users if their devices are about to become non-compliant with corporate policies, reducing access issues and the subsequent support tickets. Beyond these automated alerts, EMM reporting tools also provide valuable insights for strategic decision-making. For example, reports from your EMM can be used to help you to make informed decisions about device refreshes, by reviewing historical data within your EMM you can reliably view the battery health of your devices and the average remaining storage on your devices. Upon reviewing the data you could see that perhaps you can get another year out of the existing hardware or if the amount of device storage needs increasing when it comes to selecting new devices. Now let’s focus on the process transformation enabled by these tools. By deeply integrating an EMM into your support flow you can drastically reduce the time to resolution of most device related issues. I’ve frequently seen IT teams that haven’t done this require end users to “swing by their desk” with an issue, while this comes with the best intentions it is extremely disruptive to end user productivity. Let’s imagine a user has an issue with one of their applications, if the user was in person it is likely that a member of IT staff will try all the basics such as deleting device cache, reinstalling the application and eventually updating the devices firmware. In contrast, with devices enrolled in an EMM, the IT team can quickly identify the user via LDAP within the EMM console. The console will provide immediate insights into the device's compliance status, potentially revealing that the user’s device is non-compliant with security policies and providing a clear path to resolution. Why do your users need you to have an EMM? As an IT admin the goal when rolling out technology to an organisation should be to remove friction and empower our users, an EMM is a fantastic tool to enable this. Seamless access The utility of an EMM starts from the moment a user enrolls their device. If you’ve connected your EMM to your identity provider, the user can use the same login credentials they use on their other devices, coupling this with an SSO provider will allow them to seamlessly sign in to their applications. Immediately online “What's the WiFi password?” While we can’t solve this for you at home, an EMM at least prevents this question from being asked in the workplace. Creating a WiFi policy allows you to push down your WiFi credentials to all devices enrolled into your EMM. Quite a few organisations rely on VPN connectivity for their users to connect to corporate networks, this is also no problem for an EMM. Application distribution Smartphones have a vast amount of functionality out of the box, but I’m yet to come across a phone that ships with every app you need! While there is an element of enjoyment to scrolling through the Play Store and finding the apps you need, it can be very cumbersome when you have to do more than a handful. By using an EMM integrated managed Google Play you can approve applications for use within your organisation, creating a curated list of apps that your users can download. Additionally, you can also decide which applications are pushed to your users. Meaning those apps will automatically install on your users device once they have completed enrollment into your EMM. I would generally recommend limiting this to applications that are critical to your end users, such as email and calendar, but you can always change this based on feedback from your users. How do you choose an EMM? We’ve covered just a handful of the benefits of an EMM here, but there is so much more! This space has been evolving at a rapid pace ever since its inception, every day EMM’s receive dozens of feature requests and each has their own interpretation of how best to present information to IT admins. Go in with a plan Before you engage an EMM for evaluation, build out a plan for what you are trying to achieve with your devices. This will not only help you get a better grasp of the discussion but also ensure you have a clear success criteria for your proof of concept. To help you with your plan, here’s a few questions you’re likely to be asked: How many devices are you looking to enroll? Are you buying the devices for your users (corporately owned) or will they use their own devices (BYOD)? What do your users do with their devices? What apps do your users need? Who is your identity provider? What security policies do you need to comply with? When do you plan on starting this project? How to find an EMM You can’t go wrong with one of our Android Enterprise Recommended EMM partners! Thanks for reading! Are there any other key features that you utilise within your EMM that we haven’t covered here? Let us know!Do you really need a long pass code on Android?
Do you really need a long complicated pass code on Android? Traditionally, IT admins applied similar pass code requirements to Android devices as with server and desktop operating systems. However, this approach can be excessive and unnecessarily restrictive. Unlike laptops or desktops, where unlocking grants access to all user apps and services, Android operates differently. As “Android is now the most common interface for global users to interact with digital services”*(1) with many organizations, from small businesses to large multinational corporations and government agencies, relying on Android devices to access sensitive company data, it’s important to understand the distinction. The key difference lies in how these operating systems handle app permissions. While server/desktop OS's typically consider all apps running within the context of the logged-in user account as fully authorized, Android operates with a more granular approach. Android apps are not inherently granted full authorization for all user actions.*(1) This inherent security measure within Android mitigates the risk of malicious code exploiting the vulnerabilities of server/desktop OS's. On server/desktop systems, attackers often only need to execute malicious code with the currently logged in user's privileges to gain significant control. Android's more restrictive environment makes this type of attack more challenging. Windows, macOS, and Chrome will typically use a username and password coupled with Single Sign-On (SSO) or Multi-Factor Authentication (MFA) that is tied to a corporate account to log into the OS. Android simply uses a PIN, pass code, or pattern that is not tied to a user’s LDAP or domain account to unlock the device. This separates the device unlock on Android by not having that tied to a corporate identity. This difference keeps an Android pass code to unlock a device separate from the user's account to access corporate services and applications. In this way, the Android security model grants less power to users versus traditional OS's that do not require multi-consent models. The immediate benefit to users is that one app cannot act with full user privileges. The user cannot be tricked into letting it access data controlled by other apps due to the robust app sandboxing on Android. So, do you really need a long pass code on Android if the unlock pass code is not tied to your corporate account? Let's consider some more interesting facts to determine if a long pass code is needed to protect an Android device. NIST passcode guidelines: A shift in perspective What does the National Institute of Standards and Technology (NIST) have to say? The general password guidance from the latest version of SP 800-63b *(2) are listed below: Pass code Length: Minimum 8 digits Complexity (Special characters, uppercase, lowercase, number): No longer required Pass code hints: Do not allow Simple or known pass codes: Do not allow Periodic pass code changes (every 90 days, etc.): Not required. Only force changes when a known compromise is detected. SMS for MFA Codes: Do not use Pass code guess prevention (Throttling): Implement NIST’s updated requirements are a result of technology advances that prevent guessing a pass code. As an example, 8 digits without special characters, upper and lower case, and pass code changing requirements are no longer recommended. An 8-digit pass code of non-repeating numbers is now sufficient to provide very strong protection. On Android we actually changed our PASSWORD_COMPLEXITY_HIGH to 6 digits back in Android 12. Let's explore this a little more. Rate limiting and password guessing Android implements a very strong default rate-limiting capability, which imposes increasing delays after the 5th failed login attempt, culminating in a 24-hour lockout after 100 attempts. The benefit to a managed device is that Android Enterprise can limit the attempts to a specific number before a device wipe is triggered automatically. This helps prevent access to personal and company data. Assuming that an Android device is properly managed with a limited number of failed pass code attempts, let's say 10 tries, enforcing a device wipe by policy renders an attack mostly infeasible. Even the latest version of the password-guessing USB tool, rubber ducky, is ineffective. Now, let's explore a simplified explanation of what a hash is in this context. Imagine your pass code to unlock your Android device is "019283". Android has an "algorithm machine" (called a hash function, or algorithm such as SHA256) that takes that password and generates a unique string of characters that represents that specific data, such as "a5f4g6h7j8k9l0". This is the hash of your password. It looks nothing like your original password, making it virtually impossible to figure out your lock screen pass code "019283" just by looking at the hash. Additionally, reversing the hashing calculations is infeasible and the algorithms are created in such a way as to protect against a reversing calculation. Now, every time you try to unlock your device, Android securely feeds what you type into the unlock prompt and puts it through the same hashing algorithm. If the resulting hash matches what is stored in secure hardware on the device, then Android knows you've entered the correct password and it unlocks. What is stored in secure hardware on Android is the hash of your pass code, not your pass code itself. We have all seen the following image on social media, but it portrays incorrect data when it comes to Android. This table does not take into consideration that the attacker has successfully been able to capture the hash of the pass code. Extracting the hash of a pass code from a locked Android device's secure hardware is non-trivial and is extremely difficult, actually infeasible on Android. Conclusion: Rethinking pass code complexity for Android In conclusion, it is important to note that I have only covered a small portion of a very complicated topic that involves encryption, key storage, hashing, and rate-limiting in Android kernel and services. While anything is potentially possible, the reality of exfiltrating a hash from secure hardware is really not feasible or practical. Requiring a pass code that is long and complicated is not a factor in 2025 on Android. With the proper management policies, guessing a pass code to unlock a stolen or lost device should not be a concern any longer. Have a look at what your EMM provider options are when setting a pass code requirement and consider how you can make the user experience for your users better by not having to enforce long complex pass codes, it just frustrates users. *(1) Android Security Model: https://arxiv.org/pdf/1904.05572 *(2) https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-63b.pdfBoost User Adoption: Building Trust in Your Mobility Deployment
Building trust with your users is critical to the success of any IT project We’ve all heard it: “IT can see what is happening on my device”, and this level of distrust from users occurs regardless of the platform being used. Finding that balance between user trust and securing your organisations data & assets is a tightrope that can have catastrophic consequences if the fine balance isn’t met. In most instances lack of end user trust is caused by not having visibility into what is happening, the “black box” of IT policy and processes is a real thing! With the ever increasing number of personal devices being used in the enterprise world, ensuring end users are aware and empowered to understand what is actually visible by their employer will help ease end users' concerns about adopting mobility management. Regardless of the enrolment method your organisation has adopted, Android Enterprise is built from the ground up with a focus on end user privacy and while aiming to ensure that IT admins have the right tools to manage their assets. Build trust through communication Being able to set policies within your organisation's EMM is a powerful responsibility. While simply ticking a box and applying the configuration can feel low impact, even small changes can have inconveniences for your users which may build up frustration and distrust over time. Start a dialog with your users I know, this is easy to say and much harder to execute. There’s a vast number of variables to consider when trying to recommend a best practice for successful dialog with your users. It’s important to consider technical ability, the size of your organisation and location distribution of staff, just to name a few. But the goal of any communication to your users should be to provide a clear understanding of what the change is, why the change is being implemented, and address potential FAQs. There are the obvious communication methods of email (don’t forget to use BCC ) or posting on an internal communication board, but these may be missed or ignored. Something I have seen becoming more common is internal calls where IT decision makers within an organisation talk about upcoming changes. Alongside visibility, this has the added benefit of allowing users to ask questions. Organisations that have committed to these sessions have found it much easier to get their end users to adopt new technologies. While we are focused on Android here, this approach can help with everything from a new device rollout to deploying video conferencing software. It can be pretty daunting to know where to start with a communication plan, so we have an employee adoption kit to help! When should you communicate a change to your users If you have a change coming that’ll have a visual or workflow impact on users, be proactive and let them know. While this can add additional workload, informing users can start a useful early dialog to understand questions that may come up. IT teams are stretched at the best of times, being able to reduce inbound support requests through pro-active communication is never a bad thing! If you're looking at making disruptive changes to a fully managed device deployment, such as completely changing the UI of a kiosk, I’ve found that end users are more receptive to this level of impact during a device refresh. Users in these scenarios see these devices as tools to do their job and form habits in their workday around how their device works. If overnight you change how their device works this is likely to disrupt those learned habits, and cause friction for your users. This often leads them to believe that the device doesn’t perform as well as it used to, even if functionally you’ve just shifted an icon around. So if you have the ability to delay that new rebrand or that push to move the app icons around until your next rollout, it certainly might be worth holding off! Don’t forget dialog is a two way street Create an easy route for users to ask questions. You could look at adapting existing IT support flows, create a dedicated form or even host a weekly office hours for users to get some 1:1 time with the team. This brings us neatly to... Best practices for policy decisions and changes You can have the best laid plans for your mobility deployment, but there is one variable you cannot account for, user innovation. As a policy setter, it’s unlikely that your testing will directly replicate your end user's day-to-day behaviour. Over time they will find their own route to achieve their goals. There’s a fun equivalent called “desire paths” where pedestrians will walk an unplanned route to get to their destination causing an environmental impact to the landscape. Don’t block them from the path, embrace it! User-centric approach to change management Whether you’ve implemented a BYOD program or provided hardware to your users, the mobility decisions you’ve made will have a material impact on the day to day lives of your users, it’s one of the many great things about working in this space. This puts even the most robust testing programs under a huge amount of pressure. It’s nearly impossible to test every possible tap or swipe that an end user could perform. Don’t fret, this can lead to some fantastic opportunities part way through the lifecycle of your devices . You should run some 1:1 sessions with your users and see how they are actually using the devices. This feedback can help you make informed decisions about your next deployment milestone or make iterative changes to improve the mobile experience for everybody. An example that has always stayed with me was from a logistics organisation with a large quantity of fully managed devices. One of their users made a simple request to adjust the app layout on their kiosk to better align with their workflow. That small adjustment had a 4% time save every time a user performed that task. That might sound negligible, but when you multiply that time saving over 10,000 users performing that same task 15 times a day these small changes make a massive difference. We don’t all work for Formula 1 teams, but incremental gains can still be a target for us all. Pushing applications is more intrusive than you may think Being able to push applications to your users is one of the many benefits of enrolling a device into Android Enterprise, but it is also one of the more user intrusive actions you can take on a device under management. My general recommendation for distributing applications is you should only force install applications you know will be critical for the user to perform their work. Users who are using a device that is owned by the organisation and enrolled as fully managed will often be more open to a dozen or more applications being automatically installed on their devices. But users who have Android Work Profile, whether corporately owned or BYOD, may find it more jarring. Limit the applications installed to the core apps required for their work such as email, calendar and a document viewer. The rest can be available for the user to download through the Play Store -empower your users! What we are doing as a platform At all stages of the device lifecycle we inform the user to help them understand what is happening on their device. Through clear dialog during provisioning, helpful prompts while the device is in use and the ability for users to see what policies are actually applied to their devices, we aim to empower users through transparency and information. Visibility into policy Regardless of enrollment type, end users can see what policies are applied to their devices and all the device level information that the EMM is able to see, all from within Settings! Users simply need to go to Settings > Security and privacy > Your work policy info. Under this section they’ll be able to see everything that you can see from within your EMM and what policies have been applied to the device. For the avoidance of doubt, content in the personal profile is not visible to the organisation! Automate work/life balance BYOD and COPE users will see Android Work Profile, providing a clear separation of personal and work applications. Keep your eyes peeled for future content discussing this in more detail. Users are probably already familiar with being able to pause the Work Profile through the launcher, but did you know that they can also automate this process through Digital Wellbeing? Simply go to Settings > Digital Wellbeing > Work Profile schedule and you can set a daily schedule for when work apps will automatically pause and unpause! Users who have their devices enrolled as fully managed can utilise Digital Wellbeing to set a Focus mode to create a similar process to scheduling work apps. Visualisation In Android 14 QPR2 we introduced greater controls for end users initiating a screen-sharing session. As a standalone feature this has been well received, and helps remove the risk of sharing something users may not wish to share while presenting from their device. But in addition to this feature, we also included a clearer UI showing that the device’s screen is being shared. While a small addition in itself, this is a great demonstration on how we prioritise helping users to understand what is happening on their device. How do you build trust with your users? Considering starting an internal session discussion with your users? Perhaps you could start by talking about the on device features we discussed! Let us know below!
