More than a year after first previewing customizable security baselines, Microsoft has quietly made CIS benchmark auditing for Linux servers a native, policy-driven experience in Azure Machine Configuration. The capability, which reached general availability this month, lets administrators evaluate Azure VMs and Arc-connected Linux machines against official CIS Benchmarks directly from the Azure control plane—no standalone scanners, custom scripts, or third-party tools required.

When you assign the new audit policy, the azure-osconfig engine checks each server against the selected CIS Benchmark, surfaces per-rule evidence through Guest Assignments, and rolls up fleet-wide compliance into Azure Policy and Azure Resource Graph. It is, as one architecture lead described it to me, “the end of the compliance spreadsheet that lives on someone’s desktop.”

What changed: CIS auditing moves into Azure Policy

Microsoft first introduced customizable security baselines for Windows and Linux in early 2025 through Azure Machine Configuration. At the time, the Linux coverage was limited to a few experimental benchmarks and required manual parameter juggling. The general-availability release, first reported by Petri IT Knowledgebase, adds production-grade support for the Center for Internet Security (CIS) Benchmarks on Linux, with formal backing from Microsoft’s Azure Governance and Management team.

Administrators can now select a supported distribution and a specific CIS Benchmark version—say, CIS Benchmark for Ubuntu 22.04 L1 Server—then enable, exclude, or tune individual rules before assigning the policy. The entire configuration is captured as a JSON file that can be downloaded, versioned, and fed into infrastructure-as-code pipelines via Azure CLI, ARM, or Bicep templates.

Microsoft currently documents support for Red Hat Enterprise Linux, AlmaLinux, Rocky Linux, and Ubuntu. The exact CIS Benchmark editions available (e.g., Level 1 Server, Level 2 Workstation) depend on what the azure-osconfig engine has been validated against for each distribution, so teams should confirm coverage for their specific images.

Critically, the audit is read-only. The policy identifies configuration drift and non-compliance, but it does not automatically remediate. If a server fails a rule—say, an SSH cipher is too permissive or auditd logging is misconfigured—the findings appear in Azure Policy and Guest Assignments, but the server’s configuration remains unchanged until an admin intervenes.

What this means for your team

For security and operations teams managing hybrid estates, the shift removes a long-standing friction point. Linux CIS auditing has typically been handled by standalone tools (like Lynis, OpenSCAP, or commercial scanners) whose results feed into separate dashboards or report files. Azure Machine Configuration now extracts the same evidence and places it beside the rest of your Azure Policy governance, creating a single pane for Windows and Linux posture.

For IT admins and SecOps:
- Unified compliance view: Non-compliant machines appear in Azure Policy compliance dashboards alongside other policy assignments. Resource Graph queries can list all Linux servers that failed a specific CIS rule, making it easier to populate remediation work queues.
- Granular evidence: The Guest Assignments blade exposes the exact rule that failed, the expected value, the actual value, and a reason. That level of detail helps when you need to justify an exception or validate a finding.
- Hybrid consistency: Arc-enabled servers running on-premises, at the edge, or in other clouds use the same audit mechanism, so your compliance reporting doesn’t split into “cloud” and “everything else.”

For developers and DevOps teams:
- Policy-as-code ready: The exported JSON baseline can be stored in a Git repository and deployed via CI/CD pipelines. This brings CIS audits under the same change control processes used for infrastructure configuration, enabling pre-release compliance checks.
- No agent overhead beyond the Arc extension: The audit runs through the Azure Machine Configuration extension already deployed by the prerequisite initiative. No additional agents or daemons are needed on the Linux host.

For cloud architects and governance leads:
- Customizable guardrails: Because you can exclude or tune rules before assignment, you can align the baseline with internal standards without fighting policy violations that are acceptable in your context (for example, a rule requiring a specific filesystem mount option that conflicts with a workload).
- Audit-only by design: The read-only posture means there’s no risk of an automated hardening step breaking a production service. Remediation remains a deliberate, change-controlled action.

How we got here

Azure Policy’s guest configuration capabilities (now branded as Azure Machine Configuration) have been evolving for years. The original model revolved around custom Desired State Configuration (DSC) scripts, which were powerful but cumbersome to maintain at scale. Microsoft gradually abstracted that complexity, first by offering built-in policy definitions for common settings, then by introducing “at-scale” assignment experiences.

The 2024 preview of customizable security baselines was the first attempt to bridge the gap between industry benchmarks and native Azure Policy. At that time, the Linux story was incomplete: you could assign baselines, but the benchmark coverage was thin and the experience felt like a work in progress. Windows baselines, meanwhile, had been available for years through the legacy Azure Security Center and later through Defender for Cloud’s regulatory compliance dashboard.

