About This Release

Matrix42 Silverback 26.1 provides new and improved features that have been implemented. During the development of this version, we have been focusing on valued feedback from our customers and partners to provide an ideal feature selection. For a quick overview of the most important enhancements in this release, take a look at our Release Highlights video on the Matrix42 YouTube channel (coming soon).

Build Information

• Current Status: Technical Release
• Download: Marketplace
• Initial Build Version: 26.1.0.14

Important Announcements

Code Signing Certificate Provider Change

We have changed the code signing certificate provider used to sign our product binaries. Previously, our software packages were signed using certificates issued by DigiCert. Starting with this release, the software is signed with certificates issued by GlobalSign. To avoid issues with updating to this version, please ensure first if your server is already trusting the GlobalSign root and intermediate certificates. Perform a right-click on the Silverback executable, select Properties and navigate to Digital Signatures. After selecting Matrix42, press Details, press View Certificate and navigate to Certification Path to check the chain. In case the certificate(s) chain is not fully trusted, please review the following article from Endpoint Security section: Code Signing Certificate Provider Change – GlobalSign Root Certificate Requirement.

Overview

New Features

• Management Console and General Device Management
  • Enhanced Device Overview for Android and Multi‑Vendor Environments
  • Extended Tag Auto Population Based on Device Attributes
  • External Data as System Variables for Apps and Profiles
• Android Enterprise, AOSP, and AMAPI Management
  • Managed Configurations for Enterprise Apps
  • SCEP Proxy Support for Certificate‑Based Wi‑Fi Authentication
  • Simple File Distribution for Android Devices
  • Additional Network Controls for Advanced QR‑Code Enrollment
  • Improved Reporting of System Applications
  • Configurable Companion Polling Interval via Managed Configuration
  • New Security Controls for Android Management API (AMAPI)
• Apple Device Management
  • Extended Restriction Controls for Apple Devices
• Security Related Initiatives
  • Syslog Export for Security and Audit Events (On‑Premise)
  • TLS 1.3 Support

New Improvements and Changes

• Management Console
  • Updated Knowledge Base Links in Expiration Warnings
  • Direct Device Targeting via API Identifier
• Android Enterprise
  • Improved Handling of Non‑GMS (AOSP) Devices
  • Improved Visibility of FCM Registration Status
  • Improved Lockdown Reliability for Single App Mode (Kiosk Mode)
  • Fixed IMEI Visibility in Device Overview
  • Fixed Label Assignment in NFC‑Based Advanced Enrollment
  • Improved Transparency for Android Enterprise Location Tracking
  • Improved Stability After Enrollment and UI Lifecycle Handling
  • Improved Reliability of Background and Sync Operations
  • Improved Transparency for Enterprise App Installation Process
• Apple Device Management
  • Improved Handling of System Apps in iOS/iPadOS Blacklist (Journal App)
  • Improved Stability and Performance for VPP Command Processing
  • Improved Handling of Device Family Updates for VPP Apps
  • Improved iTunes Search API handling

New Features

Please find all new features and major improvements in Silverback 26.1 below.

Enhanced Device Overview for Android and Multi‑Vendor Environments

Managing heterogeneous Android environments often requires quick access to key device attributes that previously required navigating into individual device details. To address this topic, the Devices view in the Management Console has been extended with three new columns to improve visibility and day‑to‑day device management:

• Android Build Version
• Manufacturer
• GMS (Google Mobile Services)

With these enhancements, essential information is now directly accessible within the device list, enabling faster decision‑making and more efficient operations. These columns are available in the Managed, Blocked, and Checked Out sub‑tabs and can be freely added to or removed from the device overview, allowing administrators to tailor the view to their individual operational needs. 

All three attributes are fully integrated into the existing search and filtering mechanisms. This allows administrators to:

• Filter devices by Android build version to identify rollout gaps or outdated devices
• Search for GMS or non‑GMS devices
• Narrow down device lists based on manufacturer when supporting multiple hardware vendors

Platform availability:

• Android Build Version and GMS are specific to Android devices (Android Enterprise and AOSP).
• Manufacturer is available for all platforms where this information is provided as a dedicated field by the respective MDM protocol. This applies to Android and Windows devices. Apple devices are excluded, as all Apple hardware shares a single manufacturer by design.

Overall, these enhancements significantly reduce the effort required to gain an overview of Android fleets and multi‑vendor deployments, making device management more transparent, searchable, and efficient.

Extended Tag Auto Population Based on Device Attributes

