TL;DR: Microsoft publishes the Azure Local Security Baseline as a CSV, with three variants depending on OS build and whether the cluster is domain-joined. Use the matching aka.ms shortlink, or browse the same files in the Azure-Samples/AzureLocal GitHub repo. The CSV is the reference; the cluster already enforces the baseline via drift control.
Recommended action:
Pick the CSV that matches your deployment. The fastest path is the direct aka.ms shortlink:
Azure Local v2505 and earlier, OS build 25398.xxxx, domain-joined: https://aka.ms/SecBase
Azure Local v2506 and later, OS build 26100.xxxx, domain-joined: https://aka.ms/SecBaseDomJoin
Azure Local v2506 and later, OS build 26100.xxxx, AD-less (not domain-joined): https://aka.ms/SecBaseAdless
If you would rather browse the files (e.g. to compare variants or check history), the same CSVs live in the GitHub repo at Azure-Samples/AzureLocal — security. Open the file and use the Download raw file icon in the top-right.
Why:
The Security Baseline is Microsoft’s authoritative list of recommended security configuration settings for Azure Local nodes. Microsoft publishes a new CSV when recommendations change — new controls get added, default values change, or older settings get deprecated. Not every Azure Local release ships a new baseline; if nothing has changed, the previous CSV is still current. For background on what the baselines cover, see Microsoft’s security features overview: Security features in Azure Local.
Going forward:
Baselines update with recommendations, not every release. Re-check the shortlinks (or the
security/folder) after each Azure Local upgrade. If no newer file applies to your build, the most recent matching CSV still applies.Drift control enforces the baseline automatically. Azure Local includes drift protection that periodically re-evaluates each node and re-applies any protected setting that has drifted from the baseline. With drift control enabled you can only modify nonprotected settings. To change a protected setting you must first disable drift control on that scope:
Disable-AzsSecurity -FeatureName DriftControl -Scope <Local | Cluster>Make the change, then either leave drift control disabled or re-enable it — but note that re-enabling will overwrite any modifications you made to protected settings, reverting them to the baseline. Use
Get-AzsSecurity(from theAzureStackOSConfigAgentmodule installed at deployment) to check current state. Full guidance: Manage security defaults on Azure Local.These are low-level settings, not Group Policy. The baseline controls are applied directly — registry, security policy, system configuration — by the AzureStackOSConfigAgent on each node. They are not deployed via Group Policy Objects, so you cannot override them by linking a higher-priority GPO at the OU level; drift control will revert your override on the next pass. The only supported way to deviate is via the disable / re-enable workflow above.
Optional details:
A few baseline items intentionally do not have drift control enabled because they are meant to be customer-defined: Interactive logon: Message text / Message title (legal notice), and Minimum password length. Compliance reports will flag these as non-compliant until you configure them per your organization’s policy. They are safe to set directly without disabling drift control.
Other named features the security agent manages alongside the CSV baseline:
CredentialGuard,DRTM,HVCI,SideChannelMitigation,SMBSigning,SMBEncryption,VBS. Most are toggled withEnable-AzsSecurity/Disable-AzsSecurity -FeatureName <name> -Scope <Local | Cluster>; several require a reboot.The CSVs are plain text and can be diffed between releases (for example with
Compare-Objector any diff tool) to see exactly which controls changed when a new baseline is published.