Azure Policy Security Baseline in Practice

Last Updated on August 1, 2026 by Arnav Sharma

Most organisations assign a security baseline, watch the compliance percentage climb into the eighties, and conclude the work is done. It is not. Putting an Azure Policy security baseline in practice means confronting an uncomfortable truth: a high compliance score in Microsoft Defender for Cloud tells you how well you are reporting, not how well you are enforcing. Those are different things, and conflating them is the single most common failure in Azure security posture management.

This article covers what happens when a baseline meets a real estate. It assumes you have read the Microsoft Learn reference pages and found them referential rather than operational. What follows is the operating model: how to scope the assignment, how to promote controls from audit to enforcement without breaking your own pipelines, how to extend coverage from the control plane to the guest operating system, and how to keep the whole thing from decaying into dashboard noise.

The Compliance Illusion: Why a Green Dashboard Proves Very Little

What the Microsoft Cloud Security Benchmark Actually Assigns

The Microsoft cloud security benchmark is assigned by default to every Azure subscription. It is the default regulatory compliance standard in Microsoft Defender for Cloud, and it functions as the reference framework from which the per-service Azure security baseline documents are derived. When Microsoft publishes an Azure security baseline for a given service, that document maps the service’s features against the security controls defined by the benchmark, and lists the relevant Azure Policy definitions that let you measure compliance against those benchmark controls.

That mapping is genuinely useful as a coverage inventory. It is a poor substitute for an enforcement strategy, and it was never designed to be one. The benchmark spans the full breadth of Azure services, from Azure SQL Database and Azure Kubernetes Service through to Azure Virtual Networks, and the per-service Azure security baseline documents inherit that breadth.

A terminology note before going further, because the naming has churned and stale search results will mislead you. Azure Security Center is now Microsoft Defender for Cloud. Azure Defender is now the Defender plan model inside it. Azure Active Directory, often abbreviated Azure AD, is now Microsoft Entra ID. If you are reading a Microsoft Azure security best practice guide that still uses the old names, check its date before you act on it, because the underlying security configurations it recommends may have moved too.

There is a subtlety worth flagging before you build anything on top of it. Many of the published per-service baseline documents on Microsoft Learn now carry an explicit notice that they are based on Microsoft cloud security benchmark version 1.0 and may contain outdated guidance, with readers pointed toward the current service documentation for the latest security guidance. The security baseline mapping file for a service remains the authoritative view of how that service maps to the benchmark, but treat the prose in those pages as a snapshot, not a live standard. If you built your control set from a baseline page eighteen months ago and have not revisited it, you are governing against a frozen benchmark.

The Effect Gap Between Definition and Initiative

Here is the mechanism behind the illusion, and most teams never inspect it.

An Azure Policy initiative is a container of policy definitions that exposes parameters controlling how those definitions behave when assigned. Crucially, the effects exposed in an initiative’s parameters do not always match the effects available in the underlying policy definition. Valorem Reply documented this precisely, using the built-in policy requiring Azure Key Vault to have firewall enabled or public network access disabled. Inspect the standalone definition and a deny effect is available. Inspect the same policy as consumed inside the Microsoft cloud security benchmark initiative, and the deny effect is gone.

This is deliberate. Built-in initiatives are tuned toward audit rather than deny so they work across the broadest set of customers without breaking anyone’s deployments. A sensible default for a platform vendor with millions of tenants. A serious problem for you if you assumed the initiative named “security benchmark” was doing what its name implies.

The practical consequence: many built-in policy definitions ship inside initiatives with only audit or auditIfNotExists effects, even where the definition supports deny. Your baseline generates compliance findings rather than preventing misconfigurations. The security recommendation surfaces, someone triages it, someone chases the resource owner, and the misconfiguration lives in production for the duration of that loop. You have not built a guardrail. You have built a very expensive report.

