Skip to main content
Matrix42 Self-Service Help Center

Release Notes Silverback 22.0

About This Release

Matrix42 Silverback 22.0 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.

Important Announcements

Changes in Default Installation Folder

Starting with Silverback 22.0, the default Silverback Website Directory Location in the Silverback - Installation Wizard for fresh installations and updates is now set to C:\inetpub\Silverback. In previous versions, the default location was set to C:\Silverback and this is probably the location where you have installed Silverback. During this update, you can now decide if you want to install the Website under your existing location by changing the Silverback Website Directory Location or if you want to install it to the new location under C:\inetpub\Silverback, which ensures by default more restrictive NTFS permissions. According to the standard installation and update routine, the Installation Wizard will first uninstall in any case your existing Silverback installation (e.g., from C:\Silverback) and then re-install Silverback from the scratch under the provided Website Directory Location. This ensures a smooth transition when changing the Website Directory Location from one to another folder. If you decide to install Silverback under the new location, please note that the Installation Wizard will keep several backup files in your previous installation folder and when everything is working as expected after update, you can consider deleting your previous installation folder. If you will update or install Silverback to any other location than under C:\inetpub, please review your NTFS permission

Review your NTFS permissions

In Silverback versions earlier then 22.0, the default installation path for Silverback was C:\Silverback in the installation routine. During the folder creation of Silverback and depending on your security configuration of your Windows Server, the folder permissions for e.g., C:\Silverback were probably inherit from your C:\ folder or similar. Due to this scenario, it might be that local user accounts have been granted by default with write permissions for this folder. This could also happen if you changed the default installation folder to a custom location. To increase your security and ensure that only required permissions are set, please review the permissions granted to your Silverback installation folder as demonstrated in the Application Server Hardening Guide. Starting from this release, the default installation is set to C:\inetpub\, and local users are not granted by default with the NTFS write permissions.

Device Administrator deprecation

According to Google's official announcement, that Android 10 marked the official deprecation of the device admin and as we already updated our Device Policy Controller to API Level 30, we are discontinuing the support for devices with Android 10 and newer that are not running on Android Enterprise. This means that from now on every new device and every device that changes the user, should be enrolled with Android Enterprise.

Windows 10 Mobile deprecation

Microsoft announced in 2016 that Windows 10 Mobile, version 1709 will be the last release of Windows 10 Mobile and Microsoft ended the support already on December 10, 2019. According to our last announcement, we removed now all Windows 10 Mobile related content within this Silverback version. If you have currently Windows 10 Mobile devices under management, these devices will not be visible anymore in the Management Console. All devices will keep their current management profile with the corresponding configuration, but will not receive any updates anymore. We recommend to execute a Delete Business Data or Factory Wipe of your remaining devices, before upgrading your Silverback version. Additionally, all Windows 10 Mobile content from the technical documentation will be removed, soon.

Virtual Private Network Profile for Samsung Knox

As Android Enterprise is the standard for Android and Samsung Knox devices, all Virtual Private Networks can be configured via Managed Configurations. Due to this new standard and according to our last announcement, the Virtual Network Profile for Samsung Knox devices has been removed from the Management Console. Existing profiles will be set to disabled during the upgrade process to Silverback 22.0.

New Features

Windows 10/11 

Please find all new Windows 10 and Windows 11 related features in Silverback 22.0 below.

Custom Terms & Conditions

During Autopilot enrollments or during the Join to Azure Active Directory, users are presented with Terms & Conditions. After entering the credentials, they are required to accept these Terms & Condition which were by default filled with a Matrix42 branded experience. With Silverback 22.0, we are providing now the possibility to customize the Terms & Conditions from the Azure Active Directory section in Silverback. You can now replace the default title, the default description and the Matrix42 logo to your customized one as shown in the following screenshot: 


By pressing the Preview buttons, you can take a sneak peak upfront from your Silverback Management Console to the new User Experience for your users during the enrollment. As of today, the white theme will be shown for Azure Active Directory Joins, when the device will be joined after the out-of-the-box experience and the dark theme during enrollments through the out-of-the-box-experience. Themes are currently not related to Windows 10 or Windows 11, but this might change in the future. For additional information please refer to Windows 10/11 All about Windows Autopilot

New Factory Wipe Options

Windows 10/11 offers multiple options to wipe, and re-provisioning devices and we want to let you participate from all these scenarios. As our previous versions did not support all of them, we are now even happier to share with you multiple new factory wipe options that will increase your flexibility. All of the new factory wipe options can be either executed via the Silverback Management Console or via API calls. By clicking the Factory Wipe button from the Devices section, the following types can now be selected from the additional options section: 

