Why openNetworkConfiguration not working in enrolled device?
I have enrolled a device and want to use managed wifi on that device. I have used following configuration- "openNetworkConfiguration": { "Type": "UnencryptedConfiguration", "NetworkConfigurations": [ { "GUID": "inovex_wifi", "Name": "INovex-Dev", "Type": "WiFi", "WiFi": { "SSID": "INovex-Dev", "Security": "WPA-EAP", "EAP": { "Outer": "EAP-TLS", "Identity": "faruk", "DomainSuffixMatch": ["dms.mobi-manager.com"], "ServerCARefs": ["ca_inovex"], "ClientCertType": "Ref", "ClientCertRef": "client_inovex" } } } ], "Certificates": [ { "GUID": "ca_inovex", "Type": "Server", "X509": "ca_base64" }, { "GUID": "client_inovex", "Type": "Client", "PKCS12": "client_base64" } ] } My expection is This network automatically save in wifi list As I set client and server certificate the device should connect automatically For information I have used freeradius server for authentication.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.Android 16 STIG is now live!
Hey friends, We are pleased to announce the release of Google’s Security Technical Implementation Guide (STIG) for Android 16. Developed in partnership with the Defense Information Systems Agency (DISA), this guide provides a robust, expert-defined security baseline for organizations that require the highest level of security. It is an essential resource for government, defense, and security-conscious customers like FSI and Healthcare, who handle sensitive data and operate in compliance-driven environments. What is a STIG? A STIG is a detailed security checklist designed to “harden” an operating system. In short, it’s a technical manual that provides prescriptive, step-by-step guidance on how to adjust default settings, disable unnecessary functions, and configure a system to protect against common vulnerabilities. By following a STIG, you proactively close the doors that cyber attackers often use to exploit systems. Who can benefit from the STIG? While STIG compliance is mandatory for DoD (Department of Defense) and federal agencies, its guidance represents the gold standard for security that any organisation can use to improve its security posture. Specifically, the Android 16 STIG provides official configurations for devices deployed in Corporate-owned, business-only (COBO), and Corporate-Owned, Personally-Enabled (COPE) management modes. The key value for your business Adopting the Android 16 STIG goes beyond meeting a mandate, enabling several key business benefits. Achieve the highest security posture: The guide closes configuration weaknesses and minimizes your system’s attack surface, dramatically improving your defence against threats and enhancing system resilience. Ensure mandatory compliance: For federal and DoD-connected systems, STIG compliance is a non-negotiable step to meet the Risk Management Frameworks (RMF) and gain Authority to Operate (ATO). Unlock a standardized and efficient management framework: It provides a single, expert-defined security baseline across all your devices, which simplifies system auditing, prioritizes critical fixes (using the CAT I, II, III severity levels) and streamlines auditing and reporting. Ready to strengthen your security? Get everything your team needs to harden your Android devices, meet compliance mandates, and build a more resilient mobile fleet directly from the DISA repository. ➡️ Download the Google Android 16 STIG here For those interested in federal device certification, our latest episode of The Secure Element delves into the approval process for Android devices in compliance-focused sectors.
EOL Status of OpenCensus Jars and Request for Migration
During a recent review, we noticed that some of the Android Enterprise dependencies we use — specifically opencensus-api and opencensus-contrib-http-util — have not been updated for several years. --> Last release: 0.31.1 (April 29, 2022) These libraries are currently required as dependencies for google-http-client.jar, which we use to initialize HTTP clients for API calls. If we exclude the OpenCensus jars, the application fails at runtime with missing class errors. Therefore, these jars are currently mandatory for successful execution. However, from a security perspective, our central security team does not allow bundling outdated or unsupported dependencies. We would appreciate your guidance on the following points: Are there any plans to update or refactor google-http-client.jar to remove or upgrade its dependency on the legacy OpenCensus libraries? Is there an alternative approach or supported path to use OpenTelemetry (or any other supported telemetry library) in place of OpenCensus for tracing and metrics? We already raised in following portals and no update received, so posting it here AE Partner Escalations Git hub discussions Expert Forum Any roadmap updates or migration guidance would be extremely helpful.The 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
DPC Extras issues
Hello, I hope you're doing well. I'm reaching out for assistance on an issue I'm experiencing with DPC extras on ZTE devices. Is there a method to implement DPC extras without using a QR code? It appears that even when configuring ZTE with DPC extras, some functionalities do not activate. Additionally, several design elements seem less than optimal. For instance, if you do not use a QR code before selecting the language—which, ideally, should be sourced from the DPC—there's an option presented to transfer data from another device. This option seems inappropriate for a company-owned device. Could this be improved? The next screen prompts a WiFi connection. Using a QR code skips this step, but users still need to manually confirm the WiFi connection. Could this be streamlined? Is it possible to enroll a device as an admin, reset it, and have the DPC extras from the QR code persist on the device until it connects to WiFi and verifies its management status? It seems everyone is adding devices to ZTE for security reasons, particularly for stolen devices, yet the reliance on QR codes adds unnecessary complexity. Could this process be made more user-friendly?[Event Recap] - Secure your business continuity with Google
On Wed 1st October we held an essential session on Secure your business continuity with Google focusing on Google Lifeboat - a combination of existing Google products that can help organizations maintain operational resilience and secure communication during a cyber breach. Cyber incidents like ransomware attacks and phishing are increasing in complexity and cost. Our speakers, Dean Paterek and Matt Stevens, highlighted how Google Lifeboat and its component products provide a robust, pre-planned strategy to defend against these threats and swiftly recover when they occur. The Four Core Pillars of Google Lifeboat The platform is not a one-size-fits-all product but a configurable solution built around four core components: Mandiant Incident Response Retainer What it is: A proactive agreement that provides an SLA (Service Level Agreement) for rapid incident response from Mandiant's global team of experts. Key Benefit: It provides pre-paid funds that can be used for security posture improvements, including tabletop exercises to train key stakeholders and test your organization’s response to a breach scenario. Mandiant also offers consulting for incident response, compromise assessment, and strategic security improvement. Google Workspace What it is: A hardened, secure environment for critical communication and collaboration. Key Benefit: In a crisis where your primary collaboration tools may be compromised, Google Workspace provides a secure, separate environment for internal and third-party communication, ensuring business continuity and effective crisis management. Chrome Enterprise Premium (CEP) What it is: A secure, zero-trust method for accessing corporate applications and resources through the Chrome browser. Key Benefit: CEP enables secure access from any device (managed or unmanaged) by enforcing granular policy controls. This includes preventing data loss through features like blocking downloads, uploads, printing, and screenshots directly within the browser, and feeding security telemetry into your SIEM for improved threat detection. ChromeOS What it is: Google's secure-by-design operating system. Key Benefit: ChromeOS devices are highly secure out-of-the-box and are easy to manage and deploy quickly, making them ideal for rapid provisioning to employees in a recovery scenario—even across dispersed locations. The session highlighted the speed of deployment for uncompromised devices as a critical factor in recovering from a major incident. Flexibility and the Wider Google Stack A key takeaway was that Google Lifeboat is designed to be flexible. While Google Workspace is promoted for its separate identity management in a crisis, the platform can accommodate a "bring your own collaboration suite" approach, allowing organizations to use Microsoft 365 on ChromeOS with appropriate security policies in place (e.g., disabling local storage). The session also touched on other integrated Google solutions, such as Cameyo (a virtual application delivery product) for streaming applications in a sandboxed environment from an infected system. 🙋 Got Questions? Let Us Know! If you missed the session and have questions about any aspect, please comment below! And let us know: Would you like to see more events like this focused on security and operational resilience in the ChromeOS environment? Your feedback helps us shape future community content!Intune - Cannot change screen lock timeout
Hello community, I'm writing this post 'cause I'm facing a strange issue with the lock screen setting on our AE devices managed from Intune. The configuration policy was created by my predecessor years ago, and was configured for lock teh screen after one minute. Everything working and all happy. Then I got the request for create an exception group for that, and everything I tried failed. I tried to change the global policy to 5 mins, but it did not worked, and the maximum lock screen time is still one minute. Also remove the setting at all and left it Not Configured didn't had any effect. Then I tried to disable One Lock. With this I was able to change the system lock screen settings but on Settings - Security and Privacy - More Security Settings - Work Profile Security - Use one lock I cannot set anything longer than one minute. Pretty sure this is coming from somewhere in Intune, but also involving Microsoft and sending them the verbose logs wasn't enough. Did any of you ever encountered a similar issue and found a solution? Many thanks in advance for everyone that will try to help.
Assistance with Domain Already Linked to Android Enterprise
hello, I attempted to set up Android Enterprise using a Gmail account, but received a message saying, "This domain name has already been used." Could you please help me verify which Android Enterprise account is currently associated with our domain and advise on how I can proceed?
