[PRODUCT UPDATE] Zero-touch enhancement: Audit logs
Hey everyone, We're pleased to announce a significant enhancement to the zero-touch customer portal, designed to provide greater transparency over your data. Comprehensive audit logs, offering a detailed and accessible record of all actions affecting your customer data will soon be available in the customer portal. Key Improvements: Comprehensive Logging: Captures actions taken from all possible sources eg: zero-touch customer and reseller portal, customer and reseller API. Tracks all data related to a zero-touch customer, including: Users Devices Resellers Configurations Terms of Service CSV Files Zero-touch customer accounts Easy Access and Analysis: Access audit logs through a user-friendly interface within the portal. Download logs in CSV format for further analysis and reporting. Benefits: Accessibility and Analysis: Ensures easy access and analysis of logs. Enhanced Security: Provides a detailed record of all activities impacting customer data, enabling better monitoring. Streamlined Troubleshooting: Quickly identify and resolve data-related issues with detailed activity logs. Increased Transparency: Offers greater visibility into how your customer data is being accessed and managed. Important Note: The audit logs are only available via the zero-touch customer portal. There is no change to the zero-touch reseller portal, Reseller API, and Customer API. Migration Timeline: This feature will be enabled during the next few weeks. Only logs after March 2025 are available in the zero-touch customer portal. If you require older audit logs, please contact your reseller who can raise a support ticket. We hope you find this enhancement useful. To learn more, please refer to this Help Center guide. It would be fantastic to hear your feedback or any questions below. Thanks so much.
Issue with Copy/Paste Restriction in Intune MDM on Android Devices (Clipboard Editor Interaction)
Hi all, I’m currently experiencing an issue while setting up Intune MDM on Android devices related to restricting copy and paste to unmanaged apps. Specifically, the issue occurs when users copy text from the Teams app and try to paste within teams app. Here's what happens: After copying text, a message "Your organisation's data cannot be pasted here" immediately appears in the clipboard hud. The copied data seems blocked from being viewed, as the error message appears even before a paste attempt. Despite this, users can manually paste the copied content by long-pressing or selecting "Paste" from the text box. However, when trying to use the "paste from clipboard" feature, the warning message above is pasted instead of the copied content. We’ve set the Intune policy to allow copy/paste within managed apps, but the clipboard interaction seems to be problematic, especially with Gboard. It appears that Gboard, possibly due to Android 13 and 14’s Clipboard Editor, is treated as an unmanaged app, causing Intune’s data protection policies to block its access to the clipboard in a read-only state. Just to clarify: I want users to be able to copy and paste txt within managed apps only. So the allowed behavior of pasting with long press is fine, but I want to get rid of the block that we're getting. Here’s what we’ve tried: Added various exclusions to the Intune policy, including Gboard, Clipboard Editor, and other related apps (full list below), but the issue persists. Testing different configurations hasn’t led to a final solution, and there seems to be limited documentation specifically addressing this clipboard component in relation to Intune's data policies. We’ve escalated the issue internally but wanted to see if anyone in the community has encountered a similar problem or found a solution. Here’s the list of exclusions we’ve already added to the policy: Clipboard: com.android.clipboard SMS: com.google.android.apps.messaging SMS: com.android.mms SMS: com.samsung.android.messaging Native phone app: com.android.phone Google Play Store: com.android.vending Android system settings: com.android.providers.settings Android system settings: com.android.settings Google Maps: com.google.android.apps.maps Gboard: com.google.android.inputmethod.english Samsung: com.sec.android.inputmethod Gboard: com.google.android.inputmethod.latin Gboard: com.google.android.apps.inputmethod.hindi Gboard: com.google.android.inputmethod.pinyin Gboard: com.google.android.inputmethod.japanese Gboard: com.google.android.inputmethod.korean Gboard: com.google.android.apps.handwriting.ime Gboard: com.google.android.googlequicksearchbox Gboard: com.samsung.android.svoiceime Gboard: com.samsung.android.honeyboard Gboard: com.android.inputmethod.latin Teams app: com.microsoft.teams Any insights or suggestions would be greatly appreciated! This is my first time posting so apologies if this is the wrong space.Force settings on Dedicated devices during enrollment
Hello all, I'm trying to deploy a Dedicated device profile in Microsoft Intune, I created the configuration profiles and the compliance policy with some settings, in specific about PIN creation and complexity, but during the setup users are not asked to enter any PIN, and at the end the device result non-compliant until the PIN is set and is fulfilling the rules I set. Is there by any chance a way to force the PIN creation request during the enrollment phase as happens for user-associated devices? Thanks in advance /Lucius
Work profile on S25 Ultra
Just bought a Galaxy S25 Ultra a few weeks ago and unfortunately I'm not able to create a work profile with MS Intune. I've tried all workarounds that I found on Reddit and Samsung community (https://us.community.samsung.com/t5/Galaxy-S25/New-S25-Ultra-Unable-to-setup-work-profile-using-company-portal/td-p/3126410/page/29). I think that this can be related to some Android Enterprise support because I could not find any reference of the models when searching for it. Does anyone else are having issues when trying to create a work profile on S25 series?
[Community survey] Feedback on Android Enterprise Secure logs
Hello everyone, I'm a big fan of surveys and we haven't had one for a little while - so here we are! We'd love to hear your feedback on a potential improvement to the Android Enterprise logs. Android Enterprise logs provide critical insights into device activity and security, empowering organizations to manage and secure their mobile ecosystems effectively. These logs are divided into: Security logs, which capture key events like app installations, failed authentications, and policy changes, and Network event logs, which track network activities such as app connections and destinations. Logs are currently stored in the normal world (REE - Rich Execution Environment). We are exploring a feature enhancement to enable this storage in a secure environment (Virtual Machine) so that they are better protected. This feature enhancement has a few options / levels and we want to understand their importance to you: Logs stored in secure environment: If the OS is compromised, the logs are much harder to access and tamper Tamper evident logs: This would allow the OS to indicate if the logs were tampered with Tamper proof logs: This makes it not possible for logs to be tampered with. Logs would only be available in small quantities (4mb on average, depending on chipset capability) If you have a spare moment, please take the short survey below. If you have any additional questions, please to reply to this topic below (by clicking 'Reply'). Thank you for your time and feedback. Lizzie (and the Customer Community team)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.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.pdf