Option Description
Wipe and persist provisioned data Specifies that provisioning packages will be retained during the factory reset.
Wipe protected This option performs a remote wipe on the device and fully cleans the internal drive. The functionally is like basic wipe. But unlike Wipe, which can be easily circumvented by simply power cycling the device, this option will keep trying to reset the device until it’s done.

In some device configurations, this command may leave the device unable to boot.

Wipe and persist user data Will perform a remote reset on the device and persist user accounts and data. Additionally, the device remains enrolled during the factory reset execution and assigned profiles and applications will be re-applied to the device after the factory reset process is finished. 

In addition to the above-described Factory Wipe options, we added also the possibility to use the Autopilot Reset from the Device Overview under Actions. Autopilot Reset works like a usual reset, except that the Autopilot reset keeps the device enrolled in Azure Active Directory and in Silverback. In addition, the Autopilot reset will perform the following:

  • Removes personal files, apps, and settings.
  • Reapplies a device's original settings.
  • Sets the region, language, and keyboard to the original values.

The Windows Autopilot Reset process automatically keeps the following information from the existing device:

  • Wi-Fi connection details.
  • Provisioning packages previously applied to the device.
  • A provisioning package present on a USB drive when the reset process is started.
  • Azure Active Directory device membership and Silverback enrollment information.

By executing a Remote Reset, the current user will receive a notification that the Autopilot Reset is scheduled in 45 Minutes. 10 Minutes before the Autopilot reset will be initiated, users will receive a final notification.

First Notification Final Notification
clipboard_e21f01f3755121aa6402f4add1b678230.png clipboard_eaf8dc4f0298635f1f3ec9b65aeb9abd0.png

During the Autopilot Reset process, the device reports a status to the management system, which is shown between the Device Information and the Assigned Tags section in the Device Overview.  



Please refer to Windows 10/11 All about Windows Autopilot for additional information. 

Require Network Connection in OOBE

During the out-of-the-box-experience on Windows 10 and Windows 11 devices, users might circumvent the Autopilot enrollment by just simply providing no internet connection and creating a local account. To prevent this situation, you can now configure the Require Network in OOBE restriction, which correlates to a UEFI variable that is set to require a network connection. 

As compared in the following screenshots, the I don't have internet option will be shown or not during the out-of-the-box-experience, but the device must be one time enrolled to Silverback to apply this restriction. At the first out-of-the-box-experience, this option will be available and after the Autopilot setup, you can apply the restriction and during the next OOBE, this option will be hidden and kept active for all next OOBE scenarios. 

First OOBE, with the I don't have internet option. After applying the restriction and a factory wipe, the option will be invisible. 
clipboard_ebd67b1d77f6d7008e8716efe1a159d97.png clipboard_e4104b0283759413d052e46fc0912c7a7.png

Your users might have a second option to perform a local account creation and circumvent the Autopilot enrollment. If your Autopilot profile for the device is set to show the account options, users could press at the sign-in page the Account options button and create a local account on the device, so to fully avoid the local account creation, you must set this option to hide. Please refer for additional information to Windows 10/11 All about Windows Autopilot

New Lockdown Policies

Silverback 22.0 offers now new Lockdown policies for Windows 10 and Windows 11 devices. Lockdown policies allows you to configure your own device compliance and the option to define actions that should be automatically executed when a violation is detected. Enabling a lockdown policy ensures that the device is inspected regularly to ensure the compliance from the initial enrollment on due to the device lifecycle. Each policy can be enabled or disabled through their associated checkbox.

Compliance Policies

The following compliance policies can be configured and after enabling the specific policy, you can configure your desired Non-compliance Action and enable if administrators should receive an Alert. Administrators with the enabled Receive Email Alerts checkbox will then receive compliance notifications via e-mails.  

Compliance Policy Device Information Value that is checked Awaited Response
Device Security
Require Secure Boot Secure Boot Status Enabled
Require Encryption Encryption Compliance Encrypted
Require Antivirus Status is on and monitoring Antivirus Status Antivirus is on and monitoring
Require Most Recent Antivirus Signature Version Antivirus Signature Status  The security software reports that it is the most recent version
Require Antispyware Status is good and does not need user attention Antispyware Status The status is good and does not need user attention
Require Most Recent Antispyware Signature Version Antispyware Signature Status The security software reports that it is the most recent version.
Require Firewall is on and monitoring Firewall Status Firewall is on and monitoring
Require Running Virtualization-based Security Virtualization-based Security Status Running
Require Running Local System Authority Credential Guard Local System Authority Credential Guard Status Running
Windows Defender
Require Defender Service is running Defender service is running Yes
Require Non-outdated Signature Signature is outdated No
Require Well initialized device state Current state of the product Well initialized state
Require Clean device state Current state of the device Clean
Require Running Real-time protection Real-time protection is running Yes
Require Running Network protection Network protection is running Yes
Require Enabled Tamper protection Tamper protection feature is enabled Yes
Power Options
Required Minimum Battery level (percentage) Battery Level e.g. 90%
Non-compliance Action

