Azure governance guardrails

Azure governance guardrails: the two planes that keep an estate in line

Q: What is the difference between Azure Policy and Conditional Access?

They are two different governance planes. Azure Policy governs resources — what may be created and how it must be configured (allowed regions, required tags, no public IPs, diagnostic settings on). Microsoft Entra Conditional Access governs identity — who can sign in and under what conditions (require MFA, block legacy authentication, require a compliant device). A common mistake is trying to enforce MFA with Azure Policy; MFA enforcement lives in Conditional Access, while Azure Policy can audit and enforce the resource-side controls.

Q: Can Azure Policy enforce MFA?

No. Multi-factor authentication is an identity control, so it is enforced by Microsoft Entra Conditional Access, not Azure Policy. Azure Policy governs Azure resource configuration — it can deny a public IP, require a tag, restrict regions, or enforce diagnostic settings, but it does not evaluate sign-ins. Use Conditional Access for MFA and legacy-auth blocking, and Azure Policy for the resource guardrails around them.

Q: What is a custom Azure Policy definition?

A custom Azure Policy definition is a JSON rule you write when the built-in policies do not cover your requirement. It has a policy rule with an if condition that matches resource properties and a then effect — Audit, Deny, DeployIfNotExists, or Modify. You assign it at a management group, subscription, or resource group scope, and it evaluates every resource in that scope at creation and on an ongoing compliance scan.

Q: How do I audit sign-in activity in Azure?

Route the Microsoft Entra sign-in and audit logs to a durable destination using diagnostic settings — a Log Analytics workspace for querying, and optionally a storage account for long-term retention or an event hub for a SIEM. The logs in the portal are retained only for a limited window, so exporting them via diagnostic settings is what gives you real login auditing, alerting, and the history an investigation needs.

By Captain O7 min read

"Guardrails" is one word for two different systems. Azure Policy governs the resources; Conditional Access governs the identities. Get the split straight and every governance question — including the ones people wrongly aim at the wrong tool — sorts itself out.

New to cloud? CAMPUX is a free, build-first course. Start here →

Azure governance runs on two enforcement planes. Azure Policy decides what resources may exist and how they must be configured — allowed regions, required tags, no public IPs, diagnostic settings on. Microsoft Entra Conditional Access decides who may sign in and under what conditions — require MFA, block legacy authentication, demand a compliant device. Enforcing MFA is Conditional Access, not Azure Policy; that single distinction resolves most governance confusion. This hub is the map of both planes and the guides that go deep on each guardrail.

Every real Azure estate drifts without guardrails: someone spins up a resource in the wrong region, a storage account goes public, an admin signs in from anywhere with just a password. The fix isn't watching more dashboards — it's encoding the rules so the platform enforces them for you. Two services do that, and the most common governance mistake is asking one of them to do the other's job.

The two planes, side by side

	Azure Policy	Conditional Access
Governs	Resources & their config	Sign-ins & identities
Answers	"What may exist, configured how?"	"Who can sign in, under what conditions?"
Examples	Allowed regions, required tags, deny public IP, enforce diagnostics	Require MFA, block legacy auth, require compliant device
Effects	Audit, Deny, DeployIfNotExists, Modify	Grant, block, require controls
Scope	Management group / subscription / resource group	Users, groups, apps, conditions

Read that as a division of labour, not a rivalry. Policy keeps the resources inside the lines; Conditional Access keeps the identities inside the lines; and a third discipline — auditing — proves both are actually working. The clusters below go deep on each.

Policy governs the things. Conditional Access governs the people. Auditing proves you were right.

Go deeper: identity guardrails (Conditional Access)

The identity plane is where account takeover is won or lost. Enforce strong authentication, close the protocols that route around it, and elevate privilege only when it's needed — these are the controls Conditional Access and Entra apply to every sign-in.

Go deeper: resource guardrails (Azure Policy)

The resource plane is where cost, exposure, and compliance drift live. Restrict where things can be built, require the tags that make cost and ownership legible, and deny the configurations — public IPs, missing diagnostics — you never want to see. This is Azure Policy's home turf, custom definitions included.

Go deeper: audit & visibility

A guardrail you can't see working isn't one you can trust. Route the sign-in and activity logs somewhere durable, and use Policy itself to guarantee every resource is emitting the diagnostics an investigation would need. This is the evidence layer under both planes.

Where to start

If you're standing an estate up from scratch, do them in this order: turn on the identity guardrails first (MFA via Conditional Access, block legacy auth) because that's where the highest-probability attack is; wire up log export next so you can see what's happening; then layer Azure Policy resource guardrails on as you learn which drift actually hurts you. Guardrails added all at once tend to get switched off in a panic the first time one blocks a legitimate deploy — roll them out in Audit mode, watch, then move to Deny.

Questions people also ask

What is the difference between Azure Policy and Conditional Access?

Two governance planes. Azure Policy governs resources — what may be created and how it's configured (regions, tags, public IPs, diagnostics). Conditional Access governs identity — who can sign in and under what conditions (MFA, legacy auth, device state). Enforcing MFA is Conditional Access, not Azure Policy.

Can Azure Policy enforce MFA?

No — MFA is an identity control enforced by Conditional Access. Azure Policy governs resource configuration: it can deny a public IP, require a tag, restrict regions, or enforce diagnostic settings, but it doesn't evaluate sign-ins.

What is a custom Azure Policy definition?

A JSON rule you write when built-in policies don't cover your need: an if condition matching resource properties and a then effect (Audit, Deny, DeployIfNotExists, Modify), assigned at a management group, subscription, or resource-group scope and evaluated on creation and on ongoing compliance scans.

How do I audit sign-in activity in Azure?

Route the Entra sign-in and audit logs to a durable destination via diagnostic settings — Log Analytics for querying, storage for retention, an event hub for a SIEM. The in-portal logs are kept only briefly, so exporting them is what gives you real login auditing and history.