Take a concrete case. Requiring every subnet to carry a network security group is a foundational network security control. There is a built-in definition for it and it supports deny. If that definition sits inside your assigned initiative at audit, then a subnet without a network security group is still deployed. You get a finding. You do not get a control. Multiply that across missing security updates, unencrypted storage, and public endpoints, and the gap between what your dashboard claims and what your estate does becomes very wide.

Action: before trusting any azure policy assignment, enumerate the actual effect in force for every definition inside your assigned initiative, not the effect the definition is capable of. This is the first task in putting a baseline into practice, and almost nobody does it. Using Azure Resource Graph to query policy state at scale is far faster than clicking through the portal.

Two Planes, Two Baselines

A second structural misunderstanding compounds the first. The word “baseline” is doing double duty across two entirely different enforcement planes, with different capabilities and different failure modes.

Dimension	Control plane	Guest plane
Enforcement point	Azure Resource Manager, at deployment	Inside the operating system, after deployment
Mechanism	Azure Policy engine, policy definitions and initiatives	Machine Configuration, formerly Azure Policy guest configuration
Can it block?	Yes, deny effect rejects the deployment	No, assessment and audit only
Evaluation model	Point in time, at create or update, plus periodic scan	Continuous reassessment against desired state
Typical failure	Deny effect never enabled, so nothing is blocked	Drift accumulates silently between scans
Scope	Azure resources under a subscription or management group	Windows and Linux machines, including Azure Arc-enabled servers

Control Plane: The Policy Engine at Deployment Time

This is the plane most people mean when they say Azure Policy. Effects are the entire game here, and the taxonomy matters:

• Deny. Blocks the resource operation outright. The deployment fails with an explicit error. This is the only effect that actually prevents a misconfiguration.
• Audit. Logs a compliance event and allows the operation. Visibility without enforcement.
• AuditIfNotExists. Checks whether a related resource exists, such as a diagnostic setting, and flags non-compliance if it does not.
• DeployIfNotExists. Automatically deploys the missing component. Requires a managed identity on the policy assignment.
• Modify. Adds, updates, or removes properties during create or update. Common for injecting required tags or enforcing transport layer security minimums.
• Disabled. Not evaluated. Useful for staging a definition without effect.
• Manual. Requires human attestation.

Microsoft’s guidance is to start with audit or auditIfNotExists rather than an enforcement effect, so you can observe how a definition affects existing resources before it starts rejecting deployments. That guidance is correct. The problem is that most organisations follow the first half and never execute the second. The audit stage is supposed to be a phase. In most estates it has become a permanent condition.

Guest Plane: Machine Configuration and the Drift Problem

Azure Policy guest configuration, now called Azure Automanage Machine Configuration, is what audits settings inside the operating system: password policy, service state, file permissions, kernel parameters, TLS configuration. It is how you assess a virtual machine against the Azure compute security baseline or a Center for Internet Security benchmark.

Three properties of the guest plane trip people up constantly.

First, it cannot deny. There is no mechanism by which Machine Configuration prevents a misconfiguration inside a running operating system. It assesses, it reports, and in configuration mode it can remediate. It cannot block.

Second, it requires the Azure Monitor Agent and the Machine Configuration extension, plus a system-assigned managed identity on the machine. If either is missing, the machine does not report, and a machine that does not report does not appear as non-compliant. It appears as nothing. Silent coverage gaps are the most dangerous failure mode in any security program, because they are invisible by construction.

Third, drift here is continuous rather than transactional. A control-plane misconfiguration happens at a discrete moment: someone deployed an Azure Virtual Machine without disk encryption. A guest-plane misconfiguration happens because an administrator disabled a service at 2am during an incident and never re-enabled it. The control plane needs a gate. The guest plane needs a loop.

Scoping the Policy Assignment Before You Touch an Effect

Management Group Placement and the Exemption Tax

The scoping principle is straightforward and widely ignored: define at a high scope, assign at the lowest scope that still achieves consistent enforcement.