We highly recommend starting at the beginning with the No Action and the enabled Alert Administrators options to get familiar with the behaviour in your environment. Especially be sensitive with selecting any Wipe or the Delete Business Data operation, but anyway the following non-compliance action can be automatically executed at the detection of a mismatch between the awaited response and the last actual response from your devices:

  • No-Action 
  • Lock
  • Block
  • Factory Wipe
  • Wipe and persist user data
  • Delete Business Data 

For the Minimum Battery Level, the only option is to Alert Administrators.  

The trigger for executing policy actions is the Device Information command which starts to compare the Awaited Response with the information received from Get Defender Health Info and Get Security Info. The Audit Interval, which corresponds to the Windows devices inventory intervals for Queue Device Info after (mins) in the Web Settings section and the option to Allow Automated Unblocking can be configured from the Admin section.

In addition, we want to emphasize all customers that currently using a co-managed device setup with Unified Endpoint Management that if the UEM Agent has been installed via Silverback, the scenario is currently not fully covered to re-install the UEM Agent properly. This is especially good to be aware of with the Block or Delete Business Data non-compliance action, as on both states remotely installed applications via Silverback will be uninstalled from the device. Here, we will work on further enhancements in the near future.

Compliance Violations

Compliance Violations will be shown in the Device Overview for the particular device. Red marked violations are the indicator for violations that lead to a blocked device. In email notifications administrators will receive additional information to get an overview about the violated policy, the executed action, user and device information and the reported status that led to the policy violation. The email(s) are sent one time and at the detection point. In addition, devices will be marked in Unified Endpoint Management as non-compliant. 

As for the Autopilot Reset and for Wipe and persist user data factory wipe options, devices may report the Security Info and Defender Health Info during intermediate steps at the re-provisioning process. It may occur that policy violations will be detected during that process. You can avoid this by temporarily removing the device from your compliance tag distribution.


Please find all new macOS related features in Silverback 22.0 below.

Obliteration Behaviour and Bootstrap Tokens

With Silverback 22.0, we are supporting from now on escrowing bootstrap tokens for newly enrolled supervised devices. Escrowing bootstrap tokens is an important piece for further investments in our macOS Management as these bootstrap tokens allows to bring several new features in our upcoming releases. The first feature where we use escrowed bootstrap tokens is to leverage the Erase all Content and Settings option in macOS 12+. This factory wipe method is similar to the experience that you have on iOS and iPadOS devices: a very fast wipe and re-provision process and we can say that we already really enjoyed it during our development phase! As an example, the time from a factory wipe to re-provision the device with the Device Enrollment Program is reduced from several hours (sometimes up to 4h) to only round about 6 minutes!

In general, bootstrap tokens are supported for the following devices:

  • macOS Catalina 10.15, enrolled via Device Enrollment Program 
  • macOS 11 (Big Sur) and later, enrolled as supervised device.

The option to factory wipe macOS devices with t​​​​he Erase all Content and Setting method requires additionally an Apple Silicon Processor or an T2 Security chip, as the Factory Wipe commands uses in this case the Erase All Content and Settings (EACS) instead of the usual Erase Device Command. With Silverback 22.0, the factory wipe action confirmation pop-up will show additional options for the obliteration behaviour. In combination with the Erase Device Command, the obliteration behaviour command acts as a fallback behavior for erasing a device from Silverback and the device will performs pre-flight checks to determine if the device is in a state that allows EACS. Depending on the selected obliteration behaviour, the device either starts or doesn't start to erase itself as highlighted below: 

Obliteration Behaviour Description

If the EACS pre-flight fails, the device responds to Silverback an Error status and then attempts to erase itself. If the EACS pre-flight succeeds but EACS fails, then the device attempts to erase itself.

Do Not Obliterate

If the EACS pre-flight fails, the device responds to Silverback an Error status and doesn’t attempt to erase itself. If the EACS pre-flight succeeds but EACS fails, then the device doesn’t attempt to erase itself.

Obliterate with Warning