Tag Auto Population is a key mechanism in Silverback to automatically classify devices and drive the distribution of profile, applications, and compliance policies. While Silverback already provides a broad set of conditions for automated assignment, certain OS-, security-, and vendor‑specific attributes were not yet available for rule‑based tagging. To further extend these existing capabilities, Tag Auto Population rules now support additional device attributes that allow for more precise and fine‑grained classification. The following information can now be used as conditions in Tag Auto Population rules:

These extensions make it possible to refine existing Tag strategies without changing established workflows. For example, devices can now be automatically tagged based on their security patch level, differentiated by GMS availability, or grouped by manufacturer across Android and Windows devices to support vendor‑specific targeting. By expanding the available rule conditions, Silverback enables administrators to further automate device classification and keep Tag assignments accurate and up to date as device characteristics change—reducing manual effort while building on the tagging mechanisms already in place.

External Data as System Variables for Apps and Profiles

System Variables are a powerful mechanism in Silverback to configure applications, certificates, and profiles using device, user, or directory information. This works particularly well when the required data is already available within Silverback—for example from managed devices, local users, or directory integrations such as Active Directory. In some scenarios, however, the required information resides in external systems that are not directly accessible to the MDM. Without a way to reference this data, configuration scenarios such as credential injection, identifier‑based app configuration, or certificate personalization become difficult or impossible to automate.

To address this, Silverback now supports importing external data from CSV files and exposing it as system variables that can be used throughout application and profile configurations. External data can be uploaded and managed via External Data Management, where a CSV file is imported and mapped to a defined identifier that Silverback already knows for a device. Supported matching identifiers include, among others:

• Phone Number
• Username
• Serial Number
• Device ID
• IMEI
• ICCID
• IMSI
• EAS Device Identifier

One of these identifiers must be present in the CSV file and is selected as the matching key during import. Based on this mapping, Silverback associates the external data with the corresponding devices.

Seriennummer,Username,Password
540125290299,mario,Pa$$w0rd
560125290300,luigi,Pa$$w0rd

During schema creation, administrators can define field aliases and mark sensitive fields—such as passwords or secrets—as confidential. These values are stored encrypted and handled securely by the system.

Once imported, Silverback automatically generates system variables from the external data. These variables are visible in the device details and can be used in the same way as native system variables for app configurations, certificate profiles, and other configuration scenarios.

Default System Variables	Extended System Variables based on external source

This enhancement significantly extends the flexibility of system variables, allowing Silverback to consume data from external sources without requiring direct system integrations—unlocking advanced automation and configuration use cases that were previously out of reach.

It is important to note that changes to the external source data do not automatically trigger updates of app configurations or profiles. This behavior is consistent with the existing Silverback configuration model and remains unchanged. System variables derived from external data are resolved and applied at the time a profile or managed app configuration is installed. Subsequent changes to the external data source alone do not cause configurations to be re‑applied to devices.
To propagate updated external data, administrators have several options:

• Remove and reassign the tag that contains the affected profile or application
• Make a (minor) change to the profile or managed app configuration to trigger a new installation
• Reinstall the affected application, which will also result in the managed configuration being applied again with the updated variables
• Import a new or updated external data schema and adjust the referenced variables accordingly. In this case, the updated schema becomes effective once the associated profiles or app configurations are re‑applied.

This behavior aligns with Silverback’s established deployment model and ensures consistent and deterministic configuration updates.

Managed Configurations for Enterprise Apps on Android 

On Android, applications are typically distributed either via the Managed Google Play Store or as Enterprise Apps. With this release, Silverback extends the managed app configuration capabilities beyond Managed Google Play applications to also support Enterprise Apps on Android and Samsung devices. Previously, application configuration was limited to apps distributed via Managed Google Play. Based on customer demand for greater flexibility in enterprise environments, administrators can now configure internally distributed applications in the same consistent way.

All uploaded Enterprise Applications will now provide an “Edit managed configuration” option. If the application developer includes a configuration schema (via the app restrictions definition in the app), Silverback automatically reads and applies it, just like with Managed Play apps. This enables a seamless and unified configuration experience across both app types. Administrators can define a base configuration in the App Portal, which is automatically inherited into Tag configurations and can be further customized or overridden at the Tag level. This ensures both standardization and flexibility across different device groups.

Press the Edit managed configuration button	And perform your configuration

A key difference compared to Managed Play apps is that configurations are applied as soon as the app is assigned via a Tag and reported as installed, even if the application itself was not installed by Silverback. This ensures that configuration is already in place once the app becomes available on the device. For transparency, the applied configuration can be tracked in the Pending Commands:

