Starting with Azure Local, version 2610, you can change a single security setting, keep drift control switched on, and keep your value through solution updates. It’s one of the most common requests we’ve heard from customers since we made Azure Local secure by default, and it ships alongside a baseline update that closes most of the distance to the CIS Benchmark and the DISA STIG.
Those two changes belong together. A stricter baseline is only useful if you can live with it, and until now the honest answer for some environments was that you couldn't.
Closer alignment with industry standards
Most customers don't take a platform's security on our word. Their auditors measure it against the CIS Benchmarks and, in government and defense, the DISA STIG benchmark. Every rule the platform misses becomes an exception someone must document and defend. In finance, healthcare and the public sector, that alignment can be a condition of going to production. So, the closer the baseline sits to those standards from day one, the shorter the path from a new cluster to a live one can be.
Version 2610 ships a revisited security payload for Azure Local and Azure Local disconnected operations that better align with the Windows Server 2025 CIS Benchmark and STIG guidance. A domain-joined deployment now evaluates 429 settings, up from 408. A deployment that uses local identities instead of Active Directory evaluates 403, up from 382. Both score higher than before, and you don't have to do anything to get there: the new settings arrive with the solution update, and drift control covers them from that point on.
Sovereign private clouds get the same treatment. The infrastructure VM that supports disconnected operations runs the same baseline as the hosts. We compared both versions rule by rule against the CIS Windows Server 2025 Level 1 benchmarks (Member Server v2.1.0 and Stand-alone v2.0.0) on all three deployment types. On CIS:
- Azure Local, domain-joined, against the Member Server benchmark: from 77% to 87%.
- Azure Local with local identities, against the Stand-alone benchmark: from 79% to 87%.
- The disconnected operations infrastructure VM, against the Stand-alone benchmark: from 76% to 88%.
The rules we still don't meet are deliberate. Some are needed for Azure Local capabilities to work at all: PKU2U, for example, stays on because cluster operations and Microsoft Entra ID sign-in depend on it. We also dropped settings for components that no longer produce events or that we consider deprecated, rather than collect empty logs. We’ve reviewed each of these overrides with CIS.
Set those documented overrides aside and the baseline aligns with more than 99% of the CIS Level 1 rules on every deployment type. STIG tells a similar story. On the disconnected operations infrastructure VM, the DISA SCAP Compliance Checker passes 82% of the automated Windows Server 2025 STIG V2R3 rules, and 92% once the overrides are set aside. Most of what's left are OpenSSH rules from that revision, and we're working through them now. For the Azure Local host, a rule-by-rule review of the baseline against the STIG (V1R1) shows it covers 132 of the 148 automatable rules that apply. Alignment with a benchmark isn't a certification or an accreditation; your assessor still makes that call. That's the commitment we made: close the gap with CIS and STIG, and be clear about every place we still differ.
Additional audit metadata in the security baseline
The baseline now has answers for two different people. Your auditor wants to know which control each setting satisfies, and a percentage doesn't tell them that. Your security operations team wants to know what the setting actually does, why we evaluate it on Azure Local, what changing it would affect, and whether they're allowed to change it at all.
Starting with 2610, the settings file we publish for each deployment type answers both, with seven additional columns on every setting. The mappings speed up your evidence work; they don’t replace your assessment. Hand the first four to your compliance team instead of building that mapping yourself; read the last three before you customize anything:
- CIS RuleID: the CIS Windows Server 2025 Benchmark recommendation the setting answers.
- CIS Control: the CIS Controls v8 safeguard, with its Implementation Groups.
- STIG ID: the DISA Windows Server 2025 STIG rule, to support DoD and federal accreditation work.
- NIST SP 800-53 Rev 5: the NIST control, useful when you assemble RMF and FedRAMP evidence.
- Security Impact: what the setting protects against and, where the baseline differs from a benchmark on purpose, why.
- Change Risk Level: the functional and security consequence of changing the setting, so you know before you change it.
- Customization Posture: whether Set-AzsSecurity lets you change the setting, and whether it warns you first.
Download the 2610 files for domain-joined deployments and for deployments with local identities.
Improving drift control and adoption in enterprise environments
Until 2610, a customer who needed to adapt a handful of settings to their environment had one option: turn off drift control, which stopped the baseline from being enforced across the whole cluster. Even that didn't last. The next solution update reverted the changes, and only the seven security features you can switch with Enable-AzsSecurity and Disable-AzsSecurity kept their state.
Version 2610 adds Set-AzsSecurity on top of those seven toggles. It changes one setting and leaves drift control on for everything else. Run it with -Cluster and Azure Local records your value as cluster policy intent, applies it on every machine in the cluster, and keeps it across solution updates. Drift control then protects your value instead of the baseline value.
Backup is a common case. The baseline gives the Backup files and directories right to administrators only, which is what CIS and the STIG ask for. Many enterprises run their backup agent under a dedicated service account, and that account needs the same right. One command adds it on every machine in the cluster and keeps Administrators on the list:
Set-AzsSecurity -Type SecuritySettings -SettingName "UserRightsBackupFilesAndDirectories" -Value @("*S-1-5-32-544", "*<backup service account SID>") -Cluster
Before anything changes, the cmdlet shows the setting, the value it moves from and to, and where the change applies, then asks you to confirm. Get-AzsSecurityPolicyIntent lists every customization you've recorded. Run Set-AzsSecurity with -Default to put a setting back on the baseline.
Without -Cluster, the change applies only to the machine you're connected to and still survives updates. If the same setting also has cluster intent, the cluster value wins.
Settings that stay protected
Some settings hold the platform together, and Set-AzsSecurity won't change them: credential protection, the signed boot chain and virtualization-based security, the host firewall, the minimum SMB version, remote management over WinRM, and Defender Antivirus real-time protection.
When you target one, the cmdlet names the setting it rejected and writes nothing. No intent is recorded, and support can see the attempt. We would rather say no up front than let a change break an update three months later, when nobody remembers making it. The list will change as the platform does, so the documentation below is the place to check.
What to do next
Update to 2610 to pick up the new baseline. Download the settings list for your deployment type and run it past your own CIS or STIG scanner. Where your policy needs a different value, set it with Set-AzsSecurity and keep drift control on.
Start with these pages:
Microsoft