Enhanced Factory Reset Protection in Android 15
Factory Reset Protection: A Shield for Everyone Smartphones and tablets have become integral to our work and personal lives, however, they can also be easily lost, and on occasion, stolen by opportunistic thieves. Many times these bad actors will simply wipe the device to remove any personal and business data, with the intent of selling or using the device themselves. That's where Factory Reset Protection (FRP) steps in as a crucial line of defense. FRP is an Android security feature designed to prevent the reuse of a lost or stolen Android device. It requires your Google account or lockscreen credentials after a factory reset, ensuring that only the rightful owner can access and use the device once it has been wiped. Enhanced Factory Reset Protection Building on its initial purpose, FRP has evolved significantly with the release of Android 15. In the past, tech-savvy thieves and users found ways to bypass FRP, but Android 15 closes those loopholes with powerful new protections. These enhancements were added to combat unauthorized access and make stolen devices much less appealing to thieves, whether they're targeting personal or company-owned devices. Prior to Android 15, the Setup Wizard was responsible for determining whether FRP should be activated, and for enforcing it, including determining whether you have authenticated with the correct credentials to get out of FRP mode and proceed with setup normally. But the Setup Wizard was designed to be a user-friendly tool to walk through setting up a device, not a security enforcement barrier. In Android 15, FRP enforcement has been moved deep into the system, where it’s much harder to overcome. Benefits You Can Count On These enhancements translate into real-world benefits for everyone: Individuals: Deters Theft: FRP makes stolen devices far less valuable, as thieves can't bypass the Google account login or lock screen credential check. This significantly reduces the incentive for theft. Peace of Mind: Knowing that your Android device has this robust security feature gives you peace of mind. You can rest assured that if your device falls into the wrong hands, it cannot be used for anything. Enterprise and Managed Devices: Enhanced Device Security: Factory Reset Protection makes it much harder to reuse or sell stolen devices, which discourages thieves from stealing them in the first place. Simplified Device Management: FRP integrates seamlessly with enterprise mobility management (EMM) solutions, allowing IT administrators to enforce FRP policies and ensure devices are protected. With Android 15, FRP has evolved into a powerful deterrent against device theft by making stolen devices unusable.The Secure Element podcast - Episode #4: Device Trust
Hey Friends, Ready for the inside scoop on Device Trust from Android Enterprise? This episode of The Secure Element dives into the buzz from the recent Oktane event! I sat down with Karthig Balendran (Product Manager at Okta) and Al Chapelle (Senior Product Manager at Android Enterprise) to discuss our highlights from the event, as well as the practical implications of Device Trust from Android Enterprise on your organisation’s security posture. Join us as we dive into: Fine-grained access: A deep dive into the Device Trust from Android Enterprise framework and how it uses real-time, device-level security signals for precise access control. Partnership in action: How Android Enterprise and Okta are teaming up to bring this new security solution to customers. Security for BYOD: how Device Trust from Android Enterprise unlocks enterprise-grade security on unmanaged, employee-owned android devices. Customer reaction: Hear how the demo was received by customers at Oktane. Listen to the episode here: If you haven’t already, check out episode 1, episode 2 and episode 3 for more conversations with industry experts across all things security. As always let us know any questions or comments you have below, and we’ll be sure to follow up. Stay secure, BurrThe Secure Element podcast - Episode #3
Hey Friends, Episode 3 of The Secure Element is here! This month, I spoke with Brian Wood who runs the Android Certifications Programs to demystify what it takes to get a device approved for the federal government, a process that also benefits other security-focused industries like finance and healthcare. Join us as we dive into: The exact process for federal government device certification. The roles of NIST (National Institute of Standards and Technology) and NIAP (National Information Assurance Partnership) in setting security standards. Debunking myths about Android encryption, including its standing against iOS. Listen to the episode here: Thanks for tuning in! We’d love to hear your thoughts or any further questions in the comments below and we’ll be sure to follow them up. New to the series? Listen to Episode 1 and Episode 2 to hear more insights from industry leaders. Stay secure, Burr[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.The Secure Element podcast - Episode #2
Hey friends, Episode 2 of our new podcast; The Secure Element is now available to watch below. This month, I met with Theresa Lanowitz, Chief Cybersecurity Evangelist at LevelBlue and a globally respected leader in the Cybersecurity world. In Episode 2, we dive into: Cyber Resilience on Edge Devices Phishing Difficulties in compromising Devices M&A causes security slips Application defenses You can listen to the episode below: We'd love to hear if any of the topics mentioned here resonate with you. If you have anything you’d like to add or any challenges you currently face, please comments below. Stay secure, Burr —------------ Missed episode #1 with Bhavesh Kumar, Senior Director of Product Management at Omnissa? Catch-up 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?5 overlooked benefits of Android Enterprise
Android Enterprise is more than just a set of management tools; it's designed to address the complex needs of modern businesses. Here are 5 insights that often go overlooked: 1. Privacy you can trust Ever worried about mixing work and personal life on your phone? Or, as a business, concerned about invading your employees' privacy? Android Work Profile acts as a secure, separate container on your device. Think of it like having two phones in one, but without the extra bulk! Your work data stays within this container, completely isolated from your personal apps and information. This means: Employee privacy: Your company only sees and manages work data, not your personal photos or messages. Did you know you can see exactly what data your IT admin can see? Simply go to: Settings > Security & privacy > Your work policy info > Device info your IT admin can see. Data security: Your company's sensitive information is protected from accidental leaks or unauthorized access. Peace of mind: You can use your personal device for work without compromising your privacy or security. It's not just about security; it's about building trust. 2. Instant deployment Zero-touch enrollment allows for rapid and consistent configuration. It's not just about saving time; it ensures every device is configured correctly from the start, minimizing errors and getting your team working faster. Zero-touch enrollment enables efficient device rollouts, minimizing setup errors for a smoother user experience. Direct shipping to employees is a strategic win for businesses, bypassing central warehousing and significantly reducing costs. 3. Security that runs deep Android Enterprise isn't just an add-on; it's built into the core of the Android operating system. This means security policies are enforced at a system level. This deep integration allows for very precise control over device settings and data access. Explore Android’s multi-layered approach to security and granular control in our security paper and community podcast series. 4. Secure app distribution Think of Managed Google Play as your own private app store. You can curate and distribute approved apps to your employees, ensuring they only use safe and compliant software. This eliminates the risk of employees downloading malicious apps from unknown sources. Remote app management and updates simplify administration. 5. Future-proofing The Android ecosystem is vast and constantly evolving. By choosing Android Enterprise, you're tapping into a platform that's backed by Google's continuous investment. Plus the open nature of Android naturally enables constant innovation. This means you'll have access to a wide range of compatible devices, EMM solutions, and support - explore our partner ecosystem. As Android evolves, so will Android Enterprise, ensuring your mobile strategy remains relevant and effective. What's Next? Join the community discussion to share your insights and experiences. We'd love to hear from you: What are your experiences with Android Enterprise? What features are you most interested in? Share your thoughts in the comments below!Introducing The Secure Element podcast - Episode #1 is LIVE!
Hey friends, I'm pleased to announce the launch of our brand new security podcast: "The Secure Element"! This podcast is dedicated to all things security, covering topics relevant to our community and beyond. Plus, I am joined by some incredible people across the ecosystem along the way. We're kicking things off with our first episode, featuring special guest Bhavesh Kumar, Senior Director of Product Management at Omnissa. In Episode 1, we dive into: UEM controls to manage security Ecosystem of malware protection New capabilities for Device Trust principles You can listen to the first episode below: We'd love to carry on the conversation after you have listened/watched the video, so please do share your thoughts on any of the topics discussed in the comments below and/or any suggestions you might have for future topics. Stay secure, Burr[Guide] Learn more about Generative AI controls from Android Enterprise
Hey everyone, As generative AI increasingly integrates into the workplace, we recognize that your teams may already be exploring these experiences. Android Enterprise is here to help provide the effective control and secure deployment for the generative AI experiences your teams use every day, ensuring you can leverage this technology securely. We’ve heard your questions here in the Customer Community about controlling business data and managing AI tools on Android, and so I’m pleased to share with you this Guide to Generative AI controls, which covers key business concerns, from ensuring the security and integrity of company data to exploring Android Enterprise and Google controls for generative AI experiences. We hope this guide will provide insights into the ways you can leverage the power of generative AI in your business, while implementing the necessary controls to protect your data. Get the insights today → Android Enterprise Guide: Generative AI controls For more details, please also view this Help Center article. AI is ever evolving, so we’d love to keep the conversation going here in the community. Are there any other things related to AI that you would like to hear more about? Are you finding that employees in your company are keen to use AI in the workplace? Thanks, Lizzie *Help Center article added May 15, 2025Do 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.pdf