• Request Type: Install Profile
• Profile Name: APK App Configurations

In addition, the updated Companion app now displays Enterprise App configurations under Profiles. By selecting the profile details, users can view all configured Enterprise Apps and directly access them.

This enhancement provides a unified configuration experience across both Managed Google Play and Enterprise Apps, ensuring consistent handling regardless of how applications are distributed. It increases flexibility for internally distributed applications by allowing the same configuration mechanisms to be applied, while also enabling faster deployments through configurations that are already applied when the app becomes active. At the same time, transparency is granted through visibility in the Companion app and a command tracking is available, making it easier to understand and troubleshoot how and when configurations are applied on the device.

SCEP Proxy Support for Certificate‑Based Wi‑Fi Authentication 

Certificate‑based Wi‑Fi authentication using EAP‑TLS is a common security requirement in enterprise environments. While Silverback already supports device certificate deployment through native integrations such as Microsoft Active Directory Certificate Services (AD CS), some customer environments rely on Public Key Infrastructures that expose certificates exclusively via SCEP.

To support these architectures, Silverback now provides SCEP‑based certificate enrollment by acting as a SCEP proxy for Android and Samsung devices.
Administrators can create and manage SCEP profiles in the Admin section and reference them directly from Wi‑Fi profiles when configuring certificate‑based authentication. Once the Wi‑Fi profile is assigned to devices via tags, certificate enrollment and delivery are handled automatically.

The enrollment process follows these steps:

• An administrator creates a SCEP profile in the Admin area.
• The SCEP profile is selected in a Wi‑Fi profile configured for EAP‑TLS authentication.
• The Wi‑Fi profile is assigned to devices via Tags.
• The device requests the CA certificate chain and challenge through Silverback.
• The device generates a key pair and creates a Certificate Signing Request (CSR).
• The device sends the SCEP request to Silverback and waits for completion.
• Silverback forwards the request to the SCEP‑enabled Certificate Authority, retrieves the signed certificate, and returns it securely to the device.
• The device receives the certificate and uses it for Wi‑Fi authentication.

By acting as a SCEP proxy, Silverback enables seamless integration with existing SCEP‑based PKI infrastructures while keeping certificate handling centralized, secure, and auditable. This significantly expands the available certificate deployment options for secure network access without requiring changes to the underlying PKI architecture.

Simple File Distribution for Android Devices

In many Android deployments—especially on rugged devices—administrators need a simple way to deliver files such as configuration files, certificates, or resources directly to devices. Since OEM‑specific file management capabilities are not consistently available across manufacturers, Silverback now provides a lightweight and OEM‑independent solution.

We offer now a dedicated file transfer application that is available via the Marketplace and is deployed to devices as an Enterprise App (APK) using Silverback. The app is intentionally simple and self‑contained: it downloads a file from a configured, directly accessible URL and stores it at a defined target path on the device. The file source can be hosted on the Silverback server (on‑premise), in Azure, or on any other web server. Configuration is handled exclusively through managed app configuration, and the app operates independently on the device. To comply with modern Android storage restrictions, the app does not use elevated file system permissions. As a result, files can only be written to target paths that do not require special Android permissions, such as app‑specific storage locations. System or protected directories are intentionally not supported.

After installation, the app must be opened once manually on the device to initialize scheduling. Once initialized, it uses Android’s WorkManager to periodically (every 15 minutes) check for configuration changes. A download is triggered only when the configured source URL changes, preventing unnecessary re‑downloads. An immediate synchronization can be triggered manually using Sync now within the app, and download completion is indicated via a system notification.

While the app is installed and configured through Silverback, the file transfer itself is executed independently on the device. However, the app sends status information via the Android App Feedback Channel. When a managed account is present on the device, deployment-related feedback can be viewed on a per-device basis under Actions > Applications Feedback. A consolidated, cross-device overview comparable to the reporting available for Managed Google Play applications within the App Portal is currently not available in the product, but is planned for a future release to provide a global view of file transfer status.

In addition, please note that periodic checks are subject to Android system conditions such as battery optimization, Doze mode, and background execution limits. The app supports Light and Dark mode and is localized in English, German, and French.

Additional Network Controls for Advanced QR‑Code Enrollment

Advanced QR‑Code enrollment is a critical building block for scalable Android provisioning, especially in controlled or restricted environments. To further increase flexibility and reduce external dependencies during enrollment, Silverback introduces two important improvements.