Microsoft recommends creating policy definitions at higher levels, such as the management group, then creating the assignment at a child level such as a subscription or resource group. The reason is structural. A definition at the management group can be assigned narrowly. A definition scoped too tightly cannot be reused broadly.

The policy assignment scope decision carries a downstream cost nobody prices in at design time. Call it the exemption tax. Every scope that is too broad generates exemption requests, and every exemption is permanent governance debt that someone must review, justify, and revalidate. Assign a strict deny initiative across an entire Azure subscription estate on day one and you will spend the next quarter processing exemptions rather than improving your security posture. Assign narrowly, prove the control, then widen.

A workable topology for most estates:

• Tenant root or intermediate root: definitions and initiative definitions only. No enforcement assignments.
• Platform management group: full baseline, enforced. This is your own infrastructure, so there is no excuse for exemptions.
• Landing zone management group: baseline assigned, with effects staged per the promotion model below.
• Sandbox management group: audit only, no deny. Sandboxes exist so that people can break things safely. A denied sandbox is a shadow IT generator.

Identity and Permissions: Resource Policy Contributor and Managed Identities

Two identity considerations gate everything.

The Resource Policy Contributor role in Azure role-based access control is what allows a principal to create and assign policy at a scope. Keep that population deliberately small. Azure RBAC and Azure Policy are complementary: Azure RBAC governs who can act, Azure Policy governs what the resulting resource is allowed to look like. A common architectural error is assuming tight Azure RBAC makes policy redundant. It does not. A user with legitimate contributor rights can still deploy a non-compliant resource, and that is precisely the security risk the baseline exists to close.

Second, any remediating effect, DeployIfNotExists or Modify, requires a managed identity on the policy assignment with sufficient permissions at the assignment scope. Grant least privilege. A policy assignment that only deploys a diagnostic setting does not need Contributor at the subscription. Remediation identities are high-value targets: they hold standing write permissions across broad scope by design, which makes them exactly the kind of non-human identity an attacker hunts for after initial access.

The Four-Gate Promotion Model: Audit to Deny Without Breaking Production

This is the operating model that the reference documentation does not give you. Moving a control from observation to enforcement is not a switch flip, it is a staged promotion with explicit exit criteria at each gate.

Gate	Effect in force	Purpose	Exit criterion
1. Observe	Audit or AuditIfNotExists	Establish the true non-compliance population	Compliance data stable across two full evaluation cycles, and the non-compliant resource count is understood, not just measured
2. Remediate the backlog	Audit, plus remediation tasks or DeployIfNotExists	Drive existing non-compliance toward zero before you gate new deployments	Residual non-compliance is only resources with an approved, documented exemption
3. Shadow enforce	Deny, with enforcementMode set to DoNotEnforce	Evaluate the deny effect against live deployment traffic without blocking it	One full release cycle with zero unexpected would-be denials from legitimate pipelines
4. Enforce	Deny, enforcementMode Default	Prevent the misconfiguration at deployment	Steady state. Monitor denial events as a signal, not as noise

Gate 3 is the one that makes this model work, and it is the one nobody uses. Azure Policy supports an enforcement mode of DoNotEnforce, in which the policy still evaluates resources for compliance but the effect is not enforced, so a deny policy behaves as audit-only. That gives you something extremely valuable: a rehearsal. You can see exactly which deployments a deny effect would have blocked, over a real release cycle, with real pipelines, before any of them actually break.

Skipping Gate 3 is why “we turned on the security baseline and it broke the platform team’s deployments” is such a common story. The failure was not the deny effect. The failure was going from Gate 2 straight to Gate 4.

Gate 1: Observe

Assign the initiative in audit mode at the target scope and wait for a full evaluation cycle. Resist acting on the first compliance report, because it is measuring your data quality as much as your security configuration. Machines missing agents, resources mid-migration, and subscriptions with incomplete Defender plan coverage all distort the picture. The output of Gate 1 is not a compliance percentage. It is a list of specific non-compliant resources with named owners.

