About This Release

Matrix42 Silverback 26.2 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 Preview
• Download: Marketplace 
• Initial Build Version: 26.2.0.9

Important Announcements

Prepare your network environment for stricter security requirements

Starting with iOS 27, iPadOS 27, macOS 27, and tvOS 27, Apple operating systems may refuse connections to servers with outdated or non-compliant TLS configurations. These requirements apply to Apple device management related services, including MDM, Declarative Device Management (DDM), Automated Device Enrollment (ADE), configuration profile distribution, application deployment, and software updates. Silverback installations hardened using the provided Silverback Hardening Script already meet the minimum TLS protocol requirements announced by Apple, including TLS 1.2 support. Additionally, Silverback has supported TLS 1.3 since version 26.1. 

Administrators should nevertheless review their overall certificate and web server configuration to ensure compliance with Apple's forthcoming network security requirements. Silverback supports TLS 1.3 starting with version 26.1, while the Silverback Hardening Script configures TLS 1.2 as the minimum supported protocol. For Silverback Cloud customers, no action is required. For On-Premises installations, administrators should review their web server and certificate configuration to ensure compliance with Apple's announced requirements. In particular, organizations should verify that:

• Servers must support TLS 1.2 or later,
• Use ATS-compliant ciphersuites
• And present valid certificates that meet ATS standards

For complete network security requirements, reference the developer documentation: Prepare your network environment for stricter security requirements

Reminder for Code Signing Certificate Provider Change

Starting with Silverback 26.1, 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. Since Silverback 26.1, 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

• Declarative Device Management for Apple Software Updates
• New Android NFC Onboarding Method 
• New Android Enterprise Connectivity Restrictions
• Credential Manager Support for Companion
• Value Collections for Tag Assignments
• System User Management API with Granular Scopes
• Extended SIM Information in Device Details API

New Improvements and Changes

• Management Console
  • Gradual Push Delivery and Push Processing Optimizations
  • Configurable Syslog Settings
  • Improved Browser Handling for Password Fields
• Android Enterprise
  • Application Feedback Availability for Enterprise Apps
  • Managed Accounts and Work Profile Protection for Non-GMS Devices
  • Dedicated Support for 320x240 Android Devices
• Android Management API
  • Enhanced Android Management API Enterprise Information
• Apple Device Management
  • Restored Passcode Complexity Configuration
  • Restored IMEI Visibility and Searchability 
  • Improved macOS Enrollment Reliability
  • Enhanced Apple Business Manager Token Diagnostics

New Features

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

Declarative Device Management for Apple Software Updates

Apple is transitioning from traditional command-based Mobile Device Management (MDM) to Declarative Device Management (DDM), a modern management framework that allows devices to autonomously maintain their desired state. Instead of continuously sending commands to managed devices, administrators define a desired configuration through declarations. The device evaluates these declarations locally, applies the required changes, and proactively reports status updates back to the management server. This significantly reduces communication overhead, improves reliability, and enables a more responsive management experience. 

With Silverback 26.2, support for Apple's Declarative Device Management has been introduced, providing the foundation for future Apple management capabilities. As part of this release, all Apple Software Update management capabilities for iOS, iPadOS, and macOS have been migrated to the declarative framework. Existing Software Update Tag configurations continue to work as expected while leveraging Apple's modern management architecture.

This release introduces a new DDM Managed Information and a DDM Details Action that provides visibility into the declarative configuration assigned to a device and the capabilities reported by the operating system. This information can be used to validate DDM deployments, troubleshoot configuration issues, and verify which declarative features are supported by a managed device.

After opening the DDM Details, you will see the following information:

• Status Subscriptions: Displays which device status information is automatically reported back to Silverback.
• Device Declarations: Displays the Declarative Device Management (DDM) configurations assigned to the device.
• Reported Client Capabilities: Displays the DDM features, payloads, and declaration types supported by the device.

You can also monitor DDM activities in the Pending Commands view. DDM commands are used to synchronize declarations between Silverback and managed Apple devices. Unlike traditional MDM commands, these requests do not directly execute an action on the device. Instead, they deliver, update, or remove declarations that define the desired device state. The device evaluates these declarations locally and reports the results back to Silverback.

In addition, you can control DDM activation for new and existing enrollments, configure diagnostic logging, and define software update specific behaviors such as enforcement grace periods and informational URLs presented during update workflows.

