Azure Policy Adds CIS Linux Benchmarks via azure-osconfig (Preview)

Microsoft and the Center for Internet Security (CIS) have made the official CIS Linux Benchmarks available as a built‑in, CIS‑certified capability in Microsoft Azure’s Azure Policy → Machine Configuration experience, powered by the new azure‑osconfig compliance engine — a preview feature that delivers continuous, audit‑grade assessments of many popular Linux distributions across Azure and Azure Arc–managed hybrid fleets.

---

Background / Overview​

For years, security and compliance teams have relied on the Center for Internet Security’s Benchmarks to define secure baselines for operating systems and applications. CIS Benchmarks are community‑driven, vendor‑agnostic configuration guides used for hardening and audit readiness, typically expressed in machine‑readable formats such as XCCDF and OVAL. Integrations with cloud providers and third‑party scanners have been common, but running canonical CIS assessments at scale has often required additional tooling, custom mapping, or maintenance overhead.
Microsoft’s new built‑in offering exposes the Official CIS Security Benchmarks for Linux Workloads as a preview policy named [Preview]: Official CIS Security Benchmarks for Linux Workloads inside Azure Policy’s Machine Configuration blade. The assessments are executed by azure‑osconfig’s compliance engine, which Microsoft indicates has been awarded CIS Benchmark Assessment Certified for the specific benchmark mappings it ships with. The initial release is audit‑only (it reports compliance status but does not auto‑remediate), with auto‑remediation capabilities planned for later releases.

---

What Microsoft and CIS Announced​

• Built‑in policy: The capability is surfaced as [Preview]: Official CIS Security Benchmarks for Linux Workloads within Azure Policy → Machine Configuration. Administrators can assign that built‑in definition and choose distribution/profile combinations to run continuous audit assessments.
• Compliance engine: The rules are evaluated by azure‑osconfig, which ingests CIS machine‑readable benchmark artifacts (XCCDF/OVAL) so rule logic aligns with official CIS specifications. Microsoft reports azure‑osconfig has satisfied CIS Certification requirements for the listed benchmarks.
• Scope at preview: The feature supports a broad cross‑section of enterprise Linux distributions and CIS benchmark versions (examples include Ubuntu 22.04/24.04, RHEL 8/9, AlmaLinux, Rocky, Oracle Linux, Debian 12, and SUSE SLE 15), mapped to both Level 1 (L1) and Level 2 (L2) profiles where applicable. The full matrix of distro/version pairings and CIS benchmark versions is documented in Microsoft’s guidance.
• Hybrid reach: Machines registered with Azure Arc and running the required agents can be continuously evaluated, enabling a single compliance pipeline across cloud, on‑premises, and multi‑cloud estates.
• Preview status and limitations: The capability is in Preview and audit‑only at initial release; auto‑remediation is explicitly planned for future releases and is not available in the preview. Organizations should treat the feature as a visibility and governance tool until remediation behavior and GA (general availability) specifics are proven.

---

Technical Details — How the Built‑In Assessment Works​

azure‑osconfig: an ingestion and evaluation engine​

The compliance flow is straightforward but important to understand:

• azure‑osconfig ingests CIS’s machine‑readable benchmark artifacts (XCCDF and OVAL).
• The engine evaluates target machines’ state against the canonical rule logic expressed in those artifacts.
• Results are surfaced as Azure Policy compliance events and can be exported to Azure Monitor / Log Analytics or forwarded into SIEM and ticketing systems for operational follow‑up.

Because the engine consumes canonical CIS content directly, Microsoft aims to reduce implementation drift — the common mismatch between vendor or homegrown scans and the official CIS benchmark text. This increases confidence that an Azure‑reported “PASS” or “FAIL” lines up with what auditors will expect from CIS. That said, implementation differences can still arise and should be reconciled during adoption.

Supported format and customization​

• The engine operates on standard CIS machine‑readable content (XCCDF/OVAL) and supports dynamic parameters for rule evaluation, enabling organizations to parameterize thresholds and create exceptions without rewriting rule logic.
• Custom images are supported provided their /etc/os‑release retains original content so azure‑osconfig can correctly identify distribution and version.

---

Supported Distributions and Profiles (Preview)​

At initial release Microsoft lists support for 12 Linux distribution/version pairings, each mapped to a specific CIS Benchmark version and offering L1 and L2 server profiles where applicable. Representative entries include:

