Azure Local 2610 Security Baseline: Persistent Exceptions, Drift Control and CIS Alignment

Microsoft detailed the changes in its Azure Arc blog on November 12, 2026. For infrastructure teams, the practical headline is not simply a higher compliance percentage. It is a supported way to distinguish an approved configuration exception from unwanted drift, while giving auditors more information about both. Microsoft Learn confirms the new behavior and documents important limits, including cluster-versus-local precedence and settings that remain blocked from customization.

What changes in version 2610​

The revised baseline covers domain-joined Azure Local deployments, deployments using local identities rather than Active Directory, and the infrastructure VM supporting disconnected operations. Microsoft says that infrastructure VM uses the same baseline as the hosts. The additional settings arrive through the solution update and subsequently fall under drift control; administrators do not have to enable each new check manually.

The evaluated-setting counts increase in both host deployment models:

That is 21 additional evaluated settings in each case. Microsoft Learn independently confirms these counts and the automatic application of the expanded baseline during the solution update.

For release planning, distinguish the 2610 solution release from its underlying OS update. Microsoft’s release information lists solution build 12.2610.1004.50, available November 2, 2026, superseding 12.2610.1004.41, available October 22. Both use OS build 26100.33650. Microsoft identifies the associated October OS security update as KB5126646, released October 13. Those are different milestones, not interchangeable release dates.

There is also a concrete upgrade prerequisite worth checking: Microsoft’s release information says that, if the AzureEdgeAlerts extension is installed, it must be updated to 12.2607.5.0 or later before updating Azure Local to 2610.

Reading the CIS and STIG numbers correctly​

Microsoft reports the following rule-by-rule alignment against the Windows Server 2025 CIS Level 1 benchmarks:

These are Microsoft’s reported comparisons, not independent certification results. Keeping the benchmark revision and deployment type attached to each percentage is essential; otherwise, a useful engineering measurement becomes an ambiguous dashboard number.

Microsoft says intentional deviations account for much of the remaining CIS gap. For example, PKU2U remains enabled because Azure Local cluster operations and Microsoft Entra ID sign-in depend on it. The company also removed settings associated with components it considers deprecated or that no longer generate events, and says it reviewed the overrides with CIS. Excluding documented overrides, Microsoft reports more than 99% alignment across all three deployment types.

That adjusted figure deserves careful handling. Excluding an override from a comparison does not mean an organization’s assessor has accepted the exception. A sensible assessment should retain both the unadjusted result and the explanation for each excluded rule, rather than presenting “over 99%” as an unconditional compliance claim.

The STIG results have a different scope:

• Disconnected-operations infrastructure VM: Microsoft reports an 82% pass rate for automated Windows Server 2025 STIG V2R3 rules using DISA’s SCAP Compliance Checker, or 92% after excluding overrides.
• Azure Local hosts: A rule-by-rule review against STIG V1R1 found coverage of 132 of 148 applicable automatable rules.
• Remaining work: Microsoft says most outstanding infrastructure-VM rules concern OpenSSH requirements in V2R3.

Do not combine those into one platform-wide STIG score. They concern different targets, revisions and evaluation methods. Microsoft explicitly cautions that alignment is not certification or accreditation. The assessor still has a job; the spreadsheet has not replaced them.

Audit evidence becomes more useful​

The 2610 settings files add seven columns, split between compliance mapping and operational guidance. The first four identify the relevant CIS RuleID, CIS Controls v8 safeguard and Implementation Groups, STIG ID, and NIST SP 800-53 Rev. 5 control. These mappings are intended to help assemble assessment evidence, including RMF and FedRAMP-related work—not to confer approval.

The other three columns explain how a setting should be handled:

• Security Impact: What the setting protects, including the rationale for intentional benchmark deviations.
• Change Risk Level: The security and functional consequences of changing it.
• Customization Posture: Whether customization is permitted and whether it triggers a warning.

My practical recommendation is to use those fields together in change requests. Record the control mapping, business requirement, proposed value and operational risk in one place. That is more useful than maintaining a compliance exception in one system and an unexplained PowerShell command in another.

Choose the settings file for both the solution version and identity model. Microsoft Learn provides separate 2610-and-later files for domain-joined and non-domain-joined deployments running OS build 26100.xxxx. An older CSV is not an appropriate inventory for the expanded baseline.

Drift control now protects approved exceptions​

Previously, changing protected baseline settings required disabling drift control. Microsoft says those changes could then be overwritten by a solution update; the existing named security-feature controls were the exception to that persistence problem. Version 2610 introduces Set-AzsSecurity for individual customizable settings while leaving drift control enabled.

The central distinction is between an enforced default and an enforced customization:

• With -Cluster, Azure Local records the requested value as cluster policy intent, applies it across the cluster and reapplies it during solution updates.
• Without -Cluster, the change affects only the connected machine and also survives solution updates.
• Where cluster intent exists for the same setting, cluster intent takes precedence over a local customization.

Microsoft recommends cluster-scoped customization. It also explicitly says that modifying these baseline settings through other mechanisms, including Group Policy or direct registry edits, is unsupported and that drift control reverts those changes. For teams carrying older hardening scripts forward, this is a reason to review the configuration method—not just the desired value.