This transition ensures compatibility with Apple's latest platform requirements and prepares Silverback for future Apple management capabilities. Additional configurations and payloads will gradually be migrated to Declarative Device Management in upcoming releases as Apple continues its transition towards this framework.

New Android NFC Onboarding Method 

Companion 26.2 introduces an on-board NFC-based enrollment, providing an additional and streamlined onboarding method for Android devices equipped with NFC capabilities. This feature was primarily designed for specialized Android devices, ruggedized hardware, and non-GMS deployments where the Companion application is often pre-installed and traditional enrollment methods may not be practical. In particular, some devices do not include an integrated camera, making QR code based enrollment difficult or impossible. Other devices rely on hardware buttons and compact form factors where minimizing manual input is essential.

To address these scenarios, Companion now supports reading enrollment information directly from an NFC tag. 

Administrators can prepare NFC tags using common NFC writing tools and store the enrollment information required by Companion. When the user selects Scan NFC Tag during the enrollment process, Companion reads the information from the tag, automatically populates the enrollment fields, and immediately initiates the enrollment workflow. A typical NFC payload contains the Silverback server address, username, and one-time password (OTP), for example:

{
"server_url":"https://silverback.imagoverum.com",
"username":"staging@imagoverum.com",
"otp":"424242"
}

This approach significantly reduces manual input, minimizes enrollment errors, and accelerates device provisioning in environments where large numbers of devices must be enrolled quickly. Please note that the Scan NFC Tag option is only displayed on devices that support NFC and have NFC capabilities available to Companion. On devices without NFC hardware, the option is automatically hidden.Similarly, the Scan QR Code option is only displayed on devices with an available camera.

New Android Enterprise Connectivity Restrictions

Silverback 26.2 adds support for two new Android Enterprise restrictions introduced by Google for Android 16 / API Level 36:

• Disallow Thread Network: Prevents users from enabling or modifying Thread network connectivity on managed device owner devices. 
• Disallow NFC State Changes: Prevents users from changing the Near Field Communication (NFC) state through device settings. The restriction applies globally on the device and will not allow Near-field communication state being changed.

These restrictions can be applied to supported Android Enterprise deployments, providing administrators with additional control over device connectivity features and helping organizations meet specific security and compliance requirements.

Credential Manager Support for Companion

In Silverback 26.1, support for Android's Credential Manager was introduced for Android Management API (AMAPI) deployments. With Silverback 26.2, the same functionality is now available for Companion-managed devices, enabling on-premises and non-cloud environments to benefit from the feature as well. The Credential Manager configuration is available for Device Owner and Work Profile deployments running Android 14 or later. Administrators can define how credential manager applications are handled, choose a default policy, and maintain an allowlist of approved credential manager applications. This allows organizations to control which applications can provide and manage user credentials on corporate devices, helping to improve security and compliance while ensuring a consistent user authentication experience across managed Android environments.

Once successfully applied to the device, a new Credential Manager profile entry will appear in the Companion profile view. Using the three-dot menu, users can review the configured allowed package names. Under Settings > Passwords, Passkeys & Accounts, users will only be able to select credential provider services that have been explicitly allowed by the applied policy. Any credential provider applications not included in the allowlist will not be available for selection.

Note: Credential Manager support depends on the device manufacturer, Android version, available credential provider applications, and device-specific implementation details. During validation, successful policy enforcement was observed on selected Android 15 devices, while other Android 14 and Android 15 devices did not consistently expose the expected behavior. Additional vendor-specific validation may be required before broad deployment. When configuring restrictive Credential Manager policies such as Only allow system credential providers, administrators should verify the actual behavior on the target device model and Android version, as credential provider classification may vary depending on how the component is delivered and updated. You can check applied configurations with adb shell dumpsys device_policy and look for the following example entries:

credentialManagerPolicy:
        policyType=3
        packageNames:
          com.callpod.android_apps.keeper

Value Collections for Tag Assignments