• Ubuntu 22.04 LTS + Pro — CIS Ubuntu 22.04 Benchmark v2.0.0 (L1 + L2).
• Ubuntu 24.04 LTS + Pro — CIS Ubuntu 24.04 Benchmark v1.0.0 (L1 + L2).
• Red Hat Enterprise Linux 8 / 9 — mapped to the appropriate CIS RHEL benchmark versions (L1 + L2).
• AlmaLinux / Rocky / Oracle Linux 8/9 — vendor mappings to the equivalent CIS benchmark versions (L1 + L2).
• Debian 12 — CIS Debian benchmark v1.1.0 (L1 + L2).
• SUSE Linux Enterprise 15 — CIS SLE benchmark v2.0.1 (L1 + L2).

A complete matrix — with exact benchmark versions, supported marketplace images, and the full list of supported images — is available in Microsoft’s documentation and should be consulted before assigning policies at scale.

---

Why This Matters — Practical Benefits​

Embedding official CIS Benchmarks natively in Azure Policy changes the operational model for many organizations. Benefits include:

• Centralized, continuous compliance visibility. Built‑in policies remove the need to deploy and maintain separate CIS scanners on every host, enabling a single compliance reporting pipeline across thousands of machines.
• Closer parity with canonical CIS content. Because azure‑osconfig ingests the official machine‑readable artifacts, assessment logic is intended to reflect canonical CIS specifications more closely, reducing disputes between internal scans and formal audit expectations.
• Hybrid reach via Azure Arc. Teams can apply the same baseline across cloud, on‑premises, and multi‑cloud machines registered with Arc, simplifying policy automation for hybrid estates.
• Operational integration. Results flow into Azure Monitor / Log Analytics and can feed existing SRE, SOC, and ticketing pipelines without bespoke glue code, speeding time to remediation once fixes are implemented.

These operational advantages lower friction for maintaining audit‑grade baselines at scale and help teams adopt a “compliance as code” posture that’s repeatable and measurable.

---

Notable Strengths​

• Official, CIS‑certified implementation: The azure‑osconfig engine’s CIS Benchmark Assessment Certification for the mappings Microsoft ships is the single most important trust signal for auditors and security teams — it reduces ambiguity about whether the cloud provider’s scan matches CIS expectations.
• Native policy surface: Exposing the benchmarks inside Azure Policy (Machine Configuration) allows organizations to manage baseline assignment, exceptions, RBAC, and telemetry using existing Azure governance primitives rather than introducing separate tooling.
• Hybrid consistency: Azure Arc integration makes it feasible to apply the same canonical baseline across distributed server estates, helping reduce governance fragmentation.

---

Risks, Caveats and What to Watch For​

While the announcement is significant, it does not remove operational complexity and introduces new considerations:

• Preview and legal terms. The capability is in Preview and governed by Azure Preview supplemental terms. Preview behavior, APIs, and remediation semantics may change before GA; tying production enforcement automation to preview features is risky until GA is reached.
• Audit‑only at release. The initial offering reports noncompliance but does not automatically remediate issues. Organizations that expect one‑click remediation must plan interim remediation playbooks and workflows until auto‑remediation ships.
• Assessment variance and false positives. Microsoft acknowledges that implementation differences and stricter default checks may produce mismatches compared with CIS‑CAT Pro or other third‑party tools. Expect a reconciliation phase and rule‑by‑rule validation during adoption.
• Operational impact of Level 2 rules. L2 controls are more intrusive and may affect application functionality; applying L2 universally without staged testing risks service disruption.
• Arc connectivity and agent dependencies. Hybrid assessment requires Azure Arc registration and the correct agents; intermittent connectivity or misconfigured Arc agents will reduce assessment fidelity and could lead to incomplete coverage.
• Overreliance on scans. Passing CIS checks is necessary but not sufficient — runtime defenses, software patching, vulnerability management, and monitoring must remain operational priorities to close real risk.

---

Recommended Adoption Roadmap for IT Leaders​

A disciplined, staged approach will reduce risk and help teams get value quickly:

• Pilot (4–8 weeks). Select a representative subset of systems (web servers, app servers, test DB servers) and enable the policy in audit mode only to measure noise and mismatches.
• Parallel validation. Run Azure’s built‑in assessment alongside your existing CIS scans (CIS‑CAT Pro or vendor tools) to produce an apples‑to‑apples comparison and catalogue rule variances.
• Prioritize L1 first. Treat L1 as the production baseline. Evaluate L2 selectively and stage rollout with rollback plans for each application class.
• Create remediation playbooks. Build runbooks and CI/CD automation that can remediate findings once auto‑remediation ships. Ensure change control, rollback capability, and testing gates are in place.
• Integrate with operations. Forward audit findings into existing ticketing and SRE workflows, assign remediation owners, and track KPIs like Mean Time To Remediation (MTTR).
• Measure, tune, and iterate. Use the pilot data to tune parameters, create exceptions, and refine enforcement before expanding the policy to larger estates.

---

How the Claim Set Was Verified (Transparency and Cross‑Checks)​

Key technical claims in this announcement were verified against multiple independent sources to ensure accuracy:

• The built‑in policy name, preview status, supported distributions, audit‑only behavior, and the azure‑osconfig certification were confirmed in Microsoft’s official Azure Policy Machine Configuration documentation.
• The announcement and industry distribution (press syndication) were reflected in public press releases and industry feeds summarizing the joint CIS/Microsoft messaging.
• CIS’s broader relationship with Microsoft (and prior integrations to Microsoft Defender for Cloud) adds context to this deeper integration and was confirmed through CIS communications and Microsoft‑CIS partnership history.

Where the user supplied a specific syndicated press link that was temporarily inaccessible to verification tooling, the same claims have been confirmed against the Microsoft product documentation and other published announcements; any content unique to the inaccessible press release is flagged as unverified pending retrieval.

---

Operational Examples and Practical Notes​

• A security team can assign the built‑in policy to a subscription or management group and select target distributions and profiles; results appear as compliance state in Azure Policy and can be exported to Log Analytics for dashboarding and alerting. The policy supports custom parameters per rule to reduce noisy alerts where business constraints require specific exceptions.
• Custom images are supported if /etc/os‑release remains intact, which is a common caveat for cloud hardened images built from nonstandard packaging processes. Teams using heavily customized golden images should validate OS detection and run a sample assessment before broad assignment.
• Where L2 recommendations require disabling features used by third‑party applications, coordinate with ISVs and use staged enforcement windows and backout plans to avoid outages.

---

Strategic Implications for WindowsForum Readers and Enterprise Teams​

• For organizations standardizing on Azure, this integration reduces the maintenance burden of running and mapping canonical CIS checks, helping make continuous compliance more operationally realistic.
• For hybrid IT shops, Azure Arc’s ability to bring the same baseline across on‑premises and multi‑cloud servers creates a single source of truth for CIS posture — simplifying audits and governance reporting.
• For auditors and compliance officers, the CIS Benchmark Assessment Certification for azure‑osconfig is an important signal: cloud‑native scanning can — in principle — match the fidelity of traditional on‑premises CIS assessments when implemented carefully.

---

Final Assessment and Takeaways​

Microsoft’s addition of built‑in, CIS‑certified Linux Benchmarks to Azure Policy’s Machine Configuration is a meaningful operational milestone: it reduces the friction of running canonical CIS assessments at scale and brings hybrid fleets under a single, auditable compliance pipeline. The azure‑osconfig engine’s direct ingestion of CIS machine‑readable artifacts and Microsoft’s declaration of CIS certification for the supplied mappings are the most consequential technical achievements in this release. That said, this is a preview and audit‑only feature at release. Organizations should treat it as an improved visibility and governance capability rather than a production enforcement mechanism until auto‑remediation behavior, GA service SLAs, and long‑term support expectations are clarified. A cautious, staged adoption plan — pilot, reconcile, integrate, automate, enforce — will deliver the greatest value while minimizing disruption. The arrival of built‑in CIS Linux baselines inside a major cloud provider’s governance plane is an important step toward more standardized, cloud‑native security posture management. For teams that already use CIS Benchmarks, Azure’s new capability should be evaluated quickly: it’s a practical way to reduce operational overhead and improve audit readiness, provided the limitations of preview status and audit‑only behavior are respected during rollout.

---

Conclusion
Making CIS Benchmarks a first‑class citizen inside Azure Policy is a practical, well‑targeted enhancement that aligns with modern security operations goals: continuous assessment, single‑pane visibility, and hybrid consistency. It does not replace the need for rigorous operational security, but it does make the canonical baseline easier to apply and report on at scale. Teams should move deliberately — pilot, validate, and automate — and treat this feature as a powerful visibility tool that will become even more compelling when remediation capabilities reach GA.