If the EACS pre-flight fails, the device responds to Silverback an Acknowledged status and then attempts to erase itself. If EACS pre-flight succeeds but EACS fails, then the device attempts to erase itself.

Providing a PIN might be still required when executing the Factory Wipe options for device that are supporting EACS. If devices are not enrolled via the Device Enrollment Program, they might not report the PIN Required For Erase Device information and in this case, a PIN is required as a backup. If devices are accidently presented with the obliteration behaviour, the device will anyway ignore the command. For API Calls, the PIN and the obliteration behaviour are mandatory. 

To review if the bootstrap token is escrowed to Silverback during the enrollment, you can perform the following on your macOS device afterwards: 

  • Open Terminal
  • Enter the following command
sudo profiles status -type bootstrap token
  • Enter your password and you will receive one of the following answers:
  • Bootstrap Token supported on server: No
  • Bootstrap Token supported on server: Yes
  • Bootstrap Token escrowed to server: Yes

Notification Control

Already two years ago and with Silverback 20.0, we added the option of controlling notifications for applications on iOS and iPadOS devices. This control offered you since the capability to define specific per app notifications on the device for iOS and iPadOS devices and with Silverback 22.0, we are happy to have extended this profile to devices running on macOS 10.15+ and later. Same as for iOS and iPadOS, notifications can be disabled at all or can be permitted to options like Show in Notification Center or Show on Lock Screen. This profile helps you to ensure that your users don't accidentally disable notifications for important applications. To configure the new Notification Settings, navigate to macOS Profiles in a Tag and press New Notification Setting. Now select the App Store Country and start with a search for the app, but custom bundle IDs are also supported. After entering an app name, you receive the choice to select your application. After that, just configure the following notification controls to your needs:

Notification Setting Options Description
Allow Notifications Enabled or Disabled Allows or disallows notifications for this app
Show in Notification Center Enabled or Disabled Allows or disallows notifications to be shown in notification center
Sounds Enabled or Disabled Allows or disallows sounds for this app
Badge App Icon Enabled or Disabled Allows or disallows badges for this app
Show on Lock Screen Enabled or Disabled Allows or disallows notifications shown in the lock screen
Banner Style
  • None
  • Temporary Banner
  • Persistent Banner 
Type of alert for notifications for this app

Bypass Activation Lock

If you are managing supervised iOS and/or iPadOS devices, you may have recognized already the Activation Lock and Bypassing features in Silverback that we have now extended for macOS devices. The Activation Lock feature is in general designed to prevent anyone else from using a device that he does not own. When users add to their devices their personal Apple ID, (with enabling the Find my option) and the device gets lost or stolen and factory wiped, the next user will not be able to activate the device, as it is locked to the owner. With Silverback 22.0, we added the Allow Activation Lock option to the Restriction profile. With this option, you can control the Activation Lock for your managed devices. If you don't want to disable the Activation Lock and users are logging into their Apple ID and enabling the Find My feature, you can now unlock devices with a bypass code that can be exported Admin section > Logs > Activation Lock Bypass Codes.

From the Activation Lock screen in the macOS Recovery, select Recovery Assistant and click on Activate with MDM Key, to enter your exported bypass code for unlocking the device as demonstrated in the video below.

Please review additional information about how to enable, disable Activation Lock and the System Requirements from the official Apple documentation: Activation Lock for Mac. From the system requirements, the Activation Lock is not supported on every device. To prevent of showing errors in the Pending Commands, Silverback will send the Allow Activation Lock setting with escrowing the Bypass codes only under the following conditions:

  • macOS Version must be higher than 10.15 
  • Devices must be supervised
  • Security Information must report that the Activation Lock Manageable

In addition, the Disallow Activation Lock setting will only take affect if the Activation Lock is not already activated on the device. From the device overview of each device, you will find the following useful information about the Activation Lock: 

  • Device Information: Activation Lock Supported
  • Security Information: Activation Lock Enabled
  • Security Information: Activation Lock Manageable

For Allow or Disallow Activation Lock, the configuration is sent to your devices via the Settings command type and the escrowing Bypass Codes is executed within the Activation Lock Bypass Code type, which can be reviewed from the Pending Commands overview. 


Remote Renaming

As we offered you already the remotely rename option for iOS, iPadOS, Android, and Windows 10/11 devices, we wanted to bring this feature as well to macOS to close the gap. With Silverback 22.0, you will now gain the ability to remotely rename macOS devices by opening the device overview and executing the rename option under actions. Additionally, you can upload a *.csv file or add single devices into the Hardware Authentication to pre-define device names. When the Hardware Authentication is used, Silverback will automatically rename the devices according to the configuration. After renaming a device, Silverback will now additionally and automatically query the device information from the device to get the newest device name as soon as possible. This is one improvement that we also added within this release for iOS and iPadOS devices.