This release introduces Value Collections, a new capability to simplify and scale tag assignment based on predefined datasets. With Value Collections, administrators can define reusable lists of attribute values (such as IMEI, Serial Number, Email, or User Name) and use them as part of Tag Auto Assignment rules. This enables efficient assignment scenarios for large or externally managed datasets without requiring complex rule configurations or manual input.
Value Collections can be populated manually or via CSV import, allowing easy integration of existing device or user inventories into Silverback.
When referenced in tags, devices or users are automatically assigned based on matching attribute values, ensuring deterministic and reliable assignment behavior. Additionally, Value Collections are centrally managed and reusable across multiple tags, improving maintainability and reducing duplication in configuration.

System User Management API with Granular Scopes

With this release, Silverback extends its existing API capabilities to support system user lifecycle operations together with a more granular configuration of action‑based permissions. These capabilities were primarily designed to support integration scenarios with Privileged Access Management (PAM) solutions and other automation systems. The API now enables automation of Create, Read, Update, and Delete (CRUD) operations for system users, including password rotation, allowing secure integration into user lifecycle and credential management workflows. 

At the same time, the existing “Global Actions” scope has been refined into granular, explicitly selectable permissions. Instead of granting broad action access, API tokens can now be configured to allow only specific operations, such as:

• Tag assignment
• Device actions
• System user management
• System user password rotation

API requests are validated against these scoped permissions, and actions are logged for auditing purposes. Additional API endpoints are available to retrieve valid values for roles, cultures, time zones, and date formats. These endpoints help ensure correct input when creating or updating system users. 

To simplify API integrations, Silverback now also displays the unique API Identifier for each system user directly within the Management Console under the System Users section. This identifier can be used when working with the new System User API endpoints and helps administrators easily correlate user accounts between the user interface and automated integrations. 

The complete list of available System User API endpoints is available through the built-in API documentation, accessible under your Silverback URL, for example:

https://silverback.imagoverum.com/api/help

The system user API capabilities are governed by a dedicated functional permission model designed to prevent misuse and unintended privilege escalation. For detailed information about, supported operations, permission requirements, security restrictions, and API token behavior, please refer to the following Knowledge Base article: System User Management API with Granular Scopes 

Extended SIM Information in Device Details API

Silverback 26.2 extends the Device Details API to expose additional SIM-related information reported by managed devices.

The endpoints:

GET /api/v1/devices?page={page}&details={details}
GET /api/v1/devices/{id}?details=true

now includes information for both SIM Slot 1 and SIM Slot 2, when available on the device and reported to Silverback. Depending on the device platform, operating system, and available carrier information, the API response may include attributes such as:

• ICCID
• EID
• IMEI
• Phone Number
• Carrier Information
• MCC / MNC
• Roaming Status
• Preferred Voice and Data SIM
• Carrier Settings Version

To ensure a flexible and future-proof API design, only values that are actually available for a device are returned in the response payload.

This enhancement improves integration capabilities for inventory management, telecommunications management, asset tracking, and automation scenarios that require detailed SIM and cellular subscription information.

Special Use Cases (non public)

During this release cycle, we implemented two special use cases to support unique integration and operational requirements. As these implementations address dedicated customer use cases, they are not available as standard functionality for all customers.

External Identity Synchronization

Added support for integrating external authentication applications with Companion and Silverback. Authentication information provided by third-party applications can now be processed, enriched with device-specific information, and forwarded to backend systems through Silverback, enabling automated user synchronization. To provide traceability and auditing capabilities, all backend synchronization requests initiated by Silverback are recorded in Syslog.

SMS Provider Integration

Added support for a custom SMS provider integration. Silverback can now route SMS messages through the configured external SMS service, supporting customer-specific authentication and notification requirements. To activate the MSEGAT SMS provider in Websettings (App Portal and SMS), run the following query against the Silverback database:

IF NOT EXISTS (SELECT *
FROM dbo.WebSettings
WHERE [Key] = 'Sms_Msegat_Enabled')
BEGIN
  INSERT INTO dbo.WebSettings ([Key],[Value])
  VALUES (N'Sms_Msegat_Enabled' , N'True')
END
GO

If the key is already present due to the installation of an intermediate build, run the following query:

UPDATE dbo.WebSettings
SET [Value] = 'True'
WHERE [Key] = 'Sms_Msegat_Enabled'

After restarting the IIS, the MSEGAT provider can be selected and configured with the required User Name, API Key and User Sender. 

New Improvements

Please find all new improvements in Silverback 26.2 below.

Management Console

Gradual Push Delivery and Push Processing Optimizations