---

Source: CW39 Houston https://cw39.com/business/press-rel...-benchmarks-now-available-on-microsoft-azure/

 

[ChatGPT]

Microsoft Azure now exposes the official Center for Internet Security (CIS) Linux Benchmarks as a built‑in capability inside Azure Policy’s Machine Configuration, delivered by Microsoft’s new azure‑osconfig compliance engine and released in Preview as an audit‑only, CIS‑certified assessment capability for a broad set of Linux distributions — a change that turns a formerly fragmented compliance workflow into a first‑class, cloud‑native “compliance as code” pipeline for Azure and Azure Arc‑connected hybrid fleets.

---

Background​

The Center for Internet Security (CIS) Benchmarks are community‑driven, vendor‑agnostic configuration standards used worldwide to harden operating systems and common server workloads. They publish machine‑readable artifacts (XCCDF and OVAL) and two primary implementation profiles:

• Level 1 (L1): essential hardening that minimally impacts usability
• Level 2 (L2): more stringent settings intended for high‑assurance environments but with greater operational impact

Organizations have historically implemented CIS checks with third‑party scanners, CIS‑CAT Pro, or bespoke scripts and orchestration — approaches that require ongoing mapping, distribution‑specific tuning, and extra maintenance. The new Azure integration aims to reduce that operational lift by making CIS checks an Azure‑native policy assignment, run continuously and reported centrally.

---

What Microsoft and CIS Announced​

The headline facts​

• The feature is available in Preview as the built‑in policy named [Preview]: Official CIS Security Benchmarks for Linux Workloads within Azure Policy → Machine Configuration. Administrators can assign the definition to subscriptions, management groups, or resource scopes and select distribution/profile pairings to evaluate.
• The runtime that evaluates machines is the azure‑osconfig compliance engine. Microsoft states the engine “has satisfied the requirements of CIS Certification” and is CIS Benchmark Assessment Certified for the listed benchmark mappings.
• At initial release the capability is audit‑only (it reports compliance state but does not perform automatic remediation). Microsoft has signaled that auto‑remediation is planned for future releases.
• The feature supports a representative cross‑section of enterprise Linux distributions (Ubuntu, Red Hat, AlmaLinux, Rocky, Oracle Linux, Debian, SUSE and others), each mapped to specific CIS benchmark versions with L1 and L2 profiles where applicable. Azure’s documentation lists the definitive matrix of distro/version pairings and mapped benchmark versions.
• The capability extends to hybrid and on‑premises machines that are registered with Azure Arc and have the required agents/extensions installed, enabling a single compliance pipeline across cloud and hybrid estates.

These announcements were reflected in vendor press coverage and a CIS statement announcing built‑in Linux benchmark availability for Azure. Note that the product documentation and the CIS communications are the authoritative references for supported mappings and certification claims.

---

How the built‑in assessment works — technical flow​

Ingest, evaluate, report​

The azure‑osconfig engine ingests canonical CIS machine‑readable artifacts (XCCDF and OVAL), maps each benchmark rule to executable checks, and evaluates the target machine’s current state against the canonical rule logic. Results are surfaced as Azure Policy compliance events and can be exported to Azure Monitor / Log Analytics or forwarded into SIEM and ticketing systems for operational follow‑up. This design is intended to reduce the common implementation drift that occurs when organizations or third‑party vendors hand‑map CIS rules.

Parameterization and customization​

The evaluation engine supports dynamic parameters so organizations can tune thresholds or create exceptions for specific rules without editing the underlying benchmark artifacts. This makes it possible to preserve canonical auditability while adapting to legitimate business needs (for example, differing password rules for legacy applications). Custom images are supported provided their /etc/os‑release retains recognizable distribution/version identifiers so azure‑osconfig can map the system to the correct benchmark.

Integration points​

• Azure Policy → Machine Configuration is the management surface for assignment and view.
• Compliance telemetry integrates with Azure Monitor / Log Analytics, enabling operational dashboards, alerting, and ingestion into existing SRE/SOC pipelines.
• Arc‑registered machines can be evaluated continuously, enabling multi‑cloud and on‑premises consistency when prerequisites are met.

---

Supported distributions and profiles (Preview)​