A controlled workflow for backup-agent access​

Microsoft’s example concerns the Backup files and directories user right. The baseline assigns it to Administrators, matching the benchmark recommendations described in the announcement. A backup agent running under a dedicated service account may also need that right. Version 2610 provides a supported way to express that exception without abandoning enforcement elsewhere.

1. Establish the prerequisites​

Confirm that the system is on 2610 and that its security baselines have been properly applied. Microsoft says the new cmdlets are available on new deployments, or upgraded deployments after baseline application to the nodes. The management documentation’s general prerequisites describe a deployed, registered, Azure-connected system; its scope is hyperconverged Azure Local deployments. Do not silently treat that connected-system prerequisite as a disconnected-operations setup procedure.

Before changing backup permissions, identify the actual service-account SID and document why the account needs the right. The placeholder in Microsoft’s example is not something to paste unchanged into production.

2. Select the exact setting and policy type​

Use the CSV’s Name column for -SettingName. Microsoft Learn notes that names must match exactly and that Tab completion does not fill them in. The available policy types are:

• SecuritySettings for registry, security policy, audit policy and user-rights settings.
• SecuredCore for secured-core platform settings.
• DefenderAntivirus for antivirus configuration.

The backup-right example belongs to SecuritySettings.

3. Apply the cluster-scoped value​

Microsoft provides this command:

Set-AzsSecurity -Type SecuritySettings -SettingName "UserRightsBackupFilesAndDirectories" -Value @("*S-1-5-32-544", "*<backup service account SID>") -Cluster

Replace the backup-account placeholder with the real SID. The example retains the Administrators SID alongside the service account; it supplies the intended list rather than merely naming an account to append. Review the existing value before accepting the replacement.

4. Review the confirmation​

The cmdlet presents the setting, old value, proposed value and target scope before applying the change. Some security-weakening changes produce an additional warning. Use that prompt to catch an incorrect SID, unintended list replacement or wrong scope before committing.

For unattended execution, Microsoft documents using both -Confirm:$false and -Force to suppress confirmation and the security warning. That is an automation capability, not a reason to skip review during initial validation.

5. Check recorded intent and operational results​

Run:

Get-AzsSecurityPolicyIntent

This is a cluster-intent inventory, not a complete inventory of every customization. Microsoft Learn says it groups recorded cluster customizations by policy type, excludes unchanged baseline settings and does not list local-only changes made without -Cluster. This is an important qualification to the announcement’s broader description of the command.

For acceptance testing, confirm that the expected cluster intent appears, verify the effective right on the relevant machines, and test the backup operation under the intended account. Rerun the applicable security checks and record the exception. A recorded intention and a successful backup are different pieces of evidence; collect both.

6. Remove the exception when it is no longer needed​

Microsoft documents -Default to restore a setting’s baseline value. For the cluster-scoped example, the corresponding reset is:

Set-AzsSecurity -Type SecuritySettings -SettingName "UserRightsBackupFilesAndDirectories" -Default -Cluster

Match the reset scope to the original change. A cluster reset removes recorded policy intent so future updates follow the baseline again. A local reset is not a substitute for removing cluster intent.

Guardrails and common failure points​

Customization does not make every security control negotiable. Microsoft documents blocked settings covering credential protection and authentication, platform integrity, host firewall configuration, minimum SMB versions, remote management and selected Defender Antivirus protections. The latter include real-time protection and the attack surface reduction rule blocking process creation through PsExec and WMI commands.

A blocked attempt names the rejected setting, makes no configuration change, records no customer intent and emits a SecuritySettingBlocked event. -Force cannot override the block. That is a supportability boundary, not a confirmation prompt to defeat.

Several troubleshooting checks follow directly from the documentation:

• Cmdlet unavailable: Check the solution version and whether baseline application completed after upgrading.
• Setting name rejected: Compare it with the exact CSV Name value and its policy type.
• Local value does not persist as expected: Check for overriding cluster intent.
• Customization missing from the inventory: Determine whether it was applied locally rather than cluster-wide.
• Registry or Group Policy change reverted: Move the approved customization to the supported cmdlet instead of disabling enforcement.

For coordinated changes, Microsoft also supports a hash table through -Settings, with all settings applied or none applied. -DefaultSettings can reset several settings, including in an operation that customizes others, but one setting cannot appear in both parameters. These capabilities can simplify controlled change sets without turning them into a collection of unrelated edits.

What this means for enterprise adoption​

The strongest interpretation of 2610 is that Microsoft is reducing two practical obstacles: baseline exceptions and the difficulty of maintaining approved deviations. The published benchmark comparisons support the first; persistent, enforced customizations support the second. They do not demonstrate that deployments have become faster by a measured amount or that adoption has already increased.

For administrators, the sensible next step is a controlled rollout: check release prerequisites, use the correct settings inventory, run the organization’s own scanners, assess the remaining deviations and encode permitted exceptions through Set-AzsSecurity. Keep drift control enabled, and keep the distinction between recorded intent, effective configuration and assessment evidence clear.

That is the real improvement: not security without exceptions, but exceptions that can be deliberate, reviewable and maintained without dismantling the rest of the baseline.