For macOS, please note that we extended the device information overview also which brings now three different attributes according to the device name:

  • Device Name (Device Information)
  • Hostname (Network Information)
  • Local Hostname (Network Information)

After renaming the device, the Device Name and the Local Hostname will change and reported immediately and the Hostname requires a reboot. This is especially good to know if you use the Unified User Experience, as there the hostname is displayed as the device name.

By executing a device rename from the actions pane, the device will be automatically added to the Hardware Authentication as the same mechanism is here used for renaming devices. 

New Device Information

At the beginning of this release cycle, we simply wanted to find out the way how we can show the Enable Remote Desktop and Disable Remote Desktop button status accordingly to the device status. During our successful investigation we found several additional device information where we think that they will be interesting for you as an Administrator, too. As a result, we added overall 25 new values in three different sections: 

  • Device Information
  • Security Information
  • Network 
Device Information

In the Device Information you will now find the way of how the device is enrolled into Silverback. Besides the enrollment via the Device Enrollment Program, enrollments where users manually install the MDM profile are shown as User Approved Enrollment. User Enrollment refers to the bring your own devices mode, simply named as User Enrollment.

Information Example Description
Enrolled Via DEP Yes Displays whether the device is enrolled in Silverback through the Device Enrollment Program. This value is available in macOS 10.13.2 and later.
User Approved Enrollment No Displays whether the enrollment was user-approved. This value is available in macOS 10.13.2 and later.
User Enrollment No Displays whether the device is user-enrolled. This value is available in macOS 10.15 and later.
Security Information

The Security Information has been extended with several new categories. These information are specially useful for our upcoming plans to extend the lockdown settings for macOS devices, according to our new compliance policies for Windows 10 and Windows 11 devices from this release. With this release, we extended the device overview with the following new security information:

  • Firewall Settings (Enabled, Stealth Mode, Block all Incoming etc.)
  • Bootstrap Token (Required for Software Update, Kernel Extension Approval etc)
  • Secure Boot (Secure and External Boot Level)
  • Firmware Password (Password exists, ROMs enabled etc.)
  • Miscellaneous (Activation Lock enabled, Recovery Lock enabled, Remote Desktop enabled etc.)
Information Example Description
Firewall Settings
Firewall Enabled Yes Reports if the firewall is on.
Firewall Block All Incoming No If the reported value is yes, the firewall blocks all incoming connections.
Firewall Stealth Mode Yes Displays if the stealth mode is active for the firewall.
Firewall Logging Enabled Yes Displays if logging is enabled for the Firewall.
Firewall Logging Option Throttled Shows the type of logging emitted by the firewall. Possible values are: Throttled, Brief, Detail
Firewall Controlled Applications Show By selecting Show, a pop-up will open the overview of  Firewall controlled applications with their corresponding bundle id and the Allowed status. 
Bootstrap Token
Allowed For Authentication Allowed This value displays whether the Secure Enclave Processor (SEP) supports and allows secure operations to use the Bootstrap Token. The value is automatically set for devices enrolled through the Device Enrollment Program. Users can also manually set this value in the RecoveryOS. This value is available for Apple Silicon devices with macOS 11 and later and is not available for user enrollment. Possible Values are Allowed, Disallowed, Not Supported
Required For Software Update Yes If reported as Yes, the device can accept a Bootstrap Token from Silverback instead of prompting for user authentication prior to installation. This only applies when Allowed For Activation is Allowed. This value is available for Apple Silicon devices in macOS 11 and later and is not available for user enrollment. Please note that the purpose of using Bootstrap Tokens For Software Updates is not yet available in Silverback. 
Required For Kernel Extension Approval Yes If shown as Yes, the device can accept a Bootstrap Token from Silverback instead of prompting for user authentication prior to enabling kernel extensions or rebuilding the Kernel Cache during a remote restart. This only applies when Allowed For Activation is Allowed. This value is available for Apple silicon in macOS 11 and later and is not available for user enrollment. Please note that the purpose of using Bootstrap Tokens For Software Updates is not yet available in Silverback. 
Secure Boot
Secure Boot Level Medium Displays the security level for the bootable operating system versions. Possible values are: Off, Medium, Full, Not Supported
External Boot Level Allowed Displays the device’s external boot level, which indicates whether it allows booting from an external device. Possible values are: Allowed, Disallowed, Not Supported
Firmware Password
EFI Firmware Password Exists - Displays if the device has an EFI firmware password. This information will only be reported by non-Apple Silicon devices.
EFI Firmware Password ROMs Enabled - According to Apple's documentation is show "If Yes, enable ROMs." This information will only be reported by non-Apple Silicon devices
EFI Firmware Password Change Pending - If Yes, a firmware password change is pending. A device restart is necessary for this change to take effect. Until then, additional attempts to change the password fail. This information will only be reported by non-Apple Silicon devices
Additional Information
Activation Lock Enabled No Determines the key if Activation Lock is in an enabled state on the device. This value is available in macOS 10.9 and later.
Activation Lock Manageable Yes When the Activation Lock is manageable, the type of enrollment allows the Silverback to manage Activation Lock for this device. This value is available in macOS 10.15 and later.
Recovery Lock Enabled No Determines if a password is required to enter recovery. Available in macOS 11.5 and later and only on Apple Silicon devices.
Remote Desktop Enabled Yes Displays if Remote Desktop is active on the device and controls the availability for the actions Enable and Disable Remote Desktop for the particular device. This value is available in macOS 10.14.4 and later.
System Integrity Protection Enabled Yes Reports if the System Integrity Protection (SIP) is active on the device. This value is available in macOS 10.12 and later.
Authenticated Root Volume Enabled Yes Indicates whether the system booted using an Authenticated Root Volume. This value is available in macOS 11 and later.
Network Information