Two shifts changed the equation: the maturation of Azure Arc as a first-class management plane for non-Azure servers, and the decision to treat security baselines as a distinct capability within Azure Policy rather than a Defender for Cloud premium feature. With this GA release, Microsoft is signaling that compliance benchmarking—independent of threat detection—should be a free, embeddable control plane function.

What to do now: steps to enable CIS auditing for Linux

If you already manage servers through Azure Arc and have the Machine Configuration prerequisites in place, you can start auditing Linux CIS benchmarks today. Here’s a sequential path to get up and running:

1. Confirm prerequisites

  • The Azure Machine Configuration prerequisite initiative must be assigned to your target subscription or management group. This initiative deploys the necessary Azure Policy extension to every supported machine and enables the guest configuration provider.
  • Your Linux servers must run a supported distribution and have connectivity to Azure (directly for VMs, or through the Arc agent for non-Azure servers).
  • The user assigning the policy needs Owner or Resource Policy Contributor permissions.

2. Select and customize a baseline

  • Navigate to Azure Policy > Machine Configuration and select the Baselines tab.
  • Choose a Linux CIS Benchmark appropriate for your distribution and workload. Microsoft currently exposes baselines for the distributions mentioned earlier; verify that your OS version and benchmark edition (Level 1/Level 2, Server/Workstation) are listed.
  • Use the Modify Settings wizard to review each rule. You can enable, exclude, or adjust parameter values. For example, you might exclude a rule that enforces password complexity if your organization relies on certificate-based authentication.
  • Once satisfied, download the JSON representation. This file captures your customized baseline and can be checked into source control or deployed directly.

3. Assign the audit policy

  • Using the Azure portal, you can assign the policy directly from the baseline interface. Specify the scope (subscription, resource group, or individual machine) and provide the JSON parameter file.
  • Alternatively, use Azure CLI or infrastructure-as-code to assign the policy at scale. The policy definition to use is “Linux Workloads should comply with the Official CIS Security Benchmark” (verify the current definition name, as it may still carry a preview tag despite the broader platform being GA).
  • The assignment triggers evaluation within about 15 minutes. Machines report compliance status as compliant, non-compliant, or not applicable.

4. Review results and plan remediation

  • In Azure Policy, filter by the assigned initiative to see an aggregate view. Drill into non-compliant machines to see per-rule details.
  • For evidence, open Guest Assignments on an individual Arc server or Azure VM. Each failed rule includes a description, the expected value, the observed value, and a reason code.
  • Cross-reference findings against your operational requirements. Some failures may be intentional; you can either adjust the baseline (and reassign) or document the exception as part of your risk acceptance process.
  • Store the downloaded baseline JSON in your Git repository.
  • Use Azure Policy’s SDK or Azure CLI to programmatically assign the baseline in a pipeline, perhaps after a golden image build or during initial VM provisioning.
  • Pair the audit results with Azure Resource Graph queries to generate compliance dashboards in Power BI or Grafana.

Important caveats to keep in mind

The specific Linux CIS policy definition still shows a “preview” label in Microsoft’s policy reference documentation, even as the broader customizable baselines platform is generally available. Before treating the audit results as a compliance control of record, check the definition’s status, regional availability, and supported benchmark versions for your distributions. Microsoft has a history of rolling out GA in waves, and individual policies may lag the platform.

The audit is not a replacement for a full risk assessment. CIS Benchmarks are consensus-driven guidelines, not regulatory mandates. Aligning to a benchmark can reduce attack surface, but it doesn’t guarantee compliance with PCI DSS, HIPAA, or other frameworks. You may still need overlay assessments from tools like Qualys or Rapid7 for formal attestation.

Azure Government and sovereign clouds are not yet supported. The official documentation currently states that support for these environments is not available during public preview, and the general-availability announcement did not explicitly lift that restriction. Government customers should verify availability independently.

Outlook: more baselines, deeper integration

Microsoft’s language around “trusted industry benchmarks” suggests that CIS is just the first standard to receive this treatment. The infrastructure is extensible: a baseline is essentially a schema that maps machine configuration settings to policy rules. We can expect future support for DISA STIGs, PCI DSS technical controls, or even custom organizational baselines authored in the same format.

The audit-only posture, however, is likely to persist for Linux. Auto-remediation of security settings on a production Linux server is fraught with risk—changing PAM configurations, firewall rules, or kernel parameters automatically can take a service offline. Microsoft’s cautious design reflects that reality. For Windows, Defender for Cloud already offers some remediation options, but on Linux, the control plane will likely remain focused on detection and reporting, leaving fixing to tools like Ansible, Chef, or manual change control.

In the near term, the immediate win is consolidation. If you’re already using Azure Policy for governance and Azure Arc to manage on-premises Linux servers, you can now bring CIS auditing into the same operational workflow. The compliance data is there, queryable, and actionable—and you didn’t have to deploy an extra agent or pay for an additional scanner.