Gate 2: Remediate the Backlog

You cannot gate the front door while the house is full of non-compliant resources. Deny evaluates on create and update, so a non-compliant virtual machine that nobody touches will sit quietly until someone changes a tag on it and the deployment is rejected for an apparently unrelated reason.

Work the backlog first. Use remediation tasks for anything a DeployIfNotExists policy can fix, such as diagnostic settings, Microsoft Defender for Endpoint deployment, or Azure Backup enablement. Everything else goes to the owner with a deadline.

Gate 3: Shadow Enforce

Set the effect to deny and the assignment’s enforcementMode to DoNotEnforce. Run one complete release cycle, then query the compliance data for resources that would have been denied. Every hit here is a conversation you get to have before it becomes an outage.

Gate 4: Enforce

Flip enforcementMode to Default. The control is live. From this point, a denial event is a security signal worth routing to Microsoft Sentinel, because a well-run pipeline should not be attempting non-compliant deployments.

Putting the Azure Policy Security Baseline in Practice on Compute

Compute is where the baseline gets real, and it is where the tooling changed materially in 2026.

Customizable Security Baselines for Windows and Linux

For years the guest baseline story was take-it-or-leave-it: you could audit against the built-in benchmarks, but tailoring them to your organisation’s standards was awkward. That constraint is being lifted.

Microsoft has announced public preview support for Customizable Security Baselines in Azure Policy and Machine Configuration. The capability lets you tailor industry security benchmarks, such as Center for Internet Security benchmarks for Linux or the Azure security baselines for Windows and Linux, to align with your organisation’s own compliance standards, across both native and Arc-connected machines. You can create, parameterise, and assign custom baselines at scale, with continuous compliance visibility across the environment.

The workflow, per the Microsoft documentation, runs as follows:

1. Select a baseline from the Machine Configuration blade under Azure Policy in the Azure portal.
2. Modify the settings: enable, exclude, or parameterise individual rules to match your internal security requirements.
3. Download the JSON file representing the configured baseline.
4. Assign the baseline policy using the Azure portal, the CLI, or a CI/CD pipeline.
5. Review compliance results through Azure Policy, Azure Resource Graph, or the Guest Assignments page.

Note the prerequisite: the Machine Configuration prerequisite policy initiative must be deployed before any of this works. That initiative is what ensures the agent and managed identity are present. Deploy it first, at the same scope, or your baseline assignment will report against an empty population.

This collapses a long-standing gap. Previously, an organisation whose internal security standards diverged from CIS in a handful of controls had two bad options: accept permanent false non-compliance, or abandon the built-in baseline and hand-roll everything. Now the deviation is expressed as a parameter on a maintained baseline, so you inherit Microsoft’s ongoing benchmark maintenance while keeping your own baseline configurations.

Extending to Azure Arc-Enabled Servers

Machine Configuration policy assignments apply to both Azure virtual machines and non-Azure machines that are Azure Arc-enabled servers, extending security and compliance management across hybrid, multicloud, and edge environments. All public Azure regions are supported for the customizable baseline preview, though sovereign cloud support is excluded at this stage.

State the architectural point plainly, because it is the strongest argument for standardising on Azure Policy as your baseline engine rather than a third-party configuration tool: Azure Arc makes the policy engine the single evaluation surface for on-premises servers, machines in other public clouds, and edge estate, using the same definitions, the same initiatives, and the same compliance view. One security management plane, one set of benchmark controls, one dashboard.

Operating the Baseline: Drift, Exemptions, and Re-Baselining

Exemptions as a Managed Asset, Not an Escape Hatch

Every mature baseline accumulates exemptions. The question is not whether you will have them, but whether you can account for them.

Treat each exemption as a controlled asset with four mandatory attributes:

• Scope. The narrowest possible. Exempt the resource, not the resource group. Exempt the resource group, not the subscription.
• Expiry. Every exemption gets an expiration date. A permanent exemption is not an exemption, it is a silent revision to your security standards.
• Justification. A recorded business reason, not a ticket number.
• Owner. A named accountable individual, not a team alias.

Then instrument it. An Azure Monitor alert on the creation of any new exemption, and a scheduled report on exemptions approaching expiry, converts exemption sprawl from invisible erosion into a managed queue. Where you have Microsoft Sentinel deployed, formerly Azure Sentinel, exemption creation is a worthwhile analytics rule: an attacker with sufficient privilege who wants to deploy a non-compliant resource does not fight the deny effect, they exempt themselves from it first. This is the point where policy governance and Microsoft security operations converge, and treating the two as separate disciplines is a mistake. Any alert rules you build should run under a managed identity with least-privilege read access, not a service principal holding a long-lived secret in Azure Key Vault.

Exemption volume is also the best single indicator of whether your use of Azure Policy is calibrated to the estate. A handful of well-documented exemptions is healthy. Hundreds means the baseline is fighting the business, and the correct response is to fix the scope, not to keep granting exceptions.

Re-Baselining on a Benchmark Version Change

Benchmarks version. The Microsoft cloud security benchmark version you assigned is not the version that will be current in two years, and the older per-service baseline pages already carry warnings that they reflect cloud security benchmark version 1.0 and may not represent the latest security guidance.

Build a re-baselining cadence into the operating model rather than treating a version change as a project. On each benchmark version change:

1. Diff the new benchmark controls against the assigned initiative.
2. Identify newly added controls and place them at Gate 1, regardless of how confident you feel. New controls enter the promotion model at the bottom, always.
3. Identify deprecated controls and retire the corresponding assignments rather than leaving orphaned definitions in place.
4. Re-validate every exemption against the new control set. Exemptions written against a control that no longer exists are pure noise.
5. Re-run the effect-gap enumeration from the first section, because Microsoft may have changed which effects the initiative exposes.

Reference Architecture: What a Mature Baseline Looks Like

Layer	Component	Enforcement posture
Definition	Custom and built-in policy definitions, stored at intermediate root management group	Version controlled, deployed via pipeline
Grouping	Azure Policy initiative per governance domain: security baseline, network security, data protection	One initiative per domain, not one giant initiative
Control plane, platform	Baseline initiative, deny effects	Gate 4, fully enforced
Control plane, landing zones	Baseline initiative, mixed effects	Per-control promotion, Gates 1 to 4
Control plane, sandbox	Baseline initiative, audit only	Gate 1 permanently, by design
Guest plane	Machine Configuration, customised Azure compute security baseline	Continuous assessment, remediation where safe
Hybrid	Azure Arc-enabled servers onboarded to the same initiatives	Identical baseline, single compliance view
Visibility	Microsoft Defender for Cloud regulatory compliance, Azure Resource Graph queries	Compliance as a trend, not a snapshot
Detection	Microsoft Sentinel analytics on exemption creation and deny events	Policy events treated as security telemetry

The tell for maturity is not the compliance number. It is whether you can answer, for any single control, which gate it is at and what its exit criterion is. If the answer is “it is in the baseline”, the baseline is not in practice. It is on paper.

Two closing observations. The deny effect is not the destination for every control. Some benchmark controls are better left at audit permanently, because the cost of a false denial exceeds the security value of the block. The four-gate model is a decision framework, not an escalator, and parking a control at Gate 1 with a documented rationale is a legitimate architectural decision.

And the guest plane will always lag the control plane. Plan for that asymmetry rather than fight it. Azure Resource Manager gives you a hard gate. The operating system gives you a feedback loop. Put the non-negotiable security requirements where a gate exists, and accept that everything inside the guest is a matter of detection and mean time to remediate.