Within the Network Information section, you will find now two new information. Additionally, we moved IP Address, Bluetooth MAC, and WiFi MAC from the Device Information section to the Network Information. 

Information Example Description
Hostname Tim Displays the hostname. This value is available in macOS 10.11 and later.
Local Hostname TimTober-MacBookPro Displays the local hostname from Bonjour. This value is available in macOS 10.11 and later.

iOS, iPadOS, tvOS

Please find all new iOS, iPadOS, and tvOS related features in Silverback 22.0 below.

WPA3 Support and additional Settings for iOS and iPadOS Wi-Fi

At the starting point of this feature, we wanted to bring the WPA3 support for Wi-Fi Profiles. As WPA3 represents the latest generation in mainstream security for wireless networks, it is an important upgrade that we wanted to deliver. During the development it turned out that we can improve several areas of the Wi-Fi Profile at all and at the end we decided to provide you a 100% set of Wi-Fi features that iOS and iPadOS devices supports nowadays. This includes the following improvements and new features for Wi-Fi Profiles: 

Improvement Additional Information
New Layout for Wi-Fi Profiles
  • Applied to all Platforms
New Security Types
  • WPA2 Personal and WPA2 Enterprise (iOS 8 or later)
  • WPA3 Personal and WPA3 Enterprise (iOS 13 or later)
New Protocol Support
  • EAP-AKA support
New protocol dependent options
  • Added TLS Minimum and Maximum Version for TLS, TTLS, PEAP, EAP-Fast
  • Added OS Default and EAP as Inner Authentication option for TTLS
  • Added Allow Two RANDs option for EAP-SIM
  • Added Option to Enter static Username and Password for Authentication on LEAP, TTLS, PEAP, EAP-Fast
New Proxy Options
  • Added Allow Direct Connection if PAC is Unreachable option for Proxy Type Auto
Updated Dependencies
  • Protected Access Credentials (PAC) is now visible only for EAP-Fast
  • Trust Exceptions has been removed for WPA2 and WPA3 Enterprise due to its deprecation
  • Removed Option to enter Password for Enterprise Security Types
Hotspot 2.0 support
  • Allows to configure the network as a Passpoint (Hotspot 2.0) with Provider Information, Roaming Consortium OIs, NAI Realm Name and MCC and MNCs. 
Fast Line QoS Marking Support
  • Allows to define prioritize network traffic with QoS options for Cisco Networks for applications like Apple Audio and Video Calls or any other application.

In general, we expect now that the configuration of Wi-Fi profiles is more comfortable and more straight forward for you. For additional information, please refer to our Knowledge Base article about WPA Enterprise Settings for all WPA Enterprise related settings.

Clear your browser cache after updating to ensure the new Wi-Fi profile design will be shown accordingly. 

Application Lock for tvOS

In this release, we extended another existing profile to another applicable platform, the Application Lock for tvOS devices. With the application lock profile, you can turn the device into a device that runs only one application. This feature is very useful in demonstration areas like promotion shops or roadshows to let users only use one specific application. Within the Application Lock profile, you can setup your desired App Identifier (Bundle ID) with additional options to Disable Touch (touch surface on the Apple TV Remote), Disable Auto Lock and Enable Voice Over. Upon receiving the profile, the home button is in a disabled state, and the device returns to the app automatically upon wake or restart. The feature is supported on supervised tvOS devices running version 10.2+.

