Windows - Enterprise Branding - Configure Custom Company & Support Information

What the enterprise branding configurator does

This Automox Worklet™ customizes the company and support information that appears to users in the Windows Security Center and related security notifications. Rather than displaying generic Microsoft messages, endpoints show your organization's company name, support email, phone number, and help desk URL.

The Worklet modifies registry values under HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender Security Center\Enterprise Customization. It can optionally reboot the endpoint to apply changes immediately, or defer the reboot to a maintenance window.

You configure parameters in the Worklet to specify your company name, support email, support phone number, and support URL. The Worklet then writes these values to the appropriate registry locations on each endpoint.

Why customize enterprise branding in security notifications

Generic Windows Security Center alerts lacking company contact information create confusion that increases phishing susceptibility and support burden. When users receive security notifications without clear IT contact details, they resort to web searches for support phone numbers, exposing them to tech support scams and malicious websites impersonating legitimate help desks. Employees who cannot quickly identify authentic IT support channels delay reporting genuine security incidents, extending attacker dwell time and increasing breach impact.

This customization enhances your security posture by directing users to legitimate internal support channels instead of potentially phishing emails or malicious websites. It also reinforces your organization's security culture by demonstrating that IT team members are present and accessible.

For organizations with remote workforces or multiple business units, consistent branding in security messages maintains a unified support experience. Users see the same contact information across all security alerts, regardless of which endpoint they are using.

How enterprise branding configuration works

1. Evaluation phase: The Worklet checks whether the registry path exists and verifies that all configured properties (company name, email, phone, URL) match the desired values. If any value differs or the path does not exist, the Worklet reports non-compliance.

2. Remediation phase: The Worklet creates the registry path if it does not exist, then writes or updates each property with the configured values. If you set EnableEnterpriseCustomization to false, the Worklet removes all related properties to revert branding to default Windows settings.

Enterprise branding configuration requirements

• Windows 10 or Windows 11 endpoints

• Windows Server 2016 or later for server deployments

• Local administrator privileges to modify HKLM registry hive

• PowerShell execution policy allowing script execution

• Valid email address and support URL for contact information parameters

• Optional: Reboot window if enabling the automatic reboot parameter

Expected security center branding state

After successful remediation, open the Windows Security Center on the endpoint. You will see your configured company name, support email, support phone number, and help desk URL displayed in the interface. When Windows Security generates notifications (such as virus definition updates or security warnings), these same contact details appear in the notification toast messages.

Users can click on the support information in notifications to contact your help desk using the configured email or phone number. The customized branding persists across Windows updates and remains in place until you run the Worklet again with EnableEnterpriseCustomization set to false to revert to default Windows branding.

How to validate configure custom company & support information changes

1. Run this Worklet on a pilot Windows endpoint and review evaluation output for configure custom company & support information.

2. Confirm Automox activity logs show successful completion and exit code 0.

3. Verify endpoint state using checks aligned to evaluation script logic, such as Test-Path, Write-Output, Get-ItemProperty.

4. Validate remediation effects from script operations such as Test-Path, New-Item, Out-Null, then rerun evaluation for compliance.