Silverback 26.2 introduces a new Gradual Push Delivery mechanism designed to improve scalability and reduce infrastructure load in large environments. Previously, certain administrative actions could trigger immediate push notifications to all affected devices, causing large numbers of devices to check in at the same time. While this behavior was acceptable for smaller and medium deployments, it could create substantial load spikes in environments managing thousands of devices.

As part of this enhancement, saving profile, policy, or tag content changes no longer automatically generates tag-wide push notifications. Configuration changes are now stored immediately, while devices retrieve updated information during a their normal check-in cycle or through an administrator-initiated push operation. This prevents repeated push waves while administrators perform multiple related configuration changes. This also reduces the impact of unintended configuration changes, particularly in large or auto-populated tags, where a single modification previously had the potential to trigger immediate notifications for all assigned devices.

The Push to Devices action remains available and continues to provide administrators with a way to request an immediate device check-in. However, instead of notifying all devices simultaneously, Silverback now creates scheduled batches which are processed gradually in the background.

Batch Processing Logic

For Apple and Android devices, Silverback currently applies the following batching strategy for manual Push to Devices operations:

• Target sizing: approximately 15 batches per platform group
• Minimum batch size: 30 devices
• Maximum batch size: 1,000 devices
• Batch interval: 1 minute
• Apple and Android devices are processed independently

Windows device push processing continues to use its existing dedicated delivery path and is not part of the Apple and Android batching mechanism introduced in this release.

Examples:

The new implementation also includes several scalability improvements:

• Reduced push bursts and server load during large-scale operations
• Elimination of automatic tag-wide push notifications after profile and policy modifications
• Optimized device assignment processing for large tags
• Improved Apple Push Notification Service (APNS) request handling and concurrency management.
• Reduced database and background processing overhead during large-scale operations.
• More efficient handling of inventory-related push activities.

Syslog Configuration via Settings Administrator

We improved the configuration of Syslog export for security and audit events by introducing a dedicated configuration section within the Settings Admin area. Previously, Syslog forwarding had to be configured manually via application settings on the IIS sites (/admin and /sts). As a result, configurations were not persistent and needed to be re‑applied after updates. With this improvement, on-premise administrators can now manage Syslog settings directly within Silverback, enabling a centralized and persistent configuration experience. The new configuration interface allows administrators to:

• The transport protocol (UDP, TCP, TLS) including the Syslog server endpoint (Server URL) 
• Optional TLS certificate settings for secure transmission

This enhancement simplifies setup, reduces operational overhead, and ensures that Syslog configurations remain intact across updates.

Improved Browser Handling for Password Fields

We enhanced the handling of password fields throughout the Management Console by explicitly identifying credential creation and password update scenarios for modern browsers and password managers. This improvement builds upon the security enhancement introduced in Silverback 26.0.1.21, which reduced unwanted browser auto-completion behavior for password and one-time-password fields. With this release, additional password entry forms across Silverback have been updated to ensure a more secure and consistent credential management experience. These changes help prevent browsers from suggesting or populating unrelated stored credentials when administrators create or modify passwords, certificates, provisioning settings, and other credential-related configurations.

Android Enterprise 

Application Feedback (Bird’s Eye View) Availability for Enterprise Apps

We extended the existing Application Feedback “Bird’s Eye View” capability to also support Enterprise Apps (APK). Previously, summarized application feedback was only available for applications distributed via Managed Google Play. With this improvement, Silverback now also collects and displays feedback from Enterprise Apps, provided that the application supports the Android managed configuration feedback channel.
As a result, administrators can now access aggregated feedback information across all devices for both:

• Managed Google Play applications
• Enterprise Apps (APK)

The Bird’s Eye View in the App Portal is automatically available for Enterprise Apps as soon as feedback is received, providing the same centralized visibility into configuration status, issues, and device‑level details. This enhancement ensures consistent monitoring and troubleshooting capabilities across different app distribution methods.

Managed Accounts and Work Profile Protection for Non-GMS Devices

In previous releases, Managed Google Account and Work profiles could be assigned to non-GMS devices, even though these devices are unable to process Google account related functionality. With this release, Silverback automatically prevents these configurations from being distributed to unsupported devices. This enhancement helps avoiding unintended tag assignments, reduces configuration errors, and ensures that Managed Google Account settings are only deployed to compatible Android devices.

