Windows - Security - Rename Built-In Guest Account

What the Windows Guest account renamer does

This Automox Worklet™ renames the built-in local Guest account on Windows endpoints. The evaluation script checks for a local user matching the name defined in $oldAccountName (Guest by default). If that account exists, the endpoint is flagged for remediation, and Rename-LocalUser changes it to the value defined in $newAccountName.

Although the Worklet ships pointed at Guest, the same logic applies to any local account. Set $oldAccountName to the existing local account you want renamed and $newAccountName to the desired value, and the Worklet will handle that account instead. Both variables must be set in the remediation script before the policy runs.

The Worklet does not enable, disable, or modify the password of the account. Renaming alone is the CIS 2.3.1.6 control: the account stays in whatever enablement state your baseline already defines, but its well-known display name is gone. Pair this Worklet with a separate Disable Guest Account policy if your baseline also requires the account to be disabled.

Why obscure the Guest account at fleet scale

The local Guest account has shipped on every Windows install since Windows NT under the same default name. Account-enumeration tooling, SMB scanners, and credential-stuffing scripts target it by that exact string. Renaming the account to a non-obvious value removes the predictable target and forces an attacker to enumerate the SAM database before they can probe it, which is slower and more likely to surface in endpoint or SIEM telemetry.

CIS Microsoft Windows Benchmark control 2.3.1.6 ("Accounts: Rename guest account") calls for this exact hardening step, and NIST 800-53 IA-4 references the same principle of retiring well-known account names. Running the Worklet through Automox covers workstations and servers that never received the equivalent Group Policy setting, including standalone hosts that are not domain-joined. Recurring evaluation catches any endpoint where a sysprep cycle, image refresh, or administrator action restores the Guest name to its default.

How the Guest account rename works

1. Evaluation phase: The Worklet calls Get-LocalUser -Name $oldAccountName (default value Guest) with -ErrorAction SilentlyContinue. If the cmdlet returns a user object, the endpoint is flagged non-compliant and remediation is scheduled. If nothing is returned, the endpoint is reported compliant and the run ends. The check is wrapped in a 64-bit Shell function so it executes against the native PowerShell hive on 32-bit agent processes.

2. Remediation phase: The remediation script re-resolves the local account by name, then calls Rename-LocalUser -Name $oldAccountName -NewName $newAccountName inside a try/catch with -ErrorAction Stop. On success the script returns 0 and the Automox activity log records "Account was renamed successfully." If the account is no longer present the script returns 99 and reports "Device is already compliant." Any failure inside Rename-LocalUser (the new name already exists, insufficient privileges, account in use) returns 1 and the log records "Failed to rename account."

Guest account rename prerequisites

• Windows 10 or later, Windows Server 2016 or later (anything that ships the Microsoft.PowerShell.LocalAccounts module by default)

• PowerShell 5.1 or later, which the Automox agent already provides

• Local administrator rights on the target endpoint to call Rename-LocalUser

• Set $newAccountName in the remediation script to the value your policy requires before deploying. Pick something that does not resemble an existing service, admin, or shared account name on the host

• Optional: change $oldAccountName from Guest to any other local account name if you want to repurpose the Worklet to rename a different local account

• If a Group Policy Object already sets "Accounts: Rename guest account" through secedit, decide which path is authoritative before deploying. Running both will produce churn if the values differ

• Not applicable to Active Directory domain controllers, which do not host a local Guest account in the local SAM

Expected Guest account state after remediation

After the Worklet completes successfully, Get-LocalUser on the endpoint returns no account named Guest. A local account exists under the value you defined in $newAccountName, and its Enabled flag is whatever it was before the run, because this Worklet does not change enablement. The activity log records "Account was renamed successfully." and the policy exit code is 0.

Validate the change with Get-LocalUser | Where-Object { $_.SID.Value -like '*-501' } | Select-Object Name, Enabled, SID. The Name column should match your renamed value rather than Guest, and the SID column should end in -501, which confirms you renamed the built-in account and not a different local user. For audit evidence aligned to CIS 2.3.1.6, capture that output alongside the Automox policy run identifier and the activity-log exit code. The change persists across reboots, feature updates, and image refreshes, and is only undone if an administrator renames the account again or a Group Policy refresh forces a different value.