You can now enable Offline Provisioning for Advanced QR‑Code enrollment, allowing devices to be provisioned even when Google services are not reachable during setup. This is especially useful in restricted or offline environments and addresses the default requirement for internet connectivity when provisioning company‑owned devices on Android 13 (API level 33) and higher. 

It is important to note that while offline provisioning relaxes the default requirement for Google service connectivity, the Android Setup Wizard itself may still perform certain system‑level network and connectivity validation steps. These checks are part of the Android operating system and OEM implementation and are outside of Silverback’s control. As a result, depending on the Android version, device manufacturer, and network environment, limited connectivity to system endpoints may still be required for the setup process to complete successfully, even when offline provisioning is enabled - for example, Android OS connectivity validation endpoints (e.g. https://www.google.com/generate_204 or a reachable PAC File) used when a device connects to a Wi‑Fi or mobile network. From a Silverback perspective, the only hard requirement for enrollment is HTTPS connectivity (port 443) from the device, via the Companion (DPC), to the Silverback server. In addition, the Companion must be reachable from its configured download location during installation. Any additional connectivity requirements originate from the Android operating system, Google services, or OEM‑specific implementations.

In addition, Silverback now allows you to define an alternative download location for the Companion (DPC) used during enrollment. By default, Silverback continues to use the Managed Google Play download URL defined in the web settings (https://play.google.com/managed/downloadManagingApp?identifier=matrix42). When the new option is enabled, administrators can specify a custom download location instead. This is particularly helpful for troubleshooting scenarios, controlled test environments, or for quickly making a new Companion version available for enrollment without requiring a full Google Play publish and release cycle.

While these provisioning options are new in the Management Console, the underlying capabilities have technically been available before. Administrators could already make use of them by manually encoding the required parameters - either by writing them directly to an NFC tag or by creating a custom Advanced QR‑Code when the supported provisioning flags were known (for example by inspecting or scanning existing QR‑Codes with a QR‑Code reader).

With this release, these options are now officially supported and exposed directly in the Management Console, removing the need for manual QR‑Code generation. This makes the configuration more accessible, reduces the risk of misconfiguration, and allows administrators to apply these settings in a consistent and supportable way as part of the standard Advanced QR‑Code enrollment workflow.

Configurable Companion Polling Interval via Managed Configuration

Silverback primarily relies on push notifications to trigger device communication for actions such as command execution, profile updates, or information exchange. As a fallback mechanism, the Companion app (Android and Samsung Knox) periodically checks for pending commands to ensure reliability, even when push notifications are delayed or unavailable. It is important to note that this fallback mechanism is subject to Android system conditions, such as battery optimization, Doze mode, and background execution limits. As a result, polling intervals may not always be executed with exact precision, depending on the device state and OS behavior and are visible in the Companion logs. 

Previously, this polling behavior was hardcoded to a fixed interval of 10 minutes (600 seconds) within the Companion app. Although a corresponding setting existed in the Web Settings (Companion MDM Poll Interval), it only applied during enrollment and had no effect on already enrolled devices, limiting flexibility and control. In more recent Companion versions, this setting was effectively ignored, as the strategic direction was to move away from periodic polling in favor of push notifications as the primary and preferred communication mechanism.  

However, decisions shifted and with this release, the polling interval is now configurable via Managed Configuration. Administrators can define and dynamically adjust the interval at any time. This enhancement also enables granular control through Tags, allowing different polling intervals based on device groups or scenarios. For example, non-GMS devices can be configured with shorter intervals to ensure more reliable communication, while GMS devices can use longer intervals to optimize efficiency.

Improved Reporting of System Applications on Android

The list of installed applications is a key source of truth for Silverback to determine application state, installation status, and to correctly orchestrate app‑related workflows. By default, the Companion does not report system applications in the installed application inventory, as these apps are typically preinstalled, numerous, vendor‑specific, and not actively managed by the MDM. In scenarios where the Silverback Companion is pre‑integrated into the device OS by the manufacturer and marked as a system app, this led to inconsistent behavior. 

When updating system applications via APK, the application could be successfully installed or updated on the device but not reported back to Silverback. As a result, Silverback repeatedly attempted to reinstall the application, leading to unnecessary installation loops. In addition, Silverback could not reliably detect that the Companion was installed, which could cause issues - including the Device ID not being shown in the Companion or more notably when exiting Single App Mode (Kiosk Mode) using a PIN, where required information exchange failed and the Companion application could crash.

To address these scenarios, application reporting has been improved. The Silverback Companion is now always included in the reported installed application list, even if it is integrated into the OS and declared as a system application. In addition, any application that is installed or updated via APK through Silverback is now always reported - regardless of whether it is classified as a system app or a regular application. This ensures that Silverback has a consistent and reliable view of the actual application state on the device, preventing installation loops and improving stability for workflows such as Single App Mode. Overall, this improvement increases robustness and predictability when managing Android devices with preinstalled system applications.

New Security Controls for Android Management API (AMAPI)

Silverback extends its Android Management API (AMAPI) capabilities with new security‑focused configuration options, giving administrators more granular control over device behavior, authentication, and system access.

• You can now define detailed password policies for AMAPI‑managed Android devices, including minimum password length, complexity requirements, required character types, password expiration intervals, and thresholds for failed authentication attempts that trigger device lock or wipe actions. This allows organizations to enforce consistent authentication standards and better protect corporate data.
• In addition, Silverback now allows you to control which Accessibility Services are permitted on AMAPI‑managed devices. By explicitly allowing or blocking accessibility services, administrators can prevent misuse while still enabling approved tools - an important safeguard for high‑security environments and kiosk deployments.
• Security controls have also been expanded to cover developer‑related settings and app installation behavior. Administrators can enable or disable Developer Options, manage USB debugging, and allow or block the installation of untrusted apps. These settings help prevent unauthorized modifications, sideloading, and configuration drift on managed devices.
• Finally, Silverback now supports managing Credential Manager behavior on AMAPI‑managed devices. Administrators can control which credential manager apps are allowed or blocked, ensuring that authentication and credential storage policies are enforced consistently across the device fleet.
  Together, these enhancements significantly strengthen the security posture of Android devices managed via AMAPI, while providing administrators with clearer control and enforcement options for sensitive device capabilities.

Extended Restriction Controls for Apple Devices

Managing Apple devices in regulated or security‑sensitive environments often requires fine‑grained control over system features to prevent data leakage and enforce compliance. With this release, Silverback extends its restriction capabilities across iOS, iPadOS, and macOS to give administrators more precise control while still allowing approved business use cases.

You can now disable call recording on supervised macOS devices to ensure that sensitive conversations cannot be captured. In addition, Silverback introduces exceptions for global camera restrictions, allowing specific trusted apps to retain camera access while all other applications remain blocked—providing flexibility without compromising security.

Further restrictions include the ability to disable Live Voicemail, prevent users from clearing Safari browsing history, and block Safari private browsing mode. These controls help preserve auditability, reduce the risk of data exfiltration, and ensure consistent policy enforcement across managed Apple devices.
All restrictions are available on supervised devices running the latest supported versions of iOS, iPadOS, and macOS, enabling organizations to apply security and compliance policies consistently across their entire Apple fleet.

Syslog Export for Security and Audit Events (On‑Premise)

For security monitoring, auditing, and compliance purposes, administrators often need to forward relevant management and device events to centralized logging or SIEM systems. Until now, this required manual log analysis or external tooling. Silverback can now forward selected events directly via Syslog, enabling seamless integration with existing SIEM and log management solutions. This capability is available for on‑premise deployments and allows Silverback to send structured Syslog messages for a wide range of security‑ and audit‑relevant activities, including administrative actions, authentication events, device operations, and configuration changes.

Syslog forwarding can be enabled by adding an application setting on the IIS sites /admin and /sts:

• Name: Siem:Syslog:Server
• Value: e.g.
  • udp://localhost:514
  • tcp://syslog.example.com:514
  • tls://syslog.example.com:6514

Silverback supports UDP, TCP, and TLS for Syslog transmission, allowing administrators to align log forwarding with their security and transport requirements.
Once configured, Silverback automatically starts sending Syslog messages to the specified endpoint. The exported events include, among others:

• Administrator login and logout events, including MFA status and authentication failures
• Administrative actions such as user, tag, device, app, and policy changes
• Device‑related operations (e.g. lock, wipe, reboot, lost mode, location events)
• Certificate‑ and profile‑related activities
• Token, license, and system configuration changes

Each Syslog message contains contextual metadata such as timestamps, severity, correlation identifiers, user or device references, and the originating system component, making the events suitable for correlation and analysis in SIEM platforms.

New Improvements

Please find all new improvements in Silverback 26.1 below.

Management Console

Updated Knowledge Base Links in Expiration Warnings

When critical components such as website or signing certificates, APNs certificates, or tokens for DEP or VPP approach their expiration date, Silverback displays warnings in the Management Console to help administrators take action in time.
To support efficient resolution, these warnings include direct links to Knowledge Base articles that provide step‑by‑step instructions for renewing or replacing the affected certificates or tokens. 

As part of the recent migration to a new Help Center platform with an updated URL structure, all hardcoded Knowledge Base links used in these warnings have been updated accordingly. This ensures that administrators are always directed to the correct and current documentation when responding to expiration warnings, reducing friction and helping to prevent service interruptions caused by expired certificates or tokens.

Direct Device Targeting via API Identifier

Silverback introduces a new system variable, {APIIdentifier}, which exposes the direct API identifier of a device. This allows applications and configurations to reference a device directly via the API without requiring prior lookup based on device attributes. The variable can be used in app configurations, for example by providing both an API token and the device’s API identifier to an application. This enables apps to trigger targeted device actions through the API—such as applying additional or alternative configurations or dynamically adjusting permitted device use cases based on in‑app actions. This enhancement simplifies API‑based device interactions and enables more dynamic, app‑driven management scenarios.

Android Enterprise

Improved Handling of Non‑GMS (AOSP) Devices

Android devices without Google Mobile Services (GMS), such as AOSP devices, do not support Firebase Cloud Messaging (FCM). Previously, when tags were assigned to such devices, Silverback attempted to send push notifications regardless. This resulted in warning messages in the Management Console and log entries indicating missing FCM capabilities—although this behavior was expected and not actionable for administrators. With the availability of explicit GMS availability information, Silverback can now distinguish between GMS and non‑GMS devices and adjust its behavior accordingly.
As a result, Silverback no longer attempts to send FCM push notifications to non‑GMS (AOSP) devices, eliminating unnecessary error messages and providing a cleaner, more accurate management experience. In addition, the Silverback Companion now evaluates GMS availability during startup. On devices without GMS, the Companion automatically adapts its behavior by:

• Preventing FCM registration ID requests and updates
• Skipping Play Integrity API calls
• Location tracking is performed using the native Android LocationManager, using the Network Provider where available and falling back to the GPS Provider if required. If no provider is immediately available, the last known location is used

These improvements ensure that Silverback and the Companion operate in a way that is aligned with the actual capabilities of the device, reducing noise in the Management Console and improving stability and predictability when managing mixed GMS and AOSP environments.

Improved Visibility of FCM Registration Status

Push notifications are a core mechanism for device management and command delivery on Android. For this to work, devices must have a valid FCM (Firebase Cloud Messaging) registration. Until now, this information was only available internally in the Silverback database, making troubleshooting more difficult in certain scenarios.

With this release, the Companion (DPC) now clearly displays the FCM registration status directly on the device under About. If no FCM registration is available, the status is shown as “Not available”. If a registration exists, the Companion displays the several characters of the FCM Registration ID, allowing to quickly verify its presence without exposing the full identifier. In addition, the Management Console now indicates whether an FCM Registration ID is present in the database for a device. This information is displayed in the device details view as a simple “Yes” or “No”, enabling administrators to quickly verify the registration status across devices.

This improvement is particularly useful when troubleshooting connectivity or network‑related issues - for example when firewall rules, proxy settings, or network optimizations are being tested. Administrators can now immediately determine whether a device meets the minimum requirements to receive push notifications, directly from the device itself.

Improved Lockdown Reliability for Single App Mode (Kiosk Mode)

Single App Mode (Kiosk Mode) depends on strict control over available system UI elements to ensure a fully locked‑down device experience. Silverback provides multiple configuration options to restrict system features such as the Home button, Recent Apps, Notifications, Global Actions, the system status bar, and the keyguard.  When the None option was selected, Silverback previously applied the standard Android setting LOCK_TASK_FEATURE_NONE. While this configuration is defined to disable all optional lock task features, some devices still exposed certain system elements—most notably Global Actions—due to vendor‑specific Android behavior.

To ensure consistent and predictable behavior across devices, the handling of the None option has been improved. Silverback now applies a stricter lock task configuration by using LOCK_TASK_FEATURE_BLOCK_ACTIVITY_START_IN_TASK, which prevents activities from being started within the locked task and results in a more restrictive enforcement of Single App Mode. This change ensures that when None is selected, no system UI elements or escape paths remain accessible, providing a more reliable and robust kiosk experience across different device manufacturers.

Fixed IMEI Visibility in Device Overview

We have resolved an issue where the IMEI information was not displayed in the device details view under certain conditions for Android devices. Previously, the visibility of the IMEI field depended on whether service subscription information was reported by the Companion. The intended logic was:

• If service subscriptions are available, the IMEI is shown within the Network Information section
• If no service subscriptions are present, the IMEI is displayed in the general device information

However, some Android devices returned an empty list ([]) instead of null or an empty value for service subscriptions. This caused the system to incorrectly interpret the device as having subscription data, resulting in the IMEI being hidden in both sections.

As a result, while the IMEI was still visible in the device overview list, it was missing in the detailed device view, leading to inconsistent and incomplete information for administrators. With this fix, empty subscription responses ([]) are now correctly treated as no subscriptions, ensuring that the IMEI is reliably displayed in the appropriate section of the detailed device view.

Fixed Label Assignment in NFC‑Based Advanced Enrollment

Advanced QR‑Code Provisioning was recently extended to support label assignment and time zone configuration during enrollment. This allows devices to be automatically classified and correctly configured from the very beginning, reducing manual post‑enrollment steps. In the previous release, label assignment defined in Advanced QR‑Codes was correctly applied when devices were enrolled via QR‑Code provisioning. However, the same information was not applied when enrollment was performed using NFC, even though the configuration was present (label_name:Marketing). This inconsistency has now been resolved. With the updated Companion version, label definitions included in Advanced enrollment configurations are applied consistently, regardless of whether devices are enrolled via QR‑Code or NFC. This fix ensures a uniform enrollment experience across all supported provisioning methods and guarantees that labels and related configurations are applied reliably during device onboarding.

Improved Transparency for Android Enterprise Location Tracking

Location tracking on corporate‑owned Android Enterprise devices is a sensitive feature that requires clear communication and transparency for both administrators and end users. Following the introduction of location tracking for Android Enterprise, additional improvements have been made to ensure users are properly informed and privacy expectations are clearly communicated. 

The Enrollment Wizard has been updated to explicitly inform organizations that location data can be collected for corporate‑owned devices, making this capability visible early in the enrollment process.  When the Location Tracking profile is assigned to a device, users now receive a notification indicating that the profile has been installed. In addition, a disclaimer is displayed on the standard screen, clearly stating that periodic location tracking has been enabled by the administrator for security and recovery purposes, and that the data is handled according to the organization’s policies and accessed only by authorized staff. The Privacy section in the Companion app has also been updated to reflect this behavior. Users are now explicitly informed that their organization may see background location data for corporate devices, and the Matrix42 Companion Privacy Policy is included for additional transparency.

These improvements enhance clarity, trust, and compliance by ensuring that location tracking is clearly communicated at enrollment time and throughout the device lifecycle.

Improved Stability After Enrollment and UI Lifecycle Handling

A reliable enrollment flow and a stable user interface are essential for a smooth device onboarding experience. Under certain conditions, background processes or UI callbacks could continue running longer than necessary, potentially leading to unnecessary processing or unintended behavior. With this release, the Companion has been improved in two key areas.

After a successful enrollment, the internal polling mechanism is now restarted correctly to reflect the updated enrollment state. This ensures that background workers do not continue running based on outdated assumptions, preventing unnecessary scheduling when the device is already enrolled. In addition, the lifecycle handling of UI update callbacks has been refined. UI update handlers are now properly managed and stopped when the corresponding screen is no longer active, preventing callbacks from being triggered after a view has been destroyed. 

These improvements increase overall stability and reliability of the Companion app, especially during and after the enrollment process.

Improved Reliability of Background and Sync Operations

Android device manufacturers apply different and often very restrictive background execution and network policies. In some cases, this could lead to network‑related errors, such as unknown host exceptions, when background services attempted to communicate with the server while being throttled by the operating system. To improve reliability and consistency across different Android implementations, we have refined the handling of background and foreground services in the Companion.

When a sync operation is triggered, such as through a push notification or a scheduled worker cycle, the Companion now temporarily runs the operation as a foreground service. During this time, a short‑lived notification is displayed in the notification bar to indicate an active operation. Once the sync is completed, the foreground service is stopped and the notification is removed.

This approach aligns with Android best practices and ensures more reliable network access during active operations, while avoiding permanent notifications when no action is being performed. As a result, sync reliability is improved across OEM‑specific Android variants without impacting the regular user experience.

Improved Transparency for Enterprise App Installation Process

Previously, the Companion displayed a simplified “Fetching application (package name)” message during enterprise app (*.apk) installations. However, this step actually represents a more complex process, including downloading the application, triggering the system installation, waiting for completion, and applying runtime permissions. With this release, the installation process is now broken down into granular, user-visible steps within the Companion:

• Downloading application (package name)
• Installation requested and awaiting system confirmation (package name)
• Verifying application and applying permissions (package name)

This provides significantly better transparency into the current installation stage and helps administrators and users better understand where delays may occur. 

In addition, timeouts for installation-related processes have been increased. This accounts for scenarios where installation timing depends on the Android operating system, which may delay installations (for example, due to parallel background activities such as Google service updates). Previously, a timeout of one minute was applied after the application had been downloaded and the installation request was handed over to the operating system. If the app was not installed within this one-minute window, the Companion reported an error back to the Management Console. To reduce these error states in the Management Console, the timeout has now been increased to three minutes, providing the system with more time to complete the installation process before reporting a failure.

Security

TLS 1.3 Support Fully Enabled

TLS 1.3 provides improved security and performance compared to earlier TLS versions and is increasingly required to meet modern security and compliance standards. While Silverback already supported TLS 1.3 at a technical level, it was not officially released due to remaining dependencies across internal services that were not yet fully aligned. These dependencies have now been removed across the relevant system components, allowing Silverback to support TLS 1.3 as a fully supported and production‑ready option. As a result, you can now safely switch their Silverback environment to TLS 1.3, strengthening transport security across all communication channels without functional limitations. The Hardening Guide will be updated accordingly to reflect the recommended TLS configuration and to support customers in aligning their environments with current security best practices.

Apple Device Management

Improved Handling of System Apps in iOS/iPadOS Blacklist (Journal App)

We have resolved an issue affecting the management of system applications in enforced blacklist configurations for iPadOS. Previously, the native Apple Journal app (Bundle ID: com.apple.journal) was not available in the selectable system app list for iPad devices. While administrators could manually add the Bundle ID, it was not displayed in the blacklist UI, despite being successfully applied on the device. In addition, modifying the blacklist configuration after adding the Bundle ID could lead to inconsistent behavior, where the Journal app would reappear on the device and required re-adding the identifier. This behavior was caused by a discrepancy between the internal iOS and iPadOS system app Bundle ID lists, where the iOS list was incorrectly used for iPadOS. With this fix, the Journal app is now correctly recognized as a system app for iPadOS and is available as a selectable option in the UI.

Furthermore, we introduced the following improvements: When a system Bundle ID is added manually, the corresponding app is now automatically recognized and reflected as a selected system app in the UI. Only non-system apps (custom Bundle IDs) are displayed in the blacklist/whitelist grids, improving clarity and consistency.

Improved Stability and Performance for VPP Command Processing 

We have implemented several improvements to enhance the stability and reliability of VPP (Volume Purchase Program) command processing for Apple devices. In certain scenarios—particularly after server restarts or large-scale operations—the system could enter a state where VPP-related commands were continuously re-queued, leading to increased system load and delayed or stalled communication with Apple devices. With this release, additional sanity checks and safeguards have been introduced to prevent such conditions and ensure efficient command processing.

Improved Handling of Device Family Updates for VPP Apps

Applications distributed via Apple Volume Purchase Program (VPP) can change their supported device families over time. This includes scenarios where support for new platforms is added, for example introducing macOS support, while availability for certain device families is no longer explicitly listed. In previous versions, Silverback evaluated device family updates primarily based on the number of reported entries. In certain edge cases, where the number of device families remained unchanged but the actual supported platforms differed, these updates were not detected correctly. As a result, application metadata in the App Portal could become outdated and not fully reflect the information provided by Apple. 

This logic has now been improved. Newly reported device types are automatically added, while existing availability is preserved. Applications are only removed from the App Portal when the VPP API no longer reports the asset at all. This means that if an application previously supported iPhone, iPod, and iPad and is later reported by VPP as supporting iPhone, iPad, and macOS, Silverback will reflect all four device families. This approach ensures that newly supported platforms are captured while avoiding unintended removal of existing availability.

Improved iTunes Search API handling

The handling of Bundle ID searches against the iTunes Search API has been improved by properly URL‑encoding search terms. This increases reliability and prevents lookup issues for applications with special characters in their Bundle ID.

New Changes

• The device type model of the Galaxy A14 SM-A145R was changed from Samsung Knox to Android according to an incorrect assignment.
• The security patch level has been changed to a technical identifier according to Google's claimed format, rather than the usual date value in the local date format.
• The default search option under Volume Purchase Program has been changed from Product type to App to better align with common search behavior.