Setting Options Description
Application Lock Enabled or Disabled Enables the Application Lock profile
App Identifier e.g., Enter here the bundle id for the application that should run in the Single App Mode. 
Disable Touch Enabled or Disabled Disables the touch surface on the Apple TV Remote.
Disable Auto Lock Enabled or Disabled Controls if the device doesn't automatically go to sleep after an idle period.
Enable Voice Over Enabled or Disabled Enables or Disables Voice Over.

Android Enterprise

Please find all new Android Enterprise related features in Silverback 22.0 below.

Security Settings during Setup Wizard

For Android and Samsung Knox Device Owner enrollments, we made a slight change in the enrollment process. After the authentication process is performed in the Companion application, Silverback will send directly the restriction profile to the devices, before processing the enrollment within the Setup Wizard. The idea behind this change is to limit the potential vectors of attacks on devices that are not yet fully protected during the enrollment. With this change, devices will now be configured with important policy compliance settings during the Setup Wizard of Android and will be protected as soon as possible with a configured and applied restrictions profile. If as an example, screenshots are disabled within the restrictions profile, screenshots are already prevented at the All Set! screen, which part of the Setup Wizard that is available for newer devices. For older devices, the restriction profile will be applied independent from the Setup Wizard capabilities of the device. 

Screenshot_20220615-171041_framed.png Screenshot_20220615-171142_framed.png Screenshot_20220615-171158_framed.png
First, users are presented with the Activating Device and the Register to cloud messaging indicator At the Applying security settings point, restrictions will be applied on the device At the All Set! screen, the device is already secured and users can finish the enrollment with opening the Companion

Control Factory Reset Protection

In general, the Factory Reset Protection is a security feature on Android and Samsung Knox devices running on Android 5 and newer. It was designed to make sure that someone is not able wipe and factory reset a phone that is lost or stolen. 

If a user adds to their devices one or multiple Google Accounts, the Factory Reset Protection is active and when the devices go though an untrusted factory reset, the next user for the device needs either to enter one of the previously added Google Account or use the last known Passcode or PIN on the device to unlock the device. As this scenario is very useful for private used devices, it might lead to a scenario where a user in your organization is using a managed device with a personal Google Account and will leave your company for any reason. In this scenario, you will probably wipe the device from the Management Console and hand the device over to the next user. As the remote wipe from the Management Console is a method, that is considered as untrusted, the next user would need (one of) the previous Google Account credentials to unlock the device. Without having this account or at least the last used Passcode/PIN, the device can't be used anymore as it is locked.

With the Factory Reset Protection configuration in Silverback, we are offering two ways to prevent this scenario in the future. You can choose if you want to disable the Factory Reset protection on managed devices or to determine which account can unlock the device, like a master account that is capable to unlock the device after an untrusted factory reset has been performed. Please refer to Factory Reset Protection and Bypassing for Android and Samsung Knox for additional information.

New Improvements

Please find all new Improvements in Silverback 22.0 below.

Management Console

  • Added ~ 150 new device models
  • Renamed and aligned several LDAP Attributes and local users attributes
  • Renamed and aligned several profile configuration success messages
  • Fixed a typo and improved the hyperlink on the Service Unavailable site
  • Fixed the font color of the Submit button on the Activation page
  • Disabled AET Token Expiration Warning
  • Disabled Virtual Private Network Profile for Samsung Knox and Cisco AnyConnect
  • Fixed an Issue with Provisioning via Self Service Portal for LDAP Type Domino
  • Removed dependency for Provisioning Users and administrative groups for LDAP Type Domino
  • Fixed an issue with cloning System Tags and improved the pre-populated new Tag name
  • Fixed, improved and translated several validations for not entered settings in Web Settings
  • Reworked design for Pending Commands, Export & Import, and SMS Server section in Web Settings


  • Removed OS X from User Information submenu in Device Overview
  • Created new Network Information section with Hostname, Local Hostname, IP Address, Bluetooth MAC, and WiFi MAC information
  • Enable and Disable Remote Desktop action is now active or inactive based on the reported Remote Desktop Enabled Security Information
  • Fixed an issue with installing VPP Applications in Device Only or Device Preferred mode
  • Device information (e.g.: PIN Required For Device Lock) is now showing all queried values, even if they are reported empty
  • Added EAP-AKA as accepted EAP Types into Wi-Fi Profiles
  • Added Allow Direct Connection if PAC is Unreachable option to Wi-Fi Profiles
  • Added Allow Two Rands option for EAP-SIM option to Wi-Fi Profiles

