Release Notes Silverback 24.0 Update 3
About this Release
Matrix42 Silverback 24.0 Update 3 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.
Visit the following playlists on the Matrix42 YouTube channel to get a short overview presentation of the major new features: Link to English Video-Playlist | Link to German Video-Playlist.
Build Information
- Download: Marketplace
- Initial Build Version: 24.0.3.52
Important Announcements
SafetyNet Attestation API support ending
Google will fully turning down the SafetyNet Attestation API starting January 31, 2025. The SafetyNet Attestation API device integrity checks allows you to see if you have devices in your management that have, for example, an unlocked bootloader, a custom ROM installed, a virtual device, or devices that have not been certified by the manufacturer, including other security features that can be checked by Google. With Silverback 23.0 Update 3, we informed you about the required change and we have already made it possible for you to switch to the newer Play Integrity API for these device integrity checks. As the time has arrived, this Silverback and Companion release will remove all SafetyNet components from the Device Information, Lockdown policy, and E-Mail templates. During the upgrade, Silverback will disable automatically all currently set SafetyNet Device Integrity Compliance related Lockdown policies in Tags. For compatibility reasons, the endpoint used for receiving Companion information from older versions about SafetNet Attestation information will remain open, but the Silverback response will always be success and Silverback will not execute any further action. This will prevent too many logs from being written if devices continue to report from old Companion versions to the server.
Certification Authority Change for APNs
Apple announced in October that the Certification Authority (CA) for Apple Push Notification service (APNs) is changing. APNs will update the server certificates in production on February 24, 2025. To continue using APNs without interruption, you’ll need to ensure that the new server certificate SHA-2 Root : USERTrust RSA Certification Authority certificate is installed on your Silverback server under the Trusted Root Certification Authorities Store. To ensure a smooth transition and avoid push notification delivery failures, please make sure that both old (AAA Certificate Services) and new server certificates are included in the Trusted Root Certification Authorities Store before the cut-off date.
New Certificate | Old Certificate |
---|---|
![]() |
![]() |
Thumbprint: 2b8f1b57330dbba2d07a6c51f70ee90ddab9ad8e | Thumbprint: d1eb23a46d17d68fd92564c2f1f1601764d8e349 |
Overview
The following content is included in this new Silverback release:
New Features
- Distribute certificates in the computer context of Windows devices
- Pre-Assign Device Names, Ownership and Labels for Windows devices
- Align Passwords for devices and Identity Providers with Platform Single Sign On
- Configure Network virtualization with 5G Network Slicing
- New Apple device configurations via Restrictions
- Account-driven User Enrollment
- Lock down and locate lost company-owned Android Enterprise devices
- Maintenance Option for Single App Mode on Android Enterprise
New Improvements and Changes
Known Issues
New Features
Distribute certificates in the computer context of Windows devices
Storing a user certificate in the computer store makes it available system-wide, allowing authentication and network access for all users on the device, simplifying management in multi-user environments. As this was one of the most requested ideas on our Ideas Portal, it was time to add this feature to Silverback. Starting from our initial goal of letting you as an administrator decide in which context the certificate should be installed, we have now come up with a much more comprehensive solution for certificate profiles. In general, you will benefit from the following changes and improvements:
- The profile has been renamed from Certificate to Certificate Profiles and it is now possible to add multiple Certificate Profiles to a single Tag.
- The Key Store and Key Length configuration gives you additional options for individual client certificate configurations.
- You can now either upload an Enterprise Certificate or configure the deployment of individual certificates, regardless of the Certificate Deployment selected in Web Settings.
- The address for your CA and the selected Issuing CA, CEP Encryption Agent and Exchange Enrollment Agent certificates configured in Web Setting will be used as defaults in each individual client certificate configuration, but can be overwritten individually.
- If you select Individual Client Certificates and use the Computer Store, you can also use a Computer template from your CA instead of a User template.
- By having a pre-assigned device name in Hardware Authentication, we have ensured that the device is renamed during enrollment before the certificate is issued.
Pre-Assign Device Names, Ownership and Labels for Windows devices
In general, the Hardware authentication is a part of access control, which can ensure that only pre-authorized devices are allowed to become a managed device, e.g. only corporate owned devices that are issued and fixed assets of your organization. In addition to this, you can also use the Hardware Authentication to easily pre-assign device names, ownerships and labels for devices, based on an identifier, which is either the Serial Number or the IMEI.
Starting with this release, we have added support for pre-assigning device names to Windows 10 and Windows 11 clients. This is particularly helpful in cases where devices are to have a pre-defined device name after enrollment, and an individual client certificate is also installed in the Computer Store. As this certificate should most likely have the target device name in the Subject, SAN, and RFC 822 Name, Silverback is now able to assign the device name before the certificate will be issued and installed on the client.
There is one special feature to note here. After Silverback changes the device name, the device transmits the new device name to Silverback via the MDM protocol immediately after the action has been carried out. However, this does not mean that all conversions of the new device name have been carried out on the client as this requires a restart. To deal with this situation, there is a new setting in Admin > MDM Settings > Windows called Reboot for Hardware Authentication that can be enabled. When this is enabled, Silverback will automatically send the reboot command to devices that have been automatically renamed. Once the devices receive the command, the reboot will be executed after 5 minutes.
Align Passwords for devices and Identity Providers with Platform Single Sign On
The Platform SSO (Single Sign-On) feature on macOS, introduced in macOS Ventura 13 and enhanced in subsequent versions, is designed to streamline authentication and identity management across the system and applications. It allows users to sign in once and gain access to multiple apps and services without needing to authenticate repeatedly. Platform SSO integrates third-party identity providers (IdPs) directly into macOS, enabling users to sign in using their corporate or organizational credentials at the system level. Once authenticated, the credentials can be used seamlessly across the macOS system and supported applications, reducing the need for multiple logins. Many enterprise IdPs have already developed extensions for Platform SSO, including:
- Microsoft Entra ID
- Google Workspace
- Okta
- Ping Identity
In this new release, we extended the recently introduced Extensible Single Sign-On Profile for macOS devices with the Platform SSO configuration. After specifying the identity provider's extension bundle ID and additional settings (e.g., login URL, token expiration policy) and installing the Identity Provider’s App or Extension, users will be prompted to execute the required steps to finally log in with their organizational credentials during the macOS login process. For additional information, please refer to Platform Single Sign-On on macOS devices
Configure Network virtualization with 5G Network Slicing
5G Network Slicing enables the usage of customized, isolated network segments to optimize performance, security, and efficiency for specific applications and use cases. On Android Enterprise with Android Management API, the Network Slicing can already be globally enabled for the Work Profile. Within this release, we added the support for iOS and iPadOS devices. While Android Enterprise has a global setting for Network Slicing and pre-defined slice categories (e.g. Low latency or High bandwidth) must be addressed by the app developers, the configuration of iOS and iPadOS devices works slightly differently. The network slicing option for these devices is an app management configuration, where you can enter the specific Data Network Name (DNN) or the App Category Name for each application individually. The configuration is supported for all iPhone and iPad application types and can be configured when importing Volume Purchase Program apps, or in the App Portal or even more granularly in Tags.
This means that either the data network name (DNN) or the app category is added when the application is installed. If the application contains a corresponding configuration and the application is installed on the end device, you will see a corresponding entry in the MDM profile that this application uses a slice for network access.
If you are interested, please contact your network provider for more information about 5G network slicing.
New Apple device configurations via Restrictions
Starting with the release of iOS 17.4 and macOS 15, Apple has included 19 new configuration options in the form of restrictions. In general, restrictions are easy on/off settings that enhances the configuration options of your managed devices and increases security options. This means with this new Silverback release, you can now configure the following new restrictions:
Availability | Requirements | Description | |
---|---|---|---|
Applications | |||
Allow Install Apps from the Web |
|
|
If disabled, prevents installation of apps directly from the web. Available in iOS 17.5 and later. |
Allow Hide Apps |
|
|
If disabled, disables the ability for the user to hide apps. It doesn’t affect the user’s ability to leave it in the App Library, while removing it from the home screen. Available in iOS 18 and later. |
Allow Lock Apps |
|
|
Disables the ability for the user to lock apps. Because hiding apps also requires locking them, disallowing locking also disallows hiding. Available in iOS 18 and later. |
Network & Connection | |||
Allow eSIM Transfer |
|
|
If disabled, prevents the transfer of an eSIM from the device to a different device. Available in iOS 18 and later. |
Security & Privacy | |||
Allow iPhone Mirroring |
|
|
If disabled, prevents the iPhone from mirroring to any mac or the Mac from mirroring to any iPhone. Available in iOS 18 and later |
Apple Intelligence | |||
Allow Create New Genmoji |
|
|
If disabled, prevents creating new Genmoji. Available in iOS 18 and later. |
Allow External Intelligence Integrations |
|
|
If disabled, prevents the use of external, cloud-based intelligence services with Siri. On iOS, this restriction is temporarily allowed on unsupervised and user enrollments. In a future release, this restriction will require supervision, and will be ignored on non-supervised devices. Available in iOS 18.2 and later. |
Allow External Intelligence Integrations Sign In |
|
|
If disabled, forces external intelligence providers into anonymous mode. If a user is already signed in to an external intelligence provider, applying this restriction will cause them to be signed out when the next request is attempted. Available in iOS 18.2 and later. |
Allow Image Generation |
|
|
If disabled, prevents the use of image generation. Available in iOS 18 and later. |
Allow Use Image Wand |
|
|
If disabled, prevents the use of Image Wand. Available in iOS 18 and later. |
Allow Personalized Handwriting Results |
|
|
If disabled, prevents the system from generating text in the user’s handwriting. Available in iOS 18 and later. |
Allow Writing Tools |
|
|
If disabled, prevents the use of Apple Intelligence writing tools. Available in iOS 18 and later. |
Allow Call Recording |
|
|
If disabled, call recording is not allowed. Available in iOS 18 and later. |
Allow Mail Summary |
|
|
If disabled, prevents the ability to create summaries of email messages manually. This doesn't affect automatic summary generation. Available in iOS 18 and later. |
System Settings | |||
Allow Auto Dim |
|
|
If disabled, prevents auto dim on iPads with OLED display. Available in iOS 17.4 and later. |
Allow RCS Messaging |
|
|
If disabled, prevents the use of RCS messaging. Available in iOS 18.1 and later. |
Allow Default Browser Modifications |
|
|
If disabled, prevents the default browser preference modification. The MDM Settings command to set the default browser preference will still work when this is applied. Available in iOS 18.2 and later. |
Allow Media Sharing Modifications |
|
|
If disabled, prevents modification of Media Sharing settings. Available in macOS 15.1 and later. |
Force Bypass Screen Capture Alert |
|
|
If enabled, the system bypasses the presentation of a screen capture alert. Available in macOS 15.1 and later. |
Account-driven User Enrollment
The Account-Driven User Enrollment is a feature introduced by Apple to simplify and enhance the management of personal devices (BYOD - Bring Your Own Device) in enterprise and educational environments. It allows users to securely enroll their personal devices into a Mobile Device Management (MDM) system using their Managed Apple ID linked to their organization, with minimal intrusion into their personal data and privacy. With the most recently released operating system versions, Apple has discontinued the Profile-based User enrollment of personal devices, where the user enrollment started for the user in the Self Service Portal of Silverback.
The new Account-Driven User Enrollment starts now from the settings application on device, where the user have to enter their Managed Apple ID (e.g. maria.miller@imagoverum.com). Based on the domain portion, the device sends an HTTPS GET request for the URL https://<domain>/.well-known/com.apple.remotemanagement (where <domain> is the extracted domain/FQDN portion of the user identifier). In simple terms, this means that you must publish a file on your web server for your domain so that Apple can reach the service and retrieve enrollment information. This file contains the URL of your Silverback server and must be available for the corresponding device to be enrolled. For example, if your Managed Apple IDs are ending with imagoverum.com, you must ensure that the file is accessible at the following URL:
https://imagoverum.com/.well-known/com.apple.remotemanagement
The file contains your Silverback URL with the appendix /ssp/enrollment/byod and the Version identifier, which must be mdm-byod.
You can download the example file here: com.apple.remotemanagement.json. After the download, open the file with an Text Editor of your choice and modify the BaseURL to your own Silverback URL and save the file. Afterwards, provide the file to your Webserver Administrator and provide the additional information that this file should have the content-type application/json.
When the file is published successfully, the enrollment flow with the Account-Driven User Enrollment is the following:
- The user opens Settings > General > VPN & Device Management > Sign in with to Work or School Account
- The user enters the Managed Apple ID, e.g. maria.miller@imagoverum.com
- The user will be forwarded to the Silverback Self Service Portal to authenticate
- The Username in the Self Service Portal will be taken from the entered Managed Apple ID
- When Identity Providers are configured and Direct Forwarding is enabled , the user will be forwarded to the IdP to enter the username
- After signing in, the ownership will be set to User Enrollment for Apple devices
- The Managed Apple ID will be pre-filled (if configured) automatically or the user has to enter the ID manually
- After pressing Start, the profile will be download automatically and the user needs to Sign In to iCloud with the Managed Apple ID
- After finishing the sign-in process, the user needs to Allow Remote Management and enter their Passcode
- The enrollment will be finished.
![]() |
![]() |
![]() |
Lock down and locate lost company-owned Android Enterprise devices
Millions of devices are lost or stolen each year, which leads to significant risks to data privacy. Next to iOS and iPadOS, Google has introduced the Lost Mode feature with Android 13 which supported exclusively for Android Management API. With Silverback 24.0 Update 3, you can now remotely activate the lost mode for company-owned devices to lock devices and receive their location. From the Actions menu, press Enable Lost Mode and proceed with the following information:
- Message & Phone Number
- Email & Street address
- Company Name (optional)
After the device will receive the command, the device Device will be locked, and all apps are blocked, except:
- The device is not an organization-owned device
- The device is already in lost mode
- The password has been reset within the last 12 hours
- The employee manually exited lost mode in the last 12 hours
- The work profile on the device is paused
From the Alert State, two options are presented:
- This is my device - allows the employee to enter their password and take the device out of lost mode. If this occurs before the 5 minute period ends, no location data is sent from the device.
- I found this device - enables someone other than the employee to stop the device ringing. This moves the device into the lost state.
When the device is in lost state, the location is reported to Silverback and is visible in the Device Information in the Location section.The location is displayed in the form of a link that redirects you to the coordination on Google Maps.
Alert State | Lost State |
---|---|
![]() |
![]() |
This is the first state a device enters when put into lost mode. In this state, the device rings for up to 5 minutes, giving the user an opportunity to find their device and take the device out of lost mode. The location of the device is not reported during this time. | In this state, the device stops ringing and sends location updates every minute. |
Maintenance Option for Single App Mode on Android Enterprise
This release enhances the Single App Mode for Android Enterprise devices by introducing a new Maintenance Mode. This feature provides greater flexibility for both administrators and on-site technicians by enabling:
- Remote Deactivation: Administrators can temporarily disable kiosk mode remotely through a device action in the management console.
- On-Device Deactivation: On-site technicians can directly disable kiosk mode on the device by entering a secure PIN, allowing maintenance tasks to be performed without requiring remote assistance.
This improvement simplifies device management during maintenance while ensuring that security and control are maintained. After upgrading to Silverback 24.0 Update 3, you will find inside the Single App Mode Profile a new Maintenance Mode area to enable the Maintenance Mode, to define a 4-6 Digit PIN and a Maintenance Timeframe in minutes.
Remote Deactivation
A new Suspend Single App Mode action is visible in the Device Overview for all devices, which is active when a Single App Mode profile is assigned to the device. Under More, select Suspend Single App Mode and confirm. This action can be performed even if Maintenance Mode is not enabled in the Single App Mode Profile configuration. In this situation, Companion will perform the action with a default maintenance timeframe of 15 minutes. You can check the execution of the SuspendSingleAppMode command as usual from the Pending Commands view.
On-Site Access to Kiosk Settings in Companion
When devices are running Companion 24.0 Update 3 and Maintenance Mode is enabled and configured, a new menu item in Companion will indicate that the configuration has been applied to the device. Select Kiosk from the Companion menu and enter the required PIN code within 15 seconds. If no PIN is entered, the window will close automatically. From the Kiosk Settings, you can view various information such as the current status, the configured maintenance window, available user interface features, the main application in Single App Mode and additional allowed applications. The Kiosk Settings provides 3 actions that can be performed:
- Open applications: Tap on the application and Companion will open it.
- Suspend Single App Mode: To suspend the Single App for the configured and visible maintenance period, a confirmation pop-up will appear to perform the action.
- Reactivate Single App Mode: To re-enable Single App Mode, a confirmation pop-up will appear to perform the action.
![]() |
![]() |
![]() |
Accessing Kiosk Settings with Hardware Buttons
When devices are running Companion 24.0 Update 3 and Maintenance Mode is enabled and configured, Companion begins to listen for SCREEN_ON events reported by the device. After turning the screen on and off 5 times with no more than 3 seconds in between (including a visible counter starting with 2 repetitions remaining), the PIN code screen will appear. Again, a 15 second counter will indicate the timeframe and if the PIN code is successfully entered, the Companion Kiosk Settings screen will appear with the information and actions explained above.
Wrong Password Attempts
If an unfriendly user tries to have access to the maintenance mode and possibly tries to guess the PIN code, the PIN entry will be automatically blocked for 5 minutes after 5 failed attempts and the Companion application will switch back to the last screen each time. If the device is in this state and you need to access the maintenance mode directly, you can use the Suspend Single App Mode action from the Silverback Management Console to reset the counter and access the maintenance mode.
New Improvements
Please find all new improvements in Silverback 24.0 Update 3 below.
Management Console
- Improved tab padding in the Logs section
- Improved System Variables handling
- Fixed an issue with broken references when cloning a tag containing web clips and deleting the original tag
- Fixed an issue with disappearing x button in device overview after executing a device action
- Fixed an issue with incorrect displayed validations after canceling an device action that was first tried with wrong or missing information
Self Service Portal
- Added copy to clipboard option for Username and One Time Password
Android Enterprise
- Firebase Cloud Messaging Notifications are sent now in chunks up to 500 notifications for FCM
- Updated Google APIs Client Library to 1.68.0.3624
- Updated Google client library to access the Google Cloud Pub/Sub API to 3.19.0
Apple Management
- Added Intelligence as Skip Setup Item for Device Enrollment Program
- Added the following system applications:
- Freeform | com.apple.freeform
- Journal | com.apple.journal
- Passwords | com.apple.Passwords
- Separated the default applications lists for iPod, iPhone, iPad
- Fixed an issue with uninstalling Extensible Single Sign-On Profile
Windows 10/11
- Fixed an issue with pre-assigning ownership/label/visibility flags for Windows 10 and Windows 11 devices
- Fixed an issue with uploading Enterprise Applications that have the same product code but different versions
- Added missing Version mapping between OS Version for Windows 10 22H2, Windows 11 23H2 and 24H2
Microsoft Entra ID
- Removed redundant read async operation with wrong protectionId key that caused Invalid Id: protectionId - Operation ID error while creating App Protection Policies.
Service Bus
- Upgraded Matrix42.ServiceBus.Adapter to 6.8.2
Knowledgebase
The following new Knowledge Base articles has been added:
Known Issues
- It is currently not possible to create App Protection Policies (MAM) via the Silverback Management console. The general creation works, but an error POST error from Graph API with No OData route exists that match template will occur at the latest when integrating applications. We currently suspect that the error is not on our side due to external Graph API tests. In any case, the policies can still be created and configured via the Microsoft Intune Admin Center.