Dedicated Support for 320x240 Android Devices

Companion 26.2 introduces a dedicated user experience for ultra-compact Android devices with display resolutions as low as 320x240 pixels. The user interface has been optimized across the enrollment workflow and core device management screens to ensure improved usability on devices with limited screen space. Layouts, dialogs, input fields, and action buttons have been adjusted to prevent clipping, overlap, and rendering issues on supported small-screen devices. In addition, navigation has been enhanced to support devices that primarily rely on hardware buttons. These improvements ensure that enrollment, status visibility, and essential device management functions remain fully accessible on ruggedized, specialized, and ultra-compact Android devices.

Android Management API

Enhanced Android Management API Enterprise Information

This release extends the Android Management API (Android Management) administration page with additional enterprise information retrieved directly from Google. These enhancements improve visibility into Android Enterprise configurations and prepare Silverback for upcoming Google-managed enterprise upgrade scenarios and future Android Enterprise certification requirements. As an Administrators, you can now review the following additional enterprise properties:

• Enterprise Type: The Enterprise Type identifies the Android Enterprise binding model currently used by the organization. This information helps administrators understand whether the enterprise is based on a legacy Managed Google Play Accounts configuration or a Managed Google Domain configuration. Google increasingly recommends Managed Google Domain enterprises as the preferred Android Enterprise management model.
• Managed Google Domain Type: The Managed Google Domain Type provides additional information about the associated Google-managed organization. This helps administrators better understand the enterprise configuration and its relationship to Google's identity and management services.
• Google Authentication Required: This value indicates whether Google authentication is required for the enterprise configuration. Administrators can use this information when validating Android Enterprise enrollment and account-related management scenarios.

In addition, a new Sync action has been added to refresh enterprise metadata from Google. This allows administrators to retrieve the latest enterprise information and ensure that changes performed within Google services are reflected within Silverback. Google recommends EMM solutions maintain up-to-date enterprise information and react to enterprise binding changes.

Apple Device Management

Restored Passcode Complexity Configuration

A user interface issue affecting Apple Passcode profiles has been resolved. The Minimum Complex characters setting is now displayed correctly and can once again be configured within the Passcode policy settings. This setting defines the minimum number of non-alphanumeric characters, such as &, %, $, or #, that must be included in a device passcode and is supported on iOS, iPadOS, and macOS devices.

Restored IMEI Visibility and Searchability 

Apple no longer provides the IMEI value through the Device Information payload on recent iOS and iPadOS versions. As a result, the IMEI field was no longer populated in the Devices overview within the Silverback Management Console, preventing administrators from searching for devices by IMEI. The IMEI information itself remained available in the individual device details, as it is still provided through the device's Service Subscriptions information. With this release, Silverback automatically populates the IMEI field in the device inventory using the first available IMEI retrieved from the Service Subscriptions data. This restores IMEI visibility within the Devices overview and re-enables device searches based on IMEI values for supported Apple devices.

Improved macOS Enrollment Reliability

We resolved an issue that could cause macOS devices to remain in a Blocked state after enrollment when profile processing was interrupted during device-to-user channel transitions. Silverback now automatically detects and recovers missing profile processing commands, ensuring that remaining profiles are delivered successfully and enrolled devices can complete the enrollment process without requiring a manual refresh action.

Enhanced Apple Business Manager Token Diagnostics

In a small number of customer environments, DEP token imports may fail unexpectedly despite valid token files and successful validation during testing. Analysis of affected environments indicates that token information can be processed successfully when manually extracted and written directly into the database, suggesting that environmental factors may influence the upload or token processing workflow. To assist with root cause analysis, a new diagnostic setting has been introduced in the WebSettings table. When enabled, Silverback records highly verbose diagnostic information covering the complete DEP token upload and import workflow. This includes detailed logging of each processing step, validation stage, token handling operation, and the associated communication with Apple's enrollment services, concluding with the final request to endpoint (https://mdmenrollment.apple.com/session) and the corresponding response data returned by Apple. The additional logging is intended exclusively for troubleshooting and support scenarios and can help identify processing failures occurring during token upload, parsing, persistence, or synchronization operations. 