iOS, iPadOS

  • Fixed an issue for the Allow Uninstallation option for Enterprise applications
  • Improved alignment of Lock and Home Screen settings in the Wallpaper profile
  • Added new enrollment endpoint for supporting Shared iPad enrollments in the future 
  • After renaming a device, the device will now instantly get a request to provide new device information
  • In addition to that, for devices with a disabled Allow Changing Device Name restriction, the following improvements are made:
    • Rename (supervised devices) action will be disabled
    • Device Name changes in the Hardware Authentication will be ignored


  • Added Allow Direct Connection if PAC is Unreachable option to Wi-Fi Profiles
  • Added Allow Two Rands option for EAP-SIM option to Wi-Fi Profiles

Android Enterprise

  • Fixed the not showing additional message for the Clear Passcode option on Samsung Knox devices
  • Fixed and improved the Global HTTP Proxy profile for Samsung Knox devices
  • Added handling of empty Subject Alternative Names for Certificate Profiles
  • Installed Application List will now not be queued daily again if the previous Installed Application List command is in Pending
  • Improved formatting of Managed Configuration field types and improved .json document parsing 
  • Allow Bluetooth restriction for Samsung Knox is now disabling Bluetooth and prevents user from enabling it. Previously it was a one time deactivation after every check-in. 
  • Fixed an issue with the visibility and sending of nested restrictions. E.g, now when the parent restriction for Allow SMS is disabled, the nested Enable Incoming/Outgoing SMS restrictions will be disabled, too. 

Windows 10/11

  • Added missing configurations and re-ordered several configurations in Resultant Tags
  • Added Windows 11 22H2 build versions 
  • The {DeviceDesc} variable in Email Templates reports now the Platform followed by the Model Description under Device Types.

Enterprise Service Bus

  • Added support of new factory wipe options and additional device actions
  • Added support for sending device locations
  • Updated Service Bus Message Model to version 6.16.5


  • Processing other settings is now showing more details about which change will be applied
  • Changed and improved several translations for processed commands
  • Added grace period with 30 minutes for SafetyNet checks instead of checking it at every device refresh
  • Restrictions profile will now be processed at the beginning while device enrollment
  • Added identity certificate to certificate list for Samsung Knox devices
  • Improved and fixed installing/removing enterprise apps via user dialog
  • Added Keyence Browser and Scannertest to the enabled system application list 
  • Changed icon and description for Global HTTP Proxy profile

Security Improvements

  • Increased Password Policy for administrative accounts 
  • Added server-side validation for administrative account passwords generation
  • Added checks during password creation for containing phrases that are easy to guess
  • Added HTML encoding of several symbols in flexigrids
  • Added Anti CSRF tokens for Admin and Self-Service Portal
  • Added SameSite flags with lax attribute to cookies for Admin and Self-Service Portal
  • Changed default Silverback installation path to C:\inetpub\Silverback
  • Changed default Silversync installation path to C:\inetpub\Silversync
  • Added Client Authentication as Enhanced Key Usage to device identity certificates
  • Added Digital Signature and Key Encipherment as Key Usage to device identity certificates
  • Added same server response enforcement in the Android activation endpoint
  • Fixed an issue with the account lockout feature for administrative accounts


  • Deprecated System Tags for Windows 10 Mobile and Windows Phone are not longer sent via API or Service Bus
  • Removed Tool tips from System Extensions, Kernel Extensions, and Software Updates profiles in Resultant Tags
  • Default configuration for the Allow Parent Profile Apps Linking Restriction has been set to disabled according to Google's reference
  • Changed platform device type for 10 device models from Samsung Knox to Android according to Devices Secured by Knox
    • Galaxy A02, A02s, A10s, A11, A20s, A22 5G, 
    • Galaxy F52 5G
    • Galaxy J3
    • Galaxy M21 2021, M31
  • Changed whitelist and blacklist restriction for applications to allowed and denied list restriction payload on tvOS
  • Changed default Silverback installation path to C:\inetpub\Silverback
  • Changed default Silversync installation path to C:\inetpub\Silversync
  • Changed several validations from browser alerts to Silverback alerts
  • Renamed TTLS Identity to Inner Authentication for Wi-Fi Profiles on Apple devices

Known Issues 

  • The Audit Interval for Windows devices might not work properly
  • Was this article helpful?