Microsoft’s documentation lists supported distribution/version pairings and the CIS Benchmark versions mapped to them. Representative preview entries include:

• Ubuntu 22.04 LTS + Pro — CIS Ubuntu 22.04 Benchmark v2.0.0 — L1 + L2 (audit supported).
• Ubuntu 24.04 LTS + Pro — CIS Ubuntu 24.04 Benchmark v1.0.0 — L1 + L2.
• Red Hat Enterprise Linux 8 / 9 — mapped to the appropriate CIS RHEL benchmark versions — L1 + L2.
• AlmaLinux / Rocky / Oracle Linux (8/9) — vendor mappings to equivalent CIS benchmark versions — L1 + L2.
• Debian 12 — CIS Debian benchmark v1.1.0 — L1 + L2.
• SUSE Linux Enterprise 15 — CIS SLE benchmark v2.0.1 — L1 + L2.

This is a representative sample; the definitive matrix — including exact benchmark versions, supported marketplace image SKUs, and limitations — is available in Azure’s documentation and should be consulted before assigning policies at scale.

---

Notable strengths — why this matters for security and operations​

• Lower operational friction: Built‑in, CIS‑certified policies remove the need to deploy, maintain, and map third‑party scanning tools across every host. This reduces engineering overhead for large fleets.
• Closer parity with canonical CIS: Because azure‑osconfig consumes the canonical XCCDF/OVAL artifacts, Azure‑reported pass/fail outcomes are intended to align more closely with CIS’s official text — an important trust signal for auditors.
• Hybrid reach: Azure Arc support lets teams apply the same canonical baseline across cloud, on‑premises, and supported multi‑cloud machines, simplifying governance for hybrid estates.
• Scalability and integration: Assignments through Azure Policy, combined with telemetry exports to Azure Monitor / Log Analytics, let enterprises fold CIS results into existing ticketing, SOAR, and reporting workflows without bespoke glue code.
• Planned remediation: Microsoft’s stated roadmap includes auto‑remediation in a future release, which would enable faster closure of findings via cloud workflows and CI/CD pipelines (when available). Until then the tool is a high‑fidelity visibility and governance instrument.

---

Potential risks, limitations, and realistic caveats​

The new capability solves many operational problems, but it’s not a silver bullet. Practitioners must understand the practical limits and pitfalls:

• Audit vs. remediation: In Preview the feature is audit‑only. Passing audits improves visibility but does not change system configuration. Relying solely on audit results without remediation workflows leaves risk unaddressed. Microsoft has indicated remediation is planned; organizations should not assume it’s available until GA.
• Preview instability and API changes: As with any preview feature, behaviors, APIs, and mappings can evolve before GA. Automation built tightly to preview outputs may require rework. Treat preview assignments as exploratory until GA guarantees are in place.
• False positives and mapping differences: Even with CIS certification, implementation differences and environment specifics can yield mismatches or noisy alerts. Expect a reconciliation phase to align Azure’s assessment with existing tooling (CIS‑CAT Pro, vendor scanners). Conduct parallel scans during pilot phases.
• Operational impact of L2: Level 2 recommendations sometimes change services or behaviors in ways that affect application compatibility and uptime. L2 should be treated as a controlled program rather than a default for production.
• Agent and Arc dependencies: Hybrid/Arc coverage depends on installing and maintaining Azure agents/extensions. Intermittent connectivity or misconfigured Arc agents will reduce assessment fidelity. Verify Arc health before trusting fleet‑wide compliance numbers.
• Third‑party and ISV compatibility: Some CIS controls require disabling or changing services that third‑party applications expect. Validate with ISVs before enforcing baselines on certified workloads.

Where claims diverge between vendor marketing and public documentation, treat marketing statements as directional and rely on the official technical documentation for operational decisions. If the CIS press release or reseller PR includes claims not supported in Microsoft’s docs, flag those as unverified until the vendor updates product documentation.

---

Practical adoption roadmap — step‑by‑step​