To enable OAuth verbose logging, execute the following query against the Silverback database and restart IIS on the Silverback server:

 UPDATE dbo.WebSettings SET [Value] = N'True' WHERE [Key] = N'SimpleEnrollmentOAuthVerboseLoggingEnabled';

After enabling verbose logging, upload the new DEP token and review the generated DEP log entries under: e.g. https://silverback.imagoverum.com/sts/logs#depLogs

To disable OAuth verbose logging, execute the following query and restart IIS on the Silverback server:

 UPDATE dbo.WebSettings SET [Value] = N'False' WHERE [Key] = N'SimpleEnrollmentOAuthVerboseLoggingEnabled';

Important: Diagnostic logs may contain sensitive enrollment and authentication information. The setting should only be enabled for troubleshooting purposes and must be disabled again immediately after the required analysis has been completed. In addition, it is recommended to remove generated verbose log entries from the [dbo].[SimpleEnrollmentLogActions] table after troubleshooting has been completed. Verbose logging may contain sensitive information, including authentication details, tokens, and other secrets that should not be retained longer than necessary.

• Review the latest entries in the [dbo].[SimpleEnrollmentLogActions] table, for example by selecting the most recent records ordered by CreatedDate.
• Identify the range of log entries that were generated during your troubleshooting session.
• Execute a SELECT statement first to verify which records will be deleted:

SELECT *
FROM dbo.SimpleEnrollmentLogActions
WHERE SimpleEnrollmentLogActionId BETWEEN 8431 AND 8441;

• After verifying the result set, export or save the log entries for future reference before deleting them. Once the information has been secured, remove the identified records using the following statement:

DELETE
FROM dbo.SimpleEnrollmentLogActions
WHERE SimpleEnrollmentLogActionId BETWEEN 8431 AND 8441;

Service Bus

• Service Bus Adapter has been updated to version 7.1.2
• MessageModel has been updated to version 6.24.3

Security Hardening

Silverback 26.2 includes a series of security hardening measures across multiple application components. Improvements were made to input validation mechanisms, authorization processes, request handling, and internal security controls to further strengthen platform security.

Already distributed improvements and fixes

• Silverback 26.0.1.22
  • Updated Companion Push Notification Service Certificate for iOS & iPadOS 
• Silverback 26.0.1.21
  • Improved security of web-based authentication and credential entry forms by disabling browser auto-completion on password and one-time-password fields.
  • Improved reliability of STS Log settings across different logging configurations.
  • Improved performance when viewing STS logs, reducing database load and response times.
  • Improved memory usage in IIS application pools by removing unnecessary dependency initialization in the MDM service.
  • Fixed multiple dependency injection lifetime issues that could lead to unnecessary database context and memory retention.
  • Resolved resource cleanup issues in Cloud Connector communication components to prevent unnecessary handle retention.
  • Optimized database connection handling and introduced a keep-alive mechanism to reduce repeated TLS connection establishment overhead.
  • Implemented throttling for automatic inventory command generation while preserving immediate execution of administrator-triggered refresh operations.
  • Improved TLS certificate validation handling by scoping validation callbacks to individual connections rather than the entire application process.
  • Fixed an issue where orphaned or legacy configuration entries could trigger unnecessary exception processing during runtime.
  • Improved reliability of Android Enterprise check-in and check-out processing by isolating external Google service failures from the remaining device
  • synchronization workflow.
  • Limited Android Enterprise retry behavior to prevent excessive retry loops during repeated server-side failures.
  • Restored and corrected VPN On-Demand behavior for iOS devices when using certificate-based authentication and per-app VPN configurations.

Knowledgebase

The following new Knowledge Base articles have been added:

• Manually Grant Companion Device Owner Rights

New Changes

• Updated various missed company name references from Matrix42 AG to Matrix42 GmbH. This includes corrections within the Silverback SSL Certificate Generator and other product components to ensure consistency with the current legal entity.
• Since Version 26.1.0.20, Companion uses a default polling interval of 6 hours instead of 10 minutes. This change significantly reduces network traffic, server load, and background processing overhead, particularly in large-scale deployments with thousands of managed devices. The polling interval remains fully configurable through Managed Configuration and can be adjusted to meet specific operational requirements. This behavior is especially relevant for devices that cannot receive or are not permitted to receive Firebase Cloud Messaging (FCM) notifications, where periodic polling serves as an alternative mechanism for retrieving updates from Silverback.