• Inventory and baseline: Map which Azure images, marketplace SKUs, and custom images you run. Verify /etc/os‑release contents for custom images so azure‑osconfig can map them correctly.
• Pilot (audit‑only): Assign the built‑in policy to a small, representative scope (dev/test and a few production candidates) in audit mode. Collect telemetry for 2–4 weeks to assess noise.
• Run parallel scans: Compare Azure’s results with current CIS scans (CIS‑CAT Pro or commercial scanners) to catalog rule mismatches and false positives. Record exact rule IDs and rationale for exceptions.
• Tune parameters and exceptions: Use the policy’s dynamic parameters to create acceptable exceptions where business needs diverge. Keep a documented, auditable trail for each exception.
• Create remediation playbooks: Build runbooks and CI/CD automation for remediation tasks so that when auto‑remediation arrives you can flip from detection to controlled, audited fixes. Include rollback steps and change control.
• Integrate with SOC/SRE workflows: Export findings to Log Analytics and your SIEM/ticketing systems. Assign operational owners and SLAs for remediation.
• Stage L2 adoption: Treat L2 adoption as a staged program; pilot on non‑critical workloads before broader rollout. Validate application compatibility at each step.
• Measure and iterate: Track KPIs (time to remediation, compliant hosts %, exceptions per rule) and use them to prioritize future automation and training investments.

---

Pricing, licensing, and legal points to check​

• The Azure Policy Machine Configuration surface that hosts the built‑in CIS baselines is in Preview, and preview features are subject to Microsoft’s supplemental terms for Azure Previews. Check those terms before relying on the feature for contractual compliance attestations.
• CIS Benchmarks content is published by CIS; some downstream artifacts or automated remediations (CIS Build Kits, CIS‑CAT Pro exports) may be gated behind CIS SecureSuite subscriptions. Confirm whether any remediating artifacts or commercial tooling you use require a CIS membership or paid license. CIS continues to publish benchmark updates on its portal and in monthly update pages.
• If you reference certified assessments in audit reports, keep snapshots of the Azure documentation version and the policy mapping you used — preview and GA behavior may differ. The Microsoft documentation page includes a release timestamp and version information; capture those as artefacts for audit evidence.

If any press release or partner announcement includes claims absent from the Microsoft documentation or the CIS published benchmarks, flag those claims and wait for corroboration in the official docs before certifying controls for compliance evidence.

---

Real‑world considerations and scenarios​

For cloud‑native teams (SRE/SecOps)​

This integration reduces the number of moving parts in a compliance pipeline. Rather than maintaining bespoke scripts or multiple scanning agents, you can centralize assessment and feed results into existing observability. However, teams must still own remediation (until auto‑remediation ships), vulnerability management, and runtime detection.

For audit and compliance teams​

Azure’s CIS certification for azure‑osconfig is a welcome signal; auditors will still want to see documented evidence that the exact benchmark version, policy mapping, and evaluation date match the audit window. Keep evidence exports and maintain a reconciliation log between Azure results and any external CIS scans you’ve used historically.

For hybrid and regulated environments​

Azure Arc extends reach into on‑premises estates, but it adds lifecycle and connectivity dependencies. For regulated systems with intermittent connectivity constraints or air‑gapped networks, the built‑in capability may not be able to provide continuous assessment — plan for local scan fallbacks and clearly document gaps for auditors.

---

Where to look for authoritative details​

The authoritative source for how the built‑in capability functions, what distributions are supported, and the certification claim is the Microsoft Learn documentation page for CIS Security Benchmarks for Linux Workloads (Preview), which lists supported distributions, the policy name, preview limitations, and the statement that the azure‑osconfig engine is CIS Benchmark Assessment Certified. CIS’s public benchmark update pages list current benchmark versions and tooling updates that Microsoft consumes. For vendor messaging or press summaries, treat press releases as directional and confirm operational details against the Microsoft docs before making compliance decisions.

---

Conclusion​

Embedding official CIS Linux Benchmarks directly into Azure Policy and evaluating them with the azure‑osconfig compliance engine is a significant operational step toward standardizing how organizations assess host hardening in cloud and hybrid environments. The move reduces friction, improves parity with canonical CIS text, and gives SRE, SecOps, and audit teams a single control plane for continuous, audit‑grade visibility.
That said, the capability is Preview and audit‑only today — not a turnkey remediation system — so prudent enterprises should pilot carefully, reconcile Azure results with existing CIS scans, and prepare remediation playbooks before depending on the feature for compliance enforcement. When auto‑remediation arrives and the feature reaches GA, the combination of built‑in assessments, parameterization, and Arc reach will materially change how Linux security baselines are managed at scale in Azure.

---

Source: KLAS 8 News Now https://www.8newsnow.com/business/p...-benchmarks-now-available-